Introduzione: Ottimizzare gli LLM on-premise con Strix Halo

L'adozione di Large Language Models (LLM) in ambienti self-hosted rappresenta una priorità crescente per le aziende che mirano a mantenere la sovranità dei dati e a ottimizzare il Total Cost of Ownership (TCO). In questo contesto, l'efficienza dell'hardware e del software di inference locale è cruciale. Recenti benchmark condotti su una piattaforma AMD Strix Halo, utilizzando il popolare framework llama.cpp, offrono spunti interessanti sulle prestazioni dei modelli Qwen3.6 e sull'impatto della funzionalità Multi-Turn Prediction (MTP).

Questi test si concentrano sulla capacità di elaborare carichi di lavoro LLM complessi, come le conversazioni a lungo contesto, direttamente su hardware locale. I risultati forniscono una base concreta per i CTO e gli architetti di infrastruttura che valutano le soluzioni self-hosted per i loro carichi di lavoro di intelligenza artificiale, evidenziando i trade-off tra diverse configurazioni e ottimizzazioni.

Dettagli tecnici e metodologia dei benchmark

La configurazione hardware utilizzata per i benchmark comprendeva una CPU AMD RYZEN AI MAX+ 395 (16 core/32 thread), una iGPU Radeon 8060S (RADV GFX1151) e 30 GiB di RAM, il tutto operante su Ubuntu 24.04 con kernel 6.17. Il software di inference era llama.cpp, nella versione 9187, con API Vulkan 1.4.305 e Mesa RADV 25.0.7. Questa configurazione rappresenta un tipico ambiente di edge computing o un server on-premise di fascia media.

Sono stati testati modelli Qwen3.6, nelle varianti da 27B e 35B parametri, sia in versione base che con l'ottimizzazione MTP. La metodologia prevedeva due scenari principali: un test “single-turn” con un prompt sintetico di circa 15.000 token e un test “multi-turn” di 5 turni, dove il contesto cresceva fino a circa 28.500 token. Le metriche chiave misurate includevano il “wall time” (tempo totale end-to-end), il “prompt processing throughput” (token/sec) e il “generation throughput” (token/sec).

Analisi dei risultati: tra accelerazione e compromessi

I benchmark hanno rivelato un framework differenziato a seconda del modello e del tipo di carico di lavoro. Per il modello Qwen3.6-27B, l'adozione di MTP ha portato a un miglioramento complessivo significativo. Nel test single-turn da 15.000 token, il tempo totale è diminuito dell'11,50% (da 87,44s a 77,39s), con un incremento del 111,77% nel throughput di generazione (da 7,63 a 16,15 token/sec), nonostante un leggero rallentamento nel prompt processing (-12,46%). Ancora più marcato è stato il beneficio nel test multi-turn a lungo contesto, dove il tempo totale si è ridotto del 22,46% (da 258,65s a 200,55s), e il throughput di generazione medio è aumentato del 136,41% (da 7,61 a 17,98 token/sec).

Il modello Qwen3.6-35B ha mostrato risultati più eterogenei. Nel test single-turn, il tempo totale è aumentato dell'11,17% (da 20,83s a 23,16s), sebbene il throughput di generazione sia migliorato del 16,47%. Nel test multi-turn, il tempo totale è rimasto sostanzialmente invariato, con un leggero aumento del 2,34% (da 58,86s a 60,24s), pur registrando un incremento del 24,80% nel throughput di generazione. Questi dati suggeriscono che l'MTP tende a migliorare costantemente la generazione di token, ma può influire negativamente sul prompt processing, e l'impatto complessivo dipende dalla dominanza della fase di decodifica o di prefill nel carico di lavoro specifico.

Implicazioni per i deployment on-premise

I risultati di questi benchmark sottolineano l'importanza di valutare attentamente la forma del carico di lavoro (workload shape) quando si considerano ottimizzazioni come l'MTP per i deployment on-premise di LLM. Per scenari che richiedono una generazione intensiva di token, specialmente in contesti conversazionali a lungo termine, l'MTP può offrire vantaggi sostanziali, come dimostrato dal modello 27B. Tuttavia, per carichi di lavoro dove il prompt processing è dominante, il beneficio complessivo potrebbe essere limitato o addirittura negativo, come osservato con il modello 35B.

Per i CTO e i responsabili DevOps che esplorano soluzioni self-hosted, questi dati evidenziano la necessità di testare le configurazioni specifiche con i propri modelli e carichi di lavoro reali. La scelta dell'hardware, l'ottimizzazione del software come llama.cpp e l'adozione di funzionalità avanzate come l'MTP sono tutti fattori che influenzano direttamente le performance, il TCO e la capacità di mantenere la sovranità dei dati. AI-RADAR offre framework analitici su /llm-onpremise per aiutare a valutare questi trade-off complessi, fornendo strumenti per decisioni informate sui deployment di intelligenza artificiale.