Il costo vero dell’IA è l’inferenza: la guerra si gioca su memoria e latenza, non sui FLOPS

Un paper di Xiaoyu Ma e David Patterson (Google) sostiene che, nell’era degli LLM, la fase “Decode” è il vero collo di bottiglia: sequenziale, affamata di memoria e sensibile alla latenza di rete. Per le imprese cambia la checklist: procurement e governance devono misurare time‑to‑first‑token, capacità di memoria, energia e responsabilità su dati e rischio, non solo “potenza di calcolo”.

di Andrea Viliotti

Hardware per inferenza LLM

Nel dibattito aziendale sull’AI generativa, “più calcolo” è diventato sinonimo di “più valore”. Ma quando un assistente digitale entra in un processo – un operatore che cerca una procedura, un consulente che riassume un contratto, un medico che consulta una linea guida – l’azienda non compra un benchmark: compra inferenza con SLA. E l’inferenza, oggi, ha un tallone d’Achille diverso dal training.

È la tesi di “Challenges and Research Directions for Large Language Model Inference Hardware” (Ma, Patterson): l’LLM non è un carico uniforme. La parte che determina costi e percezione – il Decode autoregressivo, token dopo token – è vincolata da memoria e interconnessione più che dal picco di FLOPS. Se è così, il vantaggio competitivo non sta solo nel modello, ma nell’architettura che lo serve.

In numeri

• ~40% → <4%: quota di paper “industry” nelle conferenze di architettura (1976 vs ISCA 2025).

• +80X vs +17X: in un decennio le GPU aumentano i FLOPS molto più della banda di memoria (esempio NVIDIA 2012‑2022).

• Divergenza di costi: HBM con costi normalizzati in crescita (+1,35x 2023‑2025), DDR in calo (0,54x capacità e 0,45x banda 2022‑2025).

• Stessa banda, capacità diversa: in Tabella 3 un “HBF stack” è indicato a 512 GB e 1638 GB/s contro un “HBM4 stack” a 48 GB e 1638 GB/s.

Due fasi, due economie: Prefill e Decode

Gli autori separano due fasi. Nel Prefill il modello elabora l’input in parallelo (come nel training): spesso è più vicino a un problema compute‑bound. Nel Decode, invece, la generazione è sequenziale: ogni passo produce un token e dipende dal precedente. Qui entra la KV cache (Key‑Value cache), che collega le due fasi e cresce con la lunghezza totale di input+output. Risultato: anche con molta aritmetica disponibile, la pipeline può restare “a secco” se la memoria non alimenta abbastanza in fretta i dati necessari a ogni token.

Questa distinzione guida anche le architetture moderne: Prefill e Decode non sono necessariamente co‑localizzati e possono girare su server diversi (disaggregated inference). Il software può alleviare parte del problema (batching, scheduling), ma non cambia la fisica: il Decode resta un carico memory‑bound.

Il muro della memoria: perché l’hardware “da training” fatica nel Decode

Finora l’hardware per inferenza è stato spesso una derivazione di quello per training. Il paper sostiene che i trend si stanno disallineando: la capacità di calcolo cresce più rapidamente della capacità di alimentarla. Nei data center domina l’accoppiata “grande ASIC + HBM (High Bandwidth Memory)”: ottima per throughput, meno adatta quando l’inferenza è fatta di accessi frequenti e poco riusabili.

Qui entra la dimensione industriale. Il paper mostra che i costi normalizzati di HBM (per capacità e banda) possono crescere, mentre la DRAM standard (DDR) segue dinamiche diverse: è un segnale che, in scala, la memoria può diventare il vincolo di business prima del calcolo. E il tentativo di “chiudere tutto in SRAM” non è una scorciatoia: architetture nate per ridurre dipendenza da DRAM/HBM – citate Cerebras e Groq – hanno dovuto reintrodurre memoria esterna perché la dimensione dei modelli supera la SRAM integrabile a costi e consumi ragionevoli.

Per CIO/CTO e CFO il takeaway è pratico: il costo dell’AI in produzione non è lineare con il numero di query; dipende da quanta memoria serve per pesi, contesto e cache, e da quanto quella memoria è disponibile e prevedibile nel TCO.

Latenza end‑to‑end: time‑to‑first‑token e rete

L’inferenza “user‑facing” vive di latenza. Il paper distingue due metriche operative: time‑to‑completion (tutti i token) e soprattutto time‑to‑first‑token (il primo token visibile), che determina la qualità percepita. Input lunghi e RAG aumentano il lavoro prima di iniziare a rispondere; output lunghi allungano la generazione; in entrambi i casi pesa l’accesso alla KV cache.

Quando l’inferenza diventa multi‑chip, arriva la rete. Con batch piccoli e messaggi spesso ridotti, la latenza di interconnessione può contare più della banda: la rete “da training” (ottimizzata per throughput) non è automaticamente la rete “da inferenza”. Per l’impresa questo implica un cambio di capitolato: non solo “token/s”, ma variabilità della latenza sotto carico e comportamento in degradazione.

Quattro direzioni di ricerca (e quattro domande nuove al procurement)

Gli autori non vendono una soluzione pronta: indicano quattro direzioni architetturali che, se maturassero, cambierebbero i trade‑off.

1. High Bandwidth Flash (HBF): impilare flash “in stile HBM” per ottenere banda elevata con capacità molto maggiore. Obiettivo: più memoria per nodo per ridurre dimensione del sistema, overhead di rete, potenza e TCO. Vincoli chiave: endurance di scrittura e letture a pagine con latenza superiore (quindi gerarchie dove flash ospita pesi “congelati” o contesto lento‑variabile, mentre la DRAM resta per dati dinamici).

2. Processing‑Near‑Memory (PNM) vs Processing‑in‑Memory (PIM): il paper propone una distinzione netta. PIM porta logica nel die di memoria e promette banda per watt, ma introduce coupling memoria‑logica e richiede sharding su banchi piccoli; PNM tiene logica e memoria su die separati ma vicini, con più libertà di processo e partizionamento.

3. 3D memory‑logic stacking: usare TSV e packaging 3D per un’interfaccia memoria più larga e densa, puntando a più banda per watt. Ma con nuove sfide: termica, standard d’interfaccia, mapping software su rapporti diversi tra banda/capacità/FLOPS.

4. Interconnessioni a bassa latenza e processing‑in‑network: topologie con meno hop (tree, dragonfly, tori ad alta dimensione) e accelerazione “in rete” di collettive utili agli LLM (broadcast, all‑reduce, dispatch/collect per MoE) per migliorare latenza e throughput.

Tradotto in linguaggio aziendale: procurement non deve chiedere “quale GPU”, ma “quale gerarchia di memoria”, “quale rete”, “quale degrado controllato”, “quale profilo energetico”, e con quali assunzioni su contesto, RAG e variabilità dei prompt.

Che cosa cambia per le imprese

Nei prossimi 30 giorni (decisioni “reversibili”)

• Misura separata Prefill/Decode: strumentare time‑to‑first‑token e time‑to‑completion; monitorare pressione di memoria (KV cache) e segnali “memory‑bound” (utilizzo basso di calcolo con latenza alta).

• Classifica i casi d’uso per latenza: interattivo (SLA stretti) vs batch/offline; definire cosa è “degrado accettabile” (risposta più lenta, risposta sintetica, fallback).

• Capitolato “inference‑ready”: chiedere ai fornitori evidenza su variabilità della latenza sotto carico, gerarchia di memoria, requisiti di rete, profilo di potenza e modalità di osservabilità (log, metriche, audit).

• Governance minima: mappare data‑flow di prompt, RAG e output; chiarire ownership (IT, AI team, business, compliance).

  
  

Nei prossimi 90 giorni (industrializzazione)

• SLO di inferenza: formalizzare obiettivi di latenza/affidabilità per servizio, includendo “coda” e variabilità; testare su workload realistici (prompt lunghi, RAG, picchi).

• Architettura e routing: separare percorsi “lunghi” e “brevi” (contesto esteso vs standard); valutare disaggregated inference; governare cache e contesti “lento‑variabili”.

• FinOps/GreenOps: collegare consumo (TCO/potenza/CO2e) a unità di servizio; inserire capacity planning (energia/spazio) nel piano AI.

• Compliance operativa: integrare EU AI Act e GDPR come vincoli di accountability; usare ISO/IEC 42001 e NIST AI RMF come lessico di ruoli, risk register, controlli e monitoraggio.

  
  

KPI/trigger qualitativi (senza soglie inventate)

• Aumento persistente del time‑to‑first‑token in condizioni di picco; crescita della variabilità di latenza (coda).

• “Utilizzo alto di memoria / basso di calcolo” con degradazione di SLA.

• Errori o ritardi nel recupero RAG; mismatch tra contesto atteso e contesto usato.

• Lacune di logging/audit, o impossibilità di ricostruire input‑contesto‑output a posteriori.

  
  

Settori: stesso vincolo, casi d’uso diversi

Manifattura: la latenza decide l’adozione sul campo. Separare Prefill e Decode suggerisce architetture ibride (edge/on‑prem + cloud) dove la generazione finale è ottimizzata per memoria locale e tempi certi.

Finanza: i casi d’uso (antifrode, assistenza al consulente, analisi documentale) uniscono latenza e controllo. Se l’inferenza usa RAG su basi dati proprietarie, cache e logging diventano parte della governance.

Retail/consumer: picchi e stagionalità rendono decisive batching, disaggregated inference e contratti di performance. La metrica che conta è la stabilità del time‑to‑first‑token sotto carico.

PA e sanità: documenti lunghi e dati sensibili stressano memoria e tracciabilità. Se la tecnologia regge, va governata; se non regge, resta prototipo.

Compliance: governance che parla anche “hardware”

Il paper invita a ottimizzare su metriche moderne: TCO, potenza media, CO2e (operativa e incorporata) e vincoli di capacità del data center. Per le imprese è un ponte verso la governance: EU AI Act, GDPR, ISO/IEC 42001 e NIST AI RMF spingono a chiarire ruoli, controlli e ciclo di vita. Ma quelle responsabilità dipendono anche da scelte tecniche: dove gira Prefill/Decode, quali dati entrano in RAG, cosa finisce in cache, quali evidenze di monitoraggio e audit sono disponibili.

Cosa monitorare (segnali precoci)

• Memoria: roadmap HBM e alternative (gerarchie ibride, flash per contesto/pesi); maturità di packaging 3D.

• Rete: topologie low‑latency e funzioni “in‑network” utili alle collettive degli LLM.

• Software‑hardware co‑design: disaggregated inference, batching e tecniche per ridurre pressione della KV cache.

• Governance: linee guida applicative e prassi di audit; adozione di ISO/IEC 42001 e operazionalizzazione di NIST AI RMF.

  
  

L’AI come infrastruttura

La conclusione degli autori è una provocazione utile: l’attuale filosofia hardware – grandi die ad alto FLOPS, molte HBM, interconnessioni ottimizzate per banda – è una cattiva approssimazione del Decode. Per le imprese significa una cosa: chi vuole scalare l’AI deve trattarla come infrastruttura, non come feature. Misurare, progettare, governare. E mettere memoria, rete ed energia al centro della strategia.