Vendere servizi LLM: i ricavi dipendono dall'uso, i costi dalla capacità disponibile

Il soggetto di questo articolo è l’azienda che espone un modello di linguaggio di grandi dimensioni (LLM) come servizio. Può eseguirlo sulle proprie macchine, acquistare capacità cloud oppure comprare inferenza da altri fornitori. In ogni caso presenta al cliente un’interfaccia di programmazione (API), un accesso o un contratto e risponde del livello di servizio promesso.

Quell’azienda fattura in base ai token, alle richieste o a un canone. La capacità che usa, invece, costa nel tempo: per ora di GPU, per capacità prenotata, per centro di calcolo costruito e alimentato. Quando le richieste sono poche paga risorse che restano vuote; quando sono troppe, le code crescono e il servizio rallenta. Fra i due estremi deve vendere abbastanza lavoro utile da coprire la capacità impegnata.

Con il prezzo a consumo, l’azienda assume la variabilità della domanda e il rischio delle ore inutilizzate. Il listino mostra quanto incassa dal cliente, ma non prova che quel rischio sia interamente remunerato: il prezzo può anche essere promozionale o sostenuto da altri ricavi.

Questo non significa che ogni produttore noleggi GPU a ore. Un grande fornitore cloud può possedere le macchine, un laboratorio può impegnarsi a comprare capacità per anni e un intermediario può acquistare inferenza da più laboratori. Cambia il contratto, non il problema: una parte della capacità costa nel tempo, mentre il ricavo arriva quando qualcuno la usa. Per le macchine possedute quel costo non è una tariffa oraria: va ricostruito nel periodo con ammortamento, capitale, energia e vita utile.

La stessa macchina, sette carichi e sette costi unitari

Nella prova il prezzo orario della H100 non cambia. Cambia il numero di token prodotti sui quali viene distribuito.

Un esperimento pubblico permette di vedere il meccanismo senza stimare i costi segreti di un produttore. Il preprint Beyond Per-Token Pricing e il relativo repository misurano 140 configurazioni di inferenza. Prendiamone una: Qwen3-30B-A3B nel formato numerico in virgola mobile a 8 bit (FP8), eseguito con vLLM su una H100 valorizzata a 6,98 dollari l’ora.

Ogni richiesta della prova contiene in media 512 token in ingresso e ne produce 256. Gli arrivi seguono una distribuzione di Poisson; sono disattivati sia il riuso dei prefissi già elaborati sia l’elaborazione a blocchi del testo iniziale. Nella fonte, il noleggio della configurazione costa 6,98 dollari l’ora in tutti i sette punti. I punti corrispondono a sette carichi offerti alla stessa macchina: 1, 5, 10, 25, 50, 100 e 200 richieste al secondo. «Offerte» significa presentate al servizio; quando si formano code, non tutte vengono concluse nello stesso secondo.

Il costo della capacità per un milione di token prodotti si ottiene dividendo 6,98 dollari per la produzione oraria. Al primo punto la macchina produce 255 token al secondo, cioè 918.000 in un’ora: la sola capacità costa quindi circa 7,60 dollari per milione. A cento richieste offerte produce 8.902 token al secondo, circa 32 milioni l’ora: lo stesso costo orario scende a 0,218 dollari per milione.

Ecco i sette punti della curva:

Carico offerto, richieste/s	Costo della capacità ($/milione di token prodotti)	Tempo al primo token, p99
1	7,600	78 ms
5	1,548	90 ms
10	0,794	108 ms
25	0,367	144 ms
50	0,263	264 ms
100	0,218	431 ms
200	0,209	2.229 ms

A una richiesta al secondo quasi tutta la spesa oraria grava su pochi token. A cento richieste il costo viene distribuito su un flusso molto più grande. A duecento il risparmio aggiuntivo è minimo, mentre il tempo al primo token al novantanovesimo percentile passa da 0,431 a 2,229 secondi.

Chiameremo utilizzo dell’inferenza la quota di capacità che serve lavoro utile entro il livello di servizio. La soglia usata nella figura, 500 millisecondi per il tempo al primo token e 15 secondi per la latenza complessiva, è illustrativa. Non viene dal paper e non pretende di definire un buon servizio per tutti. Serve a rendere esplicita una cosa che nei conti di pareggio viene spesso nascosta: la capacità utile è quella che serve lavoro entro il livello di servizio, non quella che tiene la GPU più occupata.

Il carico determina il pareggio insieme al listino

Una tariffa diventa conveniente per chi vende solo dopo che il traffico ha distribuito il costo della capacità su abbastanza token prodotti.

Supponiamo, per mostrare il calcolo, che il servizio incassi un dollaro per milione di token prodotti. Non è la quotazione di un modello reale. Con una H100 da 6,98 dollari l’ora, il pareggio della sola capacità si raggiunge a 1.938,9 token prodotti al secondo. Nella prova cade fra cinque e dieci richieste al secondo offerte.

A cento richieste al secondo la macchina produce 8.902 token al secondo. Per arrivare a un milione impiega circa 112 secondi. Al prezzo di 6,98 dollari l’ora, quei 112 secondi di H100 costano 0,218 dollari.

Gli 0,218 dollari non rappresentano il costo industriale della sola scheda. Sono il quoziente fra il prezzo orario di noleggio assunto dalla fonte e i token prodotti nel tempo misurato. Per chi acquista la capacità, i 6,98 dollari sono un prezzo non scomponibile con i dati disponibili: non sappiamo quali quote di server, struttura, energia, rete, manutenzione e margine del fornitore cloud contenga.

Il modello AI datacenter cost breakdown di Epoch AI offre un riferimento per quelle componenti a monte. Nel modello, aggiornato nel maggio 2026, il costo annualizzato è ripartito così:

Componente	Costo annuo	Quota
Server	5,021 mld $	59,0%
Struttura	1,387 mld $	16,3%
Rete	1,167 mld $	13,7%
Energia	594 mln $	7,0%
Imposte, manutenzione, personale e altro	circa 345 mln $	4,0%

È un modello stilizzato, non il consuntivo di un operatore. Inoltre descrive chi possiede un centro dati AI da un gigawatt, non un’azienda che acquista GPU a ore. Le sue percentuali non si possono quindi applicare agli 0,218 dollari: significherebbe attribuire a un prezzo di noleggio la stessa composizione del costo annualizzato di quel centro dati e potrebbe contare due volte le stesse voci.

Il conto comprende tutti i 112 secondi noleggiati, compresa la capacità della stessa H100 che il carico osservato non usa. Non comprende invece l’avviamento, altre repliche tenute pronte per picchi o guasti, la ridondanza fra regioni e le voci fatturate separatamente. Il conto didattico diventa quindi:

Esempio didattico a 100 richieste/s, per un milione di token prodotti	Importo
Ricavo ipotizzato	1,000 $
Quota del noleggio H100 attribuita ai token	−0,218 $
Residuo prima degli altri costi diretti	0,782 $

Quel residuo non è un utile né il margine analitico dell’inferenza. Prima di calcolare quest’ultimo, l’azienda deve sottrarre i costi che il noleggio non copre già: traffico di rete eventualmente fatturato a parte, esercizio del servizio, osservabilità, sicurezza, fatturazione, supporto e capacità di riserva aggiuntiva. Ricerca, addestramento, costo del capitale proprio e altri costi aziendali appartengono ai passaggi contabili successivi.

L’esempio presume che l’azienda venda direttamente al cliente. Se il servizio passa attraverso un distributore, una parte del dollaro può fermarsi nel canale prima di arrivare al fornitore. Le partnership fra laboratori e grandi fornitori cloud documentano questi flussi, ma le percentuali pubbliche non bastano a ricostruirli.

Per non confondere le grandezze bisogna rispettare sempre la stessa scala:

1. ricavo lordo del canale: quanto paga il cliente finale;
2. ricavo netto del canale: quanto arriva al fornitore dopo l’eventuale quota del distributore;
3. margine analitico dell’inferenza: quanto resta dopo capacità e altri costi direttamente attribuibili;
4. margine lordo contabile dell’azienda;
5. utile operativo;
6. utile netto.

Un listino permette di osservare la prima voce. Talvolta un accordo rende visibile l’esistenza della seconda. Non autorizza a dedurre le ultime quattro.

Anche il ricavo lordo richiede più di un contatore. Una richiesta può fatturare separatamente token di ingresso, ingresso letto dalla cache, token prodotti, ricerca, strumenti o esecuzioni. Il conto completo somma quantità e tariffa di ciascuna voce. La linea da un dollaro dell’esempio considera soltanto i token prodotti e serve a mostrare il meccanismo del pareggio; lascia intenzionalmente a zero tutte le altre componenti.

Usare meglio la capacità richiede più che riempire la GPU

Aggregazione delle richieste, differimento, instradamento e cache aumentano il lavoro utile che una capacità già impegnata può servire.

Il fornitore ha quattro leve immediate:

• aggregare le richieste in batch;
• spostare il lavoro non urgente nelle ore meno affollate;
• instradare ciascun carico verso la macchina adatta;
• riusare calcoli già svolti.

I listini riflettono queste differenze: Anthropic e Google offrono modalità differite o batch a prezzo ridotto; Azure e Bedrock aggiungono anche capacità prenotata. Vertex vende a sua volta capacità riservata.

Il riuso della cache è il caso meno intuitivo. Durante il prefill, il modello elabora il contesto ricevuto e costruisce la cache di chiavi e valori, o KV cache. Questa memoria permette di proseguire il calcolo senza rileggere ogni volta tutto il testo precedente.

Il problema nasce quando il servizio usa più repliche in parallelo. La parola «replica» può però trarre in inganno: non indica sempre una singola GPU. Un modello piccolo può stare nella memoria di una scheda; un modello grande deve essere diviso fra più schede che lavorano insieme come una sola unità di esecuzione. I parametri sono valori numerici che devono restare disponibili nella memoria degli acceleratori. In FP8, come prima approssimazione, serve un byte per peso: 100 miliardi di parametri corrispondono a circa 100 gigabyte; un modello sette volte più grande si avvicina a 700, prima ancora della KV cache e delle strutture usate dal motore.

Il caso GLM-5.3 dà la misura. I soli file dei pesi in FP8 occupano circa 756 gigabyte, mentre una H200 dispone di 141 gigabyte di memoria. I pesi non entrano quindi in una singola scheda, ancora prima di riservare spazio alla KV cache e al motore di esecuzione. La ricetta pubblica di vLLM usa otto H200 con parallelismo tensoriale: ogni GPU conserva una parte del modello e partecipa al calcolo della stessa richiesta. Quel gruppo di otto GPU forma una replica del servizio, non otto repliche indipendenti.

Altri modelli dichiarano dimensioni superiori a GLM-5.3. Il suo README ufficiale indica 744 miliardi di parametri totali e 40 miliardi attivati per token. La scheda ufficiale di DeepSeek-V4-Pro ne indica 1.600 miliardi totali e 49 attivati; il repository di Kimi K3 ne indica 2.800 totali e 104 attivati. Sono circa 2,2 e 3,8 volte i parametri totali di GLM-5.3. Il maggiore rapporto documentato qui è dunque 3,8. Nei modelli MoE il totale pesa soprattutto sulla memoria necessaria al gruppo di GPU, mentre i parametri attivati incidono sul calcolo svolto per ciascun token.

OpenAI e Anthropic mantengono riservato il numero di parametri dei loro modelli di punta. Per analogia con i concorrenti che lo dichiarano, è ragionevole formulare un’ipotesi di lavoro: anche quei modelli appartengono probabilmente alla classe dei sistemi che richiedono esecuzione distribuita su più GPU, con un ordine di grandezza che può andare dalle centinaia ad alcune migliaia di miliardi di parametri totali. Questa è un’inferenza priva di verifica diretta. Qualità percepita e risultati dei benchmark sono insufficienti a collocarli sopra GLM, DeepSeek o Kimi per numero di parametri.

Che la replica usi una scheda o un gruppo, la KV cache resta normalmente presso il processo che l’ha costruita. Il router può assegnare la richiesta successiva della stessa conversazione, o un’altra richiesta con lo stesso prefisso, a una replica diversa. La nuova replica non trova la cache e deve ripetere il prefill. Lo stesso accade dopo un’espulsione dalla memoria o il riavvio del processo.

I rimedi seguono due strategie. L’instradamento con affinità prova a riportare le richieste sulla replica che possiede già la cache. LMCache, descritto anche nel relativo paper, rende invece i blocchi riutilizzabili disponibili fuori dal singolo processo, usando anche RAM, disco o depositi remoti, così che altre repliche possano recuperarli. Le due tecniche possono coesistere. Tentano entrambe di evitare calcoli ripetuti che consumano capacità senza produrre nuovi token.

Il diagramma non dice che LMCache rende ogni sistema più veloce. Un benchmark su otto H100 ha misurato, in una configurazione con venti richieste per prefisso, un tempo al primo token inferiore del 79 per cento e una portata superiore del 264 per cento. Sono risultati ottenuti in quella configurazione, non costanti universali. Una valutazione di GPUStack ha trovato il contrario quando il riuso mancava: trasferimenti e coordinamento hanno ridotto la portata del 3–15 per cento.

La conclusione economica è più stretta e più solida: se il carico contiene lavoro ripetibile, una cache condivisa può aumentare il lavoro utile servito dalla capacità già impegnata. Il guadagno viene dal lavoro evitato sul testo già elaborato: la GPU può servire più richieste anche se la sua percentuale di occupazione non cresce. I nuovi token in uscita devono comunque essere calcolati e continuano a consumare capacità.

I contratti distribuiscono il rischio delle ore vuote

Consumo, batch, prenotazione e abbonamento differiscono soprattutto per il soggetto che paga quando la capacità resta inutilizzata.

L’efficienza tecnica non basta. Il fornitore può anche cambiare chi sostiene il rischio del carico incerto.

• Consumo a token. Il cliente paga ciò che usa e può smettere quasi subito. Il fornitore assume il rischio della capacità vuota; il listino non dice se il prezzo lo remuneri interamente.
• Batch o elaborazione differita. Il cliente accetta di attendere; il fornitore ottiene libertà di collocare il lavoro quando ha capacità disponibile. Il prezzo può scendere.
• Capacità prenotata. Il cliente paga in anticipo una capacità garantita per una determinata portata o durata. Il ricavo diventa più prevedibile e una parte del rischio di inutilizzo passa a chi compra.
• Abbonamento con limiti. Il canone stabilizza il ricavo, ma non compra token illimitati né un esito garantito. Tetti d’uso e priorità limitano il consumo degli utenti più intensivi.

Sono prodotti diversi. Confondere canone, consumo e capacità riservata nasconde proprio la variabile che li distingue: chi paga quando la macchina resta in attesa.

L’aggregazione fra clienti aiuta soltanto se la domanda dei diversi clienti non cresce e diminuisce negli stessi momenti. Carichi indipendenti possono compensare ore piene e ore vuote; un picco correlato sullo stesso modello o nella stessa regione richiede invece repliche e capacità di riserva. Senza dati sul portafoglio dei clienti non si può quantificare questo vantaggio.

Il fornitore governa anche l’ingresso del traffico. Quote, limiti di frequenza e di concorrenza, priorità, code e rifiuti proteggono il livello di servizio quando le richieste superano la capacità disponibile. Sono strumenti economici oltre che operativi: stabiliscono quale domanda viene servita subito, rimandata o respinta.

Per l’azienda che espone il servizio, eseguire il modello in proprio porta il rischio della capacità dentro il proprio conto economico. Il caso GLM-5.3 lo rende visibile. Il modello occupa circa 756 gigabyte in FP8 e la ricetta pubblica di vLLM usa otto H200. Al prezzo pubblico di 3,99 dollari l’ora per H200, la configurazione vale 31,92 dollari l’ora prima di rete, personale e riserva. Spegnerla riduce le ore fatturate, ma comporta tempi di avviamento, minore disponibilità e lavoro operativo. Il servizio API aggrega questi problemi fra molti clienti e li rivende a consumo.

Non possiamo invece usare le prestazioni circolate in un post sui social su questo caso: il prezzo delle GPU, il peso del modello, la ricetta a otto H200 e il listino API sono riscontrabili; i token al secondo e i 41 minuti di avviamento dichiarati nel post non lo sono. L’esempio chiarisce la forma del rischio, non offre un nuovo pareggio.

Produttori, cloud, distributori e applicazioni seguono percorsi diversi

L’API descrive come entra la richiesta; token, batch, ora, capacità prenotata e canone descrivono come viene venduto il servizio.

Non esiste una sequenza obbligatoria di passaggi fra il modello e il cliente. Bisogna separare due domande: quale ruolo svolge l’azienda e con quale contratto vende il servizio. Ogni ruolo presente aggiunge astrazione e servizio, ma anche costi propri e un nuovo contatore commerciale.

• Produttore con servizio diretto. Addestra il modello, organizza l’inferenza e vende direttamente l’API. Può fatturare token, richieste, batch, capacità prenotata o un canone.
• Cloud o strato di esecuzione dei modelli. Ospita pesi propri o altrui e aggiunge GPU, regioni, disponibilità e gestione del motore di esecuzione. Può vendere ore di macchina, token, batch, portata riservata o accesso periodico. Ollama occupa questa posizione quando offre l’esecuzione locale o nel proprio cloud.
• Distributore API. Riunisce endpoint di più fornitori e aggiunge catalogo, instradamento, ripiego, fatturazione e metriche. Può applicare una commissione, una maggiorazione o una quota sui ricavi. OpenRouter è l’esempio osservato.
• Intermediario applicativo. Trasforma l’inferenza in un ambiente o in un processo. Poe usa punti; Cursor integra l’inferenza nello sviluppo e Notion la usa in funzioni e agenti. Il ricavo può arrivare da canoni, crediti o consumo aggiuntivo.

Questi percorsi possono combinarsi. Un’applicazione può comprare direttamente dal produttore, passare da un cloud o usare un distributore. Un laboratorio può anche essere cloud e distributore di se stesso; con pesi aperti, chi ha addestrato il modello può restare fuori dal pagamento della singola esecuzione.

OpenRouter rende misurabile una parte del lavoro del distributore. Per ogni coppia fra modello e provider osserva tempo al primo token, velocità dei token in uscita e disponibilità; mostra inoltre la quantizzazione dichiarata.

Quando la richiesta indica un solo modello e non impone preferenze, il distributore dà precedenza agli endpoint che non hanno avuto interruzioni significative negli ultimi trenta secondi. Fra i candidati stabili meno costosi ne sceglie uno con un peso inverso al quadrato del prezzo; gli altri restano disponibili come ripiego. Se un endpoint costa la metà di un altro, a parità delle altre condizioni riceve un peso quattro volte maggiore. La strategia predefinita bilancia così costo e continuità. La latenza minima o la portata massima devono essere richiesti esplicitamente.

Impostare l’ordinamento per prezzo, latenza o portata disattiva quel bilanciamento e fa provare gli endpoint nell’ordine risultante. Si possono anche preferire soglie p50, p75, p90 e p99. Le statistiche coprono una finestra mobile di cinque minuti e valgono come segnale operativo. Un endpoint sotto soglia rimane disponibile in fondo all’ordine: la soglia orienta il percorso, senza costituire una promessa contrattuale. Il valore aggiunto comprende quindi una sola API e la scelta continua del luogo di esecuzione secondo il livello di servizio richiesto.

Una conversazione introduce un correttivo. Quando modello e provider offrono il prompt caching a prezzo ridotto, OpenRouter prova a mantenere la conversazione sullo stesso endpoint: cambiarlo perderebbe la cache calda. L’affinità può essere legata a un session_id, scade dopo dieci minuti di inattività e cede davanti a errori o a un ordine manuale dei provider. La KV cache resta presso l’endpoint che l’ha costruita: OpenRouter conserva il percorso, non trasferisce lo stato fra fornitori. L’azienda distributrice rinuncia così a una nuova ottimizzazione del prezzo o della latenza quando il riuso del prefisso è più conveniente.

Ollama occupa una posizione diversa. Per chi usa l’API, ollama.com è un unico host remoto e la stessa interfaccia può eseguire un modello sul computer locale o nel cloud. Dietro quell’host, però, la documentazione dichiara una collaborazione con NVIDIA Cloud Providers. Ollama ospita modelli e capacità soprattutto negli Stati Uniti e può instradare domanda aggiuntiva verso Europa e Singapore. Il servizio impone ai partner di non registrare né conservare i contenuti e di non usarli per addestrare modelli.

Le fonti pubbliche non dicono quale partner serva la singola richiesta né descrivono una scelta per prezzo, latenza o portata controllabile dal cliente. Ollama può quindi bilanciare dietro le quinte la capacità fornita dai partner, ma all’esterno vende un solo servizio di esecuzione. OpenRouter, invece, rende visibili i provider e trasforma la loro selezione in una funzione dell’API. È la differenza fra coordinare subfornitori per erogare il proprio servizio e distribuire servizi riconoscibili di più fornitori.

La differenza fra ruolo e contratto si legge meglio incrociando le due dimensioni:

Ruolo, servizio e costi aggiunti	Forme commerciali possibili
Produttore con servizio diretto: modello, inferenza, capacità, livello di servizio e supporto	token, richiesta, batch, capacità prenotata, canone
Cloud o strato di esecuzione: GPU, motore di esecuzione, regioni, disponibilità e gestione operativa	ora di macchina, token, batch, portata riservata, canone
Distributore API: catalogo, API unica, instradamento, ripiego, fatturazione e metriche	commissione, maggiorazione, quota sui ricavi, crediti
Intermediario applicativo: ambiente di lavoro, strumenti, memoria, processo e assistenza all’utente	abbonamento, punti, crediti, consumo aggiuntivo

La matrice non rappresenta una successione obbligatoria. Ogni riga può collegarsi direttamente al cliente oppure a un’altra riga; una stessa impresa può svolgere più ruoli.

Alcune scelte osservate mostrano come si occupano le celle:

• OpenAI e Anthropic vendono direttamente l’API dei propri modelli a consumo e offrono anche modalità batch; Anthropic distingue inoltre cache e abbonamenti al prodotto Claude.
• Google combina più ruoli: produce Gemini, vende l’API diretta e tramite Vertex aggiunge esecuzione cloud, priorità e capacità prenotata.
• OpenRouter occupa la riga del distributore API: trasferisce i prezzi dichiarati dagli endpoint e ricava una commissione dall’acquisto dei crediti.
• Ollama occupa la riga dell’esecuzione: mantiene la stessa interfaccia fra computer locale e cloud e vende piani con limiti e consumo aggiuntivo.
• Poe, Cursor e Notion occupano la riga applicativa: trasformano l’inferenza in punti, ambiente di lavoro, funzioni e agenti venduti con canoni o crediti.

Questa classificazione non autorizza ad assegnare un margine a ogni ruolo. I listini mostrano prezzi, punti, quote e talvolta tariffe dei modelli. Non rivelano il costo netto pagato dall’intermediario, il consumo medio degli abbonati, i volumi per canale o la ripartizione dei ricavi. Possiamo descrivere la trasformazione del prodotto; non possiamo ricostruire il conto economico di Poe, Cursor, Notion, OpenRouter o Ollama.

La distinzione serve anche a evitare un altro errore. Un modello con pesi aperti può produrre ricavi per chi lo esegue senza versare ricavi API a chi lo ha addestrato. Al contrario, laboratorio, cloud e applicazione possono stare dentro la stessa impresa. «Produttore», «distributore» e «intermediario» indicano funzioni economiche, non specie aziendali separate.

L’azienda deve misurare il servizio che vende

Il confronto corretto segue domanda, ricavi e costi diretti sullo stesso periodo.

Per decidere come costruire e prezzare il servizio, l’azienda non può confrontare un listino API con il costo teorico di una GPU a pieno carico. Deve misurare almeno sei grandezze coerenti:

• domanda reale, compresi picchi, correlazioni e ore vuote;
• ricavo lordo composito, con ingresso, uscita, cache, strumenti e canoni;
• livello di servizio, soprattutto tempo al primo token e latenza nelle code peggiori;
• costo della capacità per unità utile, calcolato sul traffico servito entro quel livello;
• altri costi direttamente attribuibili, dalla rete alla capacità di riserva;
• ricavo netto del canale, dopo eventuali quote riconosciute a distributori.

Le sei grandezze devono riferirsi allo stesso insieme di richieste e allo stesso periodo. In caso contrario il prezzo, il costo unitario e il ricavo usano denominatori diversi e il margine risultante non descrive il servizio reale.

L’azienda può costruire la capacità, prenotarla oppure comprare un’API a monte. In un confronto omogeneo, una macchina ben utilizzata può costare meno dell’API; servono però lo stesso modello, qualità, regione, disponibilità e livello di servizio. L’API può convenire davanti a una macchina vuota, a un picco che richiede riserva, a un avviamento lento o a un servizio da presidiare giorno e notte. La capacità propria può vincere con un carico stabile, sufficiente e governabile; quella prenotata può stare nel mezzo. Il pareggio dipende sempre dalla domanda e dal livello di servizio.

La matrice dell’azienda cliente

La matrice non sceglie il fornitore: indica quale confronto economico aprire per primo e quali condizioni possono rovesciarne l’esito.

Fin qui il soggetto è stato l’azienda che vende il servizio LLM. In questa matrice finale la prospettiva cambia: riguarda l’azienda cliente, che deve decidere come acquistare il servizio e quale rischio lasciare al fornitore. Chi conduce la scelta non governa la capacità del venditore, ma può capire come quella capacità entra nel contratto e nel prezzo.

Per capacità residua si intende la parte già pagata, posseduta o impegnata che la domanda non assorbe nel periodo.

Profilo della domanda dell’azienda cliente	Primo confronto da aprire
Nuova, incerta o molto variabile	consumo contro canone con limiti; verificare picchi, prezzo e livello di servizio
Differibile entro una scadenza	batch contro consumo immediato; misurare quanto vale l’attesa concessa al fornitore
Prevedibile, con garanzie contrattuali	capacità prenotata contro consumo; stimare impegno minimo e capacità residua
Stabile, elevata e governabile	capacità propria o dedicata contro capacità prenotata; includere esercizio, ridondanza e avviamento
Distribuita fra modelli, provider o regioni	distributore API o servizio gestito contro rapporti diretti; verificare instradamento, cache, commissioni e trasparenza

Per usarla, chi conduce la scelta deve classificare ogni carico con dati dello stesso periodo, senza fermarsi alla media annuale. Individua tutti i profili che descrivono il carico e confronta le soluzioni indicate con almeno un’alternativa pertinente fra quelle presenti nella matrice, mantenendo uguali modello, qualità, regione, disponibilità e livello di servizio.

La matrice non è un albero decisionale definitivo. La stessa azienda cliente può avere carichi in più righe e combinarne le soluzioni. Serve a evitare confronti falsi, a rendere esplicito chi sostiene la capacità residua e a stabilire quali misure raccogliere prima di negoziare il contratto. Quando cambiano domanda o livello di servizio, il confronto va rifatto.

È qui che il conto si chiude. Chi paga il conto degli agenti AI guarda gli investimenti complessivi; l’articolo sull’harness spiega perché i produttori controllano anche l’ambiente di lavoro; quello su MoE e KV cache descrive i meccanismi tecnici. L’economia dell’azienda che lo espone sta nel punto che li unisce: trasformare capacità impegnata nel tempo in lavoro utile venduto, entro una promessa di servizio.

I concetti che questo articolo introduce

Fonti

Curva e modello economico: P. Patil, Beyond Per-Token Pricing, preprint del 10 giugno 2026, e repository vllm-cost-meter, commit 3f308c03. La tabella usa la configurazione C4 del file data/master_results.csv; la formula e i valori delle sette righe sono stati ricalcolati. Il livello di servizio e la linea da un dollaro della figura sono ipotesi didattiche dichiarate.

Perimetro del costo della capacità: AI datacenter cost breakdown, Epoch AI, aggiornato nel maggio 2026. È un modello stilizzato del costo annualizzato di un centro dati AI da un gigawatt, non il consuntivo della configurazione provata. Viene usato per identificare le componenti che possono stare a monte del prezzo di noleggio, non per applicare un moltiplicatore agli 0,218 dollari.

Listini e forme contrattuali: OpenAI API Pricing, Anthropic Pricing, Gemini Developer API, Amazon Bedrock, Azure OpenAI e Google Cloud Provisioned Throughput, letti il 29 agosto 2026. I listini sono dinamici e vengono usati per la struttura, non per fissare una classifica di prezzo.

LMCache e capacità utile: repository ufficiale LMCache e Liu et al., LMCache; benchmark congiunto su GKE; valutazione GPUStack. I risultati sono presentati come specifici delle configurazioni provate e non vengono generalizzati.

Dimensioni ed esecuzione in proprio: GLM-5.3, DeepSeek-V4-Pro, Kimi K3, specifiche NVIDIA H200, listino H200 di JarvisLabs, ricetta vLLM per GLM-5.3 e listino API Z.AI, letti il 29 e 30 agosto 2026. Le prestazioni e il tempo di avviamento riportati nel post non sono usati come prova.

Ruoli e forme commerciali: documentazioni di prodotto e listini di Poe, Cursor, Notion, OpenRouter e Ollama, lette il 30 agosto 2026. Per Ollama sono stati controllati anche i piani e chiarimenti sull’infrastruttura e l’informativa sulla privacy. Per OpenRouter sono state controllate anche le domande frequenti su prezzi, crediti e commissioni, la selezione dei provider, la cache del prompt con instradamento per affinità e la sua guida alla valutazione degli endpoint. La documentazione descrive le metriche e le regole di instradamento; la guida resta materiale del produttore. Queste fonti descrivono prodotto e contatori, non costi netti o margini.

Accordi cloud-laboratori: rapporto FTC sulle partnership cloud-laboratori. Il rapporto documenta diritti sui ricavi, impegni cloud ed esclusività, ma le condizioni economiche pubbliche sono in parte omesse.