Immaginate di costruire un agente basato su LLM per automatizzare processi aziendali. Dovreste puntare sul modello più grande e veloce nel generare token, magari con un fine-tuning accurato e un sistema prompt costruito a mano? L'esperienza di un utente che ha messo a confronto due modelli su hardware on-premise suggerisce il contrario: per i task agentici, un modello più piccolo e meno ottimizzato può surclassare uno più grande, se completare il lavoro richiede meno chiamate a tool.
Il test, descritto in un post su Reddit, ha contrapposto un Qwen3.6-27B quantizzato in INT8 (W8A16) servito con vLLM Tensor Parallelism su due schede Ampere (decodifica a 37.7 token/s – fino a 72 con speculative decoding), e un Nemotron Puzzle-75B-A9B in NVFP4 distribuito su tre schede con vLLM pipeline parallel, capace di 65 token/s. Entrambi operavano in contesti ampi (131K token), con cache KV in fp8 e senza ottimizzazioni di sistema spinta.
Il 27B, lasciato senza alcun tuning e con un prompt di sistema neutro, ha completato tutti i compiti agentici in 6-9 chiamate a tool, impiegando tra i 134 e i 190 secondi per task. Il 75B, invece, senza una profilatura manuale era un lancio di moneta, e anche dopo la messa a punto ha richiesto 13-23 chiamate, con tempi tra i 221 e i 384 secondi. In pratica, il modello che spreca meno turni vince, anche a metà della velocità di decodifica.
Il resoconto svela però un altro ostacolo per chi esegue benchmark di agenti in locale: la cache dei prefissi. A causa di un byte identico inviato nelle richieste, il parser XML si bloccava su un output malformato, producendo sei fallimenti consecutivi. Solo dopo la rotazione della cache (o l'aggiunta di un nonce nel system prompt) il test è diventato riproducibile. Un dettaglio che chiunque valuti le prestazioni di agenti su stack self-hosted deve considerare: le ottimizzazioni di serving come il prefix caching possono rendere i tentativi successivi tutt'altro che indipendenti, distorcendo le metriche di affidabilità.
Al di là dell'aneddoto, l'episodio segnala uno spostamento strutturale nel modo di pensare le infrastrutture on-premise per LLM. Mentre la corsa ai modelli sempre più grandi tende a saturare la VRAM e a imporre strategie di distribuzione su più GPU (con pipeline parallelism, tensor parallelism e quantizzazioni aggressive in NVFP4 o INT8), per carichi di lavoro agentici – dove il modello deve concatenare più passaggi di reasoning e azioni – la latenza end-to-end non è dominata dalla velocità di generazione dei singoli token, ma dalla capacità di produrre una risposta utile in poche iterazioni.
Ciò ribalta le priorità di provisioning hardware. Non serve più solo la scheda più veloce in inference batch: contano anche la stabilità dell'architettura di serving, la prevedibilità dei tempi di risposta (che il prefix caching, se mal gestito, può minare) e la possibilità di eseguire modelli di dimensione intermedia su poche GPU, riducendo i costi operativi. Il Qwen3.6-27B in INT8, ad esempio, girava su due sole schede, mentre il 75B richiedeva tre GPU con pipeline parallel: un risparmio di risorse non trascurabile per team con budget hardware limitato.
Ancora più interessante: la quantization INT8 su architettura Ampere (fp8 KV, vLLM con speculative decoding) non ha penalizzato la qualità dell'agente, anzi ha permesso di raggiungere velocità di pre-fill elevate (764 token/s a 76k token) che, sommate al minor numero di turni, hanno prodotto wall-time nettamente inferiori. Si apre così uno spazio per modelli più addestrati all'efficienza logica che alla dimensione, e per stack software che privilegino la riproducibilità e la bassa latenza di sistema, non la pura velocità di decodifica.
Chi progetta pipeline agentiche su hardware locale farà bene a considerare che il parametro chiave non è più il benchmark di token/s su prompt singoli, ma il time-to-completion reale su task complessi, inclusi i costi di chiamata a tool e le variabili di cache. E che l'ottimizzazione non deve sacrificare la riproducibilità dei test – altrimenti si rischia di rincorrere fantasmi.
💬 Commenti (0)
🔒 Accedi o registrati per commentare gli articoli.
Nessun commento ancora. Sii il primo a commentare!