一台顶配 Mac 跑视频生成模型，系统显存峰值居然被撑到了 270 GiB。
这不是硬件算力不够，而是纯粹的软件灾难。很多人一直以为 Mac 跑大模型容易卡顿或爆显存，问题出在统一内存带宽或者苹果 GPU 性能不及专用卡。但在最近合并的 PyTorch PR #195368 面前，这个遮羞布被扯了下来。Wan2.2 视频模型在 28-tile 分块解码中调用了 8764 次常数填充，苹果上层框架 MPSGraph 随之引发了驱动内存失控；而在 Qwen-Image-2.1 的图像编辑管线中，时序填充缺陷直接导致特征损坏，画面峰值信噪比一度跌到只有 10.06 dB，甚至在大尺寸 5D 张量下还会静默出现 NaN。
Hugging Face 团队联合社区交出的解决方案非常决绝，不再苦等苹果修补顶层抽象，而是直接绕过 MPSGraph，用底层 Metal 原生算子重写核心路径。
撕掉 MPSGraph 的上层画皮
在 PyTorch 2.15 发布前，MPS 后端的运行机制高度依附于苹果的高阶图编译框架 MPSGraph。这套设计的初衷是替开发者自动处理图优化和硬件调度，但在多维动态张量与高频调用的生成式模型面前，它频繁暴露严重的性能断崖。
最典型的灾难就是填充操作。PR #195368 彻底抛弃了 MPSGraph 的常数填充机制，改写为专用 Metal 算子。改动生效后，Wan2.2 的系统驱动内存峰值从 270.135 GiB 骤降至 8.108 GiB；Qwen-Image-2.1 的编解码重构质量也从残损的 10.06 dB 恢复到与 CPU 完全一致的 29.95 dB。
类似的问题广泛存在于各个核心环节。过去单行向量经过线性层仍然要进入 MPSGraph 走一遍漫长的图逻辑，词表 Softmax 计算更是存在高昂的时延开销。PyTorch 2.15 选择把这些瓶颈挨个切开，直接接到底层 Metal 算子：
- 单行解码方面，专用 GEMV 算子直接连通至
F.linear，在 96 个真实层维度测试中换来 1.23 倍的几何平均加速。 - 高维 Softmax 计算方面，针对 128,256 词表维度的采样操作，单行计算延迟从 57 µs 压缩到了 7 µs，跑出近 8 倍的性能提升。
- 精度支持方面正式上线
float8_e4m3fn张量，搭配原生F.scaled_mm矩阵乘法，显存占用直接砍半。
所谓生态成熟，往往是从开源社区受不了官方抽象层开始的。
61 与 102 之间的现实鸿沟
架构重写带来的直接收益，是混合专家模型（MoE）的推理能力大幅回血。在旧版中，分组矩阵乘法甚至需要把偏移量回传到 CPU 循环调度；而在 2.15 里，分组偏移计算完全留在了 GPU 内部。
在 M3 Ultra 硬件上，开启 torch.compile 后，Qwen3.6-35B-A3B 的解码速率从 9.4 跃升至 61.3 tokens/s，提速达到 6.5 倍；小尺寸的 LFM2.5-8B-A1B 也从 23.6 提至 123.6 tokens/s。
但这并不意味着 PyTorch 已经成为 Mac 纯文本推理的效率最优解。
| 推理框架 / 引擎 | 量化精度 | 平台硬件 | Qwen3.6-35B-A3B 吞吐 |
|---|---|---|---|
| PyTorch 2.15 (RC1) | BF16 (torch.compile) | M3 Ultra | 61.3 tok/s |
| llama.cpp | Q8_0 | M3 Ultra | 81.2 tok/s |
| MLX (oMLX) | 8-bit | M3 Ultra | 90.3 tok/s |
| MLX (Alis) | 4-bit | M3 Ultra | 102.1 tok/s |
横向对比会发现，即使 PyTorch 2.15 跑出 61.3 tok/s 的断崖式飞跃，它距离苹果自研 MLX 的 102.1 tok/s 仍有超过 40% 的速度差距，也不及 llama.cpp 的 81.2 tok/s。
- 结论.PyTorch 的优势不在于纯文本生成的极限吞吐，而在于它横跨多模态、微调训练与 Diffusers、ComfyUI 的通用生产管线。你不需要把权重转来转去，就能在一套标准生态里完成开发。
升级的门槛与断代代价
这场性能翻盘是有明确代价的。目前 PyTorch 2.15 RC1 已经发布，正式 GA 版本定于 2026 年 10 月 28 日上线。但升级这张门票并不便宜，PyTorch 官方正式移除了对 Python 3.10 的 wheel 预编译支持，要求环境必须在 Python 3.11 及以上；与此同时，MPS 后端要求系统至少升级到 macOS 15。
- 风险.对于大量依赖旧版本 Conda 虚拟环境、或固守稳定系统版本的端侧开发者而言，环境升级意味着潜在的依赖断裂；苹果系统版本与社区实现的脱节，也让老设备被挡在了性能修复的门外。
从 270 GiB 压到 8 GiB，本质上是一场逆向工程式的胜利。苹果构建的高级图框架在大模型的高维算子下碰了壁，开源社区不得不捡起最底层的 Metal 重新铺路。按照目前规划，PyTorch 2.16 还将进一步把注意力机制完全迁移至原生 Metal。
这场重构不是锦上添花，而是一场亡羊补牢的生存自救。统一内存从来不是平白兑现的算力奇迹，没有贴着硬件写的每一行底层代码，再宏大的架构叙事，也装不下一次溢出的填充循环。