DeepSeek V4 Flash ou Pro : choisir l'API selon la tâche

Un pipeline de texte peut demander de l'extraction, une revue de documents ou du jeu de rôle, chacun avec un budget de sortie différent. Pour une nouvelle intégration, commencez par deepseek/v4.1-flash/chat : $0.30 en entrée et $1.20 en sortie par million, avec un plafond de réponse de 384 000 tokens. Si votre intégration est liée à un ID V4, utilisez V4 Flash pour le travail courant ; choisissez Pro pour son contrôle explicite des appels d'outils parallèles, pour une réponse de plus de 65 536 tokens, ou pour une tâche précise dont le résultat justifie un prix du token trois fois plus élevé. Les deux ID V4 lisent 1 048 576 tokens : une longue entrée ne suffit donc pas à justifier Pro.

Le guide de migration vers V4.1 Flash couvre la voie pour un nouveau projet. Les comparaisons ci-dessous portent sur les deux ID V4 hébergés.

Quel modèle pour quelle tâche

Les différences de contrat

Les pages V4 Flash et V4 Pro montrent les champs hébergés actuels. Les deux autorisent jusqu'à 256 messages et 128 définitions d'outils, avec jusqu'à 60 minutes par requête, et aucun n'expose temperature ni top_p. La page de comparaison de SpicyAPI présente les mêmes champs d'après le schéma en direct.

Les deux endpoints rejettent les champs qu'ils ne listent pas. Un corps copié depuis l'endpoint Pro avec parallel_tool_calls échoue à la validation sur Flash au lieu d'être ignoré : gardez donc les champs propres à chaque modèle séparés plutôt que d'envoyer leur union.

Où en sont ces ID côté DeepSeek. Le journal des modifications actuel de DeepSeek retire V4 Flash et redirige temporairement son ancien alias vers V4.1 Flash, tandis que le service V4 Pro continue avec une facturation inchangée. SpicyAPI liste les ID distincts ci-dessus ; épinglez l'ID hébergé complet, et non un alias amont, pour maintenir une intégration V4. L'annonce du 10 septembre de DeepSeek décrit les redirections d'alias natifs : un résultat de forum obtenu avec des alias natifs ne compare donc peut-être pas du tout les versions V4 d'origine. Distinguez noms de modèles, ID versionnés et résultats observés avant de vous fier à une page « Flash vs Pro ». Pour un nouveau projet, le prix plus bas et le plafond de réponse plus élevé de V4.1 Flash sont la raison pratique d'y commencer.

Ce que d'autres développeurs ont constaté avec cette paire

Un benchmark de revue de code de 18 exécutions sur une base de code Python, avec les instantanés datés 0731 pour Flash et 0813 pour Pro, a relevé une différence utile :

• Couverture : Pro a produit 169 affirmations vérifiables contre 70 pour Flash. L'exactitude des affirmations était proche : 95,9 % contre 95,7 %.
• Détection de bugs : Flash a trouvé les trois bugs latents connus ; Pro en a trouvé un. Flash a aussi inventé un cas limite : vérifiez donc les correctifs proposés dans le code source.
• Régularité : la profondeur des rapports de Pro variait d'un facteur 2,7 entre exécutions répétées. Un balayage Flash suivi d'une vérification ciblée par Pro a donné les meilleurs résultats dans ce montage.

Utilisez Flash pour la première passe peu coûteuse et envoyez à Pro un constat incertain, sa source et une question précise. Le rapport d'aucun des deux modèles ne remplace la vérification de la source ni les tests de l'application.

Essayer d'abord dans le Playground

1. Ouvrez DeepSeek V4 Flash et passez au Playground.
2. Collez l'enregistrement d'approbation du catalogue et de délai d'attente de l'inventaire de l'exemple. Demandez si le job E42 peut être exporté.
3. Répétez avec V4 Pro et la même entrée. Les deux réponses doivent bloquer l'export, car la consultation actuelle de l'inventaire a échoué.

Tester les deux sur une décision à une seule bonne réponse

Supposons que l'export de la boutique d'un créateur dépende d'un catalogue approuvé et d'une consultation actuelle de l'inventaire. Le modèle doit nommer ce qui bloque l'export sans traiter une étape en attente comme terminée. Ce jeu de test est assez peu coûteux pour être lancé sur les deux modèles avant d'envoyer une longue transcription.

Définissez SPICY_API_KEY avec une clé prise dans les API Keys. La requête utilise l'interface 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 bonne décision est can_export: false, avec l'inventaire actuel manquant comme blocage. L'instantané d'hier n'est pas la consultation actuelle requise, et le tableau evidence doit citer la ligne du délai d'attente dépassé.

Il s'agit d'un contrôle sur un jeu de test, pas d'un validateur métier général : les vrais exports doivent s'appuyer sur les statuts de dépendances réels de votre application. Un modèle peut citer une vraie phrase et en tirer pourtant la mauvaise conclusion, c'est pourquoi la décision et les preuves sont toutes deux vérifiées ici.

Pour lancer Pro sur la même entrée, ne changez que l'ID du modèle. Gardez la source, les instructions, l'effort et le plafond de sortie identiques, et notez chaque réponse sur deux points : a-t-elle nommé le blocage, et les citations figurent-elles dans l'enregistrement ? Une explication plus longue n'est pas une meilleure décision.

Si Flash réussit, ce jeu de test ne vous donne aucune raison de payer Pro pour cette tâche. Si l'un des modèles invente une réussite de l'inventaire, ne transmettez pas sa réponse en aval sous prétexte que le JSON s'est analysé correctement. Si les deux échouent, vérifiez que l'exigence était énoncée clairement avant de voir dans un prix plus élevé la solution.

Laisser un Agent préparer l'appel

Pour des contrôles répétés de décision d'export, demandez à votre Agent de code d'utiliser le Skill SpicyAPI : « Read deepseek/v4-flash/chat, then adapt the example to my input; show the request before running it. » La consultation via la CLI est spicyapi models get deepseek/v4-flash/chat --json ; via le MCP, spicyapi_model_get avec model: "deepseek/v4-flash/chat". Les appels de chat passent par un client compatible ou l'API de chat ; les commandes de tâches média ne génèrent pas de réponses de chat.

Quel workflow mérite le tarif plus élevé ?

Pour extraire la date de sortie, les noms de personnages et le nombre d'images demandé d'un créateur à partir d'un brief complet, Flash dispose des contrôles courants et d'une capacité de sortie largement suffisante. Le plafond de sortie plus élevé de Pro n'apporte rien à un court objet JSON. Commencez par Flash et utilisez des valeurs manquantes explicites, afin que « no release date supplied » ne devienne pas une date inventée.

Pour une revue de dépendances sur plusieurs enregistrements, rendez les règles du job concrètes. Une référence de personnage approuvée ne suffit pas quand le plan a besoin d'un second personnage approuvé et d'un asset d'inventaire actuel. Un modèle doit repérer l'approbation manquante du second personnage, même si la transcription de production environnante répète que le plan est prêt. Le jeu de test ci-dessus vérifie cette distinction avec l'inventaire. Comparer avec Pro peut valoir la peine sur un job complexe en échec.

Pour une très grande transformation, l'exigence de sortie peut trancher sans qu'il faille invoquer la qualité. Si le document effectivement renvoyé doit dépasser 65 536 tokens en une seule réponse, le plafond de Flash ne convient pas et Pro permet davantage de sortie. Si des enregistrements indépendants peuvent être renvoyés par petits groupes, le traitement par lots peut garder Flash utilisable et faciliter la reprise d'un groupe en échec. Ne scindez pas une tâche dont la réponse dépend de relations entre ces groupes sans reporter ces relations d'un groupe à l'autre.

Une montée en gamme sélective n'est économique que si elle reste sélective. Avec les hypothèses de 50 000 tokens en entrée et 3 000 en sortie ci-dessous, 900 appels Flash plus 100 appels Pro coûtent $31.152, contre $77.88 pour les 1 000 sur Pro. Si chaque job passe d'abord par Flash et que 100 ont ensuite besoin de Pro, le total combiné est de $33.748. Ce sont des totaux hypothétiques qui expliquent l'arbitrage sur les nouvelles tentatives ; l'usage réel de tokens variera.

Ce que coûte une requête à usage égal

Pour une requête de 50 000 tokens d'entrée non mis en cache et de 3 000 tokens de sortie facturés :

• 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.

Mille requêtes de ce type coûtent $25.96 et $77.88. Si 40 000 des tokens d'entrée sont des lectures en cache et 10 000 ne le sont pas, les montants par requête deviennent $0.00892 pour Flash et $0.02684 pour Pro. Les tarifs en cache ne sont pas exactement dans un rapport de trois pour un : calculez donc les totaux au lieu d'arrondir à partir du tarif affiché.

Deux éléments pèsent plus sur la facture que le choix du modèle :

• Le raisonnement est facturé comme de la sortie. L'effort par défaut est high. Pour l'extraction et la classification, testez low, ou none pour sauter la passe de raisonnement, et comparez les résultats acceptés autant que les tokens.
• Les nouvelles tentatives comptent. Ce qui importe, c'est le coût par réponse acceptée, pas par appel.

L'escalade sélective conserve l'essentiel de l'économie. Envoyez tout à Flash, et envoyez à Pro un résultat échoué ou ambigu avec la preuve de son échec. Si une requête sur dix est escaladée avec l'usage ci-dessus, et qu'une requête escaladée paie à la fois l'appel Flash et l'appel Pro, la moyenne est d'environ $0.03375 par requête, contre $0.0779 pour tout sur Pro. Un second modèle peut répéter la même erreur : conservez donc le véritable contrôle d'exactitude de la tâche.

Quand la sortie plus large de Pro compte

Le plafond de 384 000 tokens ne compte que lorsque la réponse requise dépasse réellement 65 536 tokens, par exemple un plan de migration ordonné avec le SQL et le retour arrière de chaque étape, à renvoyer en un seul bloc. Un court rapport sur une longue entrée n'entre pas dans ce cas : la capacité d'entrée est identique.

Avant de demander une réponse énorme, vérifiez que votre consommateur peut la valider et la stocker. Une modification chapitre par chapitre, ou des enregistrements répartis en groupes indépendants, se rattrape plus facilement après une interruption. Ne gardez une réponse unique que si les parties dépendent d'une structure commune.

Ne confondez pas le maximum et la valeur par défaut. Les deux ont par défaut 32 768 tokens de sortie, et une réponse qui atteint la limite est tronquée sans erreur. Définissez une petite valeur explicite pour les tâches courtes comme le jeu de test ci-dessus, et une plus grande uniquement là où le livrable l'exige.

Quand les appels d'outils parallèles comptent

Pro accepte parallel_tool_calls ; Flash non. Cela vous indique quel corps de requête vous pouvez envoyer, pas que Flash ne sait pas utiliser d'outils : les deux acceptent les définitions d'outils et tool_choice.

Les lectures indépendantes sont de bonnes candidates aux appels parallèles, par exemple récupérer en même temps un catalogue approuvé et un enregistrement d'inventaire. L'action d'export dépend des deux résultats et doit attendre. Imposez cette dépendance dans votre application au lieu de considérer une séquence d'outils proposée comme une autorisation d'agir. Mettre parallel_tool_calls à false sur Pro donne au plus un appel par tour lorsque chaque appel a besoin du résultat précédent.

Si votre boucle exige ce contrôle explicite, c'est une raison concrète de choisir Pro. Si elle enchaîne des consultations séquentielles et renvoie une courte réponse, commencez sur Flash et n'ajoutez de la concurrence qu'une fois la boucle de base opérationnelle.

Écriture et jeu de rôle sans censure

Les deux modèles relèvent du niveau « Uncensored » sur SpicyAPI : aucun filtre de contenu de la plateforme, seul subsiste le comportement propre à chaque modèle. Lors de nos tests de l'échelle de contenu de septembre 2026, les deux ont refusé une demande directe de la catégorie de scène adulte de plus forte intensité (L4 dans les tests) lorsqu'elle arrivait sans contexte, et les deux l'ont écrite dès qu'un prompt système posait un cadre d'écriture de fiction :

Au niveau L5, chaque modèle a mené à bien trois formulations du brief de fiction pour adultes et trois d'un brief distinct de fiction crue non adulte. Flash a atténué une exécution dans la catégorie suggestive la plus légère ; les autres sondes de niveau inférieur ont abouti. Pour la fiction pour adultes, cadrez donc le job dans le prompt système sur l'un ou l'autre modèle, et ne payez pas Pro dans l'espoir qu'il refuse moins. Nos tests de V4 Flash et de V4 Pro listent chaque exécution.

Le jeu de rôle produit beaucoup de sortie, et c'est là que le rapport de prix de trois pour un se voit : environ $0.57 pour 100 tours sur Flash contre $1.72 sur Pro, en supposant 10 000 tokens d'entrée non mis en cache et 1 000 tokens de sortie facturés par tour, raisonnement compris.

FAQ

V4 Flash suffit-il pour le code ?

C'est le point de départ le moins cher, et le benchmark sur une seule base de code a trouvé les trois bugs connus avec Flash. Avant une modification suggérée, vérifiez la source citée et lancez les tests concernés. Une passe ciblée de Pro est une option d'escalade, pas un substitut à ces contrôles.

Flash est-il lent ?

Le test de SpicyAPI a relevé 40 tokens de sortie par seconde pour Flash et 46 pour Pro. Cet écart modeste ne justifie pas à lui seul de tripler le budget en tokens, et la latence réelle dépend du raisonnement et de la réponse. Baissez l'effort pour les tâches courtes plutôt que de considérer cet instantané comme une garantie de vitesse actuelle.

Pourquoi choisir Flash si Pro est le plus grand modèle ?

Les deux ID hébergés acceptent la même longue entrée, alors que Flash coûte environ un tiers aux tarifs de tokens non mis en cache. Pour des réponses courtes d'extraction ou de classification, le plafond de sortie plus élevé de Pro n'apporte rien en soi. Escaladez un résultat ambigu lorsque vous avez une question concrète pour la passe la plus coûteuse.

Dois-je démarrer une nouvelle intégration sur V4 ou sur V4.1 Flash ?

Commencez par V4.1 Flash, sauf si vous avez besoin d'un contrat V4 précis ou si vous maintenez une intégration épinglée. Seul l'alias retiré de V4 Flash est redirigé vers V4.1 ; V4 Pro continue, et ces contrats hébergés restent listés séparément. Revérifiez tout comportement sur lequel s'appuie votre application avant de basculer le trafic de production.