Intel e AMD collaborano su PyTorch/oneDNN: cosa cambia per l'IA locale sulle CPU

AMD e Intel sono i due grandi rivali della piattaforma x86. Per anni ognuno dei due ha cercato di spremere le proprie CPU per l'IA con strade software diverse. Oggi hanno deciso di unire le forze: collaborano su oneDNN, la libreria open source che fa girare i carichi di lavoro PyTorch sulle CPU. Per chi fa IA locale — o meglio, per chi si appoggia alla CPU quando la GPU non c'è o non basta — è una notizia concreta.

Cos'è successo

AMD e Intel hanno annunciato una collaborazione per combinare il proprio lavoro di ottimizzazione x86 per PyTorch dentro oneDNN, una libreria open source di deep learning che governa l'esecuzione dei carichi di lavoro IA sulle CPU. oneDNN non è un progetto di uno dei due: è governato da un organismo aperto, la Unified Acceleration Foundation (UXL). La scelta è arrivata su raccomandazione del x86 Ecosystem Advisory Group, e il risultato è che oneDNN diventa la libreria open source di default per l'accelerazione x86 dentro PyTorch.

Il pezzo di AMD che cambia posizione è ZenDNN, il fork downstream che AMD manteneva per le proprie CPU. Invece di tenere le ottimizzazioni separate, AMD sta integrando ZenDNN dentro oneDNN e entra nella fondazione UXL come membro del board di indirizzo. Intel porta da parte sua il lavoro su ACE, un set di istruzioni x86 di nuova generazione pensato per accelerare la moltiplicazione di matrici — l'operazione matematica al cuore dei carichi di lavoro IA. ACE verrà integrato in PyTorch attraverso i prossimi aggiornamenti di oneDNN.

In pratica, due strade parallele diventano una.

Perché conta per l'IA locale

Fino a ieri, se giravi un modello sulla CPU di un computer AMD o di un computer Intel, lo stavi facendo su due software path diversi. Ognuno dei due vendor aveva ottimizzato la propria architettura, e la comunità PyTorch doveva supportare entrambi i rami. Questo creava frammentazione: una configurazione che funzionava bene su un vendor poteva dare risultati diversi sull'altro, e ogni aggiornamento di PyTorch era una corsa a mantenere i due percorsi allineati.

Con oneDNN come via di default, il punto di accesso alle ottimizzazioni CPU per PyTorch diventa unico. Un'applicazione costruita una volta ha una sola strada da ottimizzare e mantenere, indipendentemente dal fatto che atterri su una CPU AMD o su una Intel. Per chi fa IA locale, questo tocca un caso d'uso preciso: i setup in cui la CPU è il motore principale — un laptop senza GPU dedicata, un mini-PC, o la CPU che gestisce prefill e tokenizzazione mentre la GPU fa il resto. Meno frammentazione significa meno sorprese quando passi da un hardware all'altro, e una base di ottimizzazioni che i due vendor spingono insieme invece di in gara.

C'è un secondo fronte che vale la pena guardare. L'IA locale vive in gran parte di modelli open che girano su CPU e GPU. Quando due vendor mettono in comune le ottimizzazioni per la CPU, si allarga la fascia di hardware su cui un modello open è davvero pratico da usare. Per il confronto generale tra piattaforme resta valido il nostro articolo su NVIDIA, AMD e Intel per l'IA locale.

Come funziona oneDNN sotto il cofano

oneDNN è una libreria di primitive: non è un runtime che gira al posto di PyTorch, ma la base su cui i framework costruiscono le operazioni matematiche (matmul, convoluzioni, attivazioni) in modo che sfruttino le istruzioni specifiche della CPU. Il valore sta nel generare codice ottimizzato per l'architettura su cui gira, e nel farlo una volta sola per l'intero ecosistema x86 invece che in due fork separati.

La moltiplicazione di matrici è l'operazione che domina i costi di inferenza e addestramento. È su questo che ACE lavora: istruzioni x86 nuove che accelerano proprio quella moltiplicazione, e che arriveranno dentro PyTorch a valle di oneDNN. Questo significa che i guadagni non sono un plugin opzionale da installare: entrano nella strada standard.

E i limiti

Onesti: questa è una notizia sulla CPU, e per gran parte dell'IA locale la GPU resta il motore principale. Se hai una scheda da 24GB o 32GB, il collo di bottiglia del tuo setup è la VRAM, non la libreria CPU. oneDNN non sposta i numeri di chi gira con la GPU.

Dove la notizia è diretta: se il tuo caso d'uso vive sulla CPU — modelli piccoli su CPU, o CPU+GPU in cui la CPU fa il prefill — una strada software comune e ottimizzata insieme da due vendor è un miglioramento concreto. E ACE è una storia per i prossimi chip, non per quelli che hai già: le istruzioni nuove si sbloccheranno solo su hardware che le supporta.

Setup minimo

Se oggi stai girando modelli sulla CPU, la cosa più utile è assicurarti che la tua build di PyTorch usi oneDNN come backend x86 di default, che è ormai il caso di default. Non c'è nulla da installare a parte: è la strada che i due vendor stanno unificando. Il confronto tra i motori di inferenza e il loro rapporto con le CPU resta coperto in Ollama vs llama.cpp: sotto il cofano, e la scelta tra CPU e GPU in GPU o CPU: quando la CPU basta.

Fonti

• AMD: AMD e Intel collaborano su oneDNN per PyTorch
• Phoronix: Intel e AMD collaborano su PyTorch/oneDNN

In sintesi

AMD e Intel hanno unito il lavoro di ottimizzazione x86 per PyTorch dentro oneDNN, la libreria open source governata dalla UXL. AMD integra il proprio fork ZenDNN in oneDNN e entra come membro del board; Intel porta le istruzioni ACE per la moltiplicazione di matrici. oneDNN diventa la via di default per l'accelerazione x86 in PyTorch, e questo significa una sola strada software da ottimizzare e mantenere per chi fa IA locale sulla CPU, invece di due. È un passo contro la frammentazione dell'ecosistema, non un salto di prestazioni per chi gira sulla GPU.

Articolo generato con IA