Reduce la factura de inferencia un 77-80 %: lista de verificación para la migración
Lista de verificación para comprobar si un modelo más barato y potente reduce el coste efectivo por token tras considerar caché, horas pico, memoria KV, concurrencia, controles de calidad y rollback.
Si ejecutas DeepSeek V4-Pro en producción, el proveedor redirigirá todas las llamadas a la API de V4-Pro a V4.1-Flash el 14 de septiembre de 2026 y las facturará a las tarifas de V4.1-Flash hasta que esté disponible un modelo V4.1-Pro. La compensación es un menor coste por token frente a la exposición en horas pico, la memoria KV y la concurrencia: V4.1-Flash es un 77 % a un 80 % más barato que su predecesor y aumenta la concurrencia de 500 a 2.500 solicitudes. El cálculo parte de la entrada con acierto en caché fuera de horas pico a $0,003 por token, frente a $0,022 del V4-Pro saliente. Los precios en horas pico son el doble que los de fuera de horas pico.
La diferencia de precio es la cuota de entrada
La facturación en horas pico y fuera de ellas cambia la media. El horario, vigente desde el 10 de septiembre de 2026, factura los días laborables de 01:00 a 04:00 y de 06:00 a 10:00 UTC como horas pico; todo lo demás es fuera de horas pico. Si tu carga es mayoritariamente fuera de horas pico, la tarifa efectiva se sitúa cerca del extremo bajo; si está concentrada en esas ventanas de días laborables, el descuento se reduce.
Calcula la tarifa efectiva antes de confiar en el titular. Pondera la entrada con acierto y fallo en caché según la proporción de tokens de entrada que aciertan en caché, y luego aplica la mezcla de horas pico/fuera de pico al resultado. Los tokens de salida suelen dominar la factura en agentes de larga duración, por lo que un pequeño cambio en la tarifa de salida puede mover el total más que un gran cambio en los aciertos de caché. No uses una tarifa mixta única. Tu proporción de aciertos en caché depende de la reutilización de prompts, la longitud del system prompt y los reinicios de sesión. Tu proporción de horas pico/fuera de pico depende de la geografía de los usuarios y los trabajos por lotes. Si cualquiera de las dos mezclas cambia, el coste efectivo por token cambia con ella.
La caché KV y la concurrencia determinan la capacidad
El comportamiento de la caché decide cuánto de la factura de entrada pagas realmente. V4.1-Flash utiliza una caché KV de 890 bytes por token, unas 3,9 veces más pequeña que la generación anterior y más de 400 veces más pequeña que DeepSeek-V1. Un estado KV más pequeño significa que más secuencias concurrentes caben en la misma memoria GPU.
El modelo tiene 552 mil millones de parámetros totales, con 8 mil millones activos para entrada y 16 mil millones activos para salida. Esa división mantiene bajo el cómputo por token y deja margen para contextos largos. Si tu stack anterior estaba limitado por la memoria KV, la caché más pequeña cambia cuántas sesiones puedes mantener activas antes de añadir GPUs.
Mide la memoria por secuencia en tu contexto más largo y luego compara el margen de concurrencia resultante con tu tasa de solicitudes pico. Un modelo que es más barato por token pero te obliga a comprar más capacidad aún puede perder en coste por tarea completada. También comprueba el tráfico por lotes frente al interactivo. Los trabajos por lotes pueden desplazarse a ventanas fuera de horas pico, mientras que el tráfico interactivo puede quedar anclado a las horas pico. El mismo modelo puede ser una ganancia para el tráfico por lotes y una pérdida para el interactivo.
Los benchmarks fijan el control de calidad
Un modelo más barato solo es una ganancia si tus tareas siguen superando el umbral. En pruebas de razonamiento máximo, V4.1-Flash obtuvo 90,6 en Terminal-Bench 2.1, 74,2 en DeepSWE v1.1 y 88,1 en CyberGym, por delante de V4-Pro. DeepSeek afirmó que V4.1-Flash superó a V4-Pro en capacidad, precio, velocidad y tiempo de finalización en pruebas internas y externas.
Tu control debe ser más estricto: tu conjunto de evaluación, tu SLO de latencia y tu presupuesto de fallos. Ejecuta los mismos prompts, herramientas y casos de fallo que usas en producción y luego compara la tasa de éxito, la latencia y el coste por tarea completada. Una victoria en un benchmark no cumple tu SLO si tu tráfico es intensivo en herramientas, de contexto largo o limitado por latencia. El control de calidad debe detener la migración antes de que los usuarios vean la regresión.
Redirige el tráfico solo con un disparador de rollback
El cambio de enrutamiento hace que la migración sea menos opcional para el tráfico existente. Usa la lista de verificación siguiente antes de conmutar el tráfico. Cada elemento se corresponde con un coste o modo de fallo que puede borrar los ahorros.
- Calcula el coste efectivo por token a partir de las tarifas de acierto/fallo en caché y de horas pico/fuera de pico.
- Compara tokens/segundo y hora-GPU frente a tu línea base actual.
- Mide la memoria de la caché KV por secuencia en tu longitud de contexto máxima.
- Verifica el margen de concurrencia frente a tu tasa de solicitudes pico.
- Ejecuta un control de calidad sobre tu conjunto de evaluación de producción.
- Establece un disparador de rollback en latencia, tasa de errores o regresión en evaluación.
Mantén el endpoint antiguo disponible hasta que el nuevo modelo supere el control. Si el coste efectivo por tarea completada aumenta, o si la latencia y las tasas de error superan tus umbrales, haz rollback antes del siguiente ciclo de facturación.