DeepSeek V4 Pro (0813): Thinking Passback y matriz de 3 APIs

Este artículo recoge las notas de uso y los escollos de deepseek-v4-pro-0813. En AIHubMix, el modelo está disponible a través de las APIs Chat Completions, Responses y Messages compatible con Claude. Consulte también: documentación oficial de la API de DeepSeek.

Las conclusiones marcadas como "Verificado" y las respuestas de ejemplo de cada sección proceden de llamadas reales realizadas el 2026-08-13 a través de las APIs de AIHubMix (Chat Completions / Responses / Messages); los datos de especificaciones no marcados como "Verificado" proceden de la documentación oficial de DeepSeek.

1. Posicionamiento del modelo y especificaciones de un vistazo

V4 Pro es el nivel superior de la generación V4 de DeepSeek (el modelo ligero deepseek-v4-flash es su hermano). La línea de lanzamiento se remonta a DeepSeek-V4 Preview del 2026-04-24, y 0813 es la etiqueta de VERSIÓN DEL MODELO que DeepSeek asignó a la compilación actual. Más allá de las especificaciones en bruto, hay cuatro aspectos que lo distinguen:

• Un modelo frontera disperso: 1,6T de parámetros totales / 49B activados (arquitectura MoE, o mezcla de expertos: en cada pase de inferencia solo se activa un subconjunto de redes expertas; los parámetros totales determinan la capacidad de conocimiento y los activados determinan el coste de cómputo por llamada). La ficha del modelo enumera la atención híbrida CSA+HCA, mHC y el optimizador Muon.
• Pesos abiertos bajo licencia MIT: deepseek-ai/DeepSeek-V4-Pro se publica en HuggingFace bajo la licencia MIT (una de las licencias de código abierto más permisivas: se permite el uso comercial y la redistribución de código cerrado) y puede alojarse por cuenta propia. La licencia MIT es poco habitual para un modelo de este tamaño. Las notas de autoalojamiento de la ficha del modelo también sugieren una ventana de contexto de ≥384K tokens al ejecutar en Think Max (el nivel de pensamiento más alto); se trata de una orientación de despliegue para el autoalojamiento, no de una especificación de la API alojada.
• El soporte multiprotocolo es de primera mano, no una traducción de terceros: DeepSeek ofrece por sí mismo una API de Chat de OpenAI, un endpoint compatible con Anthropic (/anthropic, que asigna claude-opus* a este modelo) y la API Responses (DeepSeek describe un soporte nativo del formato, con adaptaciones para Codex). También ofrece la completación FIM (fill-in-the-middle, rellenar en medio) como función Beta en un endpoint separado, que no forma parte de las tres APIs de AIHubMix.
• Una brecha de ~120× entre el precio con acierto y sin acierto de caché: el precio publicado por DeepSeek es de 0,003625 $/M con acierto de caché frente a 0,435 $/M sin acierto (salida: 0,87 $/M), y la caché es automática, sin ningún parámetro que configurar. En cargas de trabajo que reutilizan prefijos largos (prompts de sistema, documentos extensos), esa diferencia domina la factura. El precio de venta real es el que muestre la página del modelo.

Verificado: superar max_tokens es rechazado por la validación en lugar de truncarse en silencio; enviar max_tokens=9999999 devuelve HTTP 400, y el cuerpo del error nombra el campo e indica el límite 393216.

# max_tokens=9999999 -> HTTP 400
"...max_tokens... 393216"

❗ Las imágenes no generan error, pero se descartan: la formulación oficial para la API Responses es "Image and file inputs are not supported (input_image parts do not cause an error, but are replaced with a placeholder text)"; es decir, una parte input_image no hace fallar la petición, sino que se sustituye por texto de marcador de posición. En Chat Completions, el content del mensaje de usuario solo admite una cadena, y en Messages los bloques type="image" están marcados como No compatibles. Al diseñar un enrutamiento multimodal, nunca considere que "no hay error" sea prueba de que el modelo realmente vio la imagen.

2. ¿Cómo se desactiva el pensamiento? Tres APIs, tres formas de campo

V4 Pro piensa por defecto: si no envía ningún parámetro, la respuesta llega con contenido de pensamiento. Desactivarlo usa una forma de campo distinta en cada una de las tres APIs.

Chat Completions

Use el objeto thinking de nivel superior.

from openai import OpenAI

client = OpenAI(
    base_url="https://aihubmix.com/v1",
    api_key="<AIHUBMIX_API_KEY>",
)

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "What is 2 + 2?"}],
    extra_body={"thinking": {"type": "disabled"}},
)

# Thinking on  (default): message.reasoning_content present, reasoning_tokens = 43
# Thinking off (disabled): reasoning_content absent, reasoning_tokens absent

Verificado: con thinking.type="disabled", desaparecen a la vez message.reasoning_content y usage.completion_tokens_details.reasoning_tokens, lo que confirma que el interruptor surtió efecto.

Responses

En Responses no hay un interruptor aparte; desactivar el pensamiento equivale a establecer el nivel en none.

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="What is 2 + 2?",
    reasoning={"effort": "none"},
)

# effort="none": usage.output_tokens_details.reasoning_tokens = 0
#                output[0] is the message item directly (no reasoning item)
# effort unset : output always starts with a reasoning item

Verificado: reasoning.effort="none" se diferencia de forma observable del nivel por defecto (los tokens de pensamiento caen a cero y desaparece el elemento de salida reasoning), lo que confirma que surtió efecto.

Messages

Mismo nombre y misma forma que en Chat Completions: el objeto thinking de nivel superior.

from anthropic import Anthropic

client = Anthropic(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com",
)

response = client.messages.create(
    model="deepseek-v4-pro-0813",
    max_tokens=1024,
    messages=[{"role": "user", "content": "What is 2 + 2?"}],
    extra_body={"thinking": {"type": "disabled"}},
)

# Thinking on  (default): content = [thinking block, text block]
# Thinking off (disabled): content = [text block]

Verificado: una vez desactivado, el bloque thinking desaparece por completo y solo queda el bloque text.

Sobre los niveles de pensamiento: en las pruebas, low y max devolvieron 200 en Chat Completions (high es el valor por defecto y se aplica cuando se omite el campo), pero los recuentos de tokens de pensamiento no muestran una diferencia monótona entre niveles para la misma pregunta (pregunta fácil: low=43 / max=27; pregunta difícil: low=114 / max=92), y nada se repite en la respuesta: los niveles se aceptan, pero la respuesta no permite observar ninguna señal que los distinga. En Responses, solo se puede confirmar desde la respuesta el nivel none (pensamiento desactivado).

3. ¿Por qué una conversación de varios turnos devuelve de pronto 400? El historial de pensamiento debe reenviarse literalmente

Este es el escollo más común con este modelo: en modo de pensamiento, una conversación de varios turnos debe reenviar literalmente el contenido de pensamiento del turno anterior, o la petición se rechaza. No se degrada ni pierde calidad: es un HTTP 400 en toda regla.

Las tres APIs transportan el mismo contenido de pensamiento bajo nombres de campo distintos:

Verificado (condiciones de activación): esta validación se dispara de forma constante en peticiones de varios turnos que incluyen tools (el modelo emite una llamada a herramienta y después se devuelve el resultado). En peticiones de varios turnos sin herramientas, donde el modelo responde directamente, la validación no se disparó en esta ronda de pruebas y la petición devolvió 200. Dicho de otro modo, la orquestación de herramientas (cargas de trabajo de agentes o de llamadas a funciones) es donde es más probable encontrarlo, así que trate el contenido de pensamiento como parte del estado de la conversación que debe persistir y reproducir.

Chat Completions

# Multi-turn: pass the previous assistant message back verbatim, including reasoning_content
messages = [
    {"role": "user", "content": "What is 1 + 1? Remember the result."},
    {
        "role": "assistant",
        "content": "2",
        "reasoning_content": "<reasoning_content from the previous response>",
    },
    {"role": "user", "content": "Add 1 to the result."},
]

# Dropping reasoning_content -> HTTP 400 invalid_request_error

Verificado: un mensaje histórico del asistente sin reasoning_content devuelve 400; al añadirlo, la misma petición devuelve 200 y continúa correctamente.

Responses

# Multi-turn: input = previous input + response.output (reasoning item included) + new message
input = previous_input + response.output + [
    {"role": "user", "content": "Add 1 to the result."}
]

# Filtering out the type="reasoning" item -> HTTP 400

Verificado: basta con volver a insertar response.output tal cual. Filtrar los elementos de salida con type == "message" al montar el historial elimina el elemento reasoning y provoca el 400; es la forma más común de tropezar con ello.

Messages

# Multi-turn: pass response.content back verbatim as the assistant message
messages = [
    {"role": "user", "content": "What's the weather in Paris?"},
    {"role": "assistant", "content": response.content},   # thinking + tool_use blocks
    {"role": "user", "content": [tool_result_block]},
]

# Stripping the thinking block -> HTTP 400

Verificado: eliminar el bloque thinking del array de contenido devuelve 400 (con error.type igual a invalid_request_error).

4. Llamadas a herramientas

Cada API declara las herramientas con la forma de su propio protocolo; las formas no son intercambiables.

Chat Completions

Forma anidada (un objeto function que envuelve name / parameters). Un tool_choice con nombre de función fuerza la llamada.

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "What's the weather in Paris?"}],
    tools=[{
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get weather for a city",
            "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
        },
    }],
    tool_choice={"type": "function", "function": {"name": "get_weather"}},
)

# Observed: finish_reason "tool_calls", tool_calls[0].function.arguments = {"city": "Paris"}

❗ Verificado: tool_choice: "required" no puede usarse con el pensamiento activado: devuelve 400 Thinking mode does not support this tool_choice; al desactivar el pensamiento (thinking.type="disabled"), la misma petición devuelve 200. Cuando necesite la semántica de "debe llamar a una herramienta", use un tool_choice tool_choice (como en el ejemplo anterior, que funciona con el pensamiento activado), o desactive antes el pensamiento y luego use required.

Responses

Forma plana (type / name / parameters al mismo nivel).

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="What's the weather in Paris?",
    tools=[{
        "type": "function",
        "name": "get_weather",
        "description": "Get weather for a city",
        "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    }],
)

# Observed output items: ["reasoning", "function_call"]; arguments = {"city": "Paris"}

Verificado: copiar la forma anidada de Chat Completions (function: {...}) en Responses devuelve 400; use la forma plana. tool_choice: "required" está sujeto a la misma restricción del modo de pensamiento que en Chat.

Messages

Forma nativa de Anthropic (input_schema), con tool_choice: {"type": "any"} para forzar una llamada.

response = client.messages.create(
    model="deepseek-v4-pro-0813",
    max_tokens=1024,
    tools=[{
        "name": "get_weather",
        "description": "Get weather for a city",
        "input_schema": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    }],
    tool_choice={"type": "any"},
    messages=[{"role": "user", "content": "What's the weather in Paris?"}],
)

# Observed: content contains a tool_use block, name = get_weather, input = {"city": "Paris"}

❗ La llamada paralela a herramientas no puede desactivarse, por diseño de DeepSeek: la página oficial de compatibilidad con Anthropic indica, en la fila de tool_choice, que disable_parallel_tool_use is ignored, y la página de Responses dice lo mismo con parallel_tool_calls | Ignored (parallel tool calling is always enabled). Las pruebas coinciden: preguntar por dos ciudades a la vez con disable_parallel_tool_use: true sigue devolviendo dos bloques tool_use. Si necesita ejecución en serie, tome la primera llamada o gestione la cola usted mismo en el cliente.

Número de herramientas y coste de contexto: enviar 200 definiciones de función en una sola solicitud devolvió igualmente 200 con una respuesta normal y no activó ninguna validación de cantidad (observado en esta ruta; no se probaron cantidades mayores). Sin embargo, prompt_tokens de esa solicitud alcanzó 6.105: las definiciones de herramientas entran completas en el contexto y se facturan. Cuando tengas muchas herramientas, recorta el conjunto de herramientas según el escenario en lugar de declarar todas incondicionalmente.

5. Salida estructurada

Chat Completions

response_format admite el modo JSON.

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "Return {\"a\": 1} as JSON."}],
    response_format={"type": "json_object"},
)

# Observed response content: {"a":1}

Verificado: la salida es JSON válido.

Responses

Declara un JSON Schema mediante text.format, con soporte del modo strict.

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="Return the number 1 under key a.",
    text={
        "format": {
            "type": "json_schema",
            "name": "extract",
            "strict": True,
            "schema": {"type": "object", "properties": {"a": {"type": "integer"}}, "required": ["a"]},
        }
    },
)

# Observed output text: {"a":1}

Verificado: la salida se ajusta estrictamente al esquema indicado.

Messages

El protocolo Messages (Anthropic) no tiene equivalente a response_format / text.format. El patrón habitual es incluir el esquema en una herramienta: declara una herramienta cuyo input_schema sea tu esquema objetivo, establece tool_choice: {"type": "any"} y lee el resultado estructurado desde el input del bloque tool_use. En esta ronda de pruebas no se verificó específicamente ese patrón; si necesitas garantías estrictas de esquema, prefiere Chat Completions o Responses.

6. ¿Cómo activar la caché de contexto? No hay que activarla, es automática

La caché de contexto (los prefijos idénticos se reutilizan y la parte en caché se factura a una tarifa menor) está activada por defecto y no necesita parámetros. Una segunda solicitud con el mismo prefijo largo informa del acierto en usage, bajo un nombre de campo que varía según la API. Para detalles de la caché y precios actuales, consulta la página del modelo; para la estrategia de caché entre modelos y técnicas para mejorar la tasa de aciertos, consulta las prácticas de caché de prompts.

Chat Completions

# usage of the second call with an identical long prefix
"prompt_tokens_details": {"cached_tokens": 640}   # first call: 0

Verificado: dos llamadas consecutivas con el mismo prefijo largo en el mismo canal hicieron que cached_tokens pasara de 0 a 640.

Responses

# usage of the second call with identical long instructions
"input_tokens_details": {"cached_tokens": 896}    # first call: 0

Messages

# usage of a call whose long system prefix was already warmed
"cache_read_input_tokens": 896

Verificado: el prefijo anterior fue precalentado por una solicitud Responses con contenido idéntico, y la primera llamada Messages acertó 896 de inmediato, lo que es coherente con que la caché se indexe por el prefijo del contenido y se comparta entre las superficies de protocolo.

7. logprobs: Chat devuelve dos canales

logprobs (probabilidades logarítmicas: el detalle de confianza del modelo por cada token candidato) llega con formas distintas en las dos APIs, y el código de parseo debe tratarlas por separado.

Chat Completions

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "Say hi."}],
    logprobs=True,
    top_logprobs=2,
)

# Observed: choices[0].logprobs contains TWO arrays
#   logprobs.content[]            -> tokens of the final answer
#   logprobs.reasoning_content[]  -> tokens of the thinking text

❗ Verificado: Chat devuelve probabilidades logarítmicas tanto para content como para reasoning_content. El código que lee solo logprobs.content, según la forma estándar de respuesta de OpenAI, no fallará, pero omitirá en silencio el canal de razonamiento; si tu código supone un único array bajo logprobs, añade antes una comprobación de forma.

Responses

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="Say hi.",
    top_logprobs=3,
)

# Observed: logprobs only on the final message item
#   output[-1].content[0].logprobs[] with logprob + top_logprobs details

Verificado: Responses adjunta logprobs solo al último elemento de texto; no aparece la forma de doble canal que se ve en Chat.

Messages

El protocolo Messages (Anthropic) no tiene un campo equivalente. Para el detalle de probabilidades a nivel de token, usa Chat Completions o Responses.

8. ¿Qué APIs pueden buscar en la web?

La búsqueda web aquí es una herramienta del lado del servidor (la recuperación se ejecuta en el servidor; el cliente nunca emite la solicitud por sí mismo), y en las pruebas se ejecuta realmente tanto en la API Responses como en la API Messages.

Responses

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="What is the latest stable version of Python?",
    tools=[{"type": "web_search"}],
)

# Observed output item sequence:
# ["reasoning", "web_search_call", "reasoning", "message"]

Verificado: aparece un elemento web_search_call en la secuencia de salida, lo que indica que el servidor realmente ejecutó una recuperación.

Messages

response = client.messages.create(
    model="deepseek-v4-pro-0813",
    max_tokens=1024,
    tools=[{"type": "web_search_20250305", "name": "web_search"}],
    messages=[{"role": "user", "content": "What is the latest stable version of Python?"}],
)

# Observed content block sequence:
# ["thinking", "server_tool_use", "web_search_tool_result", "thinking", "text"]
# usage.server_tool_use.web_search_requests = 1

Verificado: usage.server_tool_use.web_search_requests cuenta 1; la recuperación realmente ocurrió y se contabilizó.

Chat Completions

La búsqueda web no puede activarse en Chat. La referencia oficial de la API de Chat de DeepSeek no contiene ningún campo de herramienta de búsqueda en el esquema de la solicitud (esta ausencia se estableció revisando la lista de campos uno por uno; DeepSeek no ha hecho ninguna declaración explícita negando el soporte). La API con una declaración oficial explícita de soporte para búsqueda del lado del servidor es Responses (web_search), y la página oficial de compatibilidad de Messages también enumera los bloques de contenido relacionados con la búsqueda.

# Three control groups, same question requiring live information, all HTTP 200:
# A no search field       -> "cannot retrieve", annotations = null
# B web_search_options    -> "cannot retrieve", annotations = null, usage identical to A
# C enable_search         -> "cannot retrieve", annotations = null, usage identical to A

Verificado: enviar web_search_options o enable_search no provoca error, pero tampoco recupera nada: la respuesta no incluye annotations (la lista de citas que se adjunta a una respuesta cuando se ejecuta la búsqueda web), y el uso coincide con el grupo de control campo por campo. Para acceso web, usa la API Responses o Messages.

9. Notas de uso: el diseño de DeepSeek frente a las desviaciones en nuestra ruta

Todo lo que sigue devuelve HTTP 200 mientras se comporta de forma contraintuitiva. Las causas difieren, y también lo que debes hacer al respecto, así que se listan por separado: el primer grupo es el diseño de DeepSeek para el modelo, y cambiar de proveedor no lo cambiará; el segundo grupo es el comportamiento actual en la ruta de AIHubMix, en el que estamos trabajando.

9.1 Según el diseño de DeepSeek

9.2 Comportamiento actual en la ruta de AIHubMix

9.3 No definido por DeepSeek, así que no hay veredicto en ningún sentido

Enviar un valor fuera del enum de reasoning_effort (por ejemplo bogus_xyz) devuelve 200 con una respuesta normal, sin error y sin efecto observable. El hecho está lo bastante claro: esta ruta actualmente no valida el enum de reasoning_effort. Lo que no está claro es si debería: DeepSeek publica el enum válido, pero nunca indica si un nivel ilegal debe rechazarse, así que no hay referencia contra la que juzgar; por tanto, esto no cuenta ni como comportamiento oficial ni como defecto en nuestra ruta. El enfoque seguro en el cliente es validar tú mismo el nivel y no confiar en que la API lo detecte.

10. Matriz de soporte de capacidades × API

Las celdas siguientes muestran la forma exacta del parámetro o campo para cada API. Salvo donde se marque como redacción explícita de DeepSeek, todas las conclusiones provienen de llamadas reales realizadas el 2026-08-13 contra las APIs de producción de AIHubMix.

Leyenda: ✅ verificado como funcional · 🟡 aceptado pero no se puede confirmar que sea efectivo · ❗ requiere atención (ver las notas anteriores) · ➖ no existe tal concepto en esta API

Preguntas frecuentes

¿Qué API admite deepseek-v4-pro-0813 en AIHubMix?
Chat Completions (/v1/chat/completions), Responses (/v1/responses) y la API Messages compatible con Claude (/v1/messages).

¿Por qué una conversación de varios turnos devuelve de repente 400?
La causa más común es que no se devolvió el historial de pensamiento. En el modo de pensamiento, el contenido de pensamiento del turno anterior debe reenviarse tal cual: reasoning_content en el mensaje del asistente para Chat, el elemento de salida type="reasoning" para Responses y el bloque de contenido thinking para Messages. Las conversaciones de varios turnos con herramientas son donde más se nota. Muchos frameworks filtran los elementos de salida por type == "message" al armar el historial, lo que elimina el elemento de razonamiento.

¿Se puede desactivar el pensamiento?
Sí. Envía thinking: {"type": "disabled"} en Chat o Messages, y reasoning: {"effort": "none"} en Responses. Una vez desactivado, desaparecen tanto el contenido de pensamiento como los tokens de pensamiento.

¿Difieren los tres niveles de reasoning_effort?
low, high y max se aceptan todos (el valor predeterminado es high; medium y xhigh se asignan a high por compatibilidad). En las pruebas, el número de tokens de pensamiento para una misma pregunta no muestra una diferencia monótona entre niveles y no se devuelve nada en la respuesta, por lo que la diferencia no puede confirmarse desde el lado del cliente. Solo el nivel none en Responses (pensamiento desactivado) produce una diferencia clara y observable.

¿Por qué tool_choice: "required" devuelve 400?
Ese valor no se acepta mientras el pensamiento está activado (el cuerpo del error dice Thinking mode does not support this tool_choice). Usa un tool_choice con nombre de función ({"type": "function", "function": {"name": "..."}}) para forzar una llamada específica con el pensamiento activado, o desactiva primero el pensamiento y luego usa required.

¿Cómo se activa la caché de contexto?
No hace falta activarla, es automática. Coloca al principio de la solicitud el contenido estable e invariable (prompts del sistema, fragmentos de conocimiento, definiciones de herramientas), y el número de aciertos se informa en usage: prompt_tokens_details.cached_tokens en Chat, input_tokens_details.cached_tokens en Responses y cache_read_input_tokens en Messages.

Para ver los precios y el estado en tiempo real, consulta la página del modelo deepseek-v4-pro-0813; para más modelos, visita la galería de modelos.

Guías prácticas relacionadas: guía práctica de Kimi K3 (nuevos parámetros y matriz de soporte de tres API) y cambios en la caché de prompts y la facturación de GPT-5.6.