Aller au contenu principal
MatérielIntermédiaire6 min de lecture

Intel et AMD collaborent sur PyTorch/oneDNN: ce que ça change pour l'IA locale sur CPU

i
iaLocale Team
•
Intel et AMD collaborent sur PyTorch/oneDNN: ce que ça change pour l'IA locale sur CPU

AMD et Intel sont les deux grands rivaux de la plateforme x86. Des années durant, chacun a cherché à exprimer ses CPU pour l'IA par des voies logicielles distinctes. Aujourd'hui, ils ont décidé d'unir leurs forces : ils collaborent sur oneDNN, la bibliothèque open source qui fait tourner les charges de travail PyTorch sur les CPU. Pour ceux qui pratiquent l'IA locale — ou mieux, pour ceux qui s'appuient sur le CPU quand la GPU est absente ou insuffisante — c'est une nouvelle concrète.

Ce qui s'est passé

AMD et Intel ont annoncé une collaboration pour combiner leur travail d'optimisation x86 pour PyTorch dans oneDNN, une bibliothèque open source de deep learning qui pilote l'exécution des charges de travail IA sur CPU. oneDNN n'est pas un projet de l'un ou de l'autre : il est gouverné par un organisme ouvert, la Unified Acceleration Foundation (UXL). Le choix est arrivé sur recommandation du x86 Ecosystem Advisory Group, et le résultat, c'est que oneDNN devient la bibliothèque open source par défaut pour l'accélération x86 dans PyTorch.

La pièce d'AMD qui change de position est ZenDNN, le fork downstream qu'AMD maintenait pour ses propres CPU. Au lieu de garder les optimisations séparées, AMD intègre ZenDNN dans oneDNN et entre dans la fondation UXL comme membre du board de pilotage. Intel apporte de son côté le travail sur ACE, un jeu d'instructions x86 de nouvelle génération pensé pour accélérer la multiplication de matrices — l'opération mathématique au cœur des charges de travail IA. ACE sera intégré à PyTorch par les prochaines mises à jour de oneDNN.

En pratique, deux voies parallèles deviennent une seule.

Pourquoi ça compte pour l'IA locale

Jusqu'à hier, si vous faisiez tourner un modèle sur le CPU d'un ordinateur AMD ou d'un ordinateur Intel, vous le faisiez sur deux chemins logiciels différents. Chacun des deux vendors avait optimisé sa propre architecture, et la communauté PyTorch devait maintenir les deux branches. Cette configuration créait de la fragmentation : une configuration qui marchait bien chez un vendor pouvait donner des résultats différents chez l'autre, et chaque mise à jour de PyTorch était une course pour garder les deux chemins alignés.

Avec oneDNN comme voie par défaut, le point d'accès aux optimisations CPU pour PyTorch devient unique. Une application construite une seule fois a une seule voie à optimiser et à maintenir, indépendamment du fait qu'elle atterrisse sur un CPU AMD ou un CPU Intel. Pour l'IA locale, cela touche un cas d'usage précis : les configurations où le CPU est le moteur principal — un laptop sans GPU dédiée, un mini-PC, ou le CPU qui gère le prefill et la tokenisation pendant que la GPU fait le reste. Moins de fragmentation, moins de surprises quand on passe d'un matériel à l'autre, et une base d'optimisations que les deux vendors poussent ensemble plutôt qu'en compétition.

Un second front mérite attention. L'IA locale vit en grande partie de modèles open qui tournent sur CPU et GPU. Quand deux vendors mutualisent les optimisations pour le CPU, s'élargit la bande de matériel sur laquelle un modèle open est réellement pratique à utiliser. Pour la comparaison générale entre plateformes, notre article sur NVIDIA, AMD et Intel pour l'IA locale reste valable.

Comment fonctionne oneDNN sous le capot

oneDNN est une bibliothèque de primitives : ce n'est pas un runtime qui tourne à la place de PyTorch, c'est la base sur laquelle les frameworks construisent les opérations mathématiques (matmul, convolutions, activations) de façon à exploiter les instructions spécifiques du CPU. La valeur tient dans la génération de code optimisé pour l'architecture sur laquelle on tourne, et ce, une seule fois pour l'écosystème x86 entier au lieu de deux forks séparés.

La multiplication de matrices est l'opération qui domine les coûts d'inférence et d'entraînement. C'est sur elle que ACE travaille : des instructions x86 nouvelles qui accélèrent précisément cette multiplication, et qui arriveront dans PyTorch en aval de oneDNN. Les gains ne sont donc pas un plugin optionnel à installer : ils entrent dans la voie standard.

Et les limites

Soyons honnêtes : c'est une nouvelle qui concerne le CPU, et pour une grande partie de l'IA locale la GPU reste le moteur principal. Si vous avez une carte de 24 Go ou 32 Go, le goulot d'étranglement de votre configuration est la VRAM, pas la bibliothèque CPU. oneDNN ne déplace pas les chiffres de ceux qui tournent sur GPU.

Là où la nouvelle est directe : si votre cas d'usage vit sur le CPU — petits modèles sur CPU, ou CPU+GPU où le CPU fait le prefill — une voie logicielle commune, optimisée par deux vendors ensemble, est une amélioration concrète. Et ACE est une histoire pour les prochaines puces, pas celles que vous avez déjà : les nouvelles instructions ne se débloqueront que sur du matériel qui les supporte.

Configuration minimale

Si aujourd'hui vous faites tourner des modèles sur CPU, le plus utile est de vous assurer que votre build de PyTorch utilise oneDNN comme backend x86 par défaut, ce qui est désormais le cas par défaut. Il n'y a rien d'autre à installer : c'est la voie que les deux vendors unifient. La comparaison des moteurs d'inférence et leur rapport aux CPU reste couverte dans Ollama vs llama.cpp : sous le capot, et le choix entre CPU et GPU dans GPU ou CPU : quand le CPU suffit.

Sources

En résumé

AMD et Intel ont réuni leur travail d'optimisation x86 pour PyTorch dans oneDNN, la bibliothèque open source gouvernée par l'UXL. AMD intègre son fork ZenDNN dans oneDNN et entre comme membre du board ; Intel apporte les instructions ACE pour la multiplication de matrices. oneDNN devient la voie par défaut pour l'accélération x86 dans PyTorch, ce qui signifie une seule voie logicielle à optimiser et à maintenir pour ceux qui font de l'IA locale sur CPU, au lieu de deux. C'est un pas contre la fragmentation de l'écosystème, pas un bond de performances pour ceux qui tournent sur GPU.

Article généré par IA

#amd#cpu#intel#onednn#pytorch
Partager :

Vous avez aimé cet article ?

Abonnez-vous à la newsletter pour recevoir de nouveaux tutoriels et guides.

Après l'inscription, vous recevez un e-mail de confirmation (double opt-in). Sans confirmation, nous n'envoyons rien. Pas de spam, promis.

Ressources liées

Outils et ressources des archives iaLocale pertinents pour ce contenu.