La tarifa de DeepSeek V4 no tiene un único precio durante todo el día. De lunes a viernes hay dos franjas punta: 01:00–04:00 UTC y 06:00–10:00 UTC. El resto del tiempo, incluidos los fines de semana, se cobra como periodo valle y cada tipo de token cuesta la mitad.
En la España peninsular, esas franjas son 03:00–06:00 y 08:00–12:00 mientras rige CEST; con CET pasan a 02:00–05:00 y 07:00–11:00. No basta con programar “por la noche” una vez: el cambio de hora europeo desplaza el reloj local, mientras la regla oficial permanece en UTC.
Los precios de esta guía se comprobaron el 3 de septiembre de 2026 en la tabla oficial de DeepSeek. DeepSeek puede modificarlos. Conviene volver a consultar la fuente antes de aprobar presupuesto o fijar valores en configuración.
Qué se paga realmente en cada franja
La API hospedada separa tres consumos: input que acierta en caché, input que falla la caché y output. Mezclarlos bajo un precio medio de entrada oculta una parte importante de la factura.
| Modelo | Franja | Entrada con acierto de caché | Entrada con fallo de caché | Salida |
|---|---|---|---|---|
deepseek-v4-flash | valle | 0,007 $ | 0,22 $ | 0,66 $ |
deepseek-v4-flash | punta | 0,014 $ | 0,44 $ | 1,32 $ |
deepseek-v4-pro | valle | 0,022 $ | 0,66 $ | 1,98 $ |
deepseek-v4-pro | punta | 0,044 $ | 1,32 $ | 3,96 $ |
Son importes por un millón de tokens en la API oficial con precios en USD. No determinan el coste de un gateway, un marketplace cloud o un despliegue propio de pesos abiertos. Esas vías pueden añadir margen, impuestos, otra unidad de cobro o condiciones distintas. El acceso web y app tampoco es la misma factura que la API.
Flash suele ser el primer candidato para volumen y resultados verificables. Pro solo compensa cuando el trabajo real demuestra una mejora: más tareas aceptadas, menos reintentos o menos revisión. Elegir una franja barata no convierte automáticamente Pro en la opción económica.
Un ejemplo que incluye la caché
Para una sola franja, la operación es:
textcoste = tokens de entrada con acierto / 1.000.000 × tarifa de acierto + tokens de entrada con fallo / 1.000.000 × tarifa de fallo + tokens de salida / 1.000.000 × tarifa de salida
Supongamos un lote con ocho millones de tokens de entrada. Seis millones aciertan en caché, dos millones no, y la salida suma un millón.
Con V4 Flash cuesta 6 × 0,007 + 2 × 0,22 + 1 × 0,66 = 1,142 $ en valle y 2,284 $ en punta. Con V4 Pro son 3,432 $ en valle y 6,864 $ en punta.
Mover el mismo consumo reduce a la mitad el cargo por tokens del proveedor. Mejorar la caché es otra palanca: sustituye entrada cara sin acierto por entrada barata con acierto. Se pueden combinar, pero no son la misma mejora.
La cuenta aún no incluye reintentos, margen del intermediario, impuestos, cambio de divisa, demora, degradación de calidad o revisión humana. Si esperar provoca incumplir una entrega y alguien tiene que repetir el proceso, el lote puede salir más caro aunque la línea de API sea menor.
El cambio CET/CEST puede mover también la fecha
Use UTC como referencia dentro del programador y transforme a hora local solo para la vista operativa. En España, adelantar o atrasar una hora fija dos veces al año produce errores fáciles de pasar por alto. Además, un intervalo UTC puede pertenecer a un día local distinto en otros países desde los que opere el mismo equipo.
Una prueba de calendario debería cubrir al menos una fecha en CET, otra en CEST, el domingo del cambio y la transición de viernes UTC a fin de semana. El sistema debe decidir por el instante UTC y no por una etiqueta ambigua como “madrugada laborable”.
Para poder auditar el resultado, registre por tarea:
- hora de entrada en cola, envío y finalización con offset;
- model ID exacto;
- tokens de acierto, fallo y salida;
- intento, estado final y coste calculado;
- fecha límite y edad de la tarea.
La caída total del saldo no permite separar franja, caché, mayor salida o ejecución duplicada.
Una tarea aplazable necesita más que paciencia
Una candidata sólida tiene input duradero, ejecución idempotente, verificación automática, margen suficiente hasta su fecha límite y una ruta de recuperación después del último reintento. Clasificación offline, enriquecimiento de índices, evaluaciones, análisis no urgente de repositorios y preprocesado regenerable suelen cumplirlo.
No deberían esperar por precio las respuestas interactivas, el diagnóstico de incidentes, las decisiones de pago o seguridad, los turnos de un agente de programación y cualquier automatización con un objetivo de tiempo estricto.
Para los casos intermedios, asigne not_before y deadline_at. La tarea espera la próxima franja valle mientras conserve margen; cuando se acerque el límite, sube a ejecución inmediata. Así el precio participa en la decisión sin controlar la experiencia del usuario.
La idempotencia evita que una nueva entrega de la cola duplique una notificación, un registro o una acción de cliente. Use una clave de negocio estable y siga por separado la llamada a DeepSeek y la confirmación final en su base de datos.
Valle no significa capacidad garantizada
La documentación de límites muestra actualmente 2.500 solicitudes concurrentes por cuenta para Flash y 500 para Pro. Al superar el límite, la API devuelve HTTP 429. Algunas cuentas pueden solicitar ampliación, pero la cifra pública no promete latencia ni disponibilidad en una franja concreta.
Mantenga backoff exponencial, máximo de reintentos, alerta por edad de cola y una cola de fallos definitivos. Empiece con una muestra pequeña durante una semana completa y compare tasa de aceptación, latencia p95, reintentos, longitud de salida y minutos de revisión. Amplíe solo si baja el coste por tarea aceptada, no únicamente el precio por millón de tokens.
El anuncio de V4 Pro sitúa la entrada en vigor del nuevo esquema en el 16 de agosto de 2026 a las 16:00 UTC. Por eso las guías del preview de abril y sus tarifas fijas ya no describen el cargo actual.
Si la siguiente pregunta es qué proveedor usar, conserve el mismo trabajo, límites de salida, reintentos y criterio de aceptación al consultar la comparativa actual de precios LLM API. Una franja valle es un ahorro real solo cuando la tarea correcta termina dentro de plazo y sin trabajo manual añadido.
