Compute Economist: Chi È e Perché la Potenza di Calcolo sta Ridefinendo l’Economia dell’AI
This post has already been read 10 times!
Chi è il Compute Economist: il professionista che trasforma il calcolo in una variabile economica
Per anni abbiamo trattato la potenza di calcolo come l’energia elettrica in ufficio: una riserva di fondo, fastidiosa da saldare a fine mese ma sostanzialmente prevedibile.
Serviva più capacità? Un click sulla dashboard cloud, una firma al budget IT e la macchina continuava a girare.
L’arrivo dei modelli generativi ha distrutto questa tranquillità.
Oggi una catena di agenti AI lasciata a briglia sciolta o un’architettura ottimizzata male possono prosciugare i margini di un prodotto SaaS in un singolo pomeriggio.
Non siamo più davanti a un banale problema di server, ma a un rompicapo finanziario: la domanda vera non è più quante GPU possiamo affittare, ma quanto margine generiamo per ogni singolo watt e per ogni token prodotto.
È proprio in questo cortocircuito tra hardware, algoritmi e conto economico che si sta facendo strada una figura chiave: il Compute Economist.
Il compute è diventato una risorsa economica (e un rischio letale)
La trasformazione in atto è profonda e non ammette errori.
Nel software tradizionale, il costo marginale di servire un utente aggiuntivo è quasi sempre trascurabile. Aggiungere mille clienti a un’app classica significa sostanzialmente puro margine. In un prodotto AI, invece, il paradigma si ribalta del tutto: ogni singola richiesta genera un consumo computazionale fisico, misurabile e costoso.
Un modello non sta semplicemente “nel server”. Deve essere addestrato, aggiornato ed eseguito in produzione, affrontando workload di reasoning sempre più densi e prolungati. Questo significa che le vecchie metriche, come il numero di utenti attivi (MAU), non bastano più per capire se l’azienda è in salute.
Occorre mappare la catena del valore in ogni suo anello:
costo per richiesta → costo per token → costo per task → costo per cliente → margine per cliente.
Il problema esplode definitivamente quando il prodotto utilizza agenti AI autonomi. Un singolo input dell’utente può infatti scatenare a cascata decine di chiamate a modelli pesanti, ricerche in database e sistemi di verifica.
L’impatto economico diventa quindi immediato e spietato: un prodotto AI con unit economics sbilanciate non è una startup scalabile, è un’emorragia finanziaria a ritmo di gigaflop. Il costo non dipende più da quanti clienti hai, ma dalla mole imprevedibile di lavoro computazionale che ciascuno di essi decide di generare.
Il Compute Economist nasce dall’incrocio di quattro discipline (e ne supera i limiti)
Il Compute Economist non appartiene completamente a una singola disciplina. Il vero problema delle aziende odierne, infatti, è affrontare i costi dell’AI mantenendo un approccio a compartimenti stagni di fronte a una tecnologia che, al contrario, brucia risorse in modo trasversale.
La sua competenza si trova all’intersezione di quattro macro-aree:
- Economia: Quanto vale realmente il compute prodotto?
- AI/ML: Quanto compute richiede un modello per generare un output utile?
- Infrastructure Engineering: Come viene prodotto, schedulato ed erogato questo compute?
- Finance & Strategy: Dove conviene allocare il capitale per massimizzare il ROI?
La caratteristica distintiva di questa nuova figura non è semplicemente “sapere un po’ di tutto”, ma la capacità di superare le miopie dei ruoli manageriali e tecnici tradizionali.
Il confronto è netto:
- Il CFO guarda le fatture passate: vede un centro di costo cloud esploso a fine mese e preme per tagliarlo alla cieca, rischiando di soffocare le performance del prodotto.
- L’Infrastructure Engineer guarda la saturazione della memoria e l’hardware: punta alla massima efficienza tecnica e a evitare colli di bottiglia, indipendentemente dal ritorno economico reale di quello sforzo di ottimizzazione.
- Il Data Scientist guarda i benchmark e la qualità dei token: insegue l’accuratezza assoluta del modello, spesso ignorando che un misero +2% di precisione potrebbe richiedere una potenza di calcolo tale da azzerare i margini operativi.
Il Compute Economist, al contrario, guarda alla sostenibilità del modello di business futuro.
Prende questi tre vettori isolati e li unisce. Se un ingegnere sa che una GPU è satura al 45%, il CFO sa quanto è costata e il data scientist sa quanti token sta generando, il Compute Economist è l’unico in grado di trasformare queste informazioni in un’azione strategica:
Conviene aumentare la capacità del cluster, quantizzare il modello per renderlo più leggero, cambiare l’infrastruttura hardware, ribaltare il pricing per gli utenti finali o ridurre le funzionalità del prodotto?
La metrica fondamentale: costo per unità di intelligenza
Nel cloud siamo abituati a metriche come:
- [math] euro / \text{CPU-hour}[/math];
- [math] euro / \text{GB}[/math];
- [math] euro / \text{GPU-hour}[/math].
Per l’AI queste metriche possono essere insufficienti.
L’azienda non compra GPU per il gusto di possederle. Compra GPU per ottenere output utile.
Per questo il Compute Economist ragiona su metriche più vicine al valore prodotto:
- [math] euro / \text{milione di token}[/math]
- [math] euro / \text{task completato}[/math]
- [math] euro / \text{inferenza utile}[/math]
- [math] euro / \text{ora di reasoning}[/math]
- [math] euro / \text{unità di accuratezza}[/math]
- [math] euro / \text{azione corretta dell’agente}[/math]
Il principio è simile a quello della produttività economica:
non interessa soltanto quanto input consumiamo, ma quanto output otteniamo da quell’input.
Una GPU utilizzata all’80% e una utilizzata al 30% non hanno la stessa economia, anche se hanno lo stesso prezzo nominale.
NVIDIA, per esempio, sottolinea esplicitamente il ruolo dell’utilization nell’economia dei cluster di inference: a parità di infrastruttura, raddoppiare l’utilizzo dal 40% all’80% dimezza il costo effettivo per token prodotto.
Questo è esattamente il tipo di problema che interessa a un Compute Economist.
Il problema dell’utilization
Immaginiamo di avere un cluster da 1.000 GPU.
Il costo dell’infrastruttura esiste anche quando le GPU non stanno producendo output utile.
Se il cluster viene utilizzato al 30%, una parte significativa del capitale investito rimane improduttiva.
Possiamo rappresentare una versione semplificata del problema così:
[math]\displaystyle
\text{Costo effettivo per unità di compute} = \frac{\text{costo totale}}{\text{compute utile prodotto}}
[/math]
Quindi aumentare l’utilization può essere economicamente equivalente ad acquistare nuova capacità senza comprare nuove GPU.
È un punto fondamentale.
Un aumento dell’efficienza dal 50% al 75% non è semplicemente un miglioramento tecnico del 25%. Può significare:
- maggiore capacità produttiva;
- minore costo unitario;
- maggiore margine;
- minore capitale necessario;
- maggiore capacità di servire domanda futura.
Alcune analisi recenti arrivano a formalizzare proprio questo rapporto tra capacità installata, utilization, utilizzo effettivo dei FLOPS e efficienza algoritmica.
Training e inference hanno economie diverse
Uno degli errori più comuni è trattare tutto il compute AI come se fosse uguale.
Non lo è.
Training
Il training è generalmente:
- intensivo;
- concentrato;
- capital intensive;
- altamente parallelizzabile;
- relativamente prevedibile.
L’azienda può spendere enormi quantità di compute per addestrare un modello e poi ammortizzare quel costo su milioni di utenti.
Inference
L’inference è diversa. È:
- ricorrente;
- legata alla domanda;
- sensibile alla latenza;
- dipendente dal comportamento degli utenti;
- direttamente collegata al costo di servizio.
Per un prodotto AI in forte crescita, l’inference può diventare una componente fondamentale dei costi operativi.
E qui nasce una domanda strategica:
Qual è il modello più intelligente dal punto di vista economico?
Non necessariamente quello con la maggiore accuratezza. Potrebbe essere quello che raggiunge una determinata accuratezza con un costo inferiore.
Il Pareto frontier del compute
Immaginiamo due modelli.
Modello A
- accuratezza: 92%
- costo: 1 € ogni 1.000 richieste
Modello B
- accuratezza: 94%
- costo: 4 € ogni 1.000 richieste
Quale scegliere?
Non esiste una risposta puramente tecnica. Dipende dal valore economico di quel 2% aggiuntivo di accuratezza.
Se quel miglioramento aumenta drasticamente la conversione o riduce gli errori costosi, il modello B può essere conveniente. Se invece l’incremento non produce valore economico sufficiente, il modello A è superiore.
Il Compute Economist lavora quindi su una frontiera simile a quella di molti problemi di ottimizzazione:
performance ↔ costo ↔ latenza ↔ qualità ↔ consumo energetico.
La soluzione ottimale non è necessariamente il punto di massima performance. È il punto in cui il valore marginale dell’ulteriore compute giustifica il suo costo marginale.
Compute e pricing: il cortocircuito del modello SaaS
Proprio per questi motivi, il Compute Economist diventa una figura vitale nelle aziende che vendono prodotti basati sull’AI.
Prendiamo un caso reale. Supponiamo che il tuo abbonamento SaaS costi: 49 €/mese e che il cliente medio generi: 30 € di costi computazionali per far girare il modello.
Il margine lordo è già strutturalmente schiacciato rispetto a un SaaS tradizionale (dove l’infrastruttura per utente pesa pochi centesimi).
Ma cosa succede se il cliente si appassiona a una nuova funzionalità con agenti AI e porta il suo consumo mensile a 70 €?
Nel software classico, un power user del genere è un caso di successo, una metrica da sfoggiare con gli investitori. Nell’AI, un utente super-attivo ma a tariffa fissa (flat) è un buco nero nel bilancio. Non è più “fedele”, è diventato economicamente insostenibile. Moltiplicare questa dinamica per migliaia di utenti significa scalare rapidamente verso la bancarotta.
Questo modifica radicalmente l’architettura dei prezzi.
Il Compute Economist interviene per progettare veri e propri “sistemi di difesa” finanziaria:
- pricing basato sull’utilizzo (pay-as-you-go) al posto del flat;
- crediti computazionali (a esaurimento);
- tier di abbonamento agganciati ai consumi reali;
- limiti rigidi (throttling) per le richieste di reasoning troppo lunghe;
- routing dinamico dei modelli (usare il modello più piccolo ed economico per i task facili, e quello premium solo quando strettamente necessario).
Il prezzo di un prodotto AI, in definitiva, non può più basarsi solo sul “valore percepito” dal mercato o sulle tariffe dei competitor. Deve essere un’equazione matematica ferrea, blindata per garantire che la struttura dei costi computazionali non divori l’impresa dall’interno.
Make or buy: cloud, GPU proprie o infrastruttura ibrida?
Un’altra decisione tipica è:
Conviene acquistare GPU o utilizzare il cloud?
La risposta non può essere semplicemente “il cloud costa di più” oppure “comprare conviene nel lungo periodo”.
Occorre modellare:
- CAPEX;
- ammortamento;
- costo dell’energia;
- cooling;
- networking;
- personale;
- utilization;
- durata utile dell’hardware;
- costo del capitale;
- rischio di obsolescenza;
- domanda futura;
- elasticità del workload.
Il Compute Economist costruisce quindi scenari.
Per esempio:
- Scenario A — Cloud: Costo variabile elevato, CAPEX basso.
- Scenario B — On-premise: CAPEX elevato, costo marginale potenzialmente più basso.
- Scenario C — Hybrid: Capacità proprietaria per il carico base e cloud per i picchi.
La soluzione ottimale dipende dalla distribuzione temporale della domanda.
Caso di Studio: 1 Milione di Inferenze nel Customer Care
Un’azienda e-commerce deve gestire 1.000.000 di richieste di customer care al mese attraverso un sistema AI.
Il team deve scegliere quale architettura utilizzare.
Consideriamo due modelli:
- Modello A — Small / Distillato
- costo per inferenza: [math]c_A = 0{,}0015\ €[/math]
- tasso di risoluzione autonoma: [math]S_A = 85\%[/math]
- Modello B — Frontier / Reasoning
- costo per inferenza: [math]c_B = 0{,}0080\ €[/math]
- tasso di risoluzione autonoma: [math]S_B = 94\%[/math]
Il Modello B costa quindi più di cinque volte il Modello A per inferenza, ma riduce significativamente il numero di richieste che devono essere trasferite a un operatore umano.
Assumiamo inoltre che il costo medio di una gestione umana sia:
[math]c_h = 5{,}00\ €[/math]
per ticket.
La trappola della valutazione superficiale
A questo punto emergono due possibili letture.
Un approccio esclusivamente tecnico potrebbe dire:
«Il Modello B è migliore: risolve il 94% delle richieste invece dell’85%.»
Un approccio esclusivamente orientato al costo computazionale potrebbe invece osservare:
«Il Modello B costa più di cinque volte per inferenza. Scegliamo A.»
Entrambe le valutazioni sono incomplete.
Il problema economico corretto è:
[math]\boxed{TCO = \text{Costo Compute} + \text{Costo Escalation Umana}}[/math]
Non dobbiamo quindi chiederci soltanto quanto costa eseguire il modello, ma quanto costa complessivamente il processo che il modello deve automatizzare.
Il vero TCO dell’inference
Indichiamo con:
- [math]N[/math] = numero di richieste;
- [math]c_m[/math] = costo per inferenza del modello;
- [math]S[/math] = tasso di risoluzione autonoma;
- [math]c_h[/math] = costo di escalation umana.
Il costo complessivo è:
[math]\displaystyle
TCO = N \cdot c_m + N(1 – S)c_h
[/math]
Il primo termine rappresenta il costo computazionale.
Il secondo rappresenta il costo delle richieste che l’AI non riesce a risolvere autonomamente.
Questa distinzione è fondamentale: un modello più costoso può risultare economicamente migliore se riduce abbastanza il costo degli errori o delle escalation.
Opzione A — Il modello più economico
Il costo computazionale è:
[math]\displaystyle
\text{Costo Compute}_A = 1.000.000 \cdot 0{,}0015 = 1.500\ €
[/math]
Il modello risolve autonomamente l’85% delle richieste.
Il 15% viene quindi trasferito a un operatore:
[math]\displaystyle
1.000.000(1 – 0{,}85) = 150.000
[/math]
Il costo delle escalation è:
[math]\displaystyle
\text{Costo Escalation}_A = 150.000 \cdot 5 = 750.000\ €
[/math]
Il TCO mensile è quindi:
[math]\boxed{TCO_A = 1.500 + 750.000 = 751.500\ €}[/math]
Il modello è estremamente economico dal punto di vista computazionale, ma il costo dell’errore domina completamente il conto economico.
Opzione B — Il modello più costoso
Il costo computazionale diventa:
[math]\displaystyle
\text{Costo Compute}_B = 1.000.000 \cdot 0{,}0080 = 8.000\ €
[/math]
Il Modello B risolve il 94% delle richieste.
Solo il 6% richiede escalation:
[math]\displaystyle
1.000.000(1 – 0{,}94) = 60.000
[/math]
Il costo dell’intervento umano è:
[math]\displaystyle
\text{Costo Escalation}_B = 60.000 \cdot 5 = 300.000\ €
[/math]
Pertanto:
[math]\boxed{TCO_B = 8.000 + 300.000 = 308.000\ €}[/math]
Il risultato è sorprendente.
Il Modello B richiede 6.500 € di compute aggiuntivo rispetto al Modello A, ma riduce il costo delle escalation di:
[math]750.000 – 300.000 = 450.000\ €[/math]
Il risparmio netto è quindi:
[math]450.000 – 6.500 = \boxed{443.500\ € / \text{mese}}[/math]
In questo scenario, il modello più costoso è nettamente superiore dal punto di vista economico.
E se utilizzassimo il Model Routing?
Il confronto non deve necessariamente essere binario.
Possiamo introdurre una terza architettura: model routing.
L’idea è semplice:
- l’80% delle richieste viene elaborato dal Modello A;
- il 20% viene elaborato dal Modello B.
Per il momento assumiamo una versione volutamente semplice del routing, nella quale il tasso di risoluzione medio viene calcolato come media ponderata delle performance dei due modelli.
Questa ipotesi è importante: non stiamo ancora modellando un router intelligente che conosce la difficoltà delle richieste.
Costo computazionale
Il costo medio per richiesta è:
[math]\displaystyle
c_{Hybrid} = 0{,}8(0{,}0015) + 0{,}2(0{,}0080)
[/math]
[math]\displaystyle
c_{Hybrid} = 0{,}0012 + 0{,}0016 = 0{,}0028\ €
[/math]
Su 1 milione di richieste:
[math]\displaystyle
\text{Costo Compute}_{Hybrid} = 1.000.000 \cdot 0{,}0028 = \boxed{2.800\ €}
[/math]
Il risparmio di compute rispetto al Modello B è:
[math]1 – \frac{2.800}{8.000} = 65\%[/math]
Ma attenzione: questo è un risparmio sul solo costo computazionale, non sul TCO.
Ed è proprio qui che il problema diventa interessante.
La risoluzione dell’architettura 80/20
Se assumiamo che le richieste siano assegnate ai due modelli senza introdurre un effetto di selezione legato alla difficoltà, la risoluzione media è:
[math]\displaystyle
S_{Hybrid} = 0{,}8(0{,}85) + 0{,}2(0{,}94)
[/math]
[math]\displaystyle
S_{Hybrid} = 0{,}68 + 0{,}188 = \boxed{0{,}868}
[/math]
quindi:
[math]\boxed{S_{Hybrid} = 86{,}8\%}[/math]
Non 93%.
Questo significa che il 13,2% delle richieste richiede escalation:
[math]1.000.000(1 – 0{,}868) = 132.000[/math]
Il costo umano diventa:
[math]\displaystyle
\text{Costo Escalation}_{Hybrid} = 132.000 \cdot 5 = \boxed{660.000\ €}
[/math]
Il TCO complessivo è quindi:
[math]\displaystyle
TCO_{Hybrid} = 2.800 + 660.000
[/math]
[math]\boxed{TCO_{Hybrid} = 662.800\ €}[/math]
Il confronto completo
| Architettura | Compute | Risoluzione autonoma | Escalation | TCO mensile |
|---|---|---|---|---|
| Modello A | 1.500 € | 85,0% | 750.000 € | 751.500 € |
| Modello B | 8.000 € | 94,0% | 300.000 € | 308.000 € |
| Hybrid 80/20 | 2.800 € | 86,8% | 660.000 € | 662.800 € |
Il risultato è molto diverso da quello che potremmo aspettarci osservando soltanto la fattura cloud.
L’architettura Hybrid:
- riduce il compute del 65% rispetto a B;
- riduce il TCO dell’11,8% rispetto ad A;
- ma ha un TCO 115,2% superiore a B.
Quindi il Modello B rimane la soluzione economicamente migliore nelle ipotesi considerate.
Il risultato più importante: compute ≠ TCO
Questo è il vero insegnamento del caso.
Se guardassimo soltanto al compute, sceglieremmo facilmente l’architettura Hybrid:
[math]2.800\ € < 8.000\ €[/math]
Ma il costo computazionale rappresenta soltanto una parte del problema.
Il Modello B utilizza più compute, ma riduce drasticamente il numero di escalation.
Il risultato è:
[math]\boxed{TCO_B < TCO_{Hybrid} < TCO_A}[/math]
In altre parole:
l’architettura che minimizza il compute non è necessariamente quella che minimizza il costo totale del business.
È esattamente questo il tipo di errore che il Compute Economist deve evitare.
Quanto deve essere bravo il routing per battere il Modello B?
A questo punto possiamo porci una domanda ancora più interessante.
Il routing 80/20 ha un TCO di 662.800 €.
Ma qual è il tasso di risoluzione che dovrebbe raggiungere per diventare economicamente migliore del Modello B?
Il costo computazionale rimane:
[math]2.800\ €[/math]
Vogliamo:
[math]2.800 + 1.000.000(1 – S)5 < 308.000[/math]
Da cui:
[math]1.000.000(1 – S)5 < 305.200[/math]
[math]1 – S < 0{,}06104[/math]
e quindi:
[math]\boxed{S > 93{,}904\%}[/math]
Il routing dovrebbe quindi raggiungere una risoluzione di circa 93,9% per battere economicamente il Modello B.
Questa soglia è molto interessante.
Il routing non deve semplicemente essere “economico”.
Deve essere sufficientemente intelligente da conservare quasi tutta la capacità di risoluzione del modello costoso, sfruttando contemporaneamente il modello economico per le richieste appropriate.
Il vero valore del routing dipende dalla sua qualità
L’80/20 utilizzato sopra è una semplificazione.
In un sistema reale, infatti, non avrebbe molto senso assegnare casualmente l’80% delle richieste al modello economico e il 20% al modello costoso.
Il router dovrebbe cercare di identificare caratteristiche come:
- difficoltà della richiesta;
- complessità del ragionamento necessario;
- dominio;
- rischio di errore;
- confidenza del modello;
- lunghezza del contesto;
- valore economico della richiesta.
L’obiettivo potrebbe essere:
[math]\boxed{\text{Modello A per i task semplici} \quad \rightarrow \quad \text{Modello B per i task complessi}}[/math]
In questo caso la semplice media ponderata:
[math]0{,}8S_A + 0{,}2S_B[/math]
non descriverebbe più necessariamente la performance reale del sistema, perché le richieste inviate a B sarebbero selezionate proprio in funzione della loro difficoltà.
Per conoscere la performance di un router reale servirebbero quindi dati sperimentali o una funzione di routing esplicitamente modellata.
Questo porta a una conclusione ancora più importante:
Il valore economico del model routing dipende non solo dalla percentuale di richieste assegnate a ciascun modello, ma dalla qualità con cui il router decide quale modello utilizzare.
Una nuova domanda da Compute Economist
A questo punto la domanda non è più:
Qual è il modello più economico?
e nemmeno:
Qual è il modello più accurato?
La domanda diventa:
Quale architettura minimizza il costo complessivo del servizio mantenendo il livello di qualità richiesto dal business?
Questa formulazione cambia completamente il problema.
Possiamo infatti immaginare una funzione obiettivo:
[math]\min TCO[/math]
soggetta a vincoli come:
[math]S \geq S_{min}[/math]
[math]\text{Latency} \leq L_{max}[/math]
[math]\text{Quality} \geq Q_{min}[/math]
e magari:
[math]\text{Energy} \leq E_{max}[/math]
Il problema diventa quindi una vera questione di ottimizzazione multi-obiettivo.
Morale
Il caso di studio mostra perché il Compute Economist non può limitarsi a monitorare il costo per token o il costo per GPU-hour.
Un modello può essere:
- più economico;
- più veloce;
- più efficiente dal punto di vista energetico;
e tuttavia produrre un TCO peggiore.
Allo stesso modo, un modello molto più costoso può risultare economicamente conveniente se riduce abbastanza gli errori, le escalation o altri costi downstream.
La vera unità di analisi non è quindi:
[math]\boxed{\text{costo del modello}}[/math]
ma:
[math]\boxed{\text{costo complessivo del processo che il modello automatizza}}[/math]
Ed è proprio qui che il compute smette di essere una semplice voce infrastrutturale e diventa una variabile economica strategica.
Il compute sta diventando un asset finanziario
Il fenomeno è ormai abbastanza importante da attirare anche la finanza.
Nell’agosto 2026 NVIDIA ha annunciato una collaborazione con importanti istituzioni finanziarie per creare piattaforme di finanziamento dell’infrastruttura AI con l’obiettivo di mobilitare oltre 500 miliardi di dollari di capitale.
E la trasformazione non riguarda soltanto il finanziamento.
Sono comparsi studi accademici che iniziano a trattare il compute come una vera attività economica e finanziaria, studiandone prezzi, contratti e rischio.
È un passaggio importante.
Quando una risorsa diventa:
scarsa + costosa + strategica + finanziabile + negoziabile
inizia ad assumere caratteristiche proprie di un asset economico.
Il Compute Economist si trova esattamente nel punto di intersezione tra queste dinamiche.
Energia: il lato fisico dell’economia del compute
Non esiste compute senza elettricità.
E non esiste un data center AI senza:
- energia;
- raffreddamento;
- connessioni di rete;
- trasformatori;
- infrastruttura fisica.
Questo significa che l’economia dell’AI sta progressivamente diventando anche economia dell’energia.
Un workload può essere economicamente conveniente in una regione e non esserlo in un’altra.
La localizzazione del compute può quindi dipendere da:
costo dell’elettricità + disponibilità della rete + costo del data center + latenza + fiscalità + affidabilità energetica.
In altre parole, il Compute Economist deve iniziare a ragionare anche come un esperto di location economics.
Quali competenze servono?
Non esiste ancora un percorso universitario standard chiamato “Compute Economics”.
È più realistico costruire il profilo attraverso competenze complementari.
Economia e finanza
Servono conoscenze di:
- microeconomia;
- teoria dei costi;
- economia industriale;
- capital budgeting;
- ROI;
- unit economics;
- pricing;
- teoria degli incentivi.
Data science
Sono utili:
- Python;
- SQL;
- statistica;
- forecasting;
- Monte Carlo simulation;
- optimization;
- causal inference.
AI
È necessario capire almeno:
- training;
- inference;
- fine-tuning;
- quantizzazione;
- batching;
- latency;
- throughput;
- GPU utilization;
- token economics.
Infrastructure
Non è necessario essere GPU engineer, ma bisogna comprendere:
- GPU/accelerator;
- memory bandwidth;
- networking;
- storage;
- cloud infrastructure;
- Kubernetes;
- cluster scheduling;
- observability.
Business
Infine bisogna comprendere:
- pricing;
- product economics;
- gross margin;
- CAC;
- LTV;
- forecasting;
- strategic planning.
Il vero valore del profilo sta nella capacità di collegare queste competenze.
Come potrebbe essere una giornata di lavoro?
Un Compute Economist potrebbe iniziare la giornata analizzando una dashboard.
Le metriche principali:
- GPU utilization;
- cost per token;
- cost per request;
- inference latency;
- revenue per request;
- gross margin;
- compute capacity;
- demand forecast.
Poi potrebbe lavorare con il team ML.
La domanda potrebbe essere:
Possiamo ridurre il costo del modello del 35% senza perdere più dello 0,5% di accuratezza?
Nel pomeriggio potrebbe lavorare con Finance:
Se la domanda cresce del 300%, conviene acquistare capacità o utilizzare cloud?
E con Product:
Dobbiamo includere il reasoning avanzato nel piano standard oppure trasformarlo in una funzionalità premium?
Infine potrebbe lavorare con Infrastructure:
Qual è il livello di utilization necessario per rendere economicamente conveniente questo cluster?
Non è quindi un ruolo puramente quantitativo. È una funzione cross-functional.
Il Compute Economist è già una professione?
Qui bisogna essere precisi.
Il termine non identifica ancora una professione consolidata con un’unica job description standard. È più corretto considerarlo un profilo emergente.
Esistono però già ruoli vicini che mostrano la direzione del mercato.
Per esempio, nel 2026 Anthropic ricerca economisti che combinano teoria economica, econometria, machine learning, forecasting e analisi dell’impatto dell’AI su produttività e lavoro.
Parallelamente, aziende e operatori dell’infrastruttura AI stanno sviluppando metriche sempre più sofisticate per misurare il costo del compute, l’utilization e il costo per token.
La conclusione è interessante:
il nome del mestiere potrebbe cambiare, ma il problema economico esiste già.
Potremmo incontrare titoli come:
- AI Economics;
- Compute Strategy;
- AI Infrastructure Economics;
- AI FinOps;
- AI Cost Optimization;
- AI Infrastructure Finance;
- Compute Strategy & Planning;
- AI Economics Research.
Il Compute Economist può essere visto come il concetto ombrello che unisce queste competenze.
Domande da colloquio per un Compute Economist
Se questa professione diventerà rilevante, il colloquio difficilmente sarà una semplice verifica di conoscenze economiche.
Il candidato dovrà dimostrare di saper trasformare problemi tecnici in decisioni economiche.
Ecco alcune domande plausibili.
Domanda 1 — GPU utilization
Hai un cluster da 1.000 GPU con utilization media del 40%. Il business vuole aumentare la capacità del 50%. Compreresti altre GPU?
La risposta migliore non è immediata. Bisogna prima chiedere:
- perché l’utilization è solo del 40%?
- esiste domanda non soddisfatta?
- il collo di bottiglia è la GPU?
- oppure networking, memoria, storage o scheduling?
- qual è la distribuzione temporale della domanda?
- quanto costa aumentare l’utilization?
Insight: prima di aumentare la capacità bisogna verificare se il problema è realmente la capacità.
Domanda 2 — Modello più costoso
Un modello costa il doppio ma aumenta l’accuratezza dal 90% al 93%. Quando lo utilizzeresti?
La risposta deve introdurre il concetto di marginal value.
Il 3% aggiuntivo non ha un valore universale. Bisogna stimare:
valore economico dell’incremento di accuratezza > costo computazionale aggiuntivo?
Se sì, il modello più costoso può essere razionale.
Domanda 3 — Cloud vs GPU proprietarie
Il cloud costa 2 €/GPU-hour. Una GPU acquistata costa 30.000 €. Quando conviene comprarla?
Non basta fare:
[math]30.000 / 2 = 15.000 \text{ ore}.[/math]
Bisogna considerare:
- utilizzo effettivo;
- energia;
- cooling;
- manutenzione;
- ammortamento;
- costo del capitale;
- obsolescenza;
- rischio;
- costi operativi.
Questa è una classica domanda di TCO e capital budgeting.
Domanda 4 — Pricing
Un cliente paga 100 €/mese ma genera 140 € di costi di inference. Cosa fai?
La risposta più superficiale sarebbe: aumento il prezzo.
Quella più sofisticata è:
- segmentare il comportamento;
- identificare il workload responsabile del costo;
- verificare il valore prodotto;
- valutare un tiering;
- introdurre usage-based pricing;
- ottimizzare il routing dei modelli;
- valutare un modello più economico;
- soltanto dopo modificare il prezzo.
Il problema non è semplicemente il prezzo. È l’unit economics.
Domanda 5 — Forecasting
La domanda di inference cresce del 20% al mese. Come dimensioneresti la capacità per i prossimi 12 mesi?
Qui il candidato dovrebbe costruire scenari.
Non basta estrapolare:
[math]\text{Demand}(t) = \text{Demand}(0) \times 1{,}2^t[/math]
perché la crescita potrebbe rallentare.
Una soluzione seria dovrebbe includere:
- baseline;
- scenario conservativo;
- scenario centrale;
- scenario aggressivo;
- confidence interval;
- capacità disponibile;
- lead time dell’hardware;
- utilization target.
Il Compute Economist deve ragionare in termini di capacity planning sotto incertezza.
Domanda 6 — Il trabocchetto
Qual è il modello AI migliore?
La risposta corretta è:
Dipende dall’obiettivo economico e dai vincoli del workload.
Un modello non è “migliore” in assoluto. Può essere:
- più accurato;
- più veloce;
- più economico;
- più efficiente energeticamente;
- più facile da deployare;
- più adatto a determinati workload.
La funzione del Compute Economist è trasformare queste dimensioni in una decisione economica.
Un piccolo caso pratico da colloquio
Supponiamo di avere:
1 milione di richieste al giorno.
Il modello A costa: 0,002 € per richiesta.
Il modello B costa: 0,006 € per richiesta.
Il modello B converte il 4% in più di utenti.
Il costo giornaliero è:
[math]A = 1.000.000 \times 0{,}002 = 2.000 \text{ €}[/math]
[math]B = 1.000.000 \times 0{,}006 = 6.000 \text{ €}[/math]
Il modello B costa quindi 4.000 € in più al giorno.
La domanda non è: “Quale modello è migliore?”
La domanda è:
Quanto valore economico genera quel 4% aggiuntivo di conversione?
Se genera 10.000 € al giorno, il modello B è economicamente superiore. Se genera 1.000 €, è probabilmente un pessimo investimento.
Questa trasformazione da performance tecnica → valore economico è il cuore del mestiere.
Perché è una carriera “esponenziale”
La categoria Carriere Esponenziali non riguarda soltanto professioni che stanno crescendo rapidamente.
Riguarda professioni che nascono quando una nuova tecnologia modifica le variabili fondamentali con cui le aziende prendono decisioni.
L’AI sta facendo esattamente questo.
Prima il problema era: Quanto software possiamo vendere?
Ora diventa: Quanto software AI possiamo vendere mantenendo un margine sostenibile?
E questa domanda conduce inevitabilmente al compute.
Più aumentano:
- modelli di reasoning;
- agenti autonomi;
- multimodalità;
- video generation;
- simulazioni;
- digital twins;
- AI scientifica;
più aumenta la quantità di calcolo necessaria.
Ma contemporaneamente migliorano:
- hardware;
- algoritmi;
- quantizzazione;
- batching;
- scheduling;
- caching;
- distillation;
- modelli specializzati.
Il risultato sarà una continua corsa tra domanda di compute ed efficienza del compute.
Ed è proprio questa dinamica a creare spazio per nuove competenze.
La competenza distintiva: pensare in “compute per valore”
Il vero salto concettuale consiste nel cambiare unità di misura.
Un engineer può pensare: FLOPS.
Un cloud architect: GPU-hours.
Un CFO: euro.
Un product manager: utenti.
Il Compute Economist deve collegare tutto:
quanto valore economico producono questi FLOPS, utilizzati per queste GPU-hours, al costo di questi euro, per questo segmento di utenti?
Questa è una nuova forma di alfabetizzazione economica.
E potrebbe diventare una competenza strategica per le aziende AI.
Quando il calcolo diventa economia
Il Compute Economist nasce da una semplice trasformazione.
Quando il compute era relativamente abbondante e poco differenziato, poteva essere trattato come infrastruttura.
Quando diventa:
scarso + costoso + strategico + energivoro + finanziariamente rilevante + direttamente collegato ai margini
diventa una variabile economica di primo livello.
Il professionista che sa collegare infrastruttura, AI, economia, finanza e strategia acquista quindi un valore particolare.
Non deve necessariamente progettare una GPU. Non deve necessariamente addestrare un LLM. Non deve necessariamente essere un economista accademico.
Deve saper rispondere a una domanda molto più difficile:
Qual è il modo economicamente ottimale di trasformare capacità computazionale in valore?
Questa domanda accompagnerà probabilmente la prossima fase dell’economia digitale.
E potrebbe trasformare il compute da semplice voce dell’IT budget in una delle principali variabili strategiche dell’impresa.
Il futuro non sarà soltanto di chi avrà più intelligenza artificiale. Potrebbe essere di chi saprà ottenere più intelligenza da ogni euro di compute.
📚Economia dell’AI, Costi dei Modelli e Nuova Geopolitica Tecnologica
L’intelligenza artificiale non è soltanto una questione di modelli e prestazioni: dietro la corsa all’AI ci sono costi, infrastrutture, energia, chip, competizione internazionale e sostenibilità economica. Questi approfondimenti analizzano il passaggio dall’entusiasmo iniziale alla ricerca di efficienza, il cambiamento nei budget aziendali e la trasformazione dell’ecosistema tecnologico che sostiene l’AI generativa.
👉L’inverno dei token: perché nel 2026 le aziende stanno tagliando i budget dell’AI generativa
👉La festa è finita: perché il conto dell’intelligenza artificiale è arrivato e nessuno vuole pagarlo
👉La fine della tassa premium sull’AI: perché il mercato sceglie i modelli cinesi open-weight
TUMIX di Google: L'IA non scala più, si organizza. Ecco il futuro multi-agente.
La teoria del raffreddamento sociale e delle Echo Platforms
Comunicazione Efficace: Unire il Principio di Grice ai 3 Filtri di Gandhi per Relazioni Migliori
Dalla camera da letto al mondo: la storia (quasi segreta) di AlexNet che ha cambiato l’IA per sempre
L'IA che si divora: perché il boom di Nvidia e OpenAI rischia il collasso (Analisi 2025-2030)
ChatGPT è un Bauscia Digitale? Perché l'IA ci convince (anche quando inventa)
GDPval: L'IA Smette di Giocare e Inizia a Lavorare. Cosa Significa per la Tua Professione?
