By ByteBot
AMD just agreed to contribute its ZenDNN work to a library that started life inside Intel. That sentence would have sounded absurd three years ago. On October 20, 2026, AMD and Intel announced they are unifying PyTorch’s x86 CPU backend around oneDNN — one library, two chip vendors, one optimized upstream. If you run PyTorch inference on any x86 CPU, the era of maintaining vendor-specific backends is ending.
Why Two Libraries Existed
oneDNN started as Intel’s MKL-DNN, a set of hand-tuned deep learning primitives — convolutions, matrix multiplies, activation functions — optimized for Intel silicon. AMD’s answer was ZenDNN: a downstream fork that kept the oneDNN API but swapped in kernels written specifically for Zen cores, squeezing out the performance Intel’s tuning left on the table for AMD hardware.
ZenTorch, the companion PyTorch plugin, intercepted the computation graph and applied AMD-specific transformations before execution. For ML engineers running AMD EPYC servers, the setup wasn’t optional — without it, you left significant performance on the floor. AMD benchmarks showed up to 4.5x throughput gains for llama.cpp on EPYC with ZenDNN enabled.
The cost was fragmentation. Mixed x86 fleets meant conditional code paths. Upstream contributions were complicated by the fork. Developers who just wanted to run inference on x86 didn’t need two mental models for the same operation.
What Changed on October 20
AMD is folding its ZenDNN kernel optimizations into oneDNN upstream and joining the UXL Foundation as a Steering Member. The UXL Foundation has governed oneDNN since September 2023 under the Linux Foundation. AMD’s seat at the table is governance, not just code contribution — that distinction matters for long-term roadmap influence.
Both companies have named oneDNN the default open-source library for x86 acceleration within PyTorch. The end state: oneDNN auto-dispatches to Zen-optimized kernels on AMD hardware and Intel-optimized kernels on Intel hardware — same API, no vendor plugin required. Intel’s Jeff McVeigh was direct about the goal: “Developers shouldn’t need separate software paths for x86 CPUs.”
What You Should Do Now
The announcement is directional. No timeline has been given for the first merged ZenDNN code paths to land in oneDNN, and no migration guide has been published yet. Here is the tiered read based on your current setup:
- Intel CPU users: Nothing changes. You’ve been on oneDNN since day one.
- AMD CPU users with ZenTorch: Keep your setup. ZenDNN 5.x is still maintained. When oneDNN absorbs the Zen-specific kernels, the plugin becomes redundant — but that hasn’t happened yet.
- Mixed x86 fleet users: This is your long-term win. Watch for oneDNN to absorb AMD’s gains, then you can drop the conditional backend logic entirely.
The code change, when it ships, looks like this:
# Before: AMD path requires explicit plugin
import zentorch
model = load_model()
output = model(input)
# After: single path across all x86 (once ZenDNN kernels land in oneDNN)
import torch
model = model.to(memory_format=torch.channels_last)
output = model(input) # oneDNN auto-dispatches to Zen or Intel kernelsThe Hardware Unification Is Next
AMD and Intel are also co-developing AI Compute Extensions (ACE), a new x86 instruction set targeting matrix multiply acceleration for quantized model inference. ACE slots into the existing AVX10 register file — the same registers you already use — which means no new ABI to adopt. oneDNN is the planned delivery vehicle for ACE within PyTorch.
The software unification announced today is not incidental to ACE. It sets up a coherent story for when ACE hardware ships: one library, optimized for both vendors, with hardware acceleration baked in from both sides of the aisle.
The Real Subtext
This is not corporate altruism. AMD ROCm has struggled for years to dent CUDA’s GPU dominance. Meanwhile, CPU inference has become a legitimate production option — 15 to 25 tokens per second for 8B models on modern x86 server CPUs, at roughly 6.7 times lower cost per million tokens than cloud GPU inference. A fragmented CPU backend undercuts that pitch. A unified one doesn’t.
AMD and Intel together own effectively the entire enterprise x86 server market. When they agree on a software stack, it becomes the standard. For anyone building CPU inference pipelines or maintaining mixed x86 fleets, this announcement matters — not because you need to act today, but because the path just got significantly simpler.
