Hugging Face 报告称 PyTorch 2.15 为 Apple Silicon Mac 的 MPS 后端带来多项工程改进，包括 FP8 支持、为解码阶段优化的 Metal 内核（尤其是对 MoE 模型的 grouped matmul），以及显著降低视频 VAE 解码的驱动内存峰值。这些改动在特定硬件和测试条件下展现出高幅度性能提升，但最终效果仍受模型、量化、上下文长度和系统配置影响。
Hugging Face PyTorch 团队表示，PyTorch 2.15 将为 Apple Silicon Mac 的 MPS 后端带来一组重要改进，包括 FP8 支持、更快的语言模型解码、更多面向 Metal 的专用内核，以及显著降低视频解码的内存占用。
在 Hugging Face 于 2026 年 10 月 20 日发布的技术文章《MPS in PyTorch 2.15》中，团队称，这些改动来自对 Hugging Face Hub 上真实语言、图像和视频模型的测试，以及与 PyTorch 维护者和社区贡献者的协作。文章同时预告了 PyTorch 2.16 在 MPS 上进一步减少 MPSGraph 使用、加速注意力计算的计划。
不过，文中的性能数字主要是 Hugging Face 团队在特定硬件、模型和编译条件下测得的结果，并不等同于所有 Mac 或所有工作负载都能获得相同提升。
FP8 首次进入 MPS 路径
PyTorch 2.15 为 MPS 增加了 torch.float8_e4m3fn 张量支持。FP8 每个数值占用一个字节，存储空间约为 BF16 的一半。Hugging Face 表示，用户可以通过 torch.nn.functional.scaled_mm 在 GPU 上直接执行带缩放的矩阵乘法，并支持逐张量和逐行缩放方式。
这项变化的意义在于，Apple Silicon 的统一内存虽然避免了传统独立显卡的数据搬运，但模型权重、缓存和中间张量仍然会共同争夺有限的内存空间。更低精度的权重和计算路径，有望让部分模型在本地设备上获得更大的运行余量。
FP8 并不意味着模型质量可以完全不受影响。实际效果仍取决于模型是否适配该数据类型、缩放策略、算子覆盖范围以及具体任务。PyTorch 2.15 的意义首先是提供一条可用的 MPS 计算路径，而不是保证所有模型自动获得同等收益。
MoE 模型解码速度成为最大亮点
Hugging Face 把语言模型解码列为 PyTorch 2.15 的重点改进之一。对于生成阶段的每个新 token，输入通常是一行数据，因此矩阵乘法会转化为大量矩阵向量运算。2.15 将 MPS 的 GEMV 内核接入 F.linear，并为适合的偏置加法进行融合。
对于混合专家模型（Mixture of Experts，MoE），新版本加入了原生 grouped matmul 实现。此前，MPS 的 grouped matmul 会将专家分组的偏移量复制到 CPU，再循环处理不同专家；新路径则让 Metal 内核直接在 GPU 上读取这些偏移量，并针对解码阶段常见的小分组提供专门内核。
Hugging Face 在 M3 Ultra 上使用 torch.compile 测试称，Qwen3.6-35B-A3B 的生成速度从 PyTorch 2.14 的每秒 9.4 个 token 提升到 61.3 个 token；LFM2.5-8B-A1B 则从 23.6 个 token 提升到 123.6 个 token。以 2.14 为基准，团队将 MoE 模型的整体提升概括为约 5 至 6.5 倍。
这些数字需要结合测试条件理解：它们来自特定型号的 M3 Ultra、特定模型配置和编译路径。不同内存容量、上下文长度、量化方式、软件版本以及是否启用 torch.compile，都可能改变结果。
Softmax 和线性层也针对解码阶段优化
PyTorch 2.15 不只针对 MoE。对于密集模型，单行线性层可以使用专用矩阵向量内核。Hugging Face 对 96 种来自真实模型的 BF16 层形状进行测试后，给出的几何平均加速约为 1.23 倍；较小的投影层改善更明显，而已经接近内存带宽上限的大型层变化较小。
词表上的 softmax 和 log-softmax 也改用专门的 Metal 内核。文章给出的一个例子是：在形状为 [1, 128256] 的 FP32 logits 上，softmax 的耗时从约 57 微秒降至 7 微秒，约为 8 倍提升。对于依赖逐 token 采样的语言模型，这类优化可能直接影响响应速度，但它仍然只是整个生成链路中的一个环节。
视频 VAE 解码的驱动内存峰值大幅下降
对视频生成用户而言，内存变化可能比单项算子速度更实际。Hugging Face 以 Wan2.2 的视频 VAE 解码为例，指出此前 MPSGraph 的 constant padding 路径会造成异常的驱动内存增长。
在一个包含 28 个 tile、需要调用 8,764 次 padding 的完整解码过程中，团队测得的总驱动内存峰值从约 270.135 GiB 降至 8.108 GiB。当前张量分配峰值则从 4.422 GiB 降至 4.095 GiB，分配器保留峰值均为约 8.070 GiB。
这一区别值得注意：270 GiB 是驱动内存峰值，不代表视频模型本身拥有或实际保存了 270 GiB 的模型权重。它反映的是旧路径在反复执行 padding 时的内存管理问题。新版本把 constant padding 转移到 Metal 内核后，才使这类视频解码工作负载更接近普通 Mac 能够承受的范围。
Hugging Face 还表示，Qwen-Image-2.1 在 2.14 上曾出现 MPS VAE 编码器静默破坏图像的问题。相关 padding 改动后，编码—解码往返结果与 CPU 的一致性测试从 10.06 dB PSNR 提升至 29.95 dB。这里的结果同样是特定测试条件下的指标，不能简单理解为所有图像编辑任务的质量都达到同一水平。
MPS 正在从 MPSGraph 迁移到更直接的 Metal 内核
PyTorch 的 MPS 后端长期依赖 MPSGraph 和一组针对 Metal 调整的内核。Hugging Face 团队在文章中把 PyTorch 2.15 描述为继续将常用操作从 MPSGraph 迁移到专用 Metal 内核的版本。
新增或改进的路径包括 conv1d 前向计算、constant、reflection 和 replication padding、dropout、上采样反向计算，以及 channels-last 的 conv2d 反向计算。在线性代数方面，complex64 的 LU 分解、LU 求解和三角求解可以直接在 MPS 上运行；小矩阵求逆、QR 分解以及部分 SVD 边界情况也获得改进。
开发者还可以从 Python 公开使用 MPS stream。torch.mps.Stream、torch.mps.stream 上下文管理器和 Tensor.record_stream 提供了更直接的并发和生命周期控制。对于需要在不同任务之间安排 GPU 工作的本地推理或训练应用，这比完全依赖默认流更灵活。
新版本要求 macOS 15 和 Python 3.11
Hugging Face 文章列出的 PyTorch 2.15 MPS 要求包括 Apple Silicon Mac、macOS 15 或更高版本，以及 Python 3.11 或更高版本。文章还给出了在独立环境中尝试版本候选构建的安装方式：
uv pip install torch==2.15.0 --index-url https://download.pytorch.org/whl/test/cpu
这条命令对应的是测试源中的版本候选路径。用户在生产环境中使用前，仍应以 PyTorch 官方发布页面和兼容性矩阵为准，并确认所使用的 torchvision、torchaudio 及其他依赖是否匹配。
现有 Hugging Face 文档也提醒，MPS 仍存在算子覆盖范围、统一内存压力和图缓存增长等限制。对于 Transformers 用户，整个模型通常需要适配设备的统一内存；不支持的操作可能需要回退到 CPU。对于 Diffusers 工作负载，注意力切片、批处理方式和图像尺寸仍会明显影响实际表现。
PyTorch 2.16 将进一步减少 MPSGraph 依赖
Hugging Face 还披露了 PyTorch 2.16 的早期进展，但明确表示部分改动仍在主分支或审查中，最终细节可能变化。
其中一项改进是每 16 个内核提交一次 command buffer，使 GPU 可以在 CPU 继续编码后续内核时提前工作。团队在上下文长度为 2,048、使用编译 BF16 解码的测试中，称 LFM2.5-8B-A1B 从每秒 108.8 个 token 提升至 126 个，Qwen3.6-35B-A3B 从 52.9 个提升至 62.8 个。
另一项计划是让 scaled dot-product attention 完全运行在 Metal 内核上。文章给出的早期测试显示，在 M5 Pro 上，某些 grouped-query attention 解码场景的耗时可从 465 微秒降至 65 微秒，4K×4K 的 prefill 场景则从 42 毫秒降至 6 毫秒。但这些数字属于开发中的测试结果，不能视为 PyTorch 2.16 的最终承诺。
Mac 本地 AI 的瓶颈正在从“能否运行”转向“能否稳定运行”
Apple Silicon 的统一内存和 Metal GPU 让 Mac 成为本地模型实验的重要平台，但过去 MPS 的体验经常受到缺失算子、性能断崖、CPU 回退和内存增长影响。PyTorch 2.15 的变化，集中处理的正是这些工程层面的摩擦：让更多操作留在 GPU 上，让常见解码路径少一些 CPU—GPU 同步，并让视频和图像工作负载更可控。
这也解释了为什么 Hugging Face 近期把工作重点放在模型真实运行而不只是单项基准上。此前，Hugging Face 将 Transformers 接入 llama.cpp 的 GGUF 量化模型时，首批优化也聚焦 Apple Silicon 的 MPS 路径；这次 PyTorch 后端更新则从算子、内存和调度层面继续补齐本地推理基础设施。
另一方面，苹果近期也把本地 AI 计算作为 M6 与 M5 Ultra 桌面芯片的重要卖点。硬件提供更大的统一内存和更高的带宽只是第一步；模型格式、推理框架、内核覆盖、缓存管理和应用层工具调用，才决定本地 Agent 是否能够长期稳定运行。
因此，PyTorch 2.15 更准确的定位不是让 Mac 一夜之间替代高端 GPU 服务器，而是降低在 Mac 上运行真实模型的工程成本。对于开发者和个人用户，它可能让更多本地语言、图像和视频工作流从“可以试验”走向“可以持续使用”；而最终提升幅度，仍需要在正式版本、不同芯片和独立测试中进一步验证。
来源：