# PyTorch 2.15 MPS Preview: FP8, Faster Mac Models and Memory Fixes

The release candidate improves important Apple silicon workloads, but the benchmark gains need to be read alongside its upgrade requirements.

By Paras Madan | 2026-10-20


Hugging Face's PyTorch team detailed the MPS improvements coming in PyTorch 2.15 on October 20: FP8 support, faster local-model execution and fixes for expensive video-memory use. These changes are available to test in a release candidate. The stable release is still scheduled for October 28.

For developers working on Apple silicon, this is worth watching because the improvements reach several different parts of a model pipeline. A faster token loop helps interactive generation, while a memory fix can decide whether a video workflow runs at all. Those benefits should be evaluated separately.

## PyTorch 2.15 is still a release candidate

The [official release schedule and compatibility matrix](https://github.com/pytorch/pytorch/blob/release/2.15/RELEASE.md) lists October 28 for PyTorch 2.15. As of October 20, the Hugging Face guide points readers to the test package index for a release candidate, rather than presenting it as a completed stable rollout.

The minimum Python version also moves from 3.10 in PyTorch 2.14 to 3.11 in 2.15. The MPS guide requires an Apple silicon Mac running macOS 15 or later. Check those requirements before changing an existing environment, especially if a desktop application manages its own Python installation.

I would test the candidate in a separate environment with the same models, inputs and extensions used in normal work. That gives a useful comparison without making an entire workflow depend on a prerelease package.

## FP8 weights become more practical on MPS

PyTorch's [FP8 implementation](https://github.com/pytorch/pytorch/pull/194074) adds the float8_e4m3fn data type to MPS. FP8 stores each value in one byte, compared with two bytes for FP16 or BF16. The release also supports scaled matrix multiplication for these tensors.

That storage difference can matter when model weights consume much of a Mac's unified memory. It does not imply that an application's total memory use will be cut in half: activations, caches, temporary buffers and other components still contribute to the total.

Quantization also needs numerical checks. The useful question is whether a model fits and produces acceptable results in the intended workflow, rather than whether one tensor format is smaller on paper. Existing software must actually use the supported FP8 path to benefit.

## Why mixture-of-experts execution improves

The [native grouped-matrix implementation](https://github.com/pytorch/pytorch/pull/194933) addresses an awkward part of mixture-of-experts execution. Different experts receive different amounts of work, and deciding how to dispatch it can introduce synchronization between the CPU and GPU.

The implementation handles group offsets on the GPU and includes different kernel paths for supported hardware and layouts. This reduces the need to copy information back to the CPU before proceeding. It is a concrete example of why a model can become faster without changing its weights.

Hugging Face reports substantial whole-release decoding gains on an M3 Ultra using torch.compile. Those are measurements from a particular setup, not a promised speed increase for every Mac. Dense models, different shapes and different compilation settings can expose different bottlenecks.

## Video memory and image correctness matter too

The [October 20 technical walkthrough](https://huggingface.co/blog/mps-pytorch-2-15) reports that a Wan2.2 tiled VAE decode fell from roughly 270 GiB to 8 GiB in peak driver memory after constant padding moved to Metal. This is a specific video-decoding measurement. It is not a claim that every video-generation pipeline now fits into 8 GiB.

There is also a correctness fix behind the performance story. A [ComfyUI issue](https://github.com/Comfy-Org/ComfyUI/issues/16433) documents degraded Qwen-Image-2.1 VAE encode/decode results on MPS with PyTorch 2.14. A contributor reports that the 2.15 development build matches the CPU result in their comparison.

That distinction matters when troubleshooting. If an image-editing workflow produces plausible but damaged output, changing the prompt may achieve little. Testing the same VAE round trip on another backend can help separate a model limitation from an execution problem.

## What to check before upgrading

Start with one representative language, image or video workload and record output quality, peak memory and elapsed time. Keep the checkpoint, precision and generation settings unchanged between runs, then test any new FP8 path separately.

For production work, wait for the stable release and confirm that the surrounding application supports it. For experimentation, the candidate gives Mac developers a way to identify which improvements their workloads actually use. The most valuable result may be a workflow becoming reliable enough to keep local, even when the headline speedup does not apply.

I'm Paras. I work at the intersection of AI, engineering and distribution.

If you're building developer tools and need help explaining technical changes in content developers can use, I'd be happy to work with you.

[Book a 30-minute call](https://cal.com/paras-madan/30min).