L’inference, o inferenza, è il momento in cui un modello già addestrato riceve un input e produce un risultato. È ciò che accade quando un assistente risponde a una domanda, un classificatore riconosce un documento o un agente propone un’azione. Il modello non viene riaddestrato a ogni richiesta: applica i pesi già appresi.
Per scegliere un modello o dimensionare una soluzione locale, però, questa definizione non basta. Dire che un sistema genera “40 token al secondo” non spiega quanto aspetterà l’utente, quante richieste simultanee saranno gestite o quanta memoria servirà. Occorre misurare tempo al primo token, velocità di generazione, latenza complessiva, throughput, qualità e consumo di risorse nelle condizioni reali.
Indice
- Che cos’è l’inference
- Prefill e decoding
- Le metriche che contano
- Perché i token al secondo non bastano
- Come eseguire un test con Ollama
- Un metodo ripetibile per una PMI
- Come migliorare le prestazioni
- Errori comuni
- FAQ
Che cos’è l’inference
Durante il training il sistema modifica i pesi del modello usando dati ed esempi. Durante l’inferenza, invece, usa quei pesi per calcolare un nuovo output. Il risultato può essere un testo, un’immagine, una previsione, una classificazione o una chiamata a uno strumento.
In un’applicazione generativa il percorso tipico è questo:
- il testo viene convertito in token;
- il runtime carica o riutilizza il modello in memoria;
- il prompt viene elaborato;
- il modello genera un token alla volta;
- l’applicazione ricostruisce il testo, applica regole e mostra o utilizza il risultato.
Chatbot, sistemi RAG e agenti eseguono inferenza, ma aggiungono componenti diverse: ricerca documentale, strumenti, controlli, memoria applicativa e approvazioni. Una risposta lenta può quindi dipendere dal modello, ma anche dal database, dalla rete o da un servizio esterno.
Inferenza locale o cloud
Nel cloud si delegano capacità e gestione a un fornitore, pagando normalmente consumo o abbonamento. Nell’AI locale il modello viene eseguito su hardware controllato dall’organizzazione. Questo può migliorare controllo dei dati e prevedibilità, ma richiede dimensionamento, monitoraggio, aggiornamenti e backup.
La scelta non va ridotta a “privacy contro velocità”. Bisogna confrontare dati ammessi, continuità richiesta, carico reale, competenze operative, qualità del modello e costo complessivo.
Prefill e decoding: due fasi diverse
Per comprendere le prestazioni di un LLM è utile separare due momenti.
Prefill: leggere il prompt
Nel prefill il modello elabora i token in ingresso: istruzioni, cronologia, documenti recuperati e domanda. Un prompt molto lungo aumenta il lavoro prima che compaia la risposta. Anche una context window ampia può quindi far crescere attesa e memoria, senza garantire un risultato migliore.
Decoding: generare la risposta
Dopo il prefill inizia il decoding. Il modello produce progressivamente i token di output, usando anche la cache delle informazioni già calcolate. Qui l’utente percepisce la fluidità della risposta.
Le due fasi usano l’hardware in modo diverso. Per questo una singola cifra di velocità non descrive l’esperienza completa: un sistema può generare rapidamente dopo un’attesa iniziale lunga, oppure mostrare subito il primo token e poi procedere lentamente.
Le metriche che contano davvero
La documentazione di vLLM e NVIDIA distingue esplicitamente tempo al primo token, latenza tra token, latenza della richiesta e throughput. Sono metriche complementari, non alternative.
| Metrica | Che cosa misura | Perché serve |
|---|---|---|
| TTFT | Tempo dalla richiesta al primo token | Indica quanto il chatbot sembra reattivo |
| TPOT / inter-token latency | Tempo medio tra i token successivi | Descrive la fluidità della generazione |
| Token/s di output | Token generati in un secondo | Aiuta a confrontare il decoding a parità di test |
| Latenza end-to-end | Tempo fino alla risposta completa | Conta nei workflow che attendono tutto l’output |
| Throughput | Richieste o token gestiti nell’unità di tempo | Serve per capacità e utenti simultanei |
| p50, p95, p99 | Distribuzione dei tempi | Evidenzia i casi lenti nascosti dalla media |
| RAM e VRAM di picco | Memoria occupata durante il test | Indica stabilità e margine per più richieste |
| Qualità | Correttezza rispetto a un set di prova | Impedisce di ottimizzare una risposta sbagliata |
Un esempio semplice
Immaginiamo due configurazioni sullo stesso compito:
| Configurazione | TTFT | Output | Risposta completa |
|---|---|---|---|
| A | 0,8 s | 18 token/s | 7,5 s |
| B | 2,4 s | 30 token/s | 6,8 s |
La configurazione B completa prima la risposta, ma A sembra più pronta in una conversazione. Per un processo automatico che usa l’intero JSON può convenire B; per un assistente interattivo A potrebbe offrire un’esperienza migliore. Il requisito decide la metrica prioritaria.
Perché i token al secondo non bastano
Due benchmark sono confrontabili soltanto se mantengono costanti almeno modello, quantizzazione, runtime, hardware, lunghezza del prompt, numero di token generati e concorrenza.
I risultati cambiano in modo sensibile con:
- dimensione e architettura del modello;
- formato e livello di quantizzazione;
- CPU, GPU, banda della memoria e quantità di VRAM;
- porzione del modello trasferita sulla GPU;
- lunghezza del prompt e della risposta;
- numero di richieste simultanee e batching;
- cache calda o caricamento iniziale del modello;
- runtime, versione dei driver e impostazioni;
- chiamate RAG, tool e servizi di rete.
Anche la parola “token” non rappresenta una quantità fissa di testo. Lingua, punteggiatura e tokenizer modificano il rapporto tra token e parole. Confrontare token/s tra modelli dotati di tokenizer diversi dà un’indicazione tecnica, non una misura perfetta del testo utile prodotto.
Cold start e warm run
Il primo avvio può includere il caricamento del modello da disco. Le richieste successive lo trovano già in memoria. Conviene registrare separatamente cold start e warm run, perché rispondono a domande diverse: quanto impiega il servizio a partire e quanto è veloce durante l’uso normale.
Test pratico con Ollama
L’API di Ollama restituisce nel risultato finale i campi total_duration, load_duration, prompt_eval_count, prompt_eval_duration, eval_count ed eval_duration. Le durate sono espresse in nanosecondi e permettono di ricavare due velocità indicative.
curl http://localhost:11434/api/generate -d '{
"model": "nome-modello",
"prompt": "Spiega in 120 parole che cos’è un backup 3-2-1.",
"stream": false,
"options": {"temperature": 0, "num_predict": 180}
}'Dal JSON finale si possono calcolare:
token input al secondo = prompt_eval_count / (prompt_eval_duration / 1.000.000.000)
token output al secondo = eval_count / (eval_duration / 1.000.000.000)total_duration descrive il tempo complessivo visto dal runtime; load_duration aiuta a riconoscere il caricamento del modello. Questo test non misura perfettamente il TTFT perché usa una risposta non in streaming. Per valutare la reattività percepita occorre misurare il tempo tra l’invio della richiesta e la ricezione del primo evento in streaming.
Per iniziare da zero, la guida Come installare Ollama spiega installazione e controlli di base; Open WebUI con Ollama aggiunge un’interfaccia, ma il benchmark va eseguito anche direttamente sul runtime per distinguere modello e frontend.
Un metodo ripetibile per una PMI
Un benchmark utile non deve essere enorme. Deve assomigliare al lavoro reale ed essere ripetibile.
1. Definire tre scenari
Per esempio:
- riassumere una pagina interna;
- classificare una richiesta commerciale in JSON;
- rispondere usando tre documenti recuperati dal RAG.
Per ogni scenario si stabiliscono una lunghezza di input plausibile, un limite di output e criteri di correttezza. Un testo generico come “scrivi una poesia” misura poco per un’azienda che deve estrarre codici da ordini.
2. Bloccare la configurazione
Annotare modello e digest, quantizzazione, runtime e versione, hardware, memoria, dimensione del contesto e parametri di generazione. Se cambia una variabile, il confronto va identificato come un nuovo test.
3. Eseguire warm-up e più prove
Fare una richiesta di riscaldamento, poi almeno dieci misure per scenario. Registrare mediana e p95, non soltanto la migliore esecuzione. Per un servizio condiviso ripetere con una, cinque e dieci richieste concorrenti.
4. Misurare qualità e fallimenti
Una configurazione più veloce non vince se omette campi, inventa fonti o produce JSON non valido. La scheda dovrebbe includere accuratezza, richieste fallite, timeout, uso massimo di RAM/VRAM e consumo energetico quando rilevante.
5. Stabilire una soglia operativa
Esempio: TTFT sotto 2 secondi per il 95% delle chat, risposta completa sotto 12 secondi, JSON valido nel 99% dei casi e nessun superamento della memoria disponibile. Le soglie rendono la scelta verificabile.
Come migliorare le prestazioni
Prima di acquistare hardware, conviene individuare il collo di bottiglia.
Ridurre input inutile
Eliminare cronologie duplicate, documenti non pertinenti e istruzioni ridondanti riduce prefill e memoria. In un RAG è spesso meglio recuperare pochi passaggi rilevanti anziché inserire interi manuali.
Scegliere modello e quantizzazione adeguati
Un modello più piccolo o una quantizzazione equilibrata può offrire un risultato sufficiente con latenza inferiore. Va però verificato sul set aziendale: la riduzione di memoria non garantisce automaticamente maggiore qualità o velocità.
Usare la GPU dove crea valore
La GPU può accelerare l’inferenza, ma contano anche capacità e banda della VRAM. Se il modello non entra interamente in memoria e viene spostato spesso tra RAM e GPU, la prestazione può degradare. La checklist AI locale aiuta a ragionare sull’architettura complessiva.
Gestire concorrenza e batching
Il batching può aumentare il throughput aggregato, ma allungare l’attesa di una singola richiesta. In produzione bisogna trovare un equilibrio tra capacità e latenza, osservando coda, TTFT e p95 sotto carico.
Errori comuni
- Pubblicare il risultato migliore: va riportata la distribuzione, non il record.
- Confrontare prompt diversi: lunghezze differenti alterano prefill e latenza.
- Ignorare il cold start: un servizio usato raramente può pagarlo spesso.
- Testare un solo utente: una macchina veloce a concorrenza uno può saturarsi rapidamente.
- Misurare solo token/s: non descrive primo token, coda, qualità o risposta completa.
- Cambiare più variabili insieme: non consente di capire che cosa ha migliorato il risultato.
- Dimenticare rete e strumenti: il tempo end-to-end include l’intera catena applicativa.
FAQ
Più token al secondo significa sempre un chatbot migliore?
No. Per una chat contano soprattutto tempo al primo token, fluidità e qualità. Per un’elaborazione batch può essere più importante il throughput complessivo.
Quanti token al secondo sono sufficienti?
Non esiste una soglia universale. Dipende dalla lunghezza delle risposte, dal tipo di interazione e dal numero di utenti. Il requisito va espresso come tempo e qualità accettabili per il processo reale.
Perché la prima risposta è più lenta?
Il runtime può dover caricare il modello e inizializzare risorse. Prompt molto lunghi aumentano inoltre il prefill. Le metriche di caricamento di Ollama aiutano a distinguere i due fenomeni.
La quantizzazione rende sempre l’inferenza più veloce?
Riduce generalmente memoria e quantità di dati da muovere, ma il guadagno dipende da hardware, runtime e formato. Occorre misurare anche la qualità sul proprio compito.
Come confronto cloud e locale?
Usare gli stessi scenari, output massimi e criteri di qualità. Confrontare p50 e p95, errori, costo per risultato valido, gestione dei dati e capacità sotto carico, non soltanto la velocità nominale.
Conclusioni
L’inference è il punto in cui il modello diventa un servizio utilizzabile. Ottimizzarla significa bilanciare qualità, tempo al primo token, velocità di generazione, throughput, memoria, costi e affidabilità.
Il metodo più utile è semplice: scegliere compiti realistici, bloccare le variabili, ripetere le prove e valutare l’intera esperienza. Non serve il benchmark più alto: serve una configurazione che rispetti una soglia operativa verificabile.
Per approfondire i concetti collegati consulta anche modelli open weights, quantizzazione e context window.
Vuoi ricevere guide pratiche su AI locale, integrazioni e governance? Iscriviti gratuitamente alla newsletter di BASI DI AI.
