I prezzi dell'API V4 di DeepSeek sono passati da una semplice domanda di selezione del modello a una domanda sulla tempistica.

La pagina ufficiale dei prezzi dell'API dell'azienda ora elenca DeepSeek V4 Flash e DeepSeek V4 Pro con ampie finestre di contesto da 1 milione di token, URL di base in formato OpenAI e formato Anthropic e categorie di fatturazione separate per input di cache-hit, input di cache-miss e token di output. I rapporti aggregati da Techmeme il 13 agosto affermano che DeepSeek stava aumentando i prezzi del modello V4 e introducendo la fatturazione dinamica nelle ore di punta/non di punta, con i nuovi prezzi che entreranno in vigore alle 16:00 UTC del 16 agosto 2026.

Ciò rende la modifica più di un aggiornamento di routine della tabella dei prezzi. Per i team che eseguono agenti con un elevato numero di recuperi, assistenti di codifica a lungo contesto, lavori di analisi batch o prodotti AI rivolti al cliente, il costo di una richiesta DeepSeek può ora dipendere non solo dal modello scelto, ma anche da quando la richiesta viene inviata e dalla quantità di prompt che può essere fornita dalla cache.

Cosa è cambiato nella fatturazione di DeepSeek V4

L'attuale documentazione API di DeepSeek presenta V4 Flash e V4 Pro come disponibili sia in stile OpenAI che in stile Anthropic-style API formats. Ciò è importante perché molti sviluppatori instradano già DeepSeek insieme ad altri fornitori attraverso livelli di compatibilità anziché scrivere codice applicativo specifico del fornitore.

La struttura di fatturazione degna di nota è la separazione tra input di cache-hit, input di cache-miss e output. In pratica, ciò significa che prefissi di prompt ripetuti, istruzioni di sistema, schemi di strumenti o blocchi di contesto lunghi e riutilizzabili possono avere un profilo di costo diverso dal testo di prompt appena inviato. Questa era già una parte importante della storia dei costi di DeepSeek V4-Pro. Il nuovo livello di punta/non di punta aggiunge un'altra variabile: lo stesso carico di lavoro può avere un prezzo diverso a seconda di quando viene eseguito.

I rapporti secondari indicano un aumento dei prezzi dei materiali per i modelli V4 e un programma dinamico a partire dal 16 agosto. Alcuni calcoli della community indicano aumenti percentuali molto elevati per casi specifici con un utilizzo intensivo della cache, in particolare laddove i prezzi di cache-hit sono cambiati drasticamente. Tali cifre dovrebbero essere trattate con cautela fino a quando non verranno confrontate con le fatture in tempo reale o con l’attuale tabella di fatturazione di DeepSeek. La direzione del viaggio, tuttavia, è abbastanza chiara: i consumatori API non possono più valutare DeepSeek V4 solo in base alla capacità del modello principale e alle tariffe nominali per token.

Perché i prezzi di punta e non di punta sono importanti

I prezzi di punta/non di punta sono comuni nei mercati delle infrastrutture, ma sono ancora un modello relativamente nuovo per le principali API LLM. Crea incentivi familiari ai team cloud e dati: spostare il lavoro flessibile da finestre costose, riservare tempo prezioso per le richieste rivolte agli utenti e far attendere i lavori batch quando la latenza non è critica.

Per le applicazioni IA, ciò ha diversi effetti pratici. Un bot di supporto in tempo reale di solito non può ritardare la risposta del cliente fino a una finestra più economica. Un lavoro notturno di analisi della base di codice, una pipeline di arricchimento dei documenti o un'esecuzione di valutazione spesso possono farlo. I sistemi di agenti si collocano da qualche parte nel mezzo: alcune chiamate agli strumenti sono interattive, mentre altre possono essere messe in coda, riprovate o pianificate.

Ciò cambia il problema del routing. Un gateway che sceglie tra modelli in base a qualità, latenza e prezzo del token deve ora considerare il tempo. Se DeepSeek V4 Pro è conveniente nelle ore di punta ma costoso durante le ore di punta, un'applicazione potrebbe preferire un altro modello durante il giorno e tornare a DeepSeek in un secondo momento. Se V4 Flash rimane interessante per attività rapide ma i costi economici della cache peggiorano per prefissi condivisi lunghi, potrebbe essere necessario rivedere l'architettura dei prompt stessa.

Per i team che utilizzano un gateway API AI, la funzionalità più utile potrebbe non essere un altro modello di attivazione/disattivazione. Potrebbe trattarsi di una politica: inviare immediatamente richieste interattive, mettere in coda lavori non urgenti, avvisare quando una richiesta sta entrando in una finestra di costo più elevata o applicare budget a livello di team prima dell'inizio dell'esecuzione di un batch. Ciò è direttamente rilevante per l'infrastruttura in stile Model Gate perché la fatturazione unificata, l'analisi dell'utilizzo e i controlli del routing diventano più preziosi quando i prezzi dei fornitori sono dinamici anziché statici.

Chi è più esposto

È probabile che l'impatto maggiore ricada sugli sviluppatori ad alto volume e sulle aziende con carichi di lavoro prevedibili. I prodotti di chat dei consumatori, le piattaforme di agenti di codifica, gli strumenti di ricerca, i servizi di pulizia dei dati e i team di automazione interna possono inviare un gran numero di richieste simili. Questi sistemi spesso traggono vantaggio da una memorizzazione nella cache tempestiva, ma sono anche sensibili a piccole modifiche per token moltiplicate per milioni o miliardi di token.

I team che utilizzano DeepSeek tramite interfacce compatibili con OpenAI non dovrebbero presumere che la compatibilità li protegga dalle modifiche di fatturazione. La richiesta potrebbe sembrare familiare, ma la fattura segue comunque le regole di prezzo specifiche del modello di DeepSeek.L'accesso al formato antropico crea lo stesso problema dall'altra parte: un'integrazione più semplice non elimina la necessità di comprendere le categorie di fatturazione del fornitore.

Gli sviluppatori che gestiscono calcolatori dei prezzi, dashboard dei rivenditori o strumenti interni di chargeback dovrebbero aggiornare rapidamente le ipotesi. Se la tabella dei prezzi in un prodotto tratta ancora DeepSeek V4 come un unico costo forfettario per token, potrebbe sottostimare o sopravvalutare l'utilizzo reale. Ciò può distorcere i margini dei clienti, i budget dei team e le decisioni sulla selezione dei modelli.

Anche i team di procurement e finanza dovrebbero prestare attenzione. I prezzi API dinamici rendono più difficile la previsione mensile. Un carico di lavoro accessibile in fase di test potrebbe comportarsi diversamente in produzione se il traffico degli utenti si concentra nelle finestre di picco. Lo stesso rischio si applica a demo, valutazioni e benchmark degli agenti: un confronto tra modelli eseguito in una determinata ora del giorno potrebbe non rappresentare l'economia dell'esecuzione continua dello stesso flusso di lavoro.

Cosa dovrebbero fare ora i team

Il passo immediato è separare la migrazione tecnica dalla convalida finanziaria. Potrebbe non essere necessaria alcuna modifica del codice se le applicazioni chiamano già DeepSeek V4 Flash o V4 Pro tramite formati API supportati. Ma i presupposti di fatturazione, gli avvisi e i dashboard necessitano di una revisione.

I team di ingegneri dovrebbero identificare quali carichi di lavoro DeepSeek sono interattivi e quali sono differibili. Il riepilogo batch, l'arricchimento adiacente incorporato, l'analisi del repository, la generazione di dati sintetici e le suite di valutazione sono candidati per la pianificazione nelle ore di punta se i requisiti del prodotto lo consentono. I framework degli agenti dovrebbero registrare non solo il conteggio dei token e gli ID dei modelli, ma anche l'ora della richiesta, il comportamento degli accessi alla cache e il volume di output.

I team dovrebbero anche ricontrollare la strategia di memorizzazione nella cache dei prompt. Se i blocchi di contesto riutilizzabili sono ancora più economici dell’input non memorizzato nella cache, la memorizzazione nella cache rimane preziosa. Se i prezzi di cache-hit sono aumentati sostanzialmente per un modello e una finestra temporale specifici, potrebbe valere la pena abbreviare le richieste di sistema, suddividere i flussi di lavoro o confrontare un altro fornitore per attività ripetute a lungo contesto.

Ciò che rimane incerto è l'esatto impatto sui prezzi in tempo reale per ogni carico di lavoro. La documentazione ufficiale di DeepSeek conferma i formati del modello, la finestra di contesto e le categorie di fatturazione visibili nella pagina dei prezzi, mentre i rapporti secondari descrivono l'attivazione di punta/non punta del 16 agosto e gli aumenti di prezzo. L'esatto delta dei costi dipende dalla tabella live corrente, dall'ora in cui le richieste vengono inviate, dal comportamento della cache e dalla lunghezza dell'output.

La lezione più ampia è meno incerta. I prezzi LLM stanno diventando operativi. La scelta del modello, i tempi della richiesta, la progettazione della cache e la politica di budget sono ora collegati. Per gli sviluppatori e le aziende, il controllo dei costi delle API AI non è più solo un esercizio su un foglio di calcolo dopo l'implementazione; fa parte del modo in cui i sistemi IA di produzione devono essere instradati.