DeepSeek cambiará los precios de su API el 17 de agosto, sometiendo las cargas de trabajo en tiempo real a presión

DeepSeek cambiará las tarifas de su API el 17 de agosto e introducirá un horario de horas punta en dos franjas que convierte el momento de uso en un componente directo de los costes de inferencia. La compañía afirma que el uso fuera de horas punta costará la mitad que durante las horas punta. Para los desarrolladores, el conflicto inmediato es claro: los trabajos por lotes flexibles pueden buscar tarifas más bajas, mientras que las aplicaciones orientadas al cliente no pueden simplemente esperar.

El cambio se aplicará desde la medianoche del 17 de agosto de 2026, hora de Pekín. Los periodos punta van de 9:00 a. m. a mediodía y de 2:00 p. m. a 6:00 p. m., hora de Pekín. Todas las demás horas se clasifican como fuera de horas punta, según la página oficial de precios de DeepSeek.

Esto es más que otro ajuste de una tarifa por token. DeepSeek está asignando un valor explícito al tiempo de acceso, convirtiendo los horarios de las aplicaciones en un mecanismo de control de costes. Esto pone su posicionamiento de bajo coste en tensión con las exigencias operativas de los agentes, los sistemas de soporte, los productos de programación y otros servicios que deben responder de inmediato.

El modelo se parece a la tarificación por capacidad aplicada en otros ámbitos de la computación en la nube, donde los trabajos que toleran demoras reciben condiciones favorables a cambio de aceptar tiempos de inicio inciertos. Google, por ejemplo, comercializa Flex-start VMs para trabajos de duración definida que no necesitan comenzar de inmediato. DeepSeek está aplicando una señal económica relacionada más cerca de la propia API del modelo.

El resultado divide a los clientes de la API en dos grupos. Los equipos que controlan cuándo se ejecutan sus cargas de trabajo obtienen una nueva palanca de optimización. Los equipos que atienden a usuarios en directo asumen una tarifa determinada en parte por el reloj, incluso cuando sus aplicaciones y volúmenes de tokens se mantienen sin cambios.

Qué está cambiando DeepSeek el 17 de agosto

DeepSeek está sustituyendo una estructura de tarifas única y permanente por un horario diario que cobra tarifas diferentes por la misma actividad del modelo.

La estructura actualizada cubre tanto DeepSeek-V4-Flash como DeepSeek-V4-Pro. También se aplica a las principales categorías de facturación: entrada en caché, entrada sin caché y salida generada. Por tanto, un token procesado durante una ventana punta conlleva un cargo diferente al de un token equivalente procesado fuera de esas ventanas.

Una API, o interfaz de programación de aplicaciones, permite al software enviar solicitudes a un modelo sin utilizar su interfaz de chat para consumidores. Los desarrolladores suelen pagar según el número y el tipo de tokens procesados. Los tokens son pequeñas unidades que representan palabras, fragmentos de palabras, números o signos de puntuación.

Según el horario de DeepSeek, siete horas de cada día entran dentro de las dos ventanas punta. Las 17 horas restantes son fuera de horas punta. El horario sigue la hora de Pekín en lugar de la hora local de cada cliente, por lo que su efecto práctico varía considerablemente según la región.

La primera ventana va de 9:00 a. m. a mediodía en Pekín. La segunda comienza a las 2:00 p. m. y termina a las 6:00 p. m. Un intervalo de dos horas las separa, creando un breve periodo fuera de horas punta en mitad de la jornada laboral china.

Los desarrolladores de Norteamérica se encontrarán a menudo con estas ventanas durante la tarde o la noche, según la ubicación y las reglas de horario de verano. Esto hace que el acceso fuera de horas punta sea comparativamente sencillo para muchos servicios diurnos en Estados Unidos y Canadá. Los equipos asiáticos tienen más probabilidades de afrontar precios punta durante las horas laborales habituales.

La página de precios disponible el 14 de agosto identifica DeepSeek-V4-Flash-0731 y DeepSeek-V4-Pro-0813 como las versiones actuales. Ambos admiten operación con y sin razonamiento, una ventana de contexto de un millón de tokens, llamadas a herramientas, salida JSON y las APIs Responses y compatibles con Anthropic de DeepSeek.

La página también enumera límites de concurrencia separados para los dos modelos. La concurrencia describe cuántas solicitudes o flujos de procesamiento permite un servicio a la vez. Es importante porque una tarifa más baja resulta menos útil si una carga de trabajo retrasada encuentra después un cuello de botella de capacidad.

DeepSeek no ha publicado una curva de demanda detallada que explique por qué seleccionó estas ventanas exactas. Tampoco ha divulgado datos de utilización que muestren cuánto tráfico llega actualmente durante cada periodo. La compañía vinculó anteriormente la tarificación basada en el tiempo con una mejor asignación de recursos y estabilidad del servicio, según un mensaje a suscriptores citado por el South China Morning Post.

Esa explicación es plausible, pero sigue siendo la justificación de la compañía y no un estudio de capacidad verificado de forma independiente. El horario de agosto revela hacia dónde DeepSeek quiere desplazar la demanda. No revela cuánta capacidad disponible existe fuera de esas horas ni si el incentivo eliminará la congestión.

Para los clientes, la interpretación más segura es operativa. La misma solicitud ahora tiene dos posibles resultados de facturación, y la variable decisiva es cuándo DeepSeek la procesa. Las previsiones de costes basadas solo en el volumen mensual de tokens quedarán incompletas una vez que entre en vigor la nueva estructura.

La tarifa más baja ahora exige control sobre la programación

Las condiciones económicas más favorables de DeepSeek corresponderán a las cargas de trabajo que pueden esperar, ponerse en cola o desplazarse entre zonas horarias.

Parte de la actividad de los modelos es naturalmente flexible. Una empresa puede retrasar la indexación de documentos, las evaluaciones nocturnas, la generación de datos sintéticos, la redacción de informes o la clasificación a gran escala. Estos trabajos pueden entrar en una cola y comenzar cuando se abra una ventana fuera de horas punta.

Esa flexibilidad gana valor con el nuevo sistema. Un equipo puede etiquetar las solicitudes según su urgencia, reservar la ejecución inmediata para tareas en directo y enviar el trabajo en segundo plano para más tarde. También puede distribuir el procesamiento a lo largo del día en vez de lanzar cada lote a una hora local fija.

Los productos orientados al cliente tienen menos libertad. Un asistente de soporte debe responder mientras el cliente está presente. Un asistente de programación debe responder mientras el desarrollador trabaja. Una función de búsqueda no puede retener una consulta durante varias horas simplemente porque el modelo subyacente haya entrado en un periodo punta.

Las aplicaciones basadas en agentes afrontan una complicación adicional. Un agente puede realizar muchas llamadas al modelo al completar una tarea de usuario, incluida la planificación, la recuperación, la selección de herramientas, la verificación y la revisión. Por tanto, su coste depende tanto del volumen de tokens como del número de pasos necesarios antes de completarla.

El almacenamiento en caché puede reducir el procesamiento repetido de entradas. El sistema de caché de contexto de DeepSeek guarda en disco material de prompts reutilizable e intenta reutilizarlo en solicitudes posteriores. La documentación de caché de la compañía describe esto como una forma de reducir el gasto del contexto repetido.

Sin embargo, el almacenamiento en caché no elimina el problema del momento de uso. El nuevo horario de DeepSeek distingue entre entrada en caché y sin caché, al tiempo que aplica el tratamiento de horas punta y fuera de horas punta a ambas. Un producto con una excelente reutilización de caché aún puede afrontar una tarifa más alta cuando sus usuarios llegan durante las ventanas designadas.

Por ello, los equipos deberían evaluar tareas completas en lugar de tokens aislados. Un modelo con una tarifa de entrada favorable puede resultar menos atractivo si utiliza más pasos de razonamiento, produce salidas más largas o requiere reintentos. A la inversa, una tarifa publicada más alta puede seguir siendo económica si el modelo completa el trabajo con menos llamadas.

Esta visión a nivel de tarea es especialmente importante para los sistemas autónomos. Su consumo es menos predecible que el de una interfaz sencilla de preguntas y respuestas. Una solicitud de usuario puede terminar tras una sola llamada, mientras que otra activa varias herramientas y múltiples rondas de razonamiento del modelo.

La nueva estructura también cambia las alertas presupuestarias. Un umbral fijo diario de tokens ya no corresponderá a un umbral fijo de gasto. Los equipos de finanzas e ingeniería deben distinguir el uso por modelo, categoría de tokens y ventana horaria.

Esto requiere marcas de tiempo limpias en las exportaciones de facturación o la telemetría de la aplicación. Los equipos deberían registrar cuándo comenzó una solicitud, qué modelo la gestionó, si se utilizó entrada en caché y cuántas llamadas de seguimiento se produjeron. Sin esos campos, será difícil explicar un aumento inesperado.

El enrutamiento de cargas de trabajo ofrece otra respuesta. Las aplicaciones pueden enviar el trabajo urgente a un modelo seleccionado por latencia y disponibilidad, y asignar después las tareas en segundo plano a una ruta de menor coste. Esta estrategia requiere evaluación porque cambiar de modelo puede alterar la calidad de la salida, el comportamiento de las herramientas, el formato y el rendimiento de seguridad.

Una capa de enrutamiento también añade sobrecarga de ingeniería. Los equipos deben mantener prompts para múltiples proveedores, normalizar respuestas, gestionar credenciales independientes y probar el comportamiento de respaldo. El ahorro aparente de la ejecución fuera de horas punta puede reducirse una vez que se incluyan esos costes operativos.

Las empresas mejor posicionadas para beneficiarse son aquellas que ya separan la inferencia en línea y fuera de línea. Saben qué tareas tienen objetivos estrictos de latencia y cuáles pueden tolerar demoras. Las organizaciones que envían cada solicitud a través de una única ruta síncrona tendrán más trabajo de rediseño por delante.

La estrategia de guerra de precios de DeepSeek se enfrenta al coste de la capacidad

La tensión central ya no es DeepSeek frente a rivales caros. Es la promesa de asequibilidad de DeepSeek frente al coste de atender una demanda concentrada.

DeepSeek ayudó a convertir las bajas tarifas de API en una cuestión competitiva central de la IA generativa. En febrero de 2025, introdujo descuentos sustanciales durante las horas tranquilas, presionando a proveedores de modelos chinos e internacionales. La cobertura de Reuters describió ese movimiento como un desafío para competidores que ya se enfrentaban a los modelos de menor coste de DeepSeek.

El cambio de agosto de 2026 no abandona el acceso descontado fuera de horas punta. Formaliza una separación mayor entre los periodos de menor y mayor demanda. La experiencia más barata sigue disponible, pero los clientes deben aportar flexibilidad de programación para obtenerla.

Esto supone un giro significativo en la narrativa comercial. Las tarifas bajas funcionaban antes como un simple mensaje de captación. Las tarifas basadas en el tiempo transforman la asequibilidad en una promesa condicional cuyo valor depende de la geografía, el diseño de la carga de trabajo y el comportamiento de los usuarios.

DeepSeek afirma que el mecanismo respalda la distribución de recursos y la estabilidad del servicio. La lógica sigue la economía básica de la infraestructura. La capacidad de aceleradores es cara, la demanda varía a lo largo del día y el tiempo de computación no utilizado no puede guardarse para mañana.

Una tarifa más baja fuera de horas punta anima a los clientes a desplazar las solicitudes aplazables a periodos más tranquilos. Si responden suficientes usuarios, DeepSeek puede atender más trabajo total con la misma infraestructura. También puede reducir el número de servidores necesarios para gestionar los picos de demanda más pronunciados.

La tarificación punta cumple el otro lado de ese mecanismo. Pide a los clientes sensibles a la latencia que aporten más cuando la capacidad está más disputada. Eso puede financiar infraestructura adicional, reducir el uso discrecional o lograr ambas cosas.

Sin embargo, el diseño transfiere parte de la gestión de capacidad a los clientes. En lugar de absorber cada pico de demanda bajo una tarifa predecible, DeepSeek pide a los desarrolladores que decidan qué tareas merecen ejecución inmediata. El precio de la API se convierte en una señal que indica a las aplicaciones cuándo el proveedor prefiere que se ejecuten.

Este enfoque tiene precedentes en mercados adyacentes de la nube. Google’s Dynamic Workload Scheduler ofrece acceso optimizado en costes para cargas de trabajo que pueden esperar recursos de computación. Su tarificación del programador separa el consumo flexible de las expectativas de capacidad estándar.

Google también ha introducido un nivel de inferencia flexible para solicitudes de modelos que toleran latencia. El patrón general es claro: los proveedores de IA distinguen cada vez más entre el cómputo urgente y el trabajo que puede entrar en una cola. El calendario de DeepSeek es notable porque la distinción es visible en horarios diarios fijos.

Las ventanas fijas son más fáciles de entender que los precios spot que cambian constantemente. Un desarrollador puede planificar en torno a ellas sin tener que predecir un mercado en tiempo real. La contrapartida es que un calendario fijo puede no reflejar la demanda real de un día concreto.

Un festivo, el lanzamiento de un producto o un evento viral podrían desviar el tráfico del patrón esperado. DeepSeek podría tener capacidad disponible durante un periodo nominalmente pico o sufrir congestión durante uno de menor demanda. Los clientes seguirían recibiendo la tarifa programada, salvo que la empresa cambie sus reglas.

El efecto regional también complica el panorama competitivo. El horario laboral de Pekín coincide con periodos de actividad en gran parte de Asia. Los equipos de Norteamérica pueden descubrir que su jornada laboral habitual queda en gran medida fuera de las ventanas pico de DeepSeek.

Eso significa que el calendario no ejerce la misma presión sobre todos los competidores. Alibaba, ByteDance, Tencent, Baidu y otros proveedores centrados en China atienden a clientes cuya demanda suele seguir ritmos regionales similares. Un proveedor de Estados Unidos compite bajo un patrón de uso distinto, incluso cuando sus tarifas publicadas por token parecen más altas.

Alibaba Cloud ilustra otra vía competitiva. Su Model Studio admite llamadas a modelos de pago por uso, planes de tokens agrupados y acceso a múltiples familias de modelos. El plan de tokens de la empresa destaca el uso compartido, el cambio entre modelos y un consumo predecible basado en suscripciones.

Estas ofertas no son directamente equivalentes a la API de DeepSeek. Estructuran el acceso de forma diferente y pueden implicar distintas regiones de despliegue, modelos, cuotas y características de rendimiento. Aun así, muestran cómo los competidores pueden responder a los precios basados en horarios sin copiar el mismo calendario.

Una respuesta consiste en un consumo mensual predecible. Otra es el rendimiento reservado para equipos que necesitan capacidad garantizada. Una tercera es un nivel flexible que acepta demoras sin vincular a los clientes a horarios fijos.

La ventaja de DeepSeek dependerá de algo más que de la tarifa disponible más baja. Los desarrolladores compararán fiabilidad, calidad del modelo, latencia, manejo del contexto, comportamiento de la caché, políticas de datos, acceso regional y costes de integración. El token más barato no es automáticamente la tarea completada más barata.

Lo que el calendario de precios no garantiza

Una tarifa más baja fuera de horas punta no garantiza capacidad disponible, mientras que una tarifa pico más alta no garantiza un mejor servicio.

DeepSeek ha vinculado la política a una mejor asignación de recursos y estabilidad. El calendario puede fomentar una demanda más uniforme, pero la empresa no ha prometido una latencia específica, un nivel de disponibilidad ni prioridad de procesamiento para los clientes que pagan la tarifa pico.

Esta distinción importa para los compradores en producción. Los cargos más altos durante una ventana concurrida pueden parecer un pago por un servicio prémium, incluso cuando la regla publicada solo modifica la tarifa por token. Los equipos no deben asumir acceso prioritario salvo que su contrato o la documentación del servicio lo establezcan explícitamente.

Los usuarios fuera de horas punta afrontan el riesgo inverso. Muchos clientes podrían programar sus trabajos más grandes justo en el momento en que comienza un periodo de tarifa reducida. En vez de suavizar la demanda, ese comportamiento podría crear nuevos picos bruscos en los límites de cada ventana.

El diseño de las colas puede reducir ese riesgo. Los equipos pueden añadir horarios de inicio aleatorizados, distribuir los trabajos a lo largo de un intervalo o imponer límites internos de concurrencia. Esas medidas protegen la aplicación del cliente, pero no revelan la capacidad subyacente de DeepSeek.

El calendario fijo también crea problemas de gestión horaria. Las aplicaciones necesitan una conversión fiable desde la hora de Pekín, incluida la fecha de calendario correcta. Pekín no aplica cambios estacionales de horario, mientras que muchas ubicaciones de Norteamérica y Europa sí lo hacen.

Un programador basado en una conversión local fija puede desviarse cuando comienza o termina el horario de verano. El enfoque más seguro es almacenar las marcas de tiempo en Tiempo Universal Coordinado y calcular programáticamente la ventana actual de Pekín. Las revisiones de facturación deben utilizar la misma lógica de conversión.

Las solicitudes cercanas a un límite merecen un tratamiento especial. Una solicitud de larga duración puede comenzar antes de una ventana pico y terminar después de que esta empiece. La página pública de precios de DeepSeek explica las ventanas, pero no describe con claridad qué marca de tiempo rige en estos casos límite.

La hora de inicio de la solicitud, el momento del procesamiento de los tokens o la hora de finalización podrían producir resultados distintos. Las respuestas en streaming hacen que la distinción sea más importante porque la salida llega a lo largo de un intervalo. Los desarrolladores con tráfico significativo en los límites deben solicitar aclaraciones y verificar sus primeras facturas.

Los reintentos introducen otra incertidumbre. Si una solicitud falla durante un periodo fuera de horas punta y tiene éxito después de que comience una ventana pico, el cargo resultante puede no coincidir con la expectativa original de la aplicación. El efecto depende de cómo aparezcan los tokens fallidos y reintentados en la contabilidad de DeepSeek.

Las comparaciones entre proveedores también requieren cautela. Una comparación directa de las tarifas por token puede ignorar el número de tokens que genera cada modelo para la misma tarea. También puede pasar por alto la retención de caché, el formato de los prompts, la sobrecarga de razonamiento y el umbral de calidad que determina si un resultado necesita revisión.

Las puntuaciones de referencia no bastan para resolver la cuestión. Un modelo de programación puede rendir bien en una prueba pública y, aun así, tener dificultades con las convenciones del repositorio de una empresa. Un modelo de razonamiento puede responder con precisión mientras consume demasiado tiempo o produce salidas innecesariamente largas.

Los equipos necesitan evaluaciones específicas de cada aplicación que midan el éxito por tarea completada. Un conjunto de pruebas útil debe incluir solicitudes habituales, casos límite difíciles, fallos de herramientas, contextos largos y prompts repetidos que pongan a prueba la caché.

El cambio de agosto también llega con una gama de modelos DeepSeek actualizada recientemente. Los clientes que evalúan los nuevos precios pueden estar evaluando simultáneamente el comportamiento de los modelos, lo que dificulta aislar el efecto de los precios por sí solo. Un cambio en el gasto total podría reflejar las tarifas, el crecimiento del uso, la longitud de la salida o la calidad de finalización.

Las reacciones de la comunidad aportan señales de alerta temprana, pero no estimaciones fiables de costes. Los usuarios han señalado aumentos considerables para cargas de trabajo intensivas en caché y han debatido si DeepSeek sigue siendo competitivo. Esos cálculos dependen de los patrones de tráfico individuales y no deben sustituir a los datos de producción medidos.

La conclusión escéptica más sólida es, por tanto, limitada. DeepSeek ha creado un incentivo que debería desplazar parte de la demanda flexible. Aún no ha demostrado cuánto tráfico se moverá, si mejorará la fiabilidad o cómo valorarán los clientes la complejidad resultante.

Tres señales que vigilar después de que entren en vigor las nuevas tarifas

El primer mes mostrará si la inferencia basada en horarios se convierte en un modelo operativo duradero o en otro experimento de precios.

La primera señal es el rendimiento del servicio de DeepSeek en los límites de las ventanas. Los desarrolladores deben seguir la latencia, las tasas de error, el tiempo de cola y el rendimiento antes y después de cada transición diaria. Una mejora significativa durante los periodos pico respaldaría el argumento de la empresa sobre la asignación de recursos.

El resultado contrario lo debilitaría. Si los clientes pagan la tarifa pico mientras la latencia y la disponibilidad permanecen sin cambios o empeoran, la política parecerá más un ajuste de ingresos que una herramienta de gestión del servicio. Los datos públicos de estado y la telemetría de los clientes importarán más que las afirmaciones generales.

La segunda señal es cuánto trabajo se desplaza realmente. Los equipos deben comparar la proporción de tokens procesados durante los periodos pico y fuera de horas punta antes y después del 17 de agosto. También deben medir si los trabajos retrasados generan nuevos picos inmediatamente después de que cierre una ventana pico.

Un amplio desplazamiento hacia la ejecución fuera de horas punta reforzaría el mecanismo de DeepSeek. Demostraría que los desarrolladores pueden tratar el momento de la inferencia como una variable ajustable de infraestructura. Un movimiento escaso sugeriría que la mayoría de las cargas de trabajo valiosas son demasiado sensibles a la latencia como para reprogramarlas.

La tercera señal es la respuesta competitiva. Los proveedores chinos de modelos pueden responder con tarifas más bajas, paquetes de uso, capacidad reservada, garantías de servicio más sólidas o un enrutamiento entre modelos más sencillo. Los proveedores internacionales pueden destacar precios predecibles o productos de inferencia flexible sin ventanas regionales fijas.

Una copia directa del calendario de DeepSeek validaría los precios por hora del día como una nueva dimensión competitiva. Un giro hacia el rendimiento reservado o los paquetes mensuales apuntaría en otra dirección, en la que los compradores pagan por previsibilidad en lugar de buscar horas tranquilas.

Los desarrolladores deben comenzar con una auditoría de facturación controlada, no con una migración precipitada. Registre una semana representativa de datos sobre modelo, marca de tiempo, caché, tokens, latencia y éxito de tareas. Recalcule esa carga de trabajo con el nuevo calendario y, después, identifique qué trabajos pueden trasladarse sin perjudicar a los usuarios.

A continuación, pruebe una pequeña cola fuera de horas punta. Incluya límites de reintentos, horarios de inicio aleatorizados, gestión de plazos y una vía de respaldo para el trabajo urgente. Compare el coste completo por tarea completada con éxito, no solo la tarifa publicada para una categoría de token.

Por último, mantenga preparado un conjunto de evaluación independiente del proveedor. La política de DeepSeek del 17 de agosto convierte la arquitectura de las cargas de trabajo en parte de la decisión de compra. La pregunta importante ya no es qué modelo anuncia la tarifa más baja. Es qué combinación de modelo, momento, fiabilidad y esfuerzo de ingeniería produce resultados fiables al menor coste total.