DeepSeek V4 Pro GA vs Preview: razona entre un 18% y 62% menos

La versión GA de DeepSeek V4 Pro consume entre un 18% y un 62% menos tokens de razonamiento que la Preview a la que sustituye en tareas idénticas. También corrige un fallo capaz de agotar una ventana de salida completa de 8,192 tokens y es la primera versión Pro en la que desactivar el razonamiento permite extraer JSON estricto de forma fiable. A cambio, ha perdido la capacidad de la Preview para admitir que no sabe algo. Comparamos deepseek-v4-pro-0813 con la versión Preview en un mismo lote, cuatro días después de la disponibilidad general. Solo medimos tokens: DeepSeek cambió los precios de V4 y añadió tarifas de hora punta y valle el día anterior, por lo que comparar en dólares dos tarifas cambiantes aportaría menos que los propios tokens. DeepSeek publicó la versión GA sin entrada de blog, registro de cambios ni comunicado de prensa, así que para saber qué ha cambiado hay que medirlo.

TL;DR

• GA consume entre un 18% y un 62% menos tokens de razonamiento por tarea: 18 frente a 48 en una consulta sencilla.
• El razonamiento corrompe los valores de JSON estricto en ambas versiones (2/8 correctos); GA con el razonamiento desactivado es la única configuración limpia que encontramos (8/8).
• GA corrige un fallo de Preview: thinking_budget: 16 agotó la ventana de salida de 8,192 tokens en 5 de 9 ejecuciones; GA, en 0 de 9.
• GA ha perdido el rechazo limpio: ante entidades inventadas, Preview se niega a responder en 100-150 tokens; GA no devuelve nada o se inventa una respuesta.

¿Cuánto menos razona la versión GA?

Entre un 18% y un 62% menos, con la mayor diferencia en tareas sencillas. Estos son los tokens medianos de razonamiento y de finalización en nuestras cuatro tareas estándar, con tres ejecuciones y variaciones de datos en cada una:

Ambas versiones acertaron 3/3 en todas las tareas. Es una mejora directa de eficiencia, no un sacrificio de calidad. La tendencia relevante para dimensionar costes es clara: cuanto más compleja es la tarea, menor es el ahorro. Pasa del 62% en una consulta de un paso al 18% en una cadena de cinco. Cuesten lo que cuesten ambas versiones, esa es la forma de la diferencia. La extracción estructurada es la que más mejora: con un json_schema estricto baja de 159 a 40 tokens de razonamiento, una reducción de 4x.

La caché se comporta igual en ambas versiones: las dos almacenaron 4,096 tokens de un prefijo de 5,000 y sirvieron el hit 4 segundos después de la llamada inicial. Lo que está cambiando ahora son las tarifas, no el mecanismo. DeepSeek subió los precios de la familia V4 e introdujo facturación por hora punta y valle, con una tarifa del 50% en horas valle, desde 2026-08-16 16:00 UTC. Antes de convertir estos tokens en dólares, consulte la tarifa vigente de cada versión y la franja horaria en la que vaya a ejecutarla.

¿Ha corregido GA algún problema medible?

Sí, y era el fallo más caro de esta familia. Al enviar thinking_budget: 16 a Preview, el modelo pierde el hilo: en vez de razonar brevemente y contestar, entra en un bucle de repetición (“I’ll output: 168. I’ll output: 168…”) hasta agotar max_tokens. En nueve ejecuciones de la misma tarea de cinco pasos, Preview llenó por completo la ventana de 8,192 tokens 5 veces. GA no lo hizo ninguna: respondió correctamente en todas las ejecuciones y consumió entre 79 y 130 tokens.

El coste es precisamente el problema. Una petición que intenta ahorrar limitando el razonamiento acaba facturando 8,193 tokens de finalización, frente a unos 130 en una respuesta normal. Es una factura de salida 63x mayor por pedirle al modelo que razone menos. Un límite de 64 tokens tampoco fue más seguro en Preview: devolvió respuestas incorrectas (183, 174) en 2 de 3 ejecuciones. Si sigue anclado a Preview y controla el coste con límites pequeños de razonamiento, esa es la primera combinación que debería retirar.

Aquí es seguro desactivar el razonamiento, algo que no se cumple en toda la familia: Flash 0731 pasó de 6/6 a 0/6 en aritmética de 2 pasos al desactivarlo, mientras que ambas versiones Pro mantuvieron 3/3 en nuestra cadena de cinco pasos con thinking: {"type": "disabled"} o enable_thinking: false. En Pro, desactivarlo no reduce la precisión en tareas de razonamiento y además corrige la extracción estructurada, como se explica más abajo.

El selector sigue siendo meramente decorativo en ambas versiones. reasoning_effort acepta low, medium, high, xhigh y max. Rechaza none y minimal con un error 400 que enumera los valores válidos. En nuestra tarea de cinco pasos, los distintos niveles generaron entre 76 y 122 tokens de razonamiento en GA y entre 116 y 167 en Preview, sin ninguna tendencia monotónica. Como mostró nuestra matriz de selectores entre proveedores, DeepSeek se controla mediante la desactivación y el presupuesto, no mediante el enum.

¿El razonamiento sigue corrompiendo el JSON estricto?

Sí, en ambas versiones. GA es la primera versión Pro que ofrece una salida limpia. Detectamos este defecto en DeepSeek V4 Flash 0731: JSON válido según el schema, pero con números incorrectos. El fallo continúa en Pro. Pedimos a ambas versiones que extrajeran cuatro campos de una factura de tres líneas usando un json_schema estricto. Hicimos ocho ejecuciones por configuración y validamos los valores, no solo el schema:

Todos los resultados fallidos se pueden parsear, cumplen el schema y contienen datos falsos. Una factura que enumera claramente tres artículos devolvió recuentos de 45, 22, 2026, -4, -35 y -3864 en distintas ejecuciones. Una respuesta de Preview indicó un total de -139,308,173,307,904 y una de GA se inventó una empresa distinta (“MITRE”, total 1000). Un validador consideraría válido el JSON en todos esos casos.

La conclusión operativa es sencilla. En GA, el defecto desapareció en todas nuestras ejecuciones al desactivar el razonamiento. Esta configuración por sí sola es el argumento más sólido para abandonar Preview, que siguió fallando en 6 de 8 ejecuciones incluso con el razonamiento desactivado. Coincide con el patrón de la familia que medimos en Flash, donde desactivar el razonamiento también corrigió todas las ejecuciones. Es otro caso de la zona segura para tareas de un solo paso que identificamos en nuestra matriz de controles de razonamiento: la extracción no necesita deliberación y, en esta familia, deliberar la perjudica.

¿Qué ha perdido GA?

La capacidad de decir «no lo sé». Preguntamos por cinco entidades inventadas: el precio de las acciones de una empresa, el número de empleados de un instituto, la carta fundacional de una localidad, el punto de fusión de una aleación y el ganador de un premio. Preview se niega a responder de forma clara en 100 a 150 tokens de salida: “I don’t have any information about a 1987 Pan-Continental Robotics Prize.” GA responde de una de estas dos maneras, y ninguna sirve:

Antes de publicar, lo verificamos por una segunda ruta de petición independiente. Por esa ruta, Preview rechazó las tres preguntas muestreadas en entre 101 y 148 tokens. GA consumió 8,191 tokens y devolvió una respuesta vacía en un caso, respondió con reservas en otro y afirmó un punto de fusión concreto (“2,314 degrees Celsius”) para una aleación inexistente en el tercero. Misma asimetría, cliente distinto: el comportamiento pertenece al modelo.

En pipelines de recuperación, la consecuencia práctica es un doble coste: una pregunta que el índice no puede responder consume una ventana completa de razonamiento oculto y devuelve un mensaje vacío o una invención que el validador aceptará sin problemas. Si dirige a este modelo las consultas sin respuesta, limite max_tokens lo suficiente para que el fallo sea visible y barato. Trate una finalización vacía como un miss, no como un error.

¿Cambia algo más al migrar?

Poco. Por tanto, la migración depende del comportamiento, no de la integración. Ambas versiones aceptaron 279,000 tokens de entrada en una sola llamada y respondieron una pregunta aguja cuya respuesta estaba en mitad del contexto. Las dos comparten el tokenizer de la familia: el mismo corpus de inglés, chino y código cuenta exactamente igual en GA, Preview y deepseek-v4-flash-0731. Los presupuestos de tokens pueden trasladarse entre modelos de la familia sin cambios. Ambas aceptan temperature, top_p y top_k sin avisar, además de un turno de assistant precompletado, la función de finalización por prefijo documentada por DeepSeek.

La caché es idéntica hasta en el tamaño de página. Ninguna versión almacenó un prefijo de 512 tokens. Por encima de ese umbral, ambas almacenaron páginas exactas de 1,024 tokens (1,024, 2,048, 4,096) y sirvieron hits 4 segundos después de la llamada inicial. Es el mismo tamaño de página que usa Flash. Queda otra cuestión de costes: ambas versiones devuelven la cadena de pensamiento completa en reasoning_content, y reutilizarla en el siguiente turno es gratis. Un turno posterior facturó los mismos 134 tokens de entrada en GA (56 en Preview), tanto al incluir el razonamiento del turno anterior como al eliminarlo. A diferencia de los modelos que vuelven a facturar cada token de razonamiento conservado, esta familia simplemente lo descarta.

En el bucle de herramientas no hay mejora ni empeoramiento neto. En un agente con dos funciones —consultar un incidente y reiniciar el servicio que este indicaba—, GA deliberó más en el primer paso (48 frente a 34 tokens de razonamiento) y menos en el segundo (18 frente a 35). Ambas versiones eligieron la herramienta correcta 3/3. Dado que DeepSeek orienta esta versión a cargas de agentes, el razonamiento por paso queda más equilibrado de lo que sugieren las cifras generales de eficiencia. Para un agente que llega a callejones sin salida, el comportamiento de rechazo descrito antes es más importante.

Preguntas frecuentes

¿Cuánto cuesta ejecutar la versión GA en comparación con Preview?

En tokens, consume entre un 18% y un 62% menos de razonamiento por tarea y 4x menos con un json_schema estricto. Para calcularlo en dólares, consulte la tarifa actual: DeepSeek cambió los precios de la familia V4 y añadió facturación por hora punta y valle —con un 50% de descuento en horas valle— el 2026-08-16. Los mismos tokens tienen un precio distinto según la versión y la hora.

¿GA ahorra más en tareas sencillas o complejas?

En las sencillas. El razonamiento se reduce un 62% en una consulta de un paso, alrededor de un 48% en un problema verbal de 2 pasos y en la extracción JSON, y solo un 18% en una cadena aritmética de cinco pasos. En trabajos complejos de varios pasos, ambas versiones convergen. La migración compensa más en tráfico sencillo y de gran volumen.

¿Conviene seguir usando presupuestos de razonamiento pequeños en DeepSeek V4 Pro?

No en Preview. thinking_budget: 16 provocó un bucle de repetición que consumió la ventana de salida completa de 8,192 tokens en 5 de 9 ejecuciones. Es una factura de salida unas 63x mayor para una petición que pretendía ser barata; con 64 tokens devolvió respuestas incorrectas. GA gestionó correctamente el mismo presupuesto en 9 de 9 ejecuciones. Los presupuestos pequeños solo son seguros en la versión fechada.

¿Puedo confiar en la salida JSON estricta de DeepSeek V4 Pro?

Solo con el razonamiento desactivado y solo en GA. En ocho ejecuciones por configuración, las respuestas válidas según el schema contenían números incorrectos en 6 de 8 casos con el razonamiento activado en ambas versiones: para una factura de tres artículos devolvieron recuentos de 45, 2026 y -3864. GA con thinking: {"type": "disabled"} devolvió valores correctos en 8 de 8 ejecuciones. Preview siguió fallando en 6 de 8 incluso con el razonamiento desactivado. Valide los valores, no solo el schema.

¿DeepSeek V4 Pro rechaza preguntas que no puede responder?

Preview sí, en 100-150 tokens. GA, por lo general, no. Ante entidades inventadas, consume toda la ventana de salida razonando y devuelve un mensaje vacío o, si dispone de una ventana mayor, afirma con seguridad una respuesta inventada. Contraste el resultado con sus propias fuentes en lugar de confiar en que el modelo rechace la pregunta. Trate las finalizaciones vacías como misses.

Mediciones realizadas el 2026-08-17 mediante el gateway de Synthorai, cuatro días después de aparecer la versión GA. Preview se volvió a ejecutar en el mismo lote para todas las comparaciones: matriz de selector y desactivación (7 valores de esfuerzo, 5 presupuestos, 2 parámetros de desactivación, n=3), barrido de razonamiento con cuatro tareas, salida estructurada con JSON estricto, bucle de llamada a funciones de dos turnos, prueba con cinco entidades inventadas y dos tamaños de ventana, prueba de integridad de valores con cuatro campos y JSON estricto (n=8 por configuración), par de facturación con reutilización del razonamiento, pares de caché implícita con dos tiempos de espera y delimitación de su umbral mínimo, aceptación de un contexto de 279K tokens con una aguja, comparación del tokenizer con un corpus fijo en toda la familia V4 y pruebas de aceptación de sampling, prefill y n>1. La tasa de bucles procede de nueve ejecuciones por versión con max_tokens: 8192. Indicamos tokens en lugar de dólares porque DeepSeek cambió los precios de la familia V4 e introdujo la facturación por hora punta y valle el 2026-08-16, el día anterior a este lote. El comportamiento de rechazo y el bucle se comprobaron de nuevo por una segunda ruta de petición independiente. Las tarifas y el comportamiento pueden cambiar; vuelva a medir antes de depender de una cifra concreta.

← Volver al blog