L'insidia delle corsie PCIe: un errore di configurazione dimezza le performance di un rig LLM on-premise

La costruzione di infrastrutture locali per l'Inference di Large Language Models (LLM) presenta sfide complesse, dove ogni dettaglio hardware può avere un impatto significativo sulle performance. Un recente caso studio evidenzia come una configurazione apparentemente minore possa dimezzare la capacità di un sistema multi-GPU, trasformando un "mostro di VRAM" in una configurazione sottoperformante. L'esperienza di un utente che ha assemblato un rig con quattro NVIDIA RTX 3090 ha rivelato l'importanza cruciale della corretta allocazione delle corsie PCIe, un aspetto spesso trascurato nelle build self-hosted.

L'installazione, basata su una scheda madre Gigabyte X399 Designare EX con un processore Threadripper 1950X e 128GB di DDR4, era stata concepita per gestire carichi di lavoro LLM intensivi. Nonostante tutte e quattro le GPU fossero rilevate e la VRAM disponibile, le performance in scenari multi-GPU erano inspiegabilmente deludenti. Ad esempio, l'Inference del modello Mistral Medium 3.5 128B Q4_K GGUF tramite llama.cpp raggiungeva a malapena 11 token/secondo, con un utilizzo delle GPU che si attestava intorno al 30%. Inizialmente, si era ipotizzato un problema legato al backend, al modello o alla strategia di split, come le configurazioni NCCL.

Dettaglio tecnico: la trappola delle corsie PCIe e la soluzione

La causa del collo di bottiglia si è rivelata essere una singola GPU RTX 3090 posizionata in uno slot fisico x16 che, a livello elettrico, operava come PCIe 2.0 x4. La situazione era ulteriormente aggravata dal fatto che, prima di ottimizzare le impostazioni del BIOS e la disposizione fisica, il sistema operativo Linux rilevava tale GPU con una negoziazione ancora inferiore, a Gen2 x1 o addirittura Gen1 x4. L'analisi tramite nvidia-smi ha fornito la prova inconfutabile, mostrando una delle GPU operare con una larghezza di banda drasticamente ridotta rispetto alle altre.

Dopo aver riorganizzato le schede e verificato la corretta allocazione delle corsie, il sistema ha mostrato tutte le GPU operare a Gen3 x8 o Gen3 x16, garantendo la piena larghezza di banda necessaria. Questo intervento ha portato a un miglioramento drastico delle performance. Il modello Mistral Medium 3.5 128B Q4_K GGUF, con llama.cpp e l'opzione --split-mode tensor --tensor-split 25,25,25,25, ha visto il suo Throughput salire a circa 24.7 token/secondo. Anche altri modelli hanno beneficiato enormemente: Qwen3.6 27B BF16 con vLLM e TP=4 + MTP ha raggiunto 78-80 token/secondo, mentre con llama.cpp e NCCL ha toccato i 66.5 token/secondo.

Implicazioni per i deployment on-premise e l'ottimizzazione hardware

Questo episodio sottolinea un aspetto critico per CTO, DevOps lead e architetti infrastrutturali che valutano deployment LLM self-hosted o on-premise. La promessa di un TCO inferiore e di una maggiore sovranità dei dati, tipica delle soluzioni locali, può essere vanificata da dettagli hardware apparentemente minori. La semplice lunghezza fisica di uno slot PCIe non è garanzia della sua capacità elettrica; è indispensabile consultare i manuali della scheda madre e verificare attivamente la negoziazione delle corsie tramite strumenti come nvidia-smi e lspci -vv.

Inoltre, la scelta della strategia di split per i modelli GGUF in llama.cpp si è rivelata fondamentale. L'opzione --split-mode layer, che in alcuni contesti può sottoutilizzare le GPU, è stata superata da --split-mode tensor, che ha permesso di sfruttare appieno la potenza di calcolo distribuita. Per chi valuta l'implementazione di LLM on-premise, AI-RADAR offre framework analitici su /llm-onpremise per valutare i trade-off tra performance, costi e complessità infrastrutturale, evidenziando come l'ottimizzazione hardware sia tanto cruciale quanto la scelta del software.

Prospettiva finale: l'importanza della due diligence tecnica

L'esperienza dimostra che la costruzione di un "mostro di VRAM" con GPU usate, come le RTX 3090, richiede una due diligence tecnica approfondita. Problemi di performance che potrebbero essere erroneamente attribuiti a Framework come llama.cpp o vLLM, a strategie di Quantization o ai modelli stessi, possono in realtà celare banali errori di configurazione hardware. Un singolo componente mal posizionato o non correttamente configurato può creare un collo di bottiglia che compromette l'efficienza dell'intero sistema.

Per i decision-maker tecnici, questo caso è un monito: l'investimento in hardware potente per carichi di lavoro AI/LLM on-premise deve essere accompagnato da una verifica meticolosa di ogni componente, dalla scheda madre alle GPU, e dalla comprensione delle loro interazioni. Solo così è possibile trasformare un potenziale "mostro" in una risorsa effettivamente performante, garantendo il pieno controllo e la massima efficienza dei costi operativi.