DeepSeek V4 Flash o Pro: elige la API según la tarea

Un pipeline de texto puede necesitar extracción, revisión de documentos o roleplay, cada uno con un presupuesto de salida distinto. Para una integración nueva, empieza con deepseek/v4.1-flash/chat: $0.30 de entrada y $1.20 de salida por millón, con un límite de respuesta de 384.000 tokens. Si tu integración está fijada a un ID de V4, usa V4 Flash para el trabajo rutinario; elige Pro por su control explícito de llamadas paralelas a herramientas, para una respuesta de más de 65.536 tokens o para una tarea concreta en la que su resultado justifique pagar el triple por token. Los dos ID de V4 leen 1.048.576 tokens, así que una entrada larga por sí sola no es motivo para pagar Pro.

La guía de migración a V4.1 Flash cubre la ruta para proyectos nuevos. Las comparaciones siguientes se aplican a los dos ID alojados de V4.

Qué modelo para qué trabajo

Las diferencias del contrato

Las páginas de V4 Flash y V4 Pro muestran los campos alojados actuales. Ambos permiten hasta 256 mensajes y 128 definiciones de herramientas, con hasta 60 minutos por petición, y ninguno expone temperature ni top_p. La página de comparación de SpicyAPI muestra los mismos campos a partir del esquema en vivo.

Ambos endpoints rechazan los campos que no enumeran. Un cuerpo copiado del endpoint de Pro con parallel_tool_calls falla la validación en Flash en lugar de ignorarse, así que mantén separados los campos propios de cada modelo en vez de enviar la unión.

Dónde están estos ID en origen. El registro de cambios actual de DeepSeek retira V4 Flash y redirige temporalmente su alias antiguo a V4.1 Flash, mientras que el servicio de V4 Pro continúa con la facturación sin cambios. SpicyAPI lista los ID separados de arriba; fija el ID alojado completo, no un alias de origen, al mantener una integración con V4. El anuncio del 10 de septiembre de DeepSeek describe las redirecciones de los alias nativos, así que un resultado de un foro que usara alias nativos puede que no compare en absoluto las versiones originales de V4; distingue nombres de modelo, ID con versión y resultados observados antes de fiarte de cualquier página de «Flash vs Pro». Para un proyecto nuevo, el precio más bajo y el mayor límite de respuesta de V4.1 Flash son la razón práctica para empezar ahí.

Qué encontraron otros desarrolladores con el par

Un benchmark de revisión de código de 18 ejecuciones sobre una base de código en Python, con las versiones fechadas 0731 de Flash y 0813 de Pro, encontró una diferencia útil:

• Cobertura: Pro produjo 169 afirmaciones verificables frente a las 70 de Flash. La exactitud de las afirmaciones fue similar: 95,9 % frente a 95,7 %.
• Detección de errores: Flash encontró los tres errores latentes conocidos; Pro encontró uno. Flash también inventó un caso límite, así que verifica las correcciones propuestas contra el código fuente.
• Consistencia: la profundidad de los informes de Pro varió 2,7 veces entre ejecuciones repetidas. Un escaneo con Flash seguido de una verificación enfocada con Pro dio el mejor resultado en ese montaje.

Usa Flash para la primera pasada económica y envía a Pro un hallazgo poco claro, su fuente y una pregunta precisa. El informe de ninguno de los dos modelos sustituye la comprobación del código fuente ni las pruebas de la aplicación.

Pruébalo primero en el Playground

1. Abre DeepSeek V4 Flash y cambia al Playground.
2. Pega el registro de aprobación del catálogo y de tiempo de espera del inventario del ejemplo. Pregunta si el job E42 puede exportarse.
3. Repite con V4 Pro y la misma entrada. Ambas respuestas deberían bloquear la exportación porque la consulta actual del inventario falló.

Prueba ambos en una decisión con una única respuesta correcta

Supón que la exportación de la tienda de un creador depende de un catálogo aprobado y de una consulta actual del inventario. El modelo debe nombrar qué bloquea la exportación sin tratar un paso pendiente como completado. El caso de prueba es lo bastante barato como para ejecutarlo en ambos modelos antes de enviar una transcripción grande.

Define SPICY_API_KEY con una clave de API Keys. La petición usa la interfaz Chat Completions de SpicyAPI.

cat > request.json <<'JSON'
{
  "model": "deepseek/v4-flash/chat",
  "messages": [
    {
      "role": "system",
      "content": "Return JSON with can_export (boolean), blockers (array of strings), and evidence (array of exact source quotes). Use only the supplied record. Every required dependency must be complete before export."
    },
    {
      "role": "user",
      "content": "Job E42 requires catalog approval and a current inventory lookup. Record: \"Catalog approved at 10:00. Inventory lookup timed out at 10:03. The last inventory snapshot is from yesterday.\" Can this job be exported now?"
    }
  ],
  "max_tokens": 2048,
  "reasoning_effort": "low",
  "response_format": {
    "type": "json_object"
  }
}
JSON

curl --fail-with-body https://api.spicyapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $SPICY_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  --data-binary @request.json --output response.json

python3 - <<'PY'
import json
from pathlib import Path

response = json.loads(Path("response.json").read_text())
choice = response["choices"][0]
if choice.get("finish_reason") != "stop":
    raise SystemExit("FAIL: reply did not finish normally")
answer = json.loads(choice["message"]["content"])
quotes = {"Catalog approved at 10:00.",
          "Inventory lookup timed out at 10:03.",
          "The last inventory snapshot is from yesterday."}
blockers = answer.get("blockers")
evidence = answer.get("evidence")
valid = (
    answer.get("can_export") is False
    and isinstance(blockers, list) and bool(blockers)
    and all(isinstance(item, str) and item.strip() for item in blockers)
    and any("inventory" in item.lower() for item in blockers)
    and isinstance(evidence, list) and bool(evidence)
    and all(isinstance(item, str) and item in quotes for item in evidence)
    and "Inventory lookup timed out at 10:03." in evidence
)
if not valid:
    raise SystemExit("FAIL: decision, blocker or source evidence is incorrect")
print("PASS: export is blocked by the timed-out inventory lookup")
PY

La decisión correcta es can_export: false, con la falta de inventario actual como bloqueo. La instantánea de ayer no es la consulta actual exigida, y el array evidence debería citar la línea del tiempo de espera agotado.

Esto es una comprobación del caso de prueba, no un validador de negocio general: las exportaciones reales deben usar los estados de dependencia reales de tu aplicación. Un modelo puede citar una frase real y aun así sacar la conclusión equivocada, por eso aquí se comprueban tanto la decisión como la evidencia.

Para ejecutar Pro con la misma entrada, cambia solo el ID del modelo. Mantén idénticos la fuente, las instrucciones, el esfuerzo y el límite de salida, y puntúa cada respuesta en dos aspectos: ¿nombró el bloqueo? y ¿las citas aparecen en el registro? Una explicación más larga no es una mejor decisión.

Si Flash lo supera, este caso de prueba no te da motivo para pagar Pro en esa tarea. Si alguno de los dos modelos inventa un éxito del inventario, no pases su respuesta a la siguiente fase solo porque el JSON se analizó bien. Si ambos fallan, comprueba que el requisito estaba formulado con claridad antes de tratar un precio más alto como solución.

Deja que un Agent prepare la llamada

Para comprobaciones repetidas de decisiones de exportación, pide a tu Agent de programación que use la Skill de SpicyAPI: «Read deepseek/v4-flash/chat, then adapt the example to my input; show the request before running it.» La consulta con la CLI es spicyapi models get deepseek/v4-flash/chat --json; con el MCP, spicyapi_model_get con model: "deepseek/v4-flash/chat". Las llamadas de chat usan un cliente compatible o la API de chat; los comandos de tareas multimedia no generan respuestas de chat.

¿Qué flujo de trabajo merece la tarifa más alta?

Para extraer la fecha de lanzamiento, los nombres de los personajes y el número de imágenes solicitado de un creador a partir de un briefing completo, Flash tiene los controles habituales y capacidad de salida de sobra. El mayor límite de salida de Pro no aporta nada a un objeto JSON corto. Empieza con Flash y usa valores ausentes explícitos para que «no release date supplied» no se convierta en una fecha inventada.

En una revisión de dependencias con varios registros, concreta las reglas del job. Una referencia de personaje aprobada no basta cuando el plano necesita un segundo personaje aprobado y un asset de inventario actual. Un modelo debe identificar la aprobación que falta del segundo personaje aunque la transcripción de producción circundante repita que el plano está listo. El caso de prueba anterior comprueba esta distinción con el inventario. Puede valer la pena comparar con Pro en un job complejo que falle.

En una transformación muy grande, el requisito de salida puede decidir la elección sin afirmar nada sobre calidad. Si el documento realmente devuelto debe superar los 65.536 tokens en una sola respuesta, el límite de Flash no basta y Pro permite más salida. Si los registros independientes pueden devolverse en grupos más pequeños, el procesamiento por lotes puede mantener Flash utilizable y facilitar reintentar un grupo fallido. No dividas una tarea cuya respuesta dependa de relaciones entre esos grupos sin trasladar esas relaciones de uno a otro.

Una escalada selectiva solo es económica mientras siga siendo selectiva. Con los supuestos de 50.000 tokens de entrada y 3.000 de salida de abajo, 900 llamadas a Flash más 100 a Pro cuestan $31.152, frente a $77.88 por las 1.000 en Pro. Si cada job pasa primero por Flash y 100 necesitan luego Pro, el total combinado es de $33.748. Son totales hipotéticos que explican el equilibrio de los reintentos; el uso real de tokens variará.

Cuánto cuesta una petición con el mismo uso

Para una petición con 50.000 tokens de entrada sin caché y 3.000 tokens de salida facturados:

• Flash: 50.000 × $0.44/M + 3.000 × $1.32/M = $0.02596.
• Pro: 50.000 × $1.32/M + 3.000 × $3.96/M = $0.07788.

Mil peticiones así cuestan $25.96 y $77.88. Si 40.000 de los tokens de entrada son lecturas de caché y 10.000 no, las cifras por petición pasan a $0.00892 para Flash y $0.02684 para Pro. Las tarifas de caché no guardan una proporción exacta de tres a uno, así que calcula los totales en lugar de redondear a partir de la tarifa de cabecera.

Dos cosas mueven más la factura que la elección del modelo:

• El razonamiento se factura como salida. El esfuerzo por defecto es high. Para extracción y clasificación, prueba low, o none para omitir la pasada de razonamiento, y compara los resultados aceptados además de los tokens.
• Los reintentos cuentan. Lo que importa es el coste por respuesta aceptada, no por llamada.

La escalada selectiva conserva la mayor parte del ahorro. Envía todo a Flash y manda a Pro un resultado fallido o ambiguo junto con la evidencia de por qué falló. Si una de cada diez peticiones se escala con el uso anterior, y una petición escalada paga tanto la llamada a Flash como la de Pro, el promedio es de unos $0.03375 por petición, frente a $0.0779 con todo en Pro. Un segundo modelo puede repetir el mismo error, así que mantén la comprobación real de corrección de la tarea.

Cuándo importa la mayor salida de Pro

El límite de 384.000 tokens importa solo cuando la respuesta necesaria supera de verdad los 65.536 tokens, por ejemplo un plan de migración ordenado con el SQL y el rollback de cada paso que deba volver junto. Un informe corto sobre una entrada larga no cuenta: la capacidad de entrada es idéntica.

Antes de pedir una respuesta enorme, comprueba que tu consumidor pueda validarla y almacenarla. Una edición capítulo por capítulo, o registros divididos en grupos independientes, se recuperan con más facilidad tras una interrupción. Mantén una sola respuesta únicamente cuando las partes dependan de una estructura común.

No confundas el máximo con el valor por defecto. Ambos usan por defecto 32.768 tokens de salida, y una respuesta que llega al límite se corta sin error. Fija un valor explícito pequeño para tareas cortas como el caso de prueba anterior, y uno mayor solo donde el entregable lo necesite.

Cuándo importan las llamadas paralelas a herramientas

Pro acepta parallel_tool_calls; Flash no. Eso te dice qué cuerpo de petición puedes enviar, no que Flash no pueda usar herramientas: ambos aceptan definiciones de herramientas y tool_choice.

Las lecturas independientes son candidatas a llamadas paralelas, como obtener a la vez un catálogo aprobado y un registro de inventario. La acción de exportar depende de ambos resultados y debe esperar. Impón esa dependencia en tu aplicación en lugar de tratar una secuencia de herramientas propuesta como permiso para actuar. Poner parallel_tool_calls en false en Pro da como máximo una llamada por turno cuando cada llamada necesita el resultado anterior.

Si tu bucle requiere ese control explícito, es una razón concreta para Pro. Si ejecuta consultas secuenciales y devuelve una respuesta corta, empieza con Flash y añade concurrencia solo cuando el bucle base funcione.

Escritura y roleplay sin censura

Ambos modelos tienen el nivel «Uncensored» en SpicyAPI: sin filtro de contenido de la plataforma, y lo que queda es el comportamiento propio de cada modelo. En nuestras pruebas de la escalera de contenido de septiembre de 2026, ambos rechazaron una petición directa de la categoría de escena adulta de mayor intensidad (L4 en las reseñas) cuando llegaba sin contexto, y ambos la escribieron cuando un prompt de sistema establecía un marco de escritura de ficción:

En L5, cada modelo completó tres formulaciones del briefing de ficción para adultos y tres de un briefing aparte de ficción cruda no adulta. Flash suavizó una ejecución en la categoría sugerente más leve; el resto de las pruebas de niveles inferiores se completaron. Así que para ficción adulta, enmarca el job en el prompt de sistema con cualquiera de los dos modelos, y no pagues Pro con la esperanza de que rechace menos. Nuestras reseñas de V4 Flash y V4 Pro enumeran cada ejecución.

El roleplay genera mucha salida, que es donde se nota la proporción de precio de tres a uno: unos $0.57 por 100 turnos en Flash frente a $1.72 en Pro, suponiendo 10.000 tokens de entrada sin caché y 1.000 tokens de salida facturados por turno, incluido cualquier razonamiento.

FAQ

¿Basta V4 Flash para programar?

Es el punto de partida más barato, y el benchmark de una sola base de código encontró con Flash los tres errores conocidos. Antes de una edición sugerida, verifica el código fuente citado y ejecuta las pruebas afectadas. Una pasada enfocada con Pro es una opción de escalada, no un sustituto de esas comprobaciones.

¿Flash es lento?

La revisión de SpicyAPI registró 40 tokens de salida por segundo para Flash y 46 para Pro. Esa diferencia modesta no es motivo, por sí sola, para triplicar el presupuesto de tokens, y la latencia real depende del razonamiento y de la respuesta. Baja el esfuerzo en tareas cortas en lugar de fiarte de esa instantánea como garantía de velocidad actual.

¿Por qué elegiría Flash si Pro es el modelo más grande?

Ambos ID alojados aceptan la misma entrada larga, mientras que Flash cuesta aproximadamente un tercio con las tarifas de tokens sin caché. Para respuestas cortas de extracción o clasificación, el mayor límite de salida de Pro no aporta nada por sí solo. Escala un resultado ambiguo cuando tengas una pregunta concreta para la pasada más cara.

¿Debo empezar una integración nueva en V4 o en V4.1 Flash?

Empieza con V4.1 Flash, salvo que necesites un contrato concreto de V4 o tengas una integración fijada que mantener. Solo el alias retirado de V4 Flash se redirige a V4.1; V4 Pro continúa, y estos contratos alojados siguen listados por separado. Vuelve a comprobar cualquier comportamiento del que dependa tu aplicación antes de mover el tráfico de producción.