La domanda non è dove costa meno un token
Un' impresa vuole usare un assistente per leggere documenti e preparare risposte. Le alternative sembrano immediate: pagare un servizio remoto per ogni utilizzo oppure acquistare e gestire una macchina locale. La prima ha un costo visibile nella fattura del servizio; la seconda sembra gratuita dopo l' acquisto. Ma le persone che mantengono il sistema, il tempo inutilizzato e la capacità nei momenti di punta possono cambiare la scelta. Questo articolo aiuta responsabili operativi e tecnici a costruire un confronto controllabile, prima di discutere marche o modelli. La domanda pratica è: a quale volume il locale diventa meno costoso, e quel volume può essere davvero servito?
Svilupperemo un modello di costo mensile, ne ricaveremo il pareggio e lo confronteremo con un vincolo di capacità. Tutti i prezzi, i volumi e la produttività numerica sono ipotesi didattiche: non sono listini attuali, preventivi o misure di un computer. Non abbiamo eseguito modelli né test di carico. Abbiamo invece eseguito il codice che calcola i costi e la sensibilità alle ipotesi, conservando risultati e grafici. La conclusione non raccomanda un fornitore: chiarisce quali dati raccogliere e quando un confronto apparentemente favorevole è incompleto.
Prima rendere equivalenti i due servizi
Una richiesta deve rappresentare lo stesso lavoro nei due percorsi: stesso obiettivo, documenti confrontabili, qualità minima e tempo di risposta accettabile. Se un modello locale risponde velocemente ma richiede correzioni e quello remoto risolve il compito, il costo per chiamata non confronta due servizi equivalenti. Anche contare solo i token, le unità di testo elaborate dal modello, può confondere: il lavoro richiesto e le lunghezze delle risposte possono variare. Nel modello successivo assumiamo richieste omogenee; per dati reali occorre separare almeno classi di carico o misurare un costo medio pesato sul proprio insieme di casi.
La FinOps Foundation distingue metriche di efficienza delle risorse e metriche legate ai risultati di lavoro. È un riferimento metodologico utile per scegliere il denominatore, non una prova che il cloud sia più conveniente o che l' AI produca valore in un' impresa specifica. Qui le formule e gli scenari sono analisi nostre, non risultati della Foundation.
Due voci da tenere separate: disponibilità e utilizzo
Indichiamo con F il costo mensile che sosteniamo per rendere disponibile il percorso, anche quando non arriva nessuna richiesta; con v il costo aggiuntivo medio di una richiesta omogenea. Per il locale F può comprendere quota economica della macchina, gestione e capacità riservata. Per il remoto può comprendere integrazione e impegni minimi. Non tutto il lavoro umano è fisso, e non tutta l' energia è variabile: classificare le voci secondo il comportamento reale evita di etichettarle male. Comprare una macchina con denaro già disponibile non elimina il costo del suo uso né il valore di destinarla a un altro compito.
Scegliere un orizzonte comune è indispensabile. Non confrontare un acquisto iniziale con una sola fattura mensile senza spiegare durata d' uso, manutenzione e valore residuo. Un costo mensile equivalente e un flusso di cassa rispondono a domande diverse. Nel nostro esempio F è semplicemente un parametro mensile assunto: non deriva da un ammortamento fiscale o da un' offerta. Le spese iniziali, se esistono, devono essere distribuite o mostrate separatamente con ipotesi trasparenti. Non sommare due volte acquisto e quota di quello stesso acquisto nello stesso totale.
Il modello più semplice che possiamo verificare
N è il numero di richieste nel mese, C il costo in euro nel mese. I suffissi L e C indicano locale e cloud; F è in euro al mese e v in euro per richiesta. Per un mese fissato la formula aggiunge costo di disponibilità e consumo. Assume v costante, nessun salto di capacità e la stessa composizione delle richieste. Scaglioni, sconti, cache e autoscaling richiedono invece funzioni diverse; non vengono misteriosamente assorbiti in una retta universale.
Usiamo F_L = 600 euro/mese e v_L = 0,0002 euro/richiesta; F_C = 50 e v_C = 0,005 nelle stesse unità. Sono valori inventati per rendere leggibile il meccanismo. Con 1000 richieste il locale costa 600,20 euro, il cloud 55 euro: dividere per mille dà 0,6002 e 0,055 euro per richiesta, includendo i fissi. Con zero richieste i costi rimangono 600 e 50 euro, ma il costo per richiesta non è definito. Dire che il costo unitario è zero quando nessuno usa il sistema nasconderebbe proprio l' inutilizzo che vogliamo valutare.
Il pareggio: una soglia condizionata dalle ipotesi
Per trovare il volume in cui i costi si uguagliano, imponiamo C_L = C_C e spostiamo i termini fissi da una parte e quelli proporzionali dall' altra. Se il locale ha fisso maggiore ma variabile minore, il volume può compensare la differenza iniziale. Dividiamo soltanto se v_C è diverso da v_L. Se i variabili sono uguali, non c' è una soglia di questo tipo: decide la differenza dei fissi. Se il risultato è negativo, non va presentato come un numero positivo di clienti da raggiungere; bisogna rileggere quali curve dominano nel dominio N non negativo.
Il pareggio continuo è circa 114583,33 richieste mensili. Per conteggi interi, con queste esatte ipotesi, il locale diventa meno costoso da 114584 richieste. Non significa che un' impresa con quella domanda debba comprare una macchina: manca ancora la verifica di fattibilità. Il conto serve a rendere esplicita la domanda da validare. A 100000 richieste abbiamo 620 contro 550 euro, a favore del cloud; a 200000 abbiamo 640 contro 1050, a favore del locale solo nel modello di costo. La tabella conserva anche volumi più alti per mostrare dove il conto può uscire dal suo dominio operativo.
| N/mese | Locale (€) | Cloud (€) | Locale €/rich. | Cloud €/rich. | N ≤ K (1/0) |
|---|---|---|---|---|---|
| 0 | 600.00 | 50.00 | — | — | 1 |
| 1000 | 600.20 | 55.00 | 0.600200 | 0.055000 | 1 |
| 10000 | 602.00 | 100.00 | 0.060200 | 0.010000 | 1 |
| 100000 | 620.00 | 550.00 | 0.006200 | 0.005500 | 1 |
| 200000 | 640.00 | 1050.00 | 0.003200 | 0.005250 | 1 |
| 1000000 | 800.00 | 5050.00 | 0.000800 | 0.005050 | 0 |
Nell’ultima colonna 1 significa soltanto che N non supera il limite nominale K; 0 segnala che lo supera. Non è un giudizio sulla qualità del modello o sul rispetto della latenza.
Una macchina economica può essere insufficiente
Aggiungiamo una capacità locale ipotetica di 0,5 richieste al secondo per 160 ore disponibili al mese. Non significa che un modello reale raggiunga quel ritmo su una scheda. Il prodotto fra tasso e durata dà soltanto un limite nominale: 288000 richieste. È una condizione necessaria per smaltire il mese nel tempo assunto, non una garanzia su code, memoria o scadenze. Un milione di richieste costa formalmente 800 euro nella retta locale, contro 5050 nel cloud; ma supera la capacità locale assunta. Quel valore non è un preventivo valido per servire un milione di richieste: bisogna ricalcolare un' architettura capace di farlo.
Anche 200000 richieste, inferiori al limite mensile, possono arrivare nel modo sbagliato. Se al mattino ne arrivano due al secondo mentre il servizio ne completa 0,5, durante quel tratto la coda cresce di 1,5 richieste al secondo. L' eventuale tempo libero serale non può far rispondere prima all' utente del mattino. La soluzione può essere dilazionare lavori non urgenti, aumentare capacità o usare un percorso misto; ciascuna cambia requisiti e costi. Non abbiamo simulato tale coda e non attribuiamo percentili di latenza. Il controesempio dimostra solo che la media mensile non basta a certificare il servizio.
Il lavoro storico MLPerf Inference Benchmark di Reddi e colleghi, preprint v1 del novembre 2019, distingue elaborazione offline e servizio con vincoli di latenza. È un riferimento metodologico, non una classifica attuale né un confronto locale/cloud sul nostro compito. Non abbiamo riprodotto i suoi test o risultati.
Quanto cambia la conclusione se sbagliamo una stima?
Il fisso locale è spesso una delle ipotesi più discusse: una macchina già presente sembra non costare nulla, mentre un sistema gestito con supporto può richiedere più lavoro del previsto. Tenendo invariati tutti gli altri parametri, con F_L = 300 euro il pareggio scende a circa 52083,33 richieste; con 1200 sale a 239583,33. Non stiamo stimando tre prodotti: isoliamo l' effetto di un parametro. Una sensibilità così grande consiglia di misurare e giustificare quel costo prima di dare una soglia precisa. Presentare molti decimali non rende affidabile un' ipotesi incerta.
Nel grafico a sinistra le curve sono conti, non offerte. Il tratto locale oltre 288000 richieste è prolungato tratteggiato perché supera il limite nominale del singolo servizio assunto: leggerlo come prezzo utilizzabile sarebbe scorretto. Il punto in cui i costi si uguagliano precede quel limite, ma non certifica latenza né qualità. A destra le tre barre mostrano lo spostamento della soglia al variare del fisso. Queste due viste rispondono a domande diverse: dove si incontrano le curve e quanto è fragile quella posizione rispetto alle ipotesi.
Dal costo per chiamata al costo per lavoro utilizzabile
Se solo una parte delle risposte è utilizzabile, il denominatore deve cambiare. Indicando con U il numero di lavori accettabili dopo una verifica indipendente, C/U misura il costo tecnologico per lavoro utilizzabile. Se aggiungiamo il tempo di revisione e riparazione, occorre sommare quel costo al numeratore. Non assumere che un punteggio del modello sia la probabilità di correttezza: U va osservato con criteri uguali per le due alternative. Non riportiamo un valore di U perché non abbiamo eseguito prove dei modelli. Questo limite è informazione necessaria per la scelta, non un dettaglio da riempire con numeri plausibili.
Anche i confini del servizio devono coincidere. Un prezzo di inferenza può escludere recupero dei documenti, archiviazione, trasferimenti, autenticazione e manutenzione della ricerca. Il locale può richiedere copia di sicurezza, monitoraggio, aggiornamenti e ripristino dopo un guasto. Il cloud può avere limiti di quota, impegni, trasferimenti o dipendenze contrattuali da leggere nelle condizioni effettive. Non attribuiamo queste voci a tutti i fornitori: indichiamo che cosa verificare nel preventivo specifico. Dati sensibili e accessi vanno valutati lungo l' intero percorso: «locale» non significa automaticamente protetto, e «cloud» non descrive da solo ogni flusso o politica.
Un confronto riproducibile prima della decisione
Per trasformare il conto in una valutazione reale, fissare un insieme autorizzato di compiti e un criterio di accettazione del risultato. Ripetere gli stessi casi sulle alternative, registrando versioni di modello e runtime, dimensioni del contesto, concorrenza e impostazioni. Misurare sia il tempo fino al primo risultato visibile sia quello fino al completamento utilizzabile, separando rete, attesa e calcolo quando possibile. Registrare mediana e percentili, errori, tentativi ripetuti e tempo di correzione. Sono istruzioni per una prova futura, non risultati di test effettuati qui. Il protocollo deve conservare anche i fallimenti e i casi fuori perimetro, non solo i successi rapidi.
Il profilo di domanda va provato oltre la media: richieste brevi e lunghe, picchi plausibili e periodi inattivi. Una macchina condivisa non deve essere valutata come risorsa esclusiva se altri processi ne usano la memoria. Se è necessaria disponibilità anche durante manutenzione, esplicitare ridondanza e capacità di riserva, ricalcolando F e v. Una via mista può trattare una parte dei casi localmente e il resto da remoto, ma non è gratis: occorre contare la scelta del percorso, le doppie integrazioni e i casi che falliscono su entrambi. Anche un flusso senza AI va incluso se risolve il problema con qualità e lavoro confrontabili.
Che cosa dimostra il codice, e quale scelta permette
Il programma usa Decimal per i parametri monetari, calcola sei volumi e ripete il pareggio con tre fissi locali. Nessun seed è necessario: non usa casualità. Le asserzioni verificano che a 100000 richieste il cloud sia meno costoso e a 200000 il locale lo sia nella retta assunta; verificano inoltre il limite nominale di 288000. La precisione aritmetica non riduce l' incertezza dei prezzi inventati. I risultati JSON e i grafici permettono di cambiare ipotesi e controllare i conti, non di attribuire prestazioni alla macchina della copertina. La figura è illustrativa e non rappresenta un' installazione EL-AI.
Possiamo ora rispondere senza uno slogan: il locale può compensare un fisso maggiore soltanto se il carico utile, la differenza dei variabili e la capacità lo permettono; il cloud può convenire a volumi bassi senza essere la soluzione migliore per ogni requisito. Nell' esempio il pareggio sta fra 100000 e 200000 richieste, ma un milione non è servibile dalla capacità locale ipotizzata e i picchi restano da verificare. La scelta concreta richiede costi reali, compiti equivalenti e test sulle alternative. Non abbiamo dimostrato un risparmio aziendale, un ritorno d' investimento o la superiorità di un prodotto: abbiamo costruito un conto che rende visibili le condizioni necessarie per decidere.
Fonti e materiali riproducibili
FinOps Foundation — Unit Economics; consulted 28 October 2026.
MLPerf Inference Benchmark — version-specific bibliographic record.
from decimal import Decimal as D
from pathlib import Path
import json,sys
# All costs and capacity are invented scenario inputs, not current vendor prices.
FL,FC=D('600'),D('50');VL,VC=D('.0002'),D('.005')
volumes=[0,1000,10000,100000,200000,1000000]
rows=[]
for n in volumes:
local=FL+VL*n;cloud=FC+VC*n
rows.append(dict(monthlyRequests=n,localEUR=str(local),cloudEUR=str(cloud),localEURPerRequest=str(local/n) if n else None,cloudEURPerRequest=str(cloud/n) if n else None))
break_even=(FL-FC)/(VC-VL)
assert FL+VL*100000>FC+VC*100000
assert FL+VL*200000<FC+VC*200000
assert FL+VL*114583>FC+VC*114583 and FL+VL*114584<FC+VC*114584
assert D('2')-D('.5')==D('1.5')
capacity=D('.5')*D('160')*3600
assert capacity==288000
sensitivity=[dict(localFixedEUR=str(f),breakEvenRequests=str((f-FC)/(VC-VL))) for f in [D('300'),D('600'),D('1200')]]
assert sensitivity[0]['breakEvenRequests'].startswith('52083.') and sensitivity[2]['breakEvenRequests'].startswith('239583.')
result=dict(sensitivity=sensitivity,python=sys.version.split()[0],seed=None,scope='Hypothetical equal-workload monthly cost arithmetic; no vendor quotation, hardware throughput, model quality or investment return measured',assumptions=dict(localFixedEUR=str(FL),cloudFixedEUR=str(FC),localVariableEURPerRequest=str(VL),cloudVariableEURPerRequest=str(VC),localAssumedRequestsPerSecond='.5',assumedHoursPerMonth='160'),breakEvenRequests=str(break_even),nominalMonthlyCapacityRequests=str(capacity),peakIncomingRequestsPerSecond='2',peakExceedsAssumedCapacity=True,rows=rows)
Path(__file__).with_name('results.json').write_text(json.dumps(result,indent=2),encoding='utf8')
print(json.dumps(result))
Codice, dati e istruzioni · JSON. Calcoli didattici eseguiti con Python 3.14.0; figure con Matplotlib 3.11.2. Analisi con assistenza AI, senza dichiarare peer review o revisione umana. Copertina originale ImageGen, illustrativa: non documenta persone, sedi o installazioni EL-AI. Fonti consultate il 28 ottobre 2026.