Architecture-Aware LLM Inference Optimization on AMD Instinct GPUs: A Comprehensive Benchmark and Deployment Study

Questo studio presenta una valutazione trasversale dell'inferenza di LLM su GPU AMD Instinct MI325X, dimostrando che l'ottimizzazione consapevole dell'architettura è fondamentale per massimizzare il throughput e la stabilità, evidenziando come modelli MoE+MLA e GQA richiedano configurazioni specifiche del runtime AITER e blocchi di cache diversi per raggiungere prestazioni competitive.

L'essenziale

🚀 Il Grande Esperimento: Come far correre i Giganti dell'IA su macchine AMD

Immagina di dover organizzare una gara di corsa per quattro veicoli molto diversi:

1. Un camioncino pesante (Llama-3.1-405B): Ha un motore enorme e potente, ma è tutto "denso" e pesante.
2. Un elicottero veloce (DeepSeek V3.2): Ha un motore piccolo ma intelligente che cambia le pale al volo (architettura MoE+MLA).
3. Un motore ibrido compatto (Qwen3-VL-235B): Un mix intelligente che usa solo la parte necessaria del motore e sa anche "vedere" le immagini.
4. Un mostro da un trilione di ingranaggi (Kimi-K2.5): Il più grande di tutti, ma che ne usa solo una piccola parte alla volta.

L'obiettivo? Farli correre il più velocemente possibile su una nuova pista costruita da AMD (le loro schede grafiche MI325X), usando un sistema di gestione del traffico chiamato vLLM.

Ecco cosa hanno scoperto i ricercatori, spiegato con delle metafore quotidiane.

1. Non esiste una "chiave universale" (L'importanza dell'Architettura)

Prima di questa ricerca, molti pensavano che si potesse usare lo stesso set di istruzioni per far correre tutti i veicoli. Falso.

• L'analogia: Immagina di dover parcheggiare un camioncino e un'auto sportiva nello stesso garage. Se usi le stesse regole per entrambi, il camioncino si schianterebbe o l'auto non entrerebbe.
• La scoperta: I modelli che usano una tecnologia chiamata MLA (come DeepSeek e Kimi) sono come auto sportive che hanno bisogno di un parcheggio speciale: devono usare "blocchi" di memoria molto piccoli (dimensione 1) e non possono scaricare i bagagli su un camioncino esterno (non possono usare la memoria del computer per espandersi).
• I modelli GQA (come Llama e Qwen), invece, sono come camioncini robusti: possono usare blocchi di memoria più grandi e, se il garage è pieno, possono scaricare i bagagli sul camioncino esterno per fare più spazio.
• Conclusione: Devi conoscere il "tipo di veicolo" (l'architettura) per impostare le regole del traffico correttamente. Se sbagli, il sistema si blocca o va lentissimo.

2. Il "Motore Magico" (AITER)

AMD ha un software speciale chiamato AITER che funziona come un turbo per i motori.

• Per i modelli "intelligenti" (MLA): Il turbo è obbligatorio. Senza di esso, l'elicottero (DeepSeek) volerebbe a passo d'uomo. Con il turbo, diventa un jet.
• Per i modelli "classici" (GQA): Il turbo aiuta un po' (magari del 3-5%), ma non è fondamentale. Anzi, a volte il turbo rende il viaggio un po' più "tremolante" (meno stabile nelle misurazioni).
• Il caso Kimi: Il mostro da un trilione di ingranaggi (Kimi-K2.5) è così speciale che il turbo AMD attuale non gli si adatta (è come mettere un motore di Formula 1 su un trattore). Quindi, per lui, il turbo va spento completamente, altrimenti si rompe.

3. Il vero collo di bottiglia: La "Strada", non il "Motore"

Uno dei risultati più sorprendenti è che, una volta che tutti i veicoli sono in pista, nessuno corre più veloce di una certa velocità, indipendentemente da quanto è potente il motore.

• L'analogia: Immagina una strada a un solo senso di marcia molto larga. Anche se hai un'auto da 500 cavalli, se la strada è piena di auto, non puoi andare più veloce di quanto permetta il traffico.
• La scoperta: Il limite non è la potenza di calcolo (i cavalli del motore), ma la larghezza della strada (la memoria). Quando ci sono troppe richieste contemporanee (circa 500 utenti), la strada si intasa e la velocità si stabilizza. Aggiungere più utenti dopo quel punto non aumenta la velocità, fa solo aspettare di più.
• Questo vale per tutti e quattro i modelli, anche se uno è piccolo e l'altro è enorme.

4. Chi vince la gara? (I Risultati)

• Il vincitore assoluto (in termini di velocità totale): Qwen3-VL. È un modello che "vede" le immagini. Ha vinto perché usa pochissimi ingranaggi attivi (22 miliardi su 235 totali) e sa usare bene la strada. Ha raggiunto una velocità incredibile: quasi 48.000 parole al secondo (inclusi i pixel delle immagini).
• Il duello tra i giganti: Llama (il camioncino pesante) e DeepSeek (l'elicottero intelligente) hanno corso quasi alla stessa velocità, anche se DeepSeek usa 10 volte meno "ingranaggi attivi". Questo dimostra che l'intelligenza artificiale moderna non ha bisogno di essere "pesante" per essere veloce, se è ben architettata.
• Il mostro Kimi: Nonostante sia il più grande (1 trilione di parametri), è stato messo in gara con solo metà delle ruote (4 GPU invece di 8) e senza turbo. Ha comunque funzionato perfettamente, gestendo 1.000 utenti contemporaneamente senza crashare. È una prova che i computer AMD possono gestire i modelli più grandi del mondo.

5. La stabilità è tutto

In una gara di 17.000 richieste, nessuna è fallita. Tutti gli utenti hanno ricevuto una risposta corretta. Questo è fondamentale per le aziende: non importa quanto è veloce il sistema se si blocca ogni due per tre. Qui, il sistema è stato solido come una roccia.

🏁 In Sintesi: Cosa ci insegna questo studio?

1. Non esiste una soluzione unica: Non puoi usare le stesse impostazioni per tutti i modelli di IA. Devi adattarle come un sarto che cuce un abito su misura.
2. La strada è più importante del motore: Per far correre l'IA velocemente, serve una "strada" (memoria) larga e veloce, non solo un motore potente.
3. AMD è pronto: Le macchine AMD MI325X sono perfettamente in grado di gestire i modelli più grandi e complessi del mondo, anche se richiedono un po' di "manutenzione" specifica per ogni tipo di modello.
4. L'efficienza conta: I modelli che usano solo una parte dei loro "cervelli" alla volta (architettura MoE) sono spesso più efficienti e veloci di quelli che usano tutto il cervello ogni volta.

In parole povere: L'IA del futuro non sarà solo più grande, sarà più intelligente nel modo in cui usa le risorse, e le macchine AMD sono pronte a ospitarla, a patto di sapere come guidarle.

Sommario tecnico

Ecco un riassunto tecnico dettagliato del rapporto tecnico intitolato "Architecture-Aware LLM Inference Optimization on AMD Instinct GPUs: A Comprehensive Benchmark and Deployment Study".

1. Il Problema

L'inferenza di modelli linguistici su larga scala (LLM) richiede una co-ottimizzazione complessa tra architettura del modello, capacità hardware e configurazione del sistema di servizio. Tuttavia, esistono studi di benchmarking sistematici scarsi sugli acceleratori AMD, in particolare per modelli all'avanguardia (frontier-scale) che variano da centinaia di miliardi a trilioni di parametri.
Le sfide principali includono:

• Diversità Architetturale: Modelli con meccanismi di attenzione diversi (GQA, MLA - Multi-head Latent Attention) e strutture (Dense vs. MoE - Mixture of Experts) impongono vincoli di configurazione radicalmente diversi.
• Maturità dell'Ecosistema AMD: Sebbene ROCm e vLLM siano maturi, la mancanza di linee guida specifiche per l'hardware AMD (Instinct MI325X) porta a configurazioni subottimali o errori di esecuzione.
• Scalabilità: La capacità di servire modelli da 1 trilione di parametri con alta concorrenza e affidabilità su cluster AMD non è stata precedentemente documentata in modo accademico.

2. Metodologia

Lo studio presenta un benchmark trasversale su un cluster di 8 GPU AMD Instinct MI325X (architettura CDNA 3, 2 TB di memoria HBM3e aggregata, 48 TB/s di banda).

• Framework: Utilizzo di vLLM v0.14.1 come motore di inferenza.
• Modelli Valutati: Quattro modelli all'avanguardia appartenenti a tre famiglie architetturali:
  1. DeepSeek V3.2: 685B parametri totali, 37B attivi (MoE + MLA).
  2. Llama-3.1-405B: 405B parametri totali (Dense + GQA).
  3. Qwen3-VL-235B: 235B totali, 22B attivi (MoE + GQA, multimodale).
  4. Kimi-K2.5: 1 Trilione di parametri totali, 32B attivi (MoE + MLA).
• Configurazioni: Sono state testate diverse strategie di quantizzazione (FP8, BF16, INT4 QAT), parallelismo tensoriale (TP=4 o TP=8) e ottimizzazioni specifiche (AITER, offloading KV cache).
• Carichi di Lavoro: Test di scalabilità da 1 a 1.000 utenti concorrenti, inclusi scenari di testo puro e lavoro multimodale (visione), con misurazioni di throughput (token/s), latenza (p99) e tasso di successo.

3. Contributi Chiave

Il rapporto offre cinque contributi principali:

1. Primo Benchmark Cross-Architettura su MI325X: Valutazione sistematica di modelli da 235B a 1T di parametri su hardware AMD, caratterizzando i vincoli specifici per ogni architettura.
2. Ottimizzazione Consapevole dell'Architettura: Dimostrazione che non esiste una configurazione "universale". Le architetture MLA richiedono blocchi di dimensione 1 e non supportano l'offloading della cache KV, mentre le architetture GQA beneficiano di entrambi.
3. Deploy di Modelli da 1 Trilione di Parametri: Primo benchmark pubblicato di un modello da 1T di parametri (Kimi-K2.5) su MI325X, raggiunto con quantizzazione INT4 QAT e TP=4.
4. Validazione Empirica dei Parametri Attivi: Conferma che il throughput è guidato dal numero di parametri attivi per token, non dal totale, sebbene confuso da variabili come quantizzazione e accelerazione AITER.
5. Saturazione Dipendente dal Carico: Identificazione di un punto di saturazione comune per tutti i modelli (circa 500 utenti concorrenti per carichi brevi, 100-200 per sequenze lunghe), indicando un collo di bottiglia nella banda di memoria.

4. Risultati Principali

Performance e Throughput

• Modelli Text-Only:
  • Llama-3.1-405B (Dense+GQA): 15.944 tok/s (picco).
  • DeepSeek V3.2 (MoE+MLA): 15.343 tok/s (picco).
  • Nota: Nonostante DeepSeek abbia solo il 9% dei parametri attivi di Llama (37B vs 405B), ottiene un throughput simile, ma con una latenza di output inferiore (1.239 tok/s vs 3.673 tok/s per Llama).
• Modelli Vision-Only:
  • Qwen3-VL-235B (MoE+GQA): 47.873 tok/s (picco, inclusi token immagine).
  • Kimi-K2.5 (MoE+MLA): 7.327 tok/s (picco).
  • Nota: Qwen3-VL supera Kimi-K2.5 di 6,5 volte grazie alla combinazione di GQA, AITER abilitato e TP=8, mentre Kimi-K2.5 è limitato da vincoli di AITER e TP=4.

Ottimizzazioni e Vincoli Tecnici

• AITER (AMD AI Tensor Engine):
  • È essenziale per l'inferenza MLA competitiva (DeepSeek, Kimi). Senza AITER, il fallback Triton offre prestazioni drasticamente inferiori.
  • Per i modelli GQA (Llama), AITER offre un beneficio modesto (3-5% in alto carico) ma aumenta la variabilità delle misurazioni (CoV da 0,4% a 4,7%).
  • Vincolo Critico: AITER deve essere disabilitato per Kimi-K2.5 a causa di incompatibilità hardware (richiede MXFP4 su CDNA 4, non disponibile su MI325X/CDNA 3) e vincoli sul numero di teste di attenzione.
• Configurazioni Specifiche:
  • MLA: Richiede --block-size 1 e non supporta l'offloading della cache KV su ROCm attuale.
  • GQA: Supporta offloading KV cache e dimensioni dei blocchi standard (16).
  • Kimi-K2.5: Richiede TP=4 (metà del cluster) e build nightly di vLLM.
• Affidabilità: Tutti i modelli hanno mantenuto un tasso di successo HTTP del 100% fino a 1.000 utenti concorrenti, elaborando 18,9 milioni di token senza fallimenti.

Collo di Bottiglia

L'analisi della saturazione e dell'utilizzo FLOPs (inferiore al 15% anche per i modelli più densi) conferma che l'inferenza LLM su MI325X è limitata dalla banda di memoria (Memory-Bandwidth Bound) e non dalla potenza di calcolo. La saturazione avviene quando la banda di memoria (48 TB/s) è satura, indipendentemente dall'architettura del modello.

5. Significato e Implicazioni

Questo studio è fondamentale per il deployment produttivo di LLM su hardware AMD:

• Ridefinizione delle Best Practices: Smonta l'idea che una singola configurazione vLLM funzioni per tutti i modelli. Le configurazioni devono essere adattate dinamicamente in base al meccanismo di attenzione (MLA vs GQA) e alla struttura MoE.
• Viabilità di AMD MI325X: Dimostra che la piattaforma MI325X è competitiva per modelli all'avanguardia, offrendo capacità di memoria (256 GB/GPU) sufficiente per evitare l'offloading su CPU e una banda aggregata che supporta throughput elevati.
• Guida alla Selezione dei Modelli: Per applicazioni sensibili al throughput, la scelta del modello dovrebbe basarsi sul numero di parametri attivi e sull'architettura di attenzione, piuttosto che sul totale dei parametri.
• Ottimizzazione Futura: Evidenzia la necessità di migliorare l'ecosistema ROCm/AITER (es. supporto per l'offloading KV cache su MLA, risoluzione delle incompatibilità dimensionali per i modelli vision) e suggerisce direzioni future come il speculative decoding e il disaggregated prefill/decode.

In sintesi, il rapporto fornisce una mappa tecnica dettagliata per navigare la complessità del deployment di LLM su AMD, evidenziando che il successo dipende dall'adattamento fine delle configurazioni software alle specifiche architetturali dei modelli.