AI Inference Engineering: ottimizzare modelli in produzione con un partner

C’è un momento preciso in cui un progetto di intelligenza artificiale smette di essere un esperimento e diventa una voce di costo: quando il pilot va in produzione e la fattura del serving arriva ogni mese. È lì che molte aziende scoprono che il problema non era scegliere il modello giusto, ma farlo girare in modo sostenibile. L’AI inference engineering è la disciplina che si occupa esattamente di questo, e in azienda è la variabile che decide se un agente AI genera margine o lo brucia.

La definizione più asciutta la dà ByteByteGo: l’inference engineering è «la disciplina di eseguire modelli AI addestrati in produzione in modo efficiente», un lavoro che attraversa tutto lo stack, dal codice GPU fino all’autoscaling. Tre anni fa era competenza di poche centinaia di ingegneri chiusi dentro OpenAI e Anthropic. Oggi, con oltre due milioni di modelli aperti disponibili, è diventata una competenza che qualsiasi azienda con un agente in produzione deve avere internamente o comprare da un partner.

In questo articolo scoprirai:

• Perché l'inference decide il TCO, non l'addestramento
• Come funziona davvero l'inference: prefill, decode e le metriche che contano
• Quantizzazione: la leva con il miglior rapporto sforzo/risultato
• Batching continuo, prefix caching e KV cache: dove si nasconde lo spreco
• Speculative decoding e distillazione: far fare meno lavoro al modello
• Come scegliere fra GPU, CPU ed edge senza sbagliare il dimensionamento
• I pattern di costo che fanno esplodere la bolletta di un'azienda

Perché l’inference decide il TCO, non l’addestramento

L’addestramento è un costo una tantum. L’inference è un costo ricorrente che cresce linearmente con l’uso, mentre i ricavi quasi mai crescono con la stessa pendenza. Ogni singola risposta del vostro agente è una micro-transazione che paga GPU-secondi: se l’architettura di serving è inefficiente, quella micro-inefficienza si moltiplica per milioni di richieste.

I numeri lo rendono evidente. Inworld, analizzando il costo dell’inference a scala, riduce tutto a una formula sola: «il costo per token è la tariffa oraria divisa per il throughput realizzato». Sempre secondo Inworld, «le tariffe di listino pubbliche per una NVIDIA B200 andavano da 3,49 a 14,24 dollari per GPU-ora fra i diversi cloud ad aprile 2026»: un fattore 4x prima ancora di scrivere una riga di codice. Ma il denominatore pesa di più del numeratore. Nello stesso studio, «Gemma 4 26B A4B servito sullo stack di Inworld ha restituito un TTFT mediano di 241 ms a 113 token al secondo, mentre lo stesso modello su un host general-purpose ha restituito 445 ms a 17 token al secondo»: 6,6 volte di differenza sul throughput a parità di modello, interamente attribuibile all’engineering del serving layer.

Tradotto: due aziende che usano lo stesso modello open source sulla stessa GPU possono avere un costo unitario che differisce di quasi un ordine di grandezza. La differenza non è il modello. È chi lo fa girare. Questo è lo stesso principio per cui, in un progetto AI, il servizio conta più del modello.

Come funziona davvero l’inference: prefill, decode e le metriche che contano

Per decidere dove intervenire serve capire che una richiesta a un large language model non è un’operazione sola, ma due, con vincoli fisici opposti. La letteratura accademica ha sistematizzato il campo: la survey LLM Inference Serving di Li et al. (2024) raccoglie gli avanzamenti a livello di sistema che migliorano l’efficienza senza toccare i meccanismi di decodifica del modello, ed è esattamente il perimetro di cui parliamo qui.

Il prefill processa l’intero prompt in una volta ed è compute-bound: lo limita la potenza di calcolo pura. La sua metrica è il TTFT (Time To First Token), cioè quanto aspetta l’utente prima di vedere qualcosa. Il decode genera un token alla volta ed è memory-bandwidth-bound: lo limita la velocità con cui i dati viaggiano dalla memoria al processore. La sua metrica è il TPS (Token Per Second), la “velocità di battitura” percepita del modello. A queste si aggiunge l’ITL, la latenza fra un token e il successivo.

La conseguenza pratica è controintuitiva e vale la pena metterla in grassetto: nella fase di generazione il collo di bottiglia è la banda di memoria, non i FLOPs. Come sintetizza Runpod, «la banda della VRAM determina quasi interamente la latenza inter-token». Comprare una GPU più potente senza toccare il serving spesso non risolve niente: si paga di più per lo stesso identico throughput.

Il costo nascosto della KV cache

Durante il decode il modello conserva in memoria le chiavi e i valori dei token già processati: è la KV cache, e cresce linearmente con il batch e con la lunghezza del contesto. NVIDIA fornisce la formula esplicita: «dimensione totale della KV cache in byte = (batch_size) × (sequence_length) × 2 × (num_layers) × (hidden_size) × sizeof(FP16)». Per un Llama 2 da 7 miliardi di parametri con contesto 4096 e batch pari a 1, sono già circa 2 GB. Con batch 32 e contesti lunghi, la cache può occupare più memoria del modello stesso.

È la ragione per cui la lunghezza del contesto è una leva economica, non solo tecnica: secondo Mirantis «un contesto da 128K token può costare circa 64 volte più di uno da 8K». Attenzione a leggere bene quel moltiplicatore: sedici volte in più di contesto non fa sedici volte il costo, perché alla crescita lineare della KV cache si somma il costo del meccanismo di attenzione, che scala con il quadrato della lunghezza della sequenza. È la combinazione dei due termini a produrre il 64x. Chi progetta prompt e pipeline RAG senza sapere questo sta scrivendo assegni che qualcun altro dovrà coprire. Se state costruendo su recupero documentale, vale la pena rileggere come funziona il RAG con questa lente in testa.

Quantizzazione: la leva con il miglior rapporto sforzo/risultato

Quantizzare significa ridurre la precisione numerica dei pesi: da 16 bit a 8 o 4. Meno bit significa meno memoria da attraversare per token, e siccome il decode è memory-bound, la velocità sale quasi in proporzione.

Gli ordini di grandezza sono coerenti fra fonti indipendenti. ByteByteGo e The Pragmatic Engineer indicano un miglioramento di performance fra il 30% e il 50% mantenendo la qualità. Mirantis colloca i risparmi di costo «nel range 60, 70%». Runpod porta l’esempio più concreto: Llama-3-70B in BF16 richiede circa 140 GB di VRAM, quindi due H100 da 80 GB a 2,69 dollari l’ora; lo stesso modello in 4-bit AWQ gira su due RTX A6000 a 0,49 dollari l’ora, con oltre l’80% di risparmio e perdita di qualità minima.

Quando la quantizzazione fa male: il caso degli agenti

Qui serve onestà, perché è il punto dove più spesso si sbaglia. La quantizzazione non è gratis. Gli strati di attenzione restano tipicamente a precisione piena, perché gli errori si accumulano token dopo token. E soprattutto: uno studio presentato a ICML 2025 e citato da Redis ha osservato cali del 10-15% nel tasso di successo su task reali di tipo agentico con quantizzazione a 4 bit, anche quando le metriche classiche di perplexity degradavano molto meno.

È esattamente lo scenario di un agente aziendale che deve chiamare tool, produrre JSON valido e concatenare passi. Un modello quantizzato che “sembra” identico nei benchmark può fallire il 15% in più delle esecuzioni end-to-end. Per questo la quantizzazione va validata sul vostro workload, non sui benchmark pubblici, ed è una delle ragioni per cui il passaggio dal pilot alla produzione richiede una fase di misura dedicata.

Batching continuo, prefix caching e KV cache: dove si nasconde lo spreco

Se la quantizzazione agisce sul modello, il batching agisce sull’utilizzo. Ed è qui che si trovano i guadagni più grandi, perché è qui che si spreca di più: secondo Yotta Labs molti sistemi in produzione girano al 20-40% di utilizzo GPU per via di batching e scheduling mediocri. Pagate il 100% dell’hardware per usarne un terzo.

Il continuous batching (o in-flight batching) risolve il caso peggiore del batching statico: invece di aspettare che tutte le richieste del gruppo finiscano, «espelle immediatamente le sequenze completate dal batch» e inserisce nuove richieste mentre le altre proseguono. Mirantis quantifica l’effetto: «mettere in batch 32 richieste può ridurre il costo per token di circa l’85% con solo il 20% circa di latenza in più». È probabilmente il miglior scambio disponibile in tutto lo stack.

PagedAttention: la KV cache dell’inference senza frammentazione

La PagedAttention attacca invece la frammentazione della memoria applicando alla KV cache il paging dei sistemi operativi: la cache viene divisa in blocchi di dimensione fissa memorizzabili in modo non contiguo, il che permette batch molto più grandi. Ginger Labs riporta fino a 23 volte di miglioramento del throughput con vLLM e PagedAttention rispetto a un serving naive.

Prefix caching: l’inference che non ricalcola due volte

Infine il prefix caching: se mille richieste condividono lo stesso system prompt, non ha senso ricalcolarlo mille volte. Ginger Labs stima «una riduzione del 90% del costo sui token di input in cache», che su 100.000 richieste al giorno con prompt da 10K token significa migliaia di euro al giorno. Conseguenza pratica per chi scrive i prompt: mettete la parte fissa all’inizio e quella variabile alla fine. È una regola di prompt engineering che nasce da un vincolo di infrastruttura, non di linguaggio.

Speculative decoding e distillazione: far fare meno lavoro al modello

Le due tecniche restanti cambiano la quantità di calcolo necessaria, non la sua efficienza.

Speculative decoding: il modello piccolo propone, il grande approva

Lo speculative decoding usa un modello piccolo che propone 3-12 token candidati per passo; il modello grande li verifica tutti in un unico forward pass parallelo. Migliora il TPS lasciando invariato il TTFT, e Runpod indica un guadagno di 2-3x su carichi generation-intensive senza cambiare hardware, con tassi di accettazione del draft model idealmente fra il 70% e il 90% su compiti di dominio.

Distillazione: trasferire il comportamento, non i parametri

La distillazione è l’investimento più pesante e quello con il ritorno più duraturo: un modello “teacher” grande insegna a uno “student” piccolo a replicarne il comportamento, trasferendo non le risposte ma le distribuzioni di probabilità. DistilBERT resta il riferimento didattico, come ricorda la guida di Redis alla distillazione: 40% più piccolo, inferenza fino al 60% più veloce, con circa il 97% dell’accuratezza mantenuta sul benchmark GLUE.

Redis segnala anche un dettaglio che in azienda fa la differenza: l’ordine con cui si combinano le tecniche non è indifferente. La sequenza Pruning → Distillazione → Quantizzazione risulta la migliore fra quelle testate, mentre le sequenze che quantizzano prima di distillare vedono la perplexity peggiorare di un ordine di grandezza. Sbagliare l’ordine costa mesi.

Quando conviene distillare? Quando la qualità sul vostro dominio specifico conta più della genericità, quando avete volumi tali da ammortizzare il retraining, e quando dovete scendere su hardware che la sola quantizzazione non basta a raggiungere. Non conviene se il teacher non è già buono sul vostro task: non si trasferisce conoscenza che il teacher non ha.

GPU, CPU o edge: scegliere l’hardware per l’AI inference engineering in azienda

La scelta dell’hardware è l’ultima decisione, non la prima, ma è quella che vincola tutte le altre.

Sul cloud GPU, la soglia da conoscere è quella di convenienza: Mirantis indica che «il break-even del self-hosting richiede spesso almeno il 50% di utilizzo GPU per i modelli 7B». Sotto quella soglia, il self-hosting è una scelta ideologica, non economica. Con traffico irregolare conviene il serverless; con carico sostenuto e prevedibile, istanze dedicate. È lo stesso tipo di calcolo quantitativo che governa la scelta fra agenti AI custom e off-the-shelf.

Sul fronte CPU ed edge, il calcolo cambia natura. Gli small language model vincono dove il vincolo non è il costo ma la fisica: EE World Online osserva che l’inference in cloud aggiunge 200-500 millisecondi di latenza prima del primo token, il che squalifica il cloud per ispezione industriale in tempo reale, robotica e voce interattiva. Sono i domini in cui la latenza è il requisito e non un dettaglio: su una linea di produzione, mezzo secondo di ritardo significa un pezzo difettoso già passato oltre la stazione di controllo. I modelli far-edge stanno sotto gli 8 miliardi di parametri, idealmente attorno ai 4, e la quantizzazione da 16 a 4 bit riduce di un fattore quattro il traffico di memoria per token. Anche qui, il vincolo che comanda è la banda di memoria, non i TOPS.

I pattern di costo che fanno esplodere la bolletta di un’azienda

Ginger Labs apre il proprio studio con una frase che vale come diagnosi generale: «la vostra bolletta di inference è probabilmente 3-5 volte più alta del necessario». I pattern strutturali che la gonfiano sono ricorrenti e quasi sempre gli stessi.

Il primo è il model oversizing: instradare ogni richiesta al modello più grande, anche quando serve classificare un ticket. Un routing intelligente riduce l’uso del modello frontier del 37-46%, con un impatto complessivo che può arrivare a 14x. Il secondo è l’assenza di prompt caching, già vista. Il terzo è la KV cache non gestita. Il quarto è la precisione piena dove INT8 basterebbe. Il quinto è più sottile: i token di output sono prezzati tipicamente 3-5 volte più di quelli di input e quasi nessuno ottimizza in modo asimmetrico, pur essendo l’output la voce dominante.

Il fatto che il costo di inference sia una scelta architetturale e non un destino è la stessa ragione per cui, quando l’AI generativa non genera ROI, il problema non è la tecnologia. La tecnologia c’è. Manca chi la mette a punto.

Perché l’AI inference engineering è un servizio continuo, non un progetto

C’è un dato italiano che rende urgente tutto questo: secondo l’Osservatorio Innovazione Digitale nelle PMI del Politecnico di Milano, il 76% delle PMI italiane non ha investito né prevede investimenti in intelligenza artificiale, e solo il 7% ha avviato programmi strutturati di formazione sull’AI. Parliamo di oltre 240.000 imprese che generano più del 40% del fatturato nazionale. Il gap non è di software: è di competenze.

Le competenze di inference engineering che una PMI non assume

Le competenze richieste dall’inference engineering sono di quelle che una PMI non mette a libro paga: si opera «attraverso l’intero stack, da CUDA a Kubernetes». Nessuna azienda manifatturiera italiana da 80 persone assumerà un ingegnere che sa scrivere kernel CUDA e gestire autoscaling di GPU. Non ha senso economico e non ha senso organizzativo.

Il tuning continuo dell’inference in produzione

Il secondo punto è che questa non è un’ottimizzazione da fare una volta. I modelli cambiano, i motori di serving cambiano, il traffico cambia stagione, i prezzi GPU oscillano di 4x fra provider. Una configurazione ottimale a gennaio è mediocre a settembre. È lavoro di manutenzione post-deployment, con misura continua di TTFT, TPS, utilizzo GPU e costo per token.

È esattamente il punto in cui si colloca il lavoro di Mimír. Non consegniamo un modello e ce ne andiamo: seguiamo l’onboarding dell’agente in azienda, capire i workload reali, dimensionare il modello sul compito e non sull’ambizione, impostare caching e batching sui vostri pattern di traffico, e poi restiamo per il tuning continuativo, perché è lì che il costo per token continua a scendere mese dopo mese.

Il prodotto è l’agente; il servizio è ciò che lo tiene efficiente. Se volete capire in concreto cosa aspettarsi da questo tipo di rapporto, abbiamo raccolto i criteri per scegliere un partner AI in Italia.

Portare l’ottimizzazione dentro la vostra azienda

Il messaggio di fondo è semplice: il costo di un agente AI in produzione non è una proprietà del modello, è una proprietà di come lo fate girare. Sei volte di throughput a parità di hardware, l’85% di costo per token in meno con il batching giusto, l’80% risparmiato con la quantizzazione corretta: sono margini che nessuna trattativa commerciale con un vendor vi restituirà.

Se avete un agente AI in produzione che costa più del previsto, o un pilot che non riuscite a scalare perché i conti non tornano, in Mimír possiamo aiutarvi a capire dove si perde efficienza e a impostare un percorso di ottimizzazione continuo. Trovate come iniziare su mimir.bot.

Fonti:

• ByteByteGo — A Guide to AI Inference Engineering
• The Pragmatic Engineer — What is inference engineering?
• Inworld AI — LLM inference cost at scale
• Runpod — LLM inference optimization techniques: reduce latency and cost
• NVIDIA Developer — Mastering LLM techniques: inference optimization
• Mirantis — Inference costs
• Redis — Model distillation: a guide for LLMs
• Yotta Labs — How to optimize LLM inference for throughput and cost
• Ginger Labs — LLM inference costs in the enterprise
• EE World Online — Why small language models win at the edge
• Li, Jiang, Gadepally, Tiwari — LLM Inference Serving: Survey of Recent Advances and Opportunities (arXiv, 2024)
• Osservatori Politecnico di Milano — Innovazione digitale nelle PMI italiane