I cicli di ottimizzazione per l’hardware AI si sono effettivamente chiusi. I ricercatori di DeepReinforce hanno pubblicato questa settimana un nuovo sistema in grado di generare codice macchina di basso livello che supera le librerie ottimizzate manualmente da NVIDIA fino al 28%.
Soprannominato CUDA-L2, il framework sfrutta i Large Language Models (LLM) guidati dal Reinforcement Learning (RL) per automatizzare la creazione di matrice generale a mezza precisione. Moltiplica i kernel (HGEMM). Queste operazioni sono il fondamento matematico della moderna formazione sull’intelligenza artificiale.
I benchmark rilasciati sul repository GitHub mostrano che il codice generato dall’intelligenza artificiale batte le librerie standard in 1.000 configurazioni distinte sui chip Ampere A100, sebbene il supporto per le nuove architetture Hopper sia ancora in fase di sviluppo.
Il benchmarking della svolta
I parametri delle prestazioni rivelano un divario significativo tra i kernel generati dall’intelligenza artificiale e le librerie standard. Negli scenari server che simulano l’inferenza in tempo reale, CUDA-L2 raggiunge un aumento di velocità del +28,7% rispetto a”torch.matmul”. Rispetto alla linea di base più ottimizzata di NVIDIA,”cuBLASLt-AutoTuning”, il sistema mantiene un vantaggio del +15,9%.
Confrontando i risultati con gli standard di settore consolidati, Songqiao Su, un ricercatore di DeepReinforce, ha dichiarato:”CUDA-L2 supera sistematicamente le principali linee di base matmul fino ad oggi, dall’ampiamente utilizzato torch.matmul all’avanzato closed-source di Nvidia librerie.”
I test hanno riguardato 1.000 combinazioni distinte di dimensioni della matrice (M, N, K) anziché alcuni esempi selezionati con cura. I benchmark offline, che eseguono kernel consecutivamente senza pause, hanno mostrato guadagni leggermente inferiori ma comunque sostanziali pari a +22,0% rispetto a PyTorch.
Risultati così coerenti mettono in discussione il presupposto che le librerie dei fornitori ottimizzate manualmente rappresentino il limite delle prestazioni. Automatizzando il rilevamento delle configurazioni ottimali, il sistema mette in luce le inefficienze nelle librerie di uso generale che devono bilanciare le prestazioni in un’ampia gamma di casi d’uso.
La metodologia: LLMs Writing Assembly
L’approccio di DeepReinforce sposta fondamentalmente l’ottimizzazione del kernel dalla progettazione euristica all’esplorazione automatizzata. Sfruttando Large Language Models (LLM), genera kernel candidati che vengono poi perfezionati tramite Reinforcement Learning (RL).
Descrivendo la portata del processo di ricerca automatizzata, Su ha osservato:”Anche i kernel più critici per le prestazioni e fortemente ottimizzati come HGEMM possono essere migliorati attraverso l’automazione RL guidata da LLM esplorando sistematicamente gli spazi di configurazione su scale poco pratiche per gli esseri umani.”
Per prevenire errori di valutazione”pigri”comuni nei sistemi basati su Python. test, il sistema convalida la correttezza rispetto ai riferimenti della CPU FP32. Questa fase di convalida garantisce che i guadagni di velocità non vengano raggiunti sacrificando la precisione numerica o la stabilità.
Navigando in questa complessità, l’agente RL esplora spazi di configurazione che sono troppo vasti per essere ottimizzati manualmente dagli ingegneri umani. Iterando su migliaia di potenziali progetti di kernel, il sistema identifica ottimizzazioni non ovvie che l’euristica standard non rileva.
Secondo il documento di ricerca, i miglioramenti delle prestazioni sono particolarmente pronunciati in scenari di distribuzione realistici:
“In modalità offline, dove i kernel vengono eseguiti consecutivamente senza intervalli di tempo, CUDA-L2 produce in media +22,0% rispetto a torch.matmul; +19,2% rispetto a cuBLAS utilizzando la configurazione di layout ottimale… e +11,4% rispetto al modello cuBLASLt-AutoTuning più competitivo.”
“In modalità server, in cui i kernel vengono eseguiti a intervalli casuali simulando l’inferenza in tempo reale, le velocità aumentano ulteriormente fino a +28,7%, +26,0%, +22,4% e +15,9% rispettivamente per torch.matmul, cuBLAS, cuBLASLt-heuristic e cuBLASLt-AutoTuning.”
Queste cifre evidenziano l’impatto pratico della strategia di ottimizzazione. Sebbene i guadagni offline dimostrino miglioramenti del throughput, le maggiori velocità in modalità server suggeriscono che i kernel generati gestiscono i carichi di lavoro intermittenti in modo più efficiente rispetto alle loro controparti ottimizzate manualmente.
Vincoli hardware e impatto sul mercato
L’ottimizzazione attuale è strettamente limitata all’architettura NVIDIA A100 (Ampere). Il supporto per le architetture più recenti come Hopper (H100) e Blackwell è pianificato ma non ancora disponibile. Di conseguenza, i vantaggi immediati sono limitati ai cluster aziendali legacy o esistenti piuttosto che alle implementazioni all’avanguardia.
La documentazione di GitHub delinea esplicitamente queste limitazioni hardware:
“Idealmente, i kernel addestrati su A100 dovrebbero essere utilizzati solo su A100 se si mira all’accelerazione. Potrebbero avere accelerazione su altre macchine, ma non è garantito. Rilasceremo progressivamente kernel addestrati su macchine diverse.”
Ridurre il costo computazionale di Le operazioni di HGEMM influiscono direttamente sui profitti della formazione di modelli su larga scala. Poiché la moltiplicazione delle matrici consuma la maggior parte dei cicli GPU nei carichi di lavoro LLM, anche i miglioramenti marginali in termini di efficienza si traducono in milioni di risparmi.
Analizzando le implicazioni economiche, Rohan Paul, analista AI presso Rohan’s Bytes, ha osservato:”Per il pre-training e la messa a punto di LLM, la maggior parte del tempo della GPU viene speso eseguendo queste moltiplicazioni di matrici HGEMM, quindi se questi kernel funzionano dal 10% al 30% più velocemente, l’intero lavoro di training o tuning può essere migliorato. notevolmente più economico.”
Il rilascio del codice su GitHub consente ai ricercatori di verificare queste affermazioni in modo indipendente, sebbene la convalida da parte di terzi sia ancora in sospeso. Se la metodologia si rivelasse trasferibile alle architetture più recenti, potrebbe imporre un ripensamento del modo in cui le librerie GPU di basso livello vengono sviluppate e mantenute.
