Redirige tu factura de IA tras los precios de pico de DeepSeek
Una lista de verificación práctica para mover la inferencia por lotes, corregir fallos de caché y recalcular la economía unitaria cuando cambian las tarifas por token.
Tu factura de inferencia cambió a las 16:00 UTC del 16 de agosto de 2026, cuando entró en vigor la tarifa revisada de la API V4 de DeepSeek. El costo de entrada con acierto de caché en hora pico de V4-Pro supera la tarifa anterior en un factor de poco más de 12. Si gestionas gasto en IA en producción, el cambio es un problema de enrutamiento: algunas solicitudes pueden esperar, otras no, y la nueva tabla pone precio a esa diferencia. La jugada práctica es programar el trabajo que se puede mover y luego corregir las reglas de caché que determinan si la programación compensa.
La brecha es el peaje de entrada
Las cifras de salida son tajantes. Los tokens de salida de V4-Flash ahora cuestan $0,66 por millón fuera de pico y $1,32 en hora pico, frente a $0.28 antes. Los tokens de salida de V4-Pro cuestan $1,98 fuera de pico y $3,96 en hora pico, frente a $0,87 antes. Las tarifas fuera de pico no están por debajo de los precios anteriores. El descuento es relativo, no absoluto, así que la decisión es qué solicitudes merecen el recargo. Si una solicitud puede esperar, esperar es un descuento. Si no puede, el recargo es un costo del servicio.
Las horas de pico son un mapa de zonas horarias
DeepSeek considera 01:00-04:00 UTC y 06:00-10:00 UTC como su período de pico diario, que abarca siete horas. El recargo se aplica dentro de esa ventana, así que la primera pregunta operativa es si tus trabajos por lotes pueden esperar hasta las horas restantes. Mapea los bloques UTC a las horas locales donde tus usuarios realmente llaman al modelo. Si un trabajo grande se ejecuta en una región donde la ventana cae de madrugada, es posible que estés pagando tarifa de pico por trabajo que podría ejecutarse fuera de pico. Si el mismo trabajo está orientado al usuario, la ventana es una restricción, no una opción.
Los fallos de caché es donde el multiplicador se pone feo
La tarificación de caché es la parte más difícil. Para V4-Pro, el precio de entrada con fallo de caché en hora pico pasa a ser $1.32 por millón de tokens, frente a $0.435 antes. Los prompts largos y repetidos construidos a partir de instrucciones de sistema y ejemplos few-shot pueden hacer que el precio de acierto domine la factura. Un fallo de caché durante la hora pico es el peor caso: pagas la penalización de entrada y aun así no obtienes descuento por reutilización. La solución suele ser estructural. Mantén estables los prefijos estables. Coloca las instrucciones de sistema, los esquemas de herramientas y los ejemplos few-shot antes del contenido variable. Un prompt que cambia en cada solicitud anula la caché. Cuando un prompt es mayormente estable, un fallo es un error.
Realiza estas cinco comprobaciones antes de la próxima factura
La lista de abajo es la parte que puedes ejecutar en una jornada laboral normal. Cada elemento es verificable contra tu cola actual. Si un trabajo no se puede mover, dejas de optimizar su horario y empiezas a optimizar su cantidad de tokens, su nivel de modelo o si debería ejecutarse en absoluto.
- Inventaria trabajos por lotes: abre tu cola de trabajos y marca cada uno como por lotes o orientado al usuario.
- Mapea las horas de pico a las zonas horarias de tus usuarios: marca qué horas locales caen en la ventana de pico del proveedor.
- Desplaza el trabajo por lotes fuera de pico: marca el trabajo por lotes más grande que pueda ejecutarse fuera de la ventana de pico.
- Corrige fallos de caché: encuentra un fallo de caché donde el multiplicador sea más pronunciado, especialmente la entrada con fallo de caché en hora pico de V4-Pro.
- Recalcula la economía unitaria para el tráfico inamovible: verifica un endpoint inamovible contra su margen tras el cambio de tarifa.
El orden importa porque la programación cambia el problema de caché. Un trabajo que se mueve fuera de pico ya puede que no necesite la misma forma de prompt, y un endpoint orientado al usuario que permanece en pico necesita una solución diferente. Ejecuta la lista como un bucle, no como una auditoría puntual: tras mover trabajo, vuelve a verificar la caché y el margen antes de dar la factura por resuelta.
La parte difícil es el tráfico inamovible. Las solicitudes orientadas al usuario que caen en la ventana de pico pagarán el recargo, así que las únicas palancas son la cantidad de tokens, el nivel de modelo y si la solicitud es necesaria. Comprime prompts donde la respuesta no dependa de cada ejemplo. Usa el nivel más barato cuando la calidad lo permita. Si una función solo se invoca durante el pico y solo produce salida de bajo valor, pospónla, agrúpala por lotes o elimínala. El redireccionamiento termina cuando puedes decir qué solicitudes valen el recargo.
