Alla PyTorch Conference 2025, AMD ha mostrato uno scaling lineare oltre 1.000 GPU Instinct usando Primus-Turbo, una libreria di ottimizzazione per framework di addestramento come TorchTitan. Ora quelle ottimizzazioni sono confluite nel mainline PyTorch: TorchTitan supporta direttamente le GPU Instinct e offre prestazioni FP8 competitive senza componenti proprietari da installare. La notizia non è un singolo benchmark. È un segnale di maturità per ROCm dentro il framework più diffuso della ricerca e della produzione open.

I numeri raccontano due scenari distinti. Su modelli densi, l'addestramento FP8 produce un guadagno di throughput del 13,4% rispetto a BF16 su Llama3-8B con 8×MI300X, a parità quasi esatta di memoria di picco. Il vantaggio arriva dai matrix core FP8 più veloci, non dal risparmio di memoria. Su architetture MoE come DeepSeek-V3 671B, la Quantization FP8 aggiungeva inizialmente un overhead significativo: servono scale per riga sulle attivazioni, scale per colonna sui pesi degli esperti e un tensore di offset per instradare i token. La pipeline di Quantization Triton ha poi recuperato l'89% dell'overhead, portando il forward da circa 19 ms a circa 7 ms.

La correttezza del formato viene prima del tuning

Le GPU Instinct usano una variante FP8 chiamata e4m3fnuz, con valore massimo 240 e nessuna codifica per NaN o Inf. TorchAO inizialmente calcolava le scale rispetto a un massimo diverso. Su hardware AMD questo produceva risultati errati in modo silenzioso: i tensori venivano scalati oltre i valori rappresentabili, tagliando le attivazioni e corrompendo i gradienti. Poiché il formato non prevede NaN/Inf, l'overflow non generava errori. Per questo AMD ha aggiunto l'auto-rilevamento dell'hardware in TorchAO: la scelta del formato corretto è un requisito di correttezza, non una preferenza prestazionale.

Il guadagno vero è nel movimento dei dati

La pipeline FP8 in TorchAO era una catena di passaggi separati: calcolo dell'absmax per riga o colonna, derivazione della scala, clamp e cast a FP8. Ogni passaggio lanciava un kernel e materializzava tensori intermedi nella memoria HBM. Per modelli MoE con decine di tensori di pesi per layer, questi round-trip dominavano l'overhead. Le ottimizzazioni AMD attaccano il movimento dei dati a tre livelli.

Il primo riduce il numero di kernel. Nel backward è stato eliminato un pattern .t().contiguous().t() che imponeva una copia completa attraverso HBM, e la catena di scale-and-cast è stata fusa in singoli kernel Triton. Su DeepSeek-MoE-16B il throughput del backward è migliorato di 4,2×. Nel forward, la fusione ha sostituito cinque kernel generici per chiamata con un unico kernel specializzato, parallelo su esperti e blocchi di dimensione output. Sugli 8×MI325X con DeepSeek-V3 671B il throughput end-to-end sale da 5.996 a 7.027 token/s, con un recupero dell'89% del divario rispetto alla baseline BF16.

Il secondo livello rende efficiente l'accesso alla memoria. Il kernel delle scale per colonna scriveva in modo non coalescente: le lane SIMD consecutive scrivevano a indirizzi distanti, generando transazioni separate. Trasponendo il tile di output attraverso la Local Data Share prima del salvataggio, il tempo per layer MoE passa da 7.290 a 1.170 microsecondi, un'accelerazione di 6,2×.

Il terzo livello elimina sincronizzazioni superflue. Le atomiche Triton usavano di default l'ordinamento acquire-release, che su GPU AMD inserisce memory fence prima e dopo ogni atomica. Passare al relaxed ordering ha rimosso punti di sincronizzazione costosi e non necessari per riduzioni commutative.

Cosa significa per chi gestisce cluster locali

C'è anche un esperimento non riuscito. L'ampliamento dello spazio di autotuning da 1 a 8-16 configurazioni candidate non ha prodotto miglioramenti misurabili su forme Llama 4 con MI300X e ha aumentato il tempo di compilazione al primo avvio; AMD ha ripristinato la modifica. La lezione è precisa: lo spazio di ricerca va modellato sui vincoli hardware, come dimensione dei wavefront, capacità della LDS e pressione sui registri, non esteso a caso.

Il fatto che questi guadagni siano nel mainline PyTorch, senza componenti AMD-specifiche da installare, abbassa il costo di adozione e manutenzione per chi usa GPU Instinct nei propri datacenter. Non servono fork di framework o strumenti vendor: basta aggiornare TorchAO e TorchTitan. Per le organizzazioni che tengono i dati nei propri ambienti, una piattaforma alternativa a NVIDIA diventa più credibile anche sul piano software. La collaborazione tra AMD e gli ingegneri Meta/PyTorch indica che ROCm sta entrando nel ciclo di sviluppo upstream, non come semplice porting. Il prossimo passo dichiarato è MXFP8 per le GPU MI355X: la competizione si sposta sui formati di Quantization a granularità fine. Resta aperto un punto: il guadagno FP8 sui modelli densi è solido, ma l'efficienza sui modelli MoE richiede un lavoro di fusione profondo, non l'attivazione banale del formato.