Bar chart of MoE decoding throughput on M3 Ultra with torch.compile. Qwen3.6-35B-A3B goes from 38.7 to 51.7 tokens/s at context 512 and 36.8 to 48.7 at context 2048; LFM2.5-8B-A1B goes from 77.1 to 103.2 and 74.9 to 98.7 tokens/s.
Bar chart of MoE decoding throughput on M3 Ultra with torch.compile. Qwen3.6-35B-A3B goes from 38.7 to 51.7 tokens/s at context 512 and 36.8 to 48.7 at context 查看原始材料 ↗
Bar chart of FP32 softmax time for a single row of logits at five vocabulary sizes from 128,256 to 201,088. MPSGraph takes 50 to 74 microseconds; the Metal kernel takes 7 to 10 microseconds, a 7.1x to 8.0x speedup.
Bar chart of FP32 softmax time for a single row of logits at five vocabulary sizes from 128,256 to 201,088. MPSGraph takes 50 to 74 microseconds; the Metal kern 查看原始材料 ↗
Stacked bar chart of peak driver memory during the Wan2.2 tiled VAE decode. With MPSGraph padding, 8.07 GiB of allocator-reserved memory plus 262 GiB outside the allocator gives 270.1 GiB; with Metal padding the total is 8.1 GiB.
Stacked bar chart of peak driver memory during the Wan2.2 tiled VAE decode. With MPSGraph padding, 8.07 GiB of allocator-reserved memory plus 262 GiB outside th 查看原始材料 ↗

先看证据

MoE解码较2.14宣称快5–6.5倍。关键事实
9.4升至61.3 tokens/s。M3 Ultra上Qwen3.6-35B-A3B
23.6升至123.6 tokens/s。M3 Ultra上LFM2.5-8B-A1B
文中另称MoE解码吞吐约提升1.3倍。关键事实
96种BF16层形状的线性层几何均值提速1.23倍。关键事实
57µs降至7µs，约快8倍。FP32词表softmax

更新的重点不只是跑分

Hugging Face 的 PyTorch 团队在 PyTorch 2.15 中扩展了面向 Apple 芯片的 MPS 后端，目标是让 Mac 更适合运行和训练 PyTorch 模型。更新覆盖语言、图像、视频和训练工作负载，包含新的算子路径、FP8 支持，以及 Python 侧对 MPS 执行流和事件计时的更多控制。

这组变化回应的是本地运行模型时常见的几类摩擦：算子不支持、性能突然掉档，以及内存用量异常增长。团队称，他们用 Hugging Face Hub 上的真实模型寻找短板，再与 PyTorch 维护者和社区贡献者一起修复；其中一个反复出现的做法，是用专用 Metal 内核替代部分 MPSGraph 路径。因而，2.15值得读的地方不只是“快了多少”，还在于它开始针对真实工作流中的瓶颈逐个动手。

解码阶段的算子优化，直接影响每个新token

大语言模型推理包含预填充和逐token解码两个阶段。2.15为单行线性层加入专用矩阵向量内核，并让词表上的softmax快约8倍；这类改动瞄准的是解码过程中反复执行的步骤，因此不需要改变模型结构，也可能缩短用户等待每个新token的时间。密集模型和MoE模型都可能受益，但具体收益取决于工作负载和执行路径。

MoE结果最能说明专用路径的潜力：在M3 Ultra上使用torch.compile，Qwen3.6-35B-A3B从PyTorch 2.14的9.4 tokens/s提升到2.15的61.3 tokens/s，LFM2.5-8B-A1B则从23.6提升到123.6 tokens/s。材料将提升归因于原生分组矩阵乘法及专门的解码路径、更少的GPU与CPU同步，以及更快的top-k路由。它们是有明确设备和配置的对照数字，不应直接当成所有Mac、所有模型都能复现的倍数。

内存峰值和结果正确性也是性能

视频生成展示了另一个常被跑分遮住的限制：任务可能不是算得太慢，而是内存压力让它难以完成。材料称，Wan2.2使用分块VAE解码视频时，驱动内存峰值从此前的270 GiB降至约8 GiB。这个数字描述的是该工作负载报告的峰值，不等于所有视频任务的内存需求；但它说明，修好特定算子路径可能改变任务能否在本地运行，而不只是改变运行时间。

正确性同样不是附带细节。Qwen-Image-2.1的VAE编码器在2.14的MPS上会静默损坏图像，影响图像编辑工作流；2.15中的padding改动后，编码再解码的结果与CPU对照达到29.95 dB PSNR，原先是10.06 dB。对使用ComfyUI或类似工具的团队，这类修复意味着需要把质量回归纳入升级验证，不能只看吞吐量和显存。性能优化只有在输出仍然可信时才算完成。

FP8省下的是存储空间，不是兼容性义务

2.15让MPS支持torch.float8_e4m3fn张量，并可通过F.scaled_mm进行缩放矩阵乘法，支持tensorwise和rowwise scaling。FP8每个值占一个字节，存储空间是BF16的一半，因此对Mac上显存紧张的模型，权重表示多了一种节省空间的选择。它并不意味着任意模型都能直接改用FP8，也不意味着所有算子都自动获得支持。

实际评估时，团队需要同时核对模型权重格式、量化或缩放方式、算子覆盖和输出质量。材料提到，FP8相关的其他操作在MPS上以CUDA和CPU已有支持的操作为范围，这本身就提示了支持边界；不能仅凭张量能创建或矩阵乘法能运行，就推断完整推理链路已经兼容。对部署者而言，FP8是一个值得测试的内存选项，而不是可以跳过验证的默认开关。

升级前先核对系统边界和工作负载

这次更新有明确的环境门槛：MPS需要Apple silicon Mac和macOS 15或更高版本，PyTorch 2.15需要Python 3.11或更高版本。团队若把Mac作为本地推理或创作工具链的一部分，先确认操作系统、Python环境和实际使用的模型路径，比只查看版本号更有用。MPS可用性检查也会更明确地说明系统过旧或缺少Metal GPU等原因。

更稳妥的判断方式，是挑选自己确实依赖的工作负载做升级对照：记录解码速度、内存峰值和输出质量，并分别检查MoE、视频解码或图像编辑等关键路径是否受益。2.15显示，MPS正从通用图计算路径转向更多专用Metal实现，但收益仍由设备、模型和算子组合决定。Mac本地运行因此变得更实用，却还不能被当作无需验证的通用替代方案。