PyTorch 2.15 on Mac: MoE decode 5–6.5× faster in Hugging Face's headline, but their own chart shows 1.3×. Read the baseline before you upgrade
FP8 tensors, 8× faster softmax and a 270 GiB to 8 GiB video-decode fix are real. Which speedup you get depends on what you compare against.
MoE models decode 5–6.5× faster than in 2.14: Qwen3.6-35B-A3B goes from 9.4 to 61.3 tokens/s on an M3 Ultra, thanks to a native grouped matmul with a dedicated decoding path, fewer GPU-CPU syncs and faster top-k routing.
Comprehensive take
If you run MoE or video models on a Mac, test the 2.15 release candidate on your own model and compare against your current version, not the headline figure.
Use cases
Local MoE chat and coding models
Grouped matmul on the GPU removes a CPU loop; the post reports Qwen3.6-35B-A3B at 61.3 tokens/s on an M3 Ultra versus 9.4 on 2.14.
Video generation on a Mac
Peak driver memory for Wan2.2 tiled VAE decode falls from about 270 GiB to 8 GiB.
FP8 weight storage
float8_e4m3fn tensors use half the memory of BF16 and support scaled matmul on MPS.
Specs
| MoE decode, Qwen3.6-35B-A3B (M3 Ultra, torch.compile) | 9.4 to 61.3 tokens/s vs 2.14 source |
|---|---|
| MoE small-group kernel gain | 38.7 to 51.7 tokens/s at 512 context source |
| FP32 softmax, 128,256 vocab row | 57 µs to 7 µs source |
| Wan2.2 VAE decode peak memory | 270.135 GiB to 8.108 GiB source |
| Requirements | macOS 15+, Python 3.11+ source |
Insights
- Axion reading: the 5–6.5× and ~1.3× figures likely measure different baselines; the post does not say so explicitly.
- Axion note: all benchmarks are from the Hugging Face team on an M3 Ultra and are not independently reproduced.
What shipped
The PyTorch team at Hugging Face published its walkthrough of the MPS (Apple GPU) backend in PyTorch 2.15 on 20 October 2026, and the post links the individual pull requests. The headline additions are FP8 (`float8_e4m3fn`) tensors that take half the memory of BF16, native grouped matmul for mixture-of-experts layers, and a run of operations moved from MPSGraph to dedicated Metal kernels.
The numbers, and a discrepancy to know about
The summary claims 5–6.5× faster MoE decoding than 2.14: Qwen3.6-35B-A3B from 9.4 to 61.3 tokens/s and LFM2.5-8B-A1B from 23.6 to 123.6 tokens/s on an M3 Ultra with torch.compile. Further down, the chart for the dedicated small-group decoding kernel shows a much smaller gain: Qwen3.6-35B-A3B from 38.7 to 51.7 tokens/s at 512 context, and 36.8 to 48.7 at 2048, roughly 1.3×. These are not necessarily contradictory. The larger figure appears to be the whole 2.14-to-2.15 change, the smaller one a single kernel on top of the new grouped matmul. But the post's text does not spell out the baseline for the headline, so the safe reading is: expect a large jump if your MoE model hit the old CPU-looping grouped matmul, and about a third more if you were already on a recent path.
Other measured results from the post: a 1.23× geometric-mean speedup for single-row linear layers across 96 BF16 shapes; FP32 softmax over a 128,256-entry row dropping from 57 µs to 7 µs (about 8×); and Wan2.2's tiled video VAE decode falling from a 270.135 GiB peak driver-memory footprint to 8.108 GiB. A padding fix also repairs the Qwen-Image-2.1 VAE encoder, with round-trip PSNR against CPU rising from 10.06 dB to 29.95 dB.
Who should upgrade
Anyone running local MoE models or video generation on Apple silicon has the strongest case; the memory fix alone can turn an impossible job into a possible one. Two requirements matter: MPS now needs macOS 15 or later, and PyTorch 2.15 needs Python 3.11 or later. The post ends by asking readers to try the release candidate, so wait for the final release for production use. Benchmarks are from Hugging Face's own team on an M3 Ultra, a high-end chip; expect smaller absolute numbers on laptops.
What is next
The post previews 2.16: committing the command buffer every 16 kernels (+16% to +19% on two MoE models, +4% on a 27B dense model), and attention running entirely on Metal. Those are previews, not shipped features.