Intel and AMD collaborate on PyTorch/oneDNN: what it means for local AI on CPUs

AMD and Intel are the two great rivals of the x86 platform. For years, each of them squeezed their own CPUs for AI along separate software paths. Today they decided to join forces: they are collaborating on oneDNN, the open-source library that runs PyTorch workloads on CPUs. For anyone doing local AI — or rather, anyone who leans on the CPU when the GPU is absent or not enough — this is a concrete development.

What happened

AMD and Intel announced a collaboration to combine their x86 CPU optimization work for PyTorch inside oneDNN, an open-source deep learning library that governs the execution of AI workloads on CPUs. oneDNN is not a project of one vendor or the other: it is governed by an open body, the Unified Acceleration Foundation (UXL). The decision came on the recommendation of the x86 Ecosystem Advisory Group, and the outcome is that oneDNN becomes the default open-source library for x86 acceleration within PyTorch.

The AMD piece that changes position is ZenDNN, the downstream fork AMD maintained for its own CPUs. Instead of keeping the optimizations separate, AMD is integrating ZenDNN into oneDNN and joining the UXL Foundation as a steering member. Intel brings its work on AI Compute Extensions (ACE), a next-generation x86 instruction set designed to accelerate matrix multiplication — the mathematical operation at the heart of AI workloads. ACE will be integrated into PyTorch through future oneDNN updates.

In practice, two parallel paths become one.

Why it matters for local AI

Until yesterday, if you ran a model on the CPU of an AMD or an Intel machine, you were running it on two different software paths. Each vendor had optimized its own architecture, and the PyTorch community had to maintain both branches. That created fragmentation: a configuration that worked well on one vendor could give different results on the other, and every PyTorch release was a race to keep the two paths aligned.

With oneDNN as the default path, the entry point to CPU optimizations for PyTorch becomes single. An application built once has one path to optimize and maintain, regardless of whether it lands on an AMD or an Intel CPU. For local AI, this touches a specific use case: setups where the CPU is the main engine — a laptop without a dedicated GPU, a mini-PC, or the CPU handling prefill and tokenization while the GPU does the rest. Less fragmentation means fewer surprises when you move from one piece of hardware to another, and a base of optimizations that two vendors push together instead of in competition.

There is a second front worth watching. Local AI lives largely on open models that run on CPU and GPU. When two vendors pool their CPU optimizations, the band of hardware on which an open model is genuinely practical to use gets wider. For the general platform comparison, our article on NVIDIA, AMD and Intel for local AI remains the reference.

How oneDNN works under the hood

oneDNN is a library of primitives: it is not a runtime that runs in place of PyTorch, it is the base on which frameworks build the mathematical operations (matmul, convolutions, activations) so that they exploit the specific instructions of the CPU. The value lies in generating optimized code for the architecture you run on — once for the whole x86 ecosystem instead of in two separate forks.

Matrix multiplication is the operation that dominates inference and training costs. That is what ACE targets: new x86 instructions that accelerate exactly that multiplication, and that will reach PyTorch downstream of oneDNN. The gains are not an optional plugin you install: they enter the standard path.

And the limits

To be honest: this is a CPU story, and for a large part of local AI the GPU remains the main engine. If you have a 24GB or 32GB card, the bottleneck of your setup is VRAM, not the CPU library. oneDNN does not move the numbers for people running on a GPU.

Where the news is direct: if your use case lives on the CPU — small models on CPU, or CPU+GPU where the CPU does the prefill — a common software path optimized by two vendors together is a concrete improvement. And ACE is a story for future chips, not the ones you already have: the new instructions will only become available on hardware that supports them.

Minimal setup

If you are running models on CPU today, the most useful thing is to make sure your PyTorch build uses oneDNN as the default x86 backend, which is now the case by default. There is nothing else to install: it is the path the two vendors are unifying. The comparison of inference engines and their relationship with CPUs remains covered in Ollama vs llama.cpp: under the hood, and the CPU-vs-GPU choice in GPU or CPU: when the CPU is enough.

Sources

• AMD: AMD and Intel collaborate on oneDNN for PyTorch
• Phoronix: Intel and AMD collaborate on PyTorch/oneDNN

In summary

AMD and Intel have combined their x86 optimization work for PyTorch inside oneDNN, the open-source library governed by the UXL. AMD is integrating its ZenDNN fork into oneDNN and joining the board as a steering member; Intel brings the ACE instructions for matrix multiplication. oneDNN becomes the default path for x86 acceleration in PyTorch, which means one software path to optimize and maintain for anyone doing local AI on CPU, instead of two. It is a step against ecosystem fragmentation, not a performance jump for people running on a GPU.

Article generated with AI