Il test DeepSeek H200 mette in discussione la tesi dell'«80x più economico»
DeepSeek ha affrontato una prova pratica sui costi dopo che The Call Center Doctors ha noleggiato quattro GPU Nvidia H200 per verificare la tesi del modello «80x più economico».
La società di consulenza ha provato a servire DeepSeek V4.1 Flash ai propri agenti di coding invece di usare Claude Opus 5.5 tramite Claude Code. Il suo test originale ha rilevato che pesi del modello economici non producono necessariamente un sistema funzionante economico.
Il test DeepSeek H200 ha evidenziato un divario tra la tariffazione dei token e il costo di portare a termine un reale lavoro software. Il server noleggiato gestiva rapidamente carichi sintetici, ma la sua sostenibilità economica è peggiorata quando il team ha riprodotto il traffico effettivo dei propri agenti di coding.
Alla normale tariffa di noleggio on-demand, il server costava circa il doppio rispetto all'invio dello stesso carico di lavoro all'API di DeepSeek. La società di consulenza ha inoltre concluso che i propri abbonamenti Claude Code esistenti restavano competitivi una volta misurate le modifiche al codice completate anziché i prezzi dei token.
Questi risultati derivano dal carico di lavoro, dalla configurazione e dalle misurazioni interne di una singola azienda. Non costituiscono un benchmark universale per nessuno dei due modelli. DeepSeek non ha mai ricevuto l'autorizzazione a scrivere codice di produzione durante il test, il che limita qualsiasi confronto diretto sul lavoro completato.
Tuttavia, l'esperimento è rilevante perché ha utilizzato traffico proveniente da agenti di coding già distribuiti, anziché un benchmark isolato. Ha misurato contesto ripetuto, concorrenza, latenza, lavoro operativo e il confine di sicurezza attorno all'esecuzione autonoma del codice.
Il ribaltamento centrale è semplice. Le basse tariffe API di DeepSeek sono rimaste interessanti, mentre l'hosting autonomo dello stesso modello su GPU premium ha prodotto un'economia peggiore per questo specifico carico di lavoro.
Il risultato spinge gli acquirenti a definire cosa significhi «più economico» prima di cambiare fornitore. Una bassa tariffa per token di output può essere significativa, ma non descrive throughput, affidabilità, impegno ingegneristico o consegna riuscita.
Il test DeepSeek H200 ha sostituito una tesi di prezzo con un test del carico di lavoro
La società di consulenza ha testato un sistema di inferenza completo, non solo il numero stampato accanto a un milione di token.
The Call Center Doctors costruisce e gestisce ambienti di call center per altre aziende. Utilizza inoltre agenti di coding per mantenere il software che supporta tale attività.
Il 27 settembre, l'azienda ha noleggiato un server contenente quattro acceleratori Nvidia H200. Ha scaricato DeepSeek V4.1 Flash e configurato il modello come backend per agenti normalmente connessi a Claude Code.
Il test mirava a due affermazioni comuni sui modelli a pesi aperti. La prima sostiene che tariffe dei token più basse si traducano direttamente in costi operativi inferiori. La seconda afferma che le organizzazioni possano evitare i margini dei fornitori noleggiando GPU e servendo autonomamente il modello.
DeepSeek offre agli acquirenti motivi per esaminare tali affermazioni. Il suo lancio del modello descrive V4.1 Flash come un modello mixture-of-experts progettato per un'inferenza più rapida e un throughput maggiore.
Un modello mixture-of-experts attiva soltanto una parte della propria rete per ciascun token. Questa progettazione può ridurre il calcolo rispetto all'esecuzione di ogni parametro per ogni richiesta.
DeepSeek afferma che la sua architettura attivi meno parametri durante l'elaborazione di input e output. Afferma inoltre che il modello richieda meno memoria ad alta larghezza di banda per la propria cache chiave-valore rispetto alla generazione precedente.
Una cache chiave-valore memorizza dati intermedi di attenzione provenienti dai token precedenti. Riutilizzare tali dati rende il contesto ripetuto meno costoso rispetto all'elaborazione dell'intera sequenza come nuovo input.
La società di consulenza ha quindi scelto hardware adatto a un'inferenza ad alta intensità di memoria. Ogni H200 include 141GB di memoria ad alta larghezza di banda, secondo le specifiche H200 di Nvidia.
Su quattro GPU, tale capacità era sufficiente per caricare e servire il modello dopo diverse modifiche alla configurazione. Tuttavia, raggiungere un servizio stabile ha richiesto cinque avvii.
Ogni riavvio ha richiesto un ulteriore periodo di caricamento del modello. Un'ottimizzazione ha consumato memoria inaspettata, un'altra esecuzione si è bloccata e una configurazione successiva ha fallito con una concorrenza più elevata.
Il quinto tentativo si è stabilizzato con un limite di concorrenza inferiore e la maggior parte della memoria disponibile impegnata. Questa sequenza operativa è diventata parte del risultato economico.
Un'API ospitata nasconde download del modello, allocazione della memoria, software di serving, pianificazione della capacità e avvii falliti. Una macchina noleggiata espone ogni attività al cliente.
Una volta stabilizzato, il server ha ottenuto buoni risultati nei test isolati di un minuto. Ha elaborato input in cache in modo particolarmente rapido e ha generato migliaia di token al secondo sull'intera macchina.
Questo risultato inizialmente supportava l'ipotesi dell'hosting autonomo. Quattro H200 offrivano un throughput grezzo considerevole e il design di DeepSeek orientato alla cache si è comportato come previsto.
Il problema è emerso quando il team ha smesso di testare una categoria di token alla volta. I suoi agenti di coding non inviavano una sequenza bilanciata di nuovo input, input in cache e output.
Fornivano ripetutamente conversazioni lunghe, risultati degli strumenti, contesto dei file e ragionamenti precedenti. La maggior parte di ogni richiesta consisteva in testo che il modello aveva già visto.
Quel carico di lavoro ha spostato il test dalla velocità teorica di output. Ha costretto la macchina a impiegare quasi tutto il proprio tempo nell'elaborare il contesto necessario prima di generare la risposta successiva.
L'evento non era quindi una gara convenzionale tra modelli. Era un test per verificare se tassi di inferenza interessanti resistessero al contatto con il traffico reale di un sistema di agenti.
Perché il contesto degli agenti ha saturato le quattro H200
Gli agenti di coding spesso dedicano molto più calcolo alla lettura della loro cronologia che alla scrittura del successivo token utile.
I log di settembre della società di consulenza contenevano 388,5 miliardi di token letti e 393 milioni di token scritti. Dell'input, 374,2 miliardi di token erano riletture dalla cache.
Ciò significa che oltre il 96 percento dell'input registrato ripeteva contesto precedente. Per ogni token di output, gli agenti fornivano circa 41,6 nuovi token di input e 1.042 token in cache.
Una richiesta media rileggeva approssimativamente 196.000 token. Questo schema è importante perché l'input in cache è economico per token, ma non è mai privo di costo computazionale.
Il server noleggiato elaborava ogni token in cache più rapidamente di ogni nuovo token. Tuttavia, gli agenti fornivano così tanti token in cache che questi piccoli costi si accumulavano fino a diventare il carico di lavoro dominante.
L'azienda ha misurato circa 1,9 microsecondi di tempo server per un token in cache. Un nuovo token di input richiedeva circa 60 microsecondi, mentre un token di output ne richiedeva circa 189.
Applicando tali misurazioni al mix di traffico di produzione si è ottenuto un limite combinato vicino a 213 token di output al secondo. Era il risultato aggregato per tutti gli agenti che condividevano le quattro GPU.
Secondo la società di consulenza, la formula corrispondeva al test dal vivo entro il tre percento. Tale concordanza ha rafforzato il modello del carico di lavoro, sebbene una parte indipendente non l'abbia replicato.
L'azienda ha stimato che, con questo mix, la macchina potesse elaborare circa 20 miliardi di token totali al giorno. Il suo giorno più intenso di settembre ha raggiunto 51 miliardi di token.
La capacità è quindi diventata un secondo vincolo. Un singolo server non avrebbe potuto assorbire il picco registrato, anche se la normale economia del noleggio fosse stata favorevole.
Il contrasto tra test isolati e misti spiega perché il throughput da titolo possa trarre in inganno. La macchina ha generato più di 5.000 token al secondo quando l'output è stato misurato da solo.
Gli agenti reali non possono operare soltanto sull'output. Devono fornire continuamente istruzioni, codice, file, log, risposte degli strumenti e messaggi precedenti.
Gli agenti di lunga durata amplificano tale squilibrio perché le conversazioni crescono nel tempo. Ogni chiamata successiva può contenere gran parte della stessa cronologia più una piccola quantità di nuove informazioni.
Gli sconti sulla cache riducono l'addebito per quei token ripetuti. Non eliminano la larghezza di banda della memoria, i ritardi di pianificazione o il costo opportunità di occupare un server.
Questa distinzione complica anche i confronti tra modelli. Un modello più capace potrebbe completare un'attività con meno tentativi, prompt più brevi o meno revisione.
Un modello più economico potrebbe comunque vincere se utilizza un contesto simile e raggiunge risultati comparabili. Potrebbe perdere se richiede più tentativi, spiegazioni più lunghe o la verifica di un altro modello.
Il test DeepSeek H200 non ha risposto pienamente a questa questione di qualità perché DeepSeek fungeva principalmente da revisore in sola lettura. Ha però mostrato perché le sole tariffe per token di output non possano rispondervi.
La metrica rilevante dipende dal lavoro. Un sistema di sintesi in batch potrebbe dare priorità al throughput totale, mentre un agente interattivo necessita anche di bassa latenza e uso affidabile degli strumenti.
Un'attività di coding si preoccupa di modifiche completate, tempi di revisione, regressioni, sicurezza e attesa degli sviluppatori. L'efficienza dei token è soltanto un input di quel risultato.
I log della società di consulenza hanno offerto un utile avvertimento ad altri acquirenti. Prima di selezionare l'hardware, i team devono profilare il rapporto tra nuovo input, contesto in cache e output generato.
Senza tale rapporto, un benchmark può ottimizzare la parte più piccola del carico di lavoro. Un test di generazione veloce può dire poco su un agente che trascorre la maggior parte del tempo a leggere.
L'hosting autonomo di DeepSeek ha perso contro l'API di DeepSeek
Il risultato più chiaro non era DeepSeek contro Claude, ma l'infrastruttura DeepSeek noleggiata contro il servizio gestito di DeepSeek.
La normale tariffa del server on-demand ha prodotto un costo giornaliero pari a circa 2-2,4 volte il valore dello stesso traffico tramite l'API di DeepSeek. Tale calcolo presupponeva un utilizzo continuo.
Il noleggio spot utilizzato durante l'esperimento era molto più economico. A quella tariffa temporanea, il server si avvicinava alla parità con il servizio gestito di DeepSeek soltanto operando a pieno carico.
La capacità spot comporta un compromesso in termini di disponibilità. I fornitori possono recuperarla quando cambia la domanda, rendendo difficile considerarla un'infrastruttura di produzione affidabile.
Questo è accaduto quasi immediatamente dopo l'esperimento. Il fornitore ha recuperato la macchina entro pochi minuti dal test finale.
L'alternativa on-demand evitava il rischio di tale interruzione, ma peggiorava l'economia. Inoltre addebitava costi mentre il modello si caricava, si riavviava, attendeva traffico o rimaneva al di sotto dell'utilizzo massimo.
L'API gestita di DeepSeek distribuisce tali periodi di inattività tra molti clienti. Il fornitore può raggruppare richieste, condividere l'hardware e operare il proprio stack di serving su scala maggiore.
La sua tabella tariffaria API distingue inoltre tra input in cache, nuovo input e output. Il traffico fuori picco riceve tariffe inferiori rispetto al traffico nei picchi dei giorni feriali.
Questo schema offre agli acquirenti un'altra strada di ottimizzazione. I carichi batch flessibili possono essere spostati lontano dai periodi di picco senza richiedere una macchina dedicata.
Il server noleggiato non disponeva di un adeguamento analogo alla domanda. Il suo contatore orario continuava indipendentemente dal fatto che gli agenti producessero lavoro utile.
Il confronto non dimostra che l'hosting autonomo sia sempre antieconomico. Le organizzazioni possono possedere hardware ammortizzato, negoziare tariffe di capacità inferiori o mantenere un utilizzo costante tra diversi carichi di lavoro.
Le grandi distribuzioni possono inoltre ottimizzare kernel, quantizzazione, routing e pianificazione dei batch oltre quanto ottenuto da un breve esperimento. DeepSeek stessa invita le organizzazioni che pianificano distribuzioni molto grandi a discutere opzioni aggiuntive.
La privacy può giustificare l'operatività locale anche quando l'inferenza ospitata è più economica. I carichi di lavoro regolamentati possono richiedere controlli sui dati che superano i costi diretti di calcolo.
Anche una capacità prevedibile può essere importante. Un'azienda con domanda costante potrebbe preferire un'infrastruttura che controlla, soprattutto quando un'API esterna impone limiti o rischi di disponibilità.
Tuttavia, questi vantaggi richiedono una macchina stabile, operatori esperti, monitoraggio, failover e controlli di sicurezza. Nulla di tutto questo deriva automaticamente dai pesi aperti.
Il test ha rivelato anche un costo in termini di competenze. Prima di eseguire il carico di lavoro utile, gli ingegneri hanno dovuto diagnosticare consumo di memoria, errori di avvio, limiti di concorrenza e comportamento del servizio.
Questo lavoro non era incluso nel semplice confronto tra macchine. Includerlo renderebbe meno favorevole il breve esperimento di self-hosting.
Questa è la lezione principale per le aziende che valutano un'implementazione self-hosted di DeepSeek. Il confronto rilevante è tra un servizio completo e un altro servizio completo.
I pesi del modello sono una componente. Noleggio dell'hardware, capacità inattiva, orchestrazione, osservabilità, risposta agli incidenti, energia, archiviazione e tempo del personale completano il sistema.
L'API di DeepSeek beneficia della stessa efficienza architetturale del modello scaricabile. Beneficia inoltre di un'infrastruttura che DeepSeek può gestire per molti clienti.
Il self-hosting deve superare entrambi questi vantaggi. Evitare il ricarico di un'API non basta quando il fornitore dell'API dispone di un migliore utilizzo delle risorse e di maggiore esperienza nel serving.
Per questo carico di lavoro, non ci è riuscito. L'opzione a pesi aperti offriva controllo, ma il cloud di DeepSeek ha garantito l'esperienza DeepSeek più economica.
L'affermazione “80 volte più economico” confrontava modelli di acquisto diversi
Il confronto in prima pagina perdeva forza perché affiancava le tariffe API pubbliche a un accesso in abbonamento usato intensamente.
L'affermazione “80 volte più economico” confronta tariffe per token in base a ipotesi specifiche. Non descrive automaticamente quanto paga ogni utente di Claude Code.
La società di consulenza accedeva a Claude tramite abbonamenti anziché tramite l'API a consumo di Anthropic. Anthropic conferma che i piani idonei forniscono accesso in abbonamento a Claude Code, soggetto a limiti di utilizzo condivisi.
Un abbonamento e un'API rispondono a modelli di acquisto diversi. L'abbonamento raggruppa l'accesso entro limiti definiti, mentre un'API addebita il costo in base al consumo misurato.
La società di consulenza ha affermato che il suo utilizzo in abbonamento equivaleva a ricevere un forte sconto rispetto alle tariffe API pubbliche. Questa differenza assorbiva gran parte del divario teorico di 80 volte.
Utilizzando il traffico di settembre, l'azienda ha calcolato che l'API di DeepSeek poteva risultare da leggermente più economica a più costosa rispetto ai suoi abbonamenti Claude. Il momento dell'utilizzo determinava dove esso si collocasse tra le tariffe di picco e quelle fuori picco.
I risultati riportati stimavano inoltre che la tariffa API pubblica di Claude avrebbe prodotto una fattura molto più elevata. Tuttavia, non era quello il prodotto acquistato dall'azienda.
Questa distinzione è facile da trascurare quando i confronti riducono ogni prodotto a una tariffa nominale per token. Lo stesso modello può essere venduto tramite abbonamenti, contratti aziendali, piattaforme cloud o API dirette.
Ogni canale ha limiti e incentivi economici diversi. Un abbonamento può favorire un utilizzo individuale costante, mentre un'API offre scalabilità programmabile e una contabilità dettagliata dei consumi.
Un contratto aziendale può aggiungere capacità negoziata, impegni di servizio o controlli. Il self-hosting sostituisce il margine di servizio del fornitore con infrastruttura e responsabilità operative.
Nessuna singola tariffa coglie tutti e quattro gli accordi. Gli acquirenti dovrebbero confrontare il canale che possono effettivamente acquistare e gestire.
La società di consulenza ha anche calcolato il costo di una modifica al codice integrata. I suoi agenti Claude hanno completato 5.610 modifiche integrate nel periodo misurato, cinque delle quali sono state successivamente annullate.
Ha stimato che DeepSeek avrebbe richiesto token aggiuntivi, nuovi tentativi e verifiche basate su Claude. In base a queste ipotesi, ogni modifica accettata sarebbe costata di più tramite DeepSeek.
Questa stima merita cautela. DeepSeek non ha svolto lo stesso compito con autorizzazione alla scrittura, quindi lo studio non ha potuto osservare il suo effettivo tasso di successo o l'uso totale di token.
Le ipotesi potrebbero essere troppo severe se prompt migliori, software di serving o progettazione degli agenti migliorassero l'output di DeepSeek. Potrebbero essere troppo ottimistiche se la revisione individuasse più difetti.
Ciononostante, il costo per modifica accettata è un obiettivo più utile del costo per token di output. Collega la spesa per l'inferenza al software che supera la revisione.
L'unità migliore dipende dal flusso di lavoro. I team di assistenza clienti potrebbero misurare i casi risolti, mentre i ricercatori potrebbero misurare i risultati verificati.
Una bassa tariffa per token resta preziosa quando i modelli richiedono un lavoro simile per ottenere tali risultati. Diventa meno decisiva quando capacità, latenza o oneri di revisione differiscono.
La cifra “80x” descrive quindi un confronto ristretto, non un risparmio universale. Call Center Doctors non ha smentito la tariffa pubblicata da DeepSeek.
Ha invece dimostrato che l'aritmetica dei listini può crollare quando prodotti, carichi di lavoro e qualità dei risultati differiscono.
La sicurezza ha impedito a DeepSeek di scrivere codice di produzione
Il limite più rilevante dell'esperimento è stato anche il suo avvertimento operativo più importante: DeepSeek non ha mai completato l'incarico di programmazione previsto.
L'azienda intendeva usare DeepSeek per agenti di scrittura del codice. I suoi revisori hanno poi individuato possibili percorsi attraverso i quali il codice generato avrebbe potuto sfuggire alla sandbox prevista.
Una sandbox è un ambiente di esecuzione isolato che limita ciò a cui il codice non attendibile può accedere. Dovrebbe impedire a un agente di raggiungere file sensibili, credenziali, reti o privilegi amministrativi.
Una debolezza segnalata riguardava un file di impostazioni in una directory temporanea condivisa. L'azienda riteneva che contenuti manipolati in quella posizione potessero consentire al codice generato di essere eseguito con privilegi elevati.
La società di consulenza ha quindi mantenuto offline gli agenti builder. DeepSeek ha operato solo tramite 48-64 agenti revisori in sola lettura.
Questi revisori hanno esaminato 2.377 cartelle di codice e prodotto 32 segnalazioni di bug. Questa attività ha mostrato un utile throughput, ma non ha testato l'implementazione autonoma.
Il problema di sicurezza non è stato presentato come un difetto nei pesi del modello DeepSeek. Riguardava l'ambiente circostante degli agenti della società di consulenza e i relativi controlli di esecuzione.
Questa distinzione è importante. Qualsiasi modello capace di generare comandi può esporre debolezze in una toolchain scarsamente isolata.
Claude, DeepSeek o un altro modello possono produrre azioni non sicure quando gli agenti ricevono accesso al filesystem e alla shell. Il confine di sicurezza deve presumere che l'output del modello non sia attendibile.
Il test ha quindi mescolato due domande distinte. Una riguardava l'economia dell'inferenza DeepSeek. L'altra riguardava se la sandbox degli agenti dell'azienda fosse pronta per l'automazione con autorizzazione alla scrittura.
Solo la prima domanda ha ricevuto misurazioni dirette del carico di lavoro. La seconda ha interrotto la prova di programmazione comparativa prevista.
Questo impedisce di sostenere con forza che Claude abbia prodotto codice migliore nello stesso esperimento. Il lavoro completato da Claude a settembre era costituito da dati storici di produzione, mentre il lavoro di DeepSeek era un test limitato.
Impedisce inoltre una misurazione equa del costo di DeepSeek per modifica integrata. Il modello non ha mai avuto l'opportunità di generare modifiche da sottoporre a revisione e distribuzione.
L'azienda ha fatto riferimento a benchmark pubblici di programmazione per sostenere che Opus avesse un vantaggio in termini di capacità. I benchmark possono fornire contesto, ma non sostituiscono un insieme identico di attività interne.
Un rigoroso seguito dello studio fornirebbe a entrambi i modelli gli stessi repository, strumenti, restrizioni di sicurezza, prompt e test di accettazione. I revisori resterebbero all'oscuro dell'identità del modello.
Lo studio registrerebbe modifiche riuscite, regressioni, nuovi tentativi, latenza, uso di token, tempo di revisione umana e violazioni della sicurezza. Solo allora potrebbe confrontare direttamente i costi totali di consegna.
Nonostante questo limite, il deployment interrotto offre una lezione pratica. Il costo dell'infrastruttura ha scarso significato quando il livello di esecuzione non può esporre in sicurezza gli strumenti previsti per il modello.
I sistemi di agenti ampliano la superficie di attacco perché collegano l'output probabilistico del modello ad azioni deterministiche. Un singolo percorso non sicuro può contare più di migliaia di token economici.
Le aziende dovrebbero quindi testare il contenimento prima di calcolare i risparmi derivanti dal lavoro autonomo. L'analisi in sola lettura e gli agenti con autorizzazione alla scrittura appartengono a categorie di rischio molto diverse.
La sicurezza influenza anche l'economia. Un isolamento più robusto può richiedere ambienti usa e getta, credenziali limitate, controlli di rete, logging e punti di approvazione.
Questi controlli consumano tempo ingegneristico e aggiungono latenza. Possono inoltre ridurre la concorrenza o richiedere infrastrutture separate.
Il modello con la tariffa di inferenza più bassa potrebbe non generare il costo più basso per una consegna sicura. Il sistema rilevante include ogni controllo necessario per fidarsi del suo output.
Cosa significa il test DeepSeek H200 per gli acquirenti di IA
Il prossimo confronto dovrebbe concentrarsi sul lavoro accettato, sull'utilizzo sostenuto e sull'esecuzione sicura, anziché su un singolo prezzo per token.
Il primo segnale da osservare è una ripetizione controllata con autorizzazione alla scrittura. DeepSeek necessita degli stessi strumenti, repository, prompt e criteri di accettazione usati in precedenza con Claude.
Se completa modifiche comparabili con una revisione limitata, la conclusione negativa della società di consulenza si indebolirebbe. Se tentativi e correzioni restano elevati, l'argomento basato sui costi per risultato si rafforzerebbe.
Il secondo segnale è l'utilizzo sostenuto nell'arco di diverse settimane. Un server self-hosted diventa più interessante quando la domanda utile resta prossima alla capacità per tutta la giornata.
Call Center Doctors ha misurato un picco che superava la capacità di una singola macchina. Tuttavia, un traffico variabile può comunque lasciare costosi periodi di inattività al di fuori di quei picchi.
Un test più lungo dovrebbe riportare l'utilizzo per ora, la profondità della coda, la latenza del primo token, le interruzioni e la quota di tempo trascorsa nel caricamento o nel ripristino.
Dovrebbe inoltre separare input memorizzato nella cache, input nuovo e output. Queste categorie interagiscono in modo diverso con la larghezza di banda della memoria e il batching.
Il terzo segnale è DeepSeek V4.1-Pro. DeepSeek afferma che la sua attuale architettura Flash sarà estesa a modelli più grandi, ma non ha fornito una data di rilascio certa.
Un modello più potente potrebbe cambiare l'economia se completa più attività con meno tentativi. Potrebbe anche richiedere più memoria o offrire un throughput inferiore.
Gli acquirenti dovrebbero osservare sia le capacità sia i requisiti di serving. Un miglioramento del benchmark non garantisce un costo di produzione inferiore.
Il risultato attuale di DeepSeek resta significativo. Le sue tariffe ufficiali rendono accessibile la sperimentazione ad alto volume e i suoi pesi scaricabili offrono flessibilità di deployment.
Il test non ha cancellato questi vantaggi. Ha ristretto le condizioni in cui si traducono in risparmi.
Per una domanda intermittente o incerta, l'API gestita di DeepSeek appare più razionale del noleggio di un server dedicato con quattro GPU. Mantiene basse tariffe per token senza trasferire al cliente le operazioni infrastrutturali.
Per dati sensibili, domanda sostenuta prevedibile o ottimizzazione specializzata, il self-hosting può comunque meritare una valutazione. Il business case deve includere personale, affidabilità, sicurezza e capacità inutilizzata.
Claude Code presenta una proposta diversa. Riunisce l'accesso al modello, un'interfaccia di programmazione e infrastruttura gestita dal fornitore entro limiti di abbonamento.
Questa formula può superare i confronti basati sui token per un uso individuale intenso. Può anche diventare restrittiva quando le organizzazioni necessitano di capacità programmabile o controllo centralizzato.
La pressione ricade quindi sui team di approvvigionamento e sui responsabili dell'ingegneria. Devono smettere di trattare “API”, “abbonamento” e “self-hosted” come unità di acquisto intercambiabili.
Dovrebbero iniziare dalle tracce di produzione anziché dagli esempi dei fornitori. La traccia più utile registra lunghezza del contesto, cache hit, output, latenza, errori e risultati accettati.
I team possono quindi riprodurre carichi di lavoro rappresentativi attraverso sistemi concorrenti. Il test dovrebbe includere le condizioni operative che contano dopo una demo riuscita.
Tali condizioni includono concorrenza, variazioni di traffico, riavvii, accodamento, aggiornamenti dei modelli, monitoraggio e ripristino. I test di sicurezza devono svolgersi prima che gli agenti ottengano accesso in scrittura.
Le metriche di risultato dovrebbero corrispondere all'obiettivo dell'organizzazione. Per gli agenti di coding, includono modifiche integrate, difetti, rollback, tempi di revisione e tempi di completamento.
Per gli agenti di supporto, misure utili includono casi risolti, escalation, soddisfazione dei clienti e violazioni delle policy. Per gli agenti di ricerca, le scoperte verificate contano più delle pagine generate.
Il test DeepSeek H200 è prezioso perché si è avvicinato a questo standard. Ha sostituito un confronto astratto delle tariffe con una distribuzione reale del contesto e un'infrastruttura reale.
I suoi limiti sono altrettanto istruttivi. La breve durata, la singola organizzazione, il lavoro di sicurezza incompleto e l'accesso alla produzione non uniforme impediscono un verdetto universale.
La conclusione appropriata è più circoscritta. Quattro H200 noleggiati non hanno superato l'API di DeepSeek per questo carico di lavoro degli agenti, e l'API non ha offerto un evidente vantaggio di 80 volte rispetto agli abbonamenti.
Questo basta per mettere in discussione le affermazioni semplicistiche. Non basta per liquidare DeepSeek, i pesi aperti o l'inferenza self-hosted.
Prima di modificare uno stack AI, raccogliete una settimana di traffico rappresentativo e calcolate il costo per risultato accettato. Poi ripetete il confronto con i controlli di sicurezza abilitati.
Chiedetevi se il modello porta a termine lo stesso lavoro, non se il suo token più economico appare impressionante. Il prossimo test DeepSeek H200 dovrebbe rispondere a questa domanda più difficile.
