Evidence at a glance
The Point Is More Than a Benchmark
The PyTorch team at Hugging Face expanded the MPS backend for Apple silicon in PyTorch 2.15, aiming to make Macs more capable places to run and train PyTorch models. The update spans language, image, video, and training workloads, adding new operator paths, FP8 support, and more Python-level control over MPS streams and event timing.
These changes target familiar sources of friction in local model execution: unsupported operators, sudden performance cliffs, and unexpectedly high memory use. The team says it used real models from the Hugging Face Hub to identify gaps, then worked with PyTorch maintainers and community contributors to fix them. One recurring approach is replacing selected MPSGraph paths with dedicated Metal kernels. The release is therefore notable not only for how much faster some workloads become, but for its focus on bottlenecks found in real workflows.
Decode Optimizations Affect Every New Token
Large language model inference has a prefill phase and a step-by-step decode phase. PyTorch 2.15 adds specialized matrix-vector kernels for single-row linear layers and makes vocabulary softmax about eight times faster. These changes target operations repeated during decoding, so they can reduce the wait for each new token without changing the model architecture. Dense and MoE models may both benefit, although the result depends on the workload and execution path.
The MoE results show the potential of specialized paths. On an M3 Ultra with torch.compile, Qwen3.6-35B-A3B rises from 9.4 tokens per second in PyTorch 2.14 to 61.3 in 2.15, while LFM2.5-8B-A1B rises from 23.6 to 123.6. The post attributes the gains to native grouped matrix multiplication and a dedicated decode path, fewer GPU-to-CPU synchronizations, and faster top-k routing. These are comparisons tied to specified hardware and configuration, not multipliers that every Mac and model should be expected to reproduce.
Memory Peaks and Correctness Are Part of Performance
Video generation exposes a limit that benchmark scores can obscure: a task may be difficult to complete because of memory pressure, not because it runs too slowly. The post reports that Wan2.2 tiled VAE video decoding now peaks at about 8 GiB of driver memory, down from 270 GiB. That figure describes the reported peak for this workload, not the memory requirement of every video task. Still, it shows how fixing a particular operator path can determine whether a job is feasible locally, not just how long it takes.
Correctness is just as important. In PyTorch 2.14, the MPS VAE encoder for Qwen-Image-2.1 silently corrupted images, affecting image-editing workflows. After a padding change in 2.15, an encode-decode round trip reached 29.95 dB PSNR against the CPU reference, up from 10.06 dB. Teams using ComfyUI or similar tools should include output-quality regressions in upgrade checks rather than judging a release by throughput and memory alone. An optimization is not complete if the result cannot be trusted.
FP8 Saves Storage, Not Compatibility Work
PyTorch 2.15 adds MPS support for torch.float8_e4m3fn tensors and scaled matrix multiplication through F.scaled_mm, with tensorwise and rowwise scaling. FP8 uses one byte per value, half the storage of BF16, giving memory-constrained Mac workloads another way to represent weights more compactly. That does not mean every model can switch to FP8 directly, or that every operator is automatically supported.
Evaluation should cover the model's weight format, quantization or scaling method, operator coverage, and output quality. The post frames other supported FP8 operations in relation to operations already supported on CUDA and CPU, which is a reminder that support has boundaries. The ability to create a tensor or run a matrix multiplication does not establish that an entire inference pipeline is compatible. For deployment teams, FP8 is a memory-saving option to test, not a default switch that removes the need for validation.
Check System Requirements and Workloads Before Upgrading
The release has clear environment requirements: MPS needs an Apple silicon Mac running macOS 15 or later, and PyTorch 2.15 requires Python 3.11 or later. For teams using Macs in local inference or creative-tool workflows, checking the operating system, Python environment, and actual model paths is more useful than looking at the version number alone. The MPS availability check also gives clearer reasons when the OS is too old or no Metal GPU is available.
A safer upgrade decision is to compare workloads the team actually depends on, tracking decode speed, memory peaks, and output quality. Check separately whether critical paths such as MoE inference, video decoding, or image editing benefit. PyTorch 2.15 shows MPS moving from general graph-based execution toward more dedicated Metal implementations, but the gains still depend on the device, model, and operator mix. Local execution on a Mac is becoming more practical, not a universal replacement that can be adopted without testing.