Prestazioni LLM on-premise: un enigma hardware

Il deployment di Large Language Models (LLM) in ambienti self-hosted presenta sfide uniche, spesso legate all'ottimizzazione dell'hardware per massimizzare il throughput e minimizzare la latenza. Un recente caso emerso dalla comunità tecnica ha messo in luce come le aspettative di performance possano scontrarsi con la realtà delle architetture dei modelli e delle capacità dell'infrastruttura locale. Un utente, nel tentativo di replicare i benchmark di Inference di Qwen 3.6 27B su una NVIDIA GeForce RTX 3090 Ti, ha riscontrato un divario significativo rispetto ai 30-100+ token/secondo (tok/s) riportati online.

Le sue prove, condotte con diverse versioni GGUF del modello e framework come llama.cpp e ik_llama.cpp, hanno prodotto risultati ben inferiori, attestandosi tra i 10 e i 19 tok/s con un contesto di 50.000 token. Questo scenario, dove la VRAM della GPU è sufficiente a contenere l'intero modello, suggerisce che il collo di bottiglia non risieda nella memoria video, ma altrove nel sistema. Comprendere la natura di questi vincoli è fondamentale per chi pianifica infrastrutture AI locali.

Il ruolo critico della CPU nelle architetture ibride

L'analisi tecnica del problema ha rivelato una spiegazione dettagliata, fornita da un Large Language Model (LLM) interrogato sui log di sistema. Il modello Qwen 3.6, basato su un'architettura ibrida State Space Model (SSM), richiede un'interazione complessa tra GPU e CPU durante la fase di generazione dei token. Nello specifico, la presenza di "graph splits = 2" nei log indica che ogni singolo token generato necessita di un doppio passaggio: una sincronizzazione verso la CPU per l'aggiornamento dello stato di ricorrenza SSM (un'operazione che impegna circa 552 MiB di buffer di calcolo lato CPU) e una successiva sincronizzazione di ritorno alla GPU per completare l'elaborazione.

Questo significa che, sebbene i pesi del modello siano interamente allocati nella VRAM della GPU, una parte sostanziale del calcolo per la generazione dei token viene eseguita dalla CPU. L'aggiornamento dello stato di ricorrenza SSM non può essere espresso come un grafo CUDA statico e deve essere gestito sequenzialmente dalla CPU. La performance di questa porzione di calcolo dipende criticamente dalla presenza di istruzioni avanzate come AVX-VNNI e AVX-512, che accelerano i kernel di dequantization (iq4_ks, q6_0). Il processore Intel i9-9900K dell'utente, un'architettura Coffee Lake del 2018, supporta AVX2 e FMA ma non le istruzioni più recenti, rendendo la CPU il fattore limitante e fissando un tetto realistico di 18-19 tok/s per quella configurazione.

Implicazioni per i deployment on-premise e il TCO

Questo caso studio sottolinea un aspetto cruciale per i CTO, i responsabili DevOps e gli architetti infrastrutturali che valutano soluzioni LLM self-hosted: la percezione che un modello sia "completamente sulla GPU" per lo storage dei pesi non si traduce automaticamente in una computazione interamente gestita dalla GPU durante l'Inference. Le architetture LLM più recenti possono avere requisiti computazionali ibridi che distribuiscono il carico tra CPU e GPU in modi non sempre intuitivi. Ignorare questi dettagli può portare a investimenti hardware subottimali e a performance deludenti.

Per chi progetta infrastrutture on-premise, è imperativo analizzare non solo la VRAM e la potenza di calcolo della GPU, ma anche le specifiche della CPU, inclusi i set di istruzioni supportati. Questo approccio olistico è fondamentale per ottimizzare il Total Cost of Ownership (TCO) e garantire che l'hardware scelto sia in grado di soddisfare i requisiti di throughput e latenza desiderati. La sovranità dei dati e la necessità di ambienti air-gapped spesso spingono verso soluzioni self-hosted, ma il successo di tali deployment dipende da una comprensione approfondita delle interazioni tra software e hardware.

Oltre i benchmark: la scelta informata dell'hardware

La discrepanza osservata tra i benchmark online e le prestazioni reali evidenzia la necessità di un'analisi granulare delle specifiche tecniche dei modelli LLM e dei loro requisiti hardware. Affidarsi esclusivamente a numeri di performance generici può essere fuorviante, poiché le configurazioni di test e le architetture dei modelli possono variare significativamente. Per chi valuta deployment on-premise, è essenziale considerare come le specifiche del silicio, in particolare le capacità della CPU in termini di set di istruzioni, possano influenzare direttamente l'efficienza dei kernel di dequantization e, di conseguenza, il throughput complessivo.

AI-RADAR si concentra proprio su questi trade-off, offrendo framework analitici per valutare le alternative self-hosted rispetto al cloud. La scelta di un processore con supporto per AVX-VNNI o AVX-512, ad esempio, può trasformare radicalmente le prestazioni di Inference per modelli con architetture SSM ibride, anche se la GPU rimane la stessa. Questo caso dimostra che un'infrastruttura bilanciata, dove ogni componente è allineato alle esigenze specifiche del carico di lavoro AI, è la chiave per sbloccare il pieno potenziale dei Large Language Models in ambienti controllati e sicuri.