Le applicazioni basate su LLM diventano lente e costose più in fretta di quanto ci si aspetti: in un prototipo tutto sembra a posto, ma in produzione il traffico si accumula in coda, le conversazioni si allungano, le pipeline RAG aggiungono contesto a ogni prompt e gli agenti chiamano più tool. La tesi di questa guida KDnuggets è che la soluzione raramente sia un modello migliore o più GPU: quasi tutti i guadagni arrivano tagliando lavoro non necessario.
Misurare prima di ottimizzare
Il primo passo è capire dove va il tempo. La end-to-end latency non basta: vanno tracciati anche queue time, time to first token (TTFT), inter-token latency, conteggio di token in input e output, cache hit rate, latenza di tool e retrieval, e soprattutto i percentili P50, P95 e P99, perché la tail latency conta più della media. Un TTFT alto può indicare prompt lunghi, retrieval lento o coda; un inter-token latency lento suggerisce un modello sovradimensionato o batching mal configurato.
Meno token, meno chiamate, modello giusto
I token in output sono spesso la fonte più chiara di latenza e costo, perché vengono generati in sequenza: impostare max_tokens realistici, usare stop sequence, schemi JSON compatti e separare modalità “risposta breve” e “spiegazione dettagliata”. Molti carichi ripetitivi (sentiment, estrazione dati, moderazione, FAQ) possono girare su un modello più piccolo, con un pattern di routing che escala al modello più forte solo quando serve. Va inoltre ridotto il numero di chiamate LLM sequenziali: alcuni passi si combinano in un solo prompt, altri (formattazione date, validazioni, lookup su database) non richiedono affatto un LLM e conviene lasciarli a codice deterministico, eseguendo in parallelo i task indipendenti.
Caching e controllo del contesto
Il prefix caching è tra le leve più efficaci: mettere all’inizio del prompt i contenuti stabili (system instruction, policy, definizioni dei tool, few-shot) e in coda quelli che cambiano, così da trasformare un contesto ripetuto in un cache hit. A questo si aggiungono cache di risposta esatta, semantica, di retrieval e di tool result. Sul fronte RAG serve un context budget: recuperare meno documenti, fare reranking, deduplicare i chunk, evitare di mandare tutto “per sicurezza”. Vanno gestiti anche la KV cache e la lunghezza di contesto per non saturare la memoria GPU.
- Il batching va tarato sugli SLO utente (P95/P99 TTFT), non sulla sola utilizzazione GPU; per i modelli self-hosted è utile il continuous batching.
- Ottimizzazioni di serving come quantization, speculative decoding e parallelismo vanno validate sul traffico reale, perché non sono vittorie universali.
- Admission control e graceful degradation (rate limit, fallback a modello più piccolo, output ridotto sotto carico) evitano che uno spike renda l’intera esperienza inutilizzabile.
Fonte: 12 Ways to Reduce LLM Latency and Inference Costs in Production — https://www.kdnuggets.com/12-ways-to-reduce-llm-latency-and-inference-costs-in-production
Hai qualcosa da aggiungere? Unisciti alla discussione.