DeepSeek V4 Flash o Pro: scegli l'API in base al compito

Una pipeline di testo può richiedere estrazione, revisione di documenti o roleplay, ciascuno con un budget di output diverso. Per una nuova integrazione, parti da deepseek/v4.1-flash/chat: $0.30 di input e $1.20 di output per milione, con un limite di risposta di 384.000 token. Se la tua integrazione è vincolata a un ID V4, usa V4 Flash per il lavoro di routine; scegli Pro per il suo controllo esplicito delle chiamate parallele ai tool, per una risposta oltre i 65.536 token o per un compito specifico in cui il risultato giustifichi un prezzo per token triplo. Entrambi gli ID V4 leggono 1.048.576 token, quindi un input lungo da solo non è un motivo per pagare Pro.

La guida alla migrazione a V4.1 Flash copre il percorso per i nuovi progetti. I confronti qui sotto riguardano i due ID V4 ospitati.

Quale modello per quale lavoro

Le differenze di contratto

Le pagine di V4 Flash e V4 Pro mostrano i campi ospitati attuali. Entrambi consentono fino a 256 messaggi e 128 definizioni di tool, con fino a 60 minuti per richiesta, e nessuno dei due espone temperature né top_p. La pagina di confronto di SpicyAPI mostra gli stessi campi dallo schema in tempo reale.

Entrambi gli endpoint rifiutano i campi che non elencano. Un body copiato dall'endpoint Pro con parallel_tool_calls fallisce la validazione su Flash invece di essere ignorato, quindi tieni separati i campi specifici di ciascun modello invece di inviare l'unione.

A che punto sono questi ID a monte. Il changelog attuale di DeepSeek ritira V4 Flash e instrada temporaneamente il suo vecchio alias su V4.1 Flash, mentre il servizio V4 Pro prosegue con la fatturazione invariata. SpicyAPI elenca gli ID separati indicati sopra; per mantenere un'integrazione V4, fissa l'ID ospitato completo e non un alias a monte. L'annuncio del 10 settembre di DeepSeek descrive i reindirizzamenti degli alias nativi, quindi il risultato di un forum che usava alias nativi potrebbe non confrontare affatto le versioni V4 originali; distingui nomi dei modelli, ID con versione e risultati osservati prima di fidarti di qualsiasi pagina «Flash vs Pro». Per un nuovo progetto, il prezzo più basso e il limite di risposta più alto di V4.1 Flash sono il motivo pratico per partire da lì.

Cosa hanno scoperto altri sviluppatori con questa coppia

Un benchmark di revisione del codice da 18 esecuzioni su una singola codebase Python, con gli snapshot datati 0731 per Flash e 0813 per Pro, ha rilevato una differenza utile:

• Copertura: Pro ha prodotto 169 affermazioni verificabili contro le 70 di Flash. L'accuratezza delle affermazioni era vicina: 95,9 % contro 95,7 %.
• Individuazione dei bug: Flash ha trovato tutti e tre i bug latenti noti; Pro ne ha trovato uno. Flash ha anche inventato un caso limite, quindi verifica le correzioni proposte sul sorgente.
• Coerenza: la profondità dei report di Pro variava di 2,7 volte tra esecuzioni ripetute. In quella configurazione ha funzionato meglio una scansione con Flash seguita da una verifica mirata con Pro.

Usa Flash per la prima passata economica e invia a Pro un risultato poco chiaro, la sua fonte e una domanda precisa. Il report di nessuno dei due modelli sostituisce le verifiche sul sorgente o i test dell'applicazione.

Prova prima nel Playground

1. Apri DeepSeek V4 Flash e passa al Playground.
2. Incolla il record di approvazione del catalogo e di timeout dell'inventario dell'esempio. Chiedi se il job E42 può essere esportato.
3. Ripeti su V4 Pro con lo stesso input. Entrambe le risposte dovrebbero bloccare l'esportazione perché la consultazione attuale dell'inventario è fallita.

Prova entrambi su una decisione con una sola risposta giusta

Supponi che l'esportazione della vetrina di un creator dipenda da un catalogo approvato e da una consultazione attuale dell'inventario. Il modello deve indicare che cosa blocca l'esportazione senza trattare un passaggio in sospeso come completato. Il caso di prova costa abbastanza poco da poter essere eseguito su entrambi i modelli prima di inviare una trascrizione voluminosa.

Imposta SPICY_API_KEY con una chiave da API Keys. La richiesta usa l'interfaccia Chat Completions di 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 decisione corretta è can_export: false, con l'inventario attuale mancante come blocco. Lo snapshot di ieri non è la consultazione attuale richiesta, e l'array evidence dovrebbe citare la riga del timeout.

È una verifica del caso di prova, non un validatore di business generale: le esportazioni reali devono usare gli stati effettivi delle dipendenze nella tua applicazione. Un modello può citare una frase reale e trarre comunque la conclusione sbagliata, ed è per questo che qui si controllano sia la decisione sia le prove.

Per eseguire Pro sullo stesso input, cambia solo l'ID del modello. Mantieni identici fonte, istruzioni, effort e limite di output, e valuta ogni risposta su due punti: ha indicato il blocco, e le citazioni compaiono nel record? Una spiegazione più lunga non è una decisione migliore.

Se Flash supera la prova, questo caso non ti dà alcun motivo per pagare Pro su quel compito. Se uno dei due modelli inventa un successo dell'inventario, non passare la sua risposta a valle solo perché il JSON è stato analizzato. Se falliscono entrambi, verifica che il requisito fosse espresso con chiarezza prima di considerare un prezzo più alto come la soluzione.

Lascia che un Agent prepari la chiamata

Per verifiche ripetute di decisioni di esportazione, chiedi al tuo Agent di programmazione di usare la Skill di SpicyAPI: «Read deepseek/v4-flash/chat, then adapt the example to my input; show the request before running it.» La consultazione tramite CLI è spicyapi models get deepseek/v4-flash/chat --json; tramite MCP, spicyapi_model_get con model: "deepseek/v4-flash/chat". Le chiamate di chat usano un client compatibile o l'API di chat; i comandi dei task multimediali non generano risposte di chat.

Quale workflow merita la tariffa più alta?

Per estrarre da un brief completo la data di uscita, i nomi dei personaggi e il numero di immagini richiesto da un creator, Flash ha i controlli comuni e ampia capacità di output. Il limite di output più alto di Pro non offre alcun vantaggio a un breve oggetto JSON. Parti da Flash e usa valori mancanti espliciti, in modo che «no release date supplied» non diventi una data inventata.

Per una revisione di dipendenze su più record, rendi concrete le regole del job. Un riferimento di personaggio approvato non basta quando l'inquadratura richiede un secondo personaggio approvato e un asset di inventario attuale. Un modello dovrebbe individuare la seconda approvazione mancante anche se la trascrizione di produzione circostante continua a definire l'inquadratura pronta. Il caso di prova qui sopra verifica questa distinzione usando l'inventario. Confrontare con Pro può valere la pena su un job complesso fallito.

Per una trasformazione molto grande, il requisito di output può decidere la scelta senza alcuna affermazione sulla qualità. Se il documento effettivamente restituito deve superare i 65.536 token in una sola risposta, il limite di Flash non basta e Pro consente più output. Se record indipendenti possono essere restituiti in gruppi più piccoli, il batching può mantenere Flash utilizzabile e rendere più facile ritentare un gruppo fallito. Non dividere un compito la cui risposta dipende dalle relazioni tra quei gruppi senza riportare tali relazioni da un gruppo all'altro.

Un upgrade selettivo è economico solo finché resta selettivo. Con le ipotesi di 50.000 token di input e 3.000 di output qui sotto, 900 chiamate Flash più 100 chiamate Pro costano $31.152, contro $77.88 per tutte le 1.000 su Pro. Se ogni job passa prima da Flash e poi 100 richiedono Pro, il totale combinato è $33.748. Sono totali ipotetici che spiegano il compromesso dei tentativi ripetuti; l'uso reale di token sarà diverso.

Quanto costa una richiesta a parità di utilizzo

Per una richiesta con 50.000 token di input non in cache e 3.000 token di output fatturati:

• 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 richieste di questo tipo costano $25.96 e $77.88. Se 40.000 dei token di input sono letture dalla cache e 10.000 no, le cifre per richiesta diventano $0.00892 per Flash e $0.02684 per Pro. Le tariffe della cache non stanno in un rapporto esatto di tre a uno, quindi calcola i totali invece di arrotondare partendo dal prezzo di listino.

Due cose incidono sul conto più della scelta del modello:

• Il reasoning è fatturato come output. L'effort predefinito è high. Per estrazione e classificazione, prova low, oppure none per saltare la fase di reasoning, e confronta i risultati accettati oltre ai token.
• I tentativi ripetuti contano. Conta il costo per risposta accettata, non per chiamata.

L'escalation selettiva mantiene gran parte del risparmio. Invia tutto a Flash, e a Pro un risultato fallito o ambiguo insieme alle prove del motivo per cui è fallito. Se con l'utilizzo sopra una richiesta su dieci viene escalata, e una richiesta escalata paga sia la chiamata Flash sia quella Pro, la media è circa $0.03375 per richiesta, contro $0.0779 con tutto su Pro. Un secondo modello può ripetere lo stesso errore, quindi mantieni il vero controllo di correttezza del compito.

Quando conta l'output più ampio di Pro

Il limite di 384.000 token conta solo quando la risposta richiesta supera davvero i 65.536 token, per esempio un piano di migrazione ordinato con l'SQL e il rollback di ogni passaggio da restituire insieme. Un breve report su un input lungo non rientra nel caso: la capacità di input è identica.

Prima di chiedere una risposta enorme, verifica che il tuo consumer possa validarla e archiviarla. Una modifica capitolo per capitolo, o record divisi in gruppi indipendenti, si recupera più facilmente dopo un'interruzione. Mantieni una risposta unica solo quando le parti dipendono da una struttura condivisa.

Non confondere il massimo con il valore predefinito. Entrambi hanno 32.768 token di output come predefinito, e una risposta che raggiunge il limite viene troncata senza errore. Imposta un valore esplicito piccolo per i compiti brevi come il caso di prova qui sopra, e uno più grande solo dove il risultato lo richiede.

Quando contano le chiamate parallele ai tool

Pro accetta parallel_tool_calls; Flash no. Questo ti dice quale body di richiesta puoi inviare, non che Flash non possa usare tool: entrambi accettano definizioni di tool e tool_choice.

Le letture indipendenti sono candidate alle chiamate parallele, per esempio recuperare nello stesso momento un catalogo approvato e un record di inventario. L'azione di esportazione dipende da entrambi i risultati e deve attendere. Imponi questa dipendenza nella tua applicazione invece di trattare una sequenza di tool proposta come un permesso di agire. Impostare parallel_tool_calls su false su Pro dà al massimo una chiamata per turno quando ogni chiamata ha bisogno del risultato precedente.

Se il tuo ciclo richiede questo controllo esplicito, è un motivo concreto per Pro. Se esegue consultazioni sequenziali e restituisce una risposta breve, parti da Flash e aggiungi la concorrenza solo dopo che il ciclo di base funziona.

Scrittura e roleplay senza censura

Entrambi i modelli hanno il livello «Uncensored» su SpicyAPI: nessun filtro di contenuto della piattaforma, e ciò che resta è il comportamento proprio di ciascun modello. Nei nostri test della scala dei contenuti di settembre 2026, entrambi hanno rifiutato una richiesta diretta della categoria di scena per adulti a maggiore intensità (L4 nelle recensioni) quando arrivava senza contesto, ed entrambi l'hanno scritta quando un prompt di sistema stabiliva una cornice di scrittura di narrativa:

A L5, ciascun modello ha completato tre formulazioni del brief di narrativa per adulti e tre di un brief separato di narrativa cruda non per adulti. Flash ha attenuato un'esecuzione nella categoria suggestiva più lieve; le altre prove di livello inferiore sono state completate. Quindi, per la narrativa per adulti, inquadra il job nel prompt di sistema su entrambi i modelli, e non pagare Pro sperando che rifiuti meno. Le nostre recensioni di V4 Flash e V4 Pro elencano ogni esecuzione.

Il roleplay genera molto output, ed è lì che il rapporto di prezzo di tre a uno si vede: circa $0.57 ogni 100 turni su Flash contro $1.72 su Pro, ipotizzando 10.000 token di input non in cache e 1.000 token di output fatturati per turno, incluso l'eventuale reasoning.

FAQ

V4 Flash basta per programmare?

È il punto di partenza più economico, e il benchmark su una singola codebase ha trovato con Flash tutti e tre i bug noti. Prima di una modifica suggerita, verifica il sorgente citato ed esegui i test interessati. Una passata mirata con Pro è un'opzione di escalation, non un sostituto di questi controlli.

Flash è lento?

La recensione di SpicyAPI ha registrato 40 token di output al secondo per Flash e 46 per Pro. Questo divario modesto non è di per sé un motivo per triplicare il budget di token, e la latenza reale dipende dal reasoning e dalla risposta. Riduci l'effort nei compiti brevi invece di affidarti a quell'istantanea come garanzia di velocità attuale.

Perché scegliere Flash se Pro è il modello più grande?

Entrambi gli ID ospitati accettano lo stesso input lungo, mentre Flash costa circa un terzo alle tariffe dei token non in cache. Per risposte brevi di estrazione o classificazione, il limite di output più alto di Pro non offre da solo alcun vantaggio. Fai l'escalation di un risultato ambiguo quando hai una domanda concreta per la passata più costosa.

Devo avviare una nuova integrazione su V4 o su V4.1 Flash?

Parti da V4.1 Flash, a meno che tu non abbia bisogno di uno specifico contratto V4 o debba mantenere un'integrazione vincolata. Solo l'alias ritirato di V4 Flash viene instradato su V4.1; V4 Pro prosegue, e questi contratti ospitati restano elencati separatamente. Ricontrolla ogni comportamento su cui si basa la tua applicazione prima di spostare il traffico di produzione.