Quando si eseguono LLM in locale per flussi di lavoro agentici – tool calling, coding agent, RAG – l’attenzione si concentra quasi sempre sulla velocità di generazione dei token, il tg128. Ma un appassionato di LLM locali ha condotto un benchmark strutturato su 13 modelli, spingendosi fino a 131.000 token di contesto con una AMD RX 7900 XT 20GB, backend Vulkan e llama.cpp. Il responso: a contesti lunghi, il prefill domina in modo schiacciante e la metrica architetturale da guardare sono i KV head, non i parametri.

In uno scenario tipico, con 65K token in ingresso e una risposta di 300 token, il prefill assorbe tra il 94% e il 99% del tempo totale. Per i carichi agentici, dove gli output sono spesso stringhe brevi (istruzioni, chiamate a strumenti), la velocità di elaborazione del contesto diventa il vero collo di bottiglia, non la generazione.

La vera partita si gioca sui KV head, non sui parametri

L’analisi dei dati sfata un mito comune: a parità di classe, il numero di KV head dell’architettura influenza la scalabilità del prefill molto più del numero di parametri. Due modelli dense come Ornith-9B (4 KV head, 9 miliardi di parametri) e Apriel-15B (8 KV head, 15 miliardi di parametri) lo dimostrano: a 128K token di contesto il primo è 4,4 volte più veloce, pur avendo metà dei parametri. Ogni passaggio di attenzione deve scandire l’intera cache KV e con 8 head si spostano 2,5 volte più dati per token. La regola pratica: quando valuti un modello per contesti lunghi, controlla prima il valore di n_kv_heads e head_dim, non i miliardi di parametri.

Il paradosso della quantization: F16 a volte vince

Ridurre la cache KV tramite quantization (Q8_0 per le chiavi, Q4_0 per i valori) è considerata una best practice per risparmiare VRAM e velocizzare l’inference. Ma il benchmark rivela un fenomeno controintuitivo: a 65K token di contesto, per i modelli MoE e i dense compatti, mantenere la cache in F16 (nessuna quantization) è più veloce del 20-53% rispetto a Q8/Q4. Il motivo? La dequantization on-the-fly richiede risorse computazionali che, sommando migliaia di token, superano il vantaggio di banda risparmiato. Su GPU con throughput di calcolo elevato, il costo di dequantization diventa dominante. Nei modelli dense con 8 KV head, invece, F16 perde vistosamente perché la cache doppia forza lo spill di tutti i pesi sulla PCIe. Il consiglio: testate F16 sul vostro hardware al contesto di lavoro reale, non date per scontato che applicare la quantization sia sempre meglio.

Mamba2 e MLA: promesse e primi scricchiolii

L’unico modello ibrido Mamba2 testato, Granite-4.0-H-Small, mantiene il 69% della velocità di prefill a 131K contesto rispetto a 4K, mentre ogni trasformatore puro crolla sotto il 42%. Il merito è degli strati Mamba2 dotati di stato ricorrente fisso, che non accumulano cache KV. Peccato che la qualità di ragionamento sia ancora bassa e la generazione lenta (71 t/s). Se qualcuno addestrerà un buon modello su questa architettura, potrebbe diventare una seria contendente per i carichi agentici.

All’estremo opposto, il modello con attenzione MLA (GLM-4.7-Flash) perde l’80% di velocità passando da 512 a 16K contesto e crasha sopra i 65K su Vulkan. Il kernel di compressione/decompressione MLA scala male, almeno su backend Vulkan. Su CUDA o Metal potrebbe andare diversamente, ma il dato è chiaro: non estrapolate benchmark MLA a contesti brevi per l’uso a contesto lungo su Vulkan.

Cosa cambia per il self-hosting dei carichi agentici

Per chi progetta deployment on-premise, il benchmark riscrive le priorità. Invece di ossessionarsi sul tg128, occorre valutare i modelli sulla base del prefill a 65K o 131K token. L’architettura dei KV head diventa un criterio di selezione essenziale: un modello con 4 head e cache da 64 KB per token scala drammaticamente meglio di uno con 8 head e 160 KB per token, indipendentemente dal numero di parametri. Questo impatta direttamente la scelta dell’hardware: GPU con elevata larghezza di banda di memoria sono sempre utili, ma in presenza di carichi dominati dal prefill, il rapporto tra capacità di calcolo e banda può ribaltare l’efficacia delle ottimizzazioni di quantization. I modelli MoE, infine, sfruttano il meccanismo di spill sulla VRAM in modo più elegante: solo i parametri attivi attraversano il bus PCIe, contenendo la penalità e offrendo una combo di prefill veloce e intelligenza competitiva. In ottica di TCO, privilegiare modelli con queste caratteristiche può tradursi in una migliore efficienza dell’infrastruttura esistente, rinviando investimenti in hardware più costoso.

Il dataset completo e lo script sono disponibili nella fonte originale.