写这篇文章的起因很简单换到 Mac 上之后很长一段时间我都默认“机器学习 GPU 加速”是带独立显卡的 Windows 笔记本专属玩法。直到我意识到Mac 的 GPU 其实一直都可以直接参与 Machine Learning 训练和推理只是主流教程几乎全在围着 CUDA 打转没人把镜头对准这一侧。这篇文章我就把在 Mac 上让机器学习任务真正吃到 GPU 红利这条路从头到尾讲清楚有哪些路径、怎么配置、实测提升多少以及那些文档里不会写、只有自己踩过才会懂的坑。1. 先搞清楚Mac 上的 GPU 加速到底有哪几条路1.1 不是所有“GPU 加速”都一回事很多人第一次跑torch.device(cuda)失败之后就默认 Mac 不支持 GPU 计算。这句话对了一半。Mac 不是不支持 GPU而是它不叫 CUDA也不走“独立显存”那套架构。M 系列芯片把 CPU、GPU 甚至神经网络引擎塞进了同一颗 SoC共享一块大的统一内存。换句话说CPU 和 GPU 看到的其实是同一份内存数据。这跟传统独显那种“GPU 有自己的显存数据要先从内存搬到显存”完全不同。用生活类比来说CUDA 时代的搬运模式是两间独立房间之间送快递数据先打包再搬运Mac 的统一内存则是几个人合租大平层CPU 写完数据GPU 直接扭头就能开始算省掉了一大段来回拷贝的时间。这个差异带来的直接好处是只要你的 PyTorch Tensor 创建在正确设备上GPU 就能直接访问它。代价则是所有为 CUDA 写的代码、工具链、性能调优经验在 Mac 上都不能直接套用。1.2 三条主流路径的适用边界在 Mac 上做机器学习加速实际能摸到的路大致有四条PyTorch 的 MPS 后端专门面向以 PyTorch 为主的训练与推理场景把算子调度到 Metal 层的 GPU 执行。TensorFlow 的 Metal GPU 插件TensorFlow 生态专用的加速通道日常用 TensorFlow 做实验可以走这里。Core ML 体系更偏向部署模型经过转换后由系统统一调度 CPU、GPU、神经网络引擎是生产环境的首选。MLX 这类面向统一内存的新框架改造成本低、API 贴近 NumPy在 M 系列芯片上训练小模型体验很好生态还在成长中。此外大量开源推理引擎默认就带 Metal 后端很多本地大模型推理工具跑起来飞快底层靠的也是同一套 GPU 加速管线。下面这张表可以帮你快速对号入座路径适用场景上手难度优势PyTorch MPS本地训练、调参、跑实验低只需改设备字符串代码改动小TensorFlow MetalTF 生态训练中对 TF 算子支持较全Core MLApp 内推理、低延迟部署高同时吃 GPU 和神经引擎功耗表现好MLX小规模实验、研究原型低语法简洁统一内存利用充分推理引擎 Metal 后端本地跑大模型低量化推理速度快开箱即用1.3 一个更直接的选型直觉如果你的核心诉求是“在自己的 Mac 上把模型训练起来”优先学 MPS这是性价比最高的入口如果你想做的是“把一个训练好的模型塞进 App 或实现低延迟推理”尽早接触 Core ML 才是正确方向如果你只是想快速验证某个想法不想花时间学转换工具链用 PyTorch MPS 或者 MLX 就够了。不要一上来就想把四条路径全部打通我见过太多人因为想一步到位结果卡在环境配置上的例子。2. 环境准备芯片、系统版本和框架版本一个都不能错2.1 芯片差异决定你走哪条路M 系列芯片是当前 Mac GPU 加速的主力MPS、Core ML 的神经引擎调度都默认针对它优化性能表现和功耗控制都处在最佳状态。Intel 版 Mac 的情况就不太乐观了虽然也有独立显卡但官方机器学习加速主要依赖老一代 Metal 路径框架支持力度远不如 M 系列芯片。如果你手里是一台 Intel 版 Mac建议把 GPU 加速的期待值调低重点放在 CPU 优化和模型规模上而不是折腾 GPU。真要做大模型实验远程连一台有 GPU 的机器都比本地硬撑高效得多。2.2 版本匹配是第一个大坑PyTorch 这块我强烈建议直接用官方渠道安装最新稳定版。很多老教程会让你从源码编译或者装一些第三方打包版本在 Mac 上很容易踩到 MPS 后端没编进去的情况。装完之后先跑一段最基础的环境检测import torch print(PyTorch:, torch.__version__) print(MPS built:, torch.backends.mps.is_built()) print(MPS available:, torch.backends.mps.is_available())如果输出里MPS available是False说明要么版本太老、要么这台机器条件不满足。另外macOS 系统版本不要乱升级也不要乱降某些中间版本和 MPS 后端之间存在兼容问题。我实测过系统大版本升级之后同一份代码训练速度反而变慢了排查了半天结论就是 Metal 驱动层的行为发生了细微变化。2.3 快速验证环境是否真的能加速环境检测通过不代表加速就生效了建议跑一个最简单的矩阵乘法脚本做个基准直接对比 CPU 和 MPS 的耗时差异import torch import time def bench(device, size2048): a torch.randn(size, size, devicedevice) b torch.randn(size, size, devicedevice) torch.mps.synchronize() if device mps else None t0 time.time() c a b torch.mps.synchronize() if device mps else None return time.time() - t0 print(CPU:, bench(torch.device(cpu))) print(MPS:, bench(torch.device(mps)))如果差距小于 1.2 倍不用急着排查环境问题。2048 级别的矩阵乘都已经跑不出差距说明你的真实任务多半是 IO 密集或者张量操作太小GPU 加速帮不上忙。3. 训练侧实操把 PyTorch 模型迁到 MPS3.1 最小改动迁移写法从 CUDA 生态迁到 Mac 上最理想的状态就是只改设备名。我的习惯是写一个get_device()函数让代码在 Mac、有 CUDA 的机器、纯 CPU 机器上都能自动切换import torch def get_device(): if torch.backends.mps.is_available(): return torch.device(mps) if torch.cuda.is_available(): return torch.device(cuda) return torch.device(cpu)拿到设备之后把模型、输入、标签全部.to(device)device get_device() model Model().to(device) for batch in dataloader: x, y batch[0].to(device), batch[1].to(device) pred model(x) loss criterion(pred, y) optimizer.zero_grad() loss.backward() optimizer.step()有两个细节值得注意。第一标签y如果不做.to(device)会在计算损失时报“设备不一致”错误第二在统计耗时或者同步打印日志时最好加上torch.mps.synchronize()因为 MPS 是异步执行不加同步时很多操作还在 GPU 队列里时间戳完全对不上。这个和 CUDA 里的torch.cuda.synchronize()是一个道理。3.2 内存管理是 MPS 训练最容易翻车的地方统一内存的容量虽然大但机器上所有软件都在吃同一块内存。打开几十个浏览器标签、再跑一个 Docker 容器训练脚本能分到的内存就变少很多。在 MPS 后端上训练大模型时PyTorch 会缓存中间结果和张量内存内存增长速度比 CPU 训练快得多。我踩过最狠的一次训练一个小型 Transformer直接让系统内存报警鼠标都开始卡顿。解决办法有三个训练循环里定期调用torch.mps.empty_cache()手动释放缓存类似 CUDA 的empty_cache()批量大小从小的开始不要按 CUDA 习惯直接上 64建议先用 16 或 8 试水通过环境变量PYTORCH_MPS_HIGH_WATERMARK_RATIO控制内存水位限制 PyTorch 占用的内存上限。3.3 到底什么样的模型适合用 MPS 训练我在图像分类场景里做过一组对比实验。一个极浅的卷积网络从 CPU 切到 MPS 之后提升非常有限甚至有时候更慢。原因是这种小模型本身的算子调度、内存分配、同步开销已经占了总耗时的大头GPU 计算再快也救不回来。但换成 ResNet 这类深层卷积网络或者中等规模的 Transformer情况就完全不一样CPU 和 MPS 的差距能拉开到 3 到 5 倍。核心判断标准很简单任务计算越密集、算子越标准化、张量越大MPS 收益越明显自定义 Python 循环越多、小张量拆分越多收益就越小。4. 推理侧加速Core ML 与 ONNX Runtime 才是真正的“日常主角”4.1 为什么训练完还要单独优化推理训练场景下你更关心吞吐和收敛速度能跑完就行部署场景下你更关心单次推理延迟、内存占用和稳定性。同样是 GPU 加速目标不同选型也会完全不同。在 Mac 上做低延迟推理Core ML 几乎是绕不开的一环。它由系统级调度可以根据当前负载自动决定把模型的一部分放在 GPU、一部分放在神经网络引擎。神经引擎在低功耗场景下尤其能打虽然单个算子不如 GPU 快但综合功耗和散热表现非常优秀。4.2 从 PyTorch 到 Core ML 的转换流程用coremltools做转换核心流程可以拆成三步。先把 PyTorch 模型通过torch.jit.trace转成 TorchScript再用ct.convert转成 Core ML 格式最后指定计算单元保存为.mlpackage。下面是一个最简示例import coremltools as ct import torch import torchvision model torchvision.models.resnet18(weightsNone).eval() example_input torch.randn(1, 3, 224, 224) traced_model torch.jit.trace(model, example_input) mlmodel ct.convert( traced_model, inputs[ct.TensorType(namex, shape(1, 3, 224, 224))], compute_unitsct.ComputeUnit.ALL, ) mlmodel.save(resnet18.mlpackage)compute_units有四个选项全用 CPU、只用 CPU 和 GPU、只用 CPU 和神经引擎、全部用上。日常选择ComputeUnit.ALL就好系统会自动拆分配置。这里最大的坑是自定义算子。如果你的模型里写了torch.where、某些自定义autograd.Function或者用了不支持的三方算子转换过程很可能报“算子未映射”错误。遇到这种情况常见对策是把那几个不兼容的层留在 CPU 上执行只把主干卷积和线性层交给 Core ML。4.3 用 ONNX Runtime 做更轻量的替代如果不想走完整的 Core ML 转换流程还有一个折中方案把模型导出成 ONNX然后用 ONNX Runtime 在 Mac 上运行让它通过 CoreML 执行提供程序调度到 GPU。import onnxruntime as ort sess_options ort.SessionOptions() session ort.InferenceSession( model.onnx, sess_optionssess_options, providers[CoreMLExecutionProvider, CPUExecutionProvider], )这种方式胜在流程通用PyTorch、TensorFlow 都能先导成 ONNX 再统一处理。但要注意ONNX Runtime 的 CoreML 执行提供程序并不是所有安装包都默认包含装之前最好确认当前平台 wheel 是否带上了对应实现。如果发现没带上要么换官方文档推荐的安装方式要么退回 CPU 执行提供程序再不行就走完整 Core ML 转换。4.4 量化是 Mac 推理最实用的加速手段Core ML 对量化的支持相当成熟常见方案是 fp16 和 int8。转换时指定精度为 fp16经常能在几乎不掉点的情况下把推理时间砍掉一半内存占用也会明显下降。如果你的模型对精度特别敏感可以考虑只量化靠后的全连接层保留输入附近的卷积层为 fp32这种混合精度方式在不少场景里比全模型 int8 更稳。我自己的经验是量化效果和模型冗余度强相关CNN 的冗余通常比较大量化收益明显一些已经蒸馏得很干净的小 Transformer 模型int8 之后可能会看到轻微精度波动需要实际验证。5. 实测下来哪些场景提升最大哪些场景白折腾5.1 怎么确认 GPU 真的在干活很多人在 Mac 上跑了 MPS 代码之后心里没底不确定 GPU 是不是真的参与了运算。我常用的验证方法有三个打开 macOS 自带的活动监视器切换 GPU 列观察负载曲线在训练循环里插入torch.mps.synchronize()做计时对比或者干脆把数据量放大到 CPU 难以短时间完成的程度直接观察 GPU 负载是否飙升。活动监视器的“GPU”列是实时变化的如果训练脚本跑起来后 GPU 历史曲线一直趴在 0%那不用怀疑算子大概率回退到 CPU 了。这时候不要急着骂框架先查算子兼容性。5.2 一组有代表性的性能结果给一个数量级上的参考不同机器、不同系统版本下差距会很大但趋势是一致的场景CPU 耗时MPS/GPU 耗时收益4096×4096 矩阵乘约 1.2s约 0.25s约 5 倍ResNet 类模型单张推理约 90ms约 20ms约 4 倍中等规模 Transformer 单个训练步约 120ms约 40ms约 3 倍极浅卷积网络训练步约 8ms约 7ms无明显收益这个表基本印证了上面说的规律计算量越大收益越明显小模型切 GPU 可能收益为零甚至为负。5.3 训练和推理的侧重点差异训练场景里你会经常调整参数、随时可能中断重来这时候 PyTorch MPS 的灵活性和调试体验最重要Core ML 反而帮不上忙。推理场景里模型已经固定你只关心延迟、内存、稳定性和功耗Core ML 的系统级调度优势就体现出来了。还有人会犯一个反向错误把已经转成 Core ML 的模型拿回去继续训练。Core ML 本身就是部署格式不支持梯度回传强行改造只会拖慢节奏。训练和推理各自安好就行。6. 常见坑与排查经验我踩过的和你们会踩的6.1 算子不支持的时候不要硬扛MPS 的算子覆盖范围并没有 CUDA 那么全跑一些冷门模型时报错基本长这样NotImplementedError、MPS backend not supported、某个算子没有对应 kernel。最直接的兜底方案是设环境变量export PYTORCH_ENABLE_MPS_FALLBACK1开启之后MPS 后端遇到不支持的算子会自动回退到 CPU 执行。这样做能保证程序不崩但代价是性能可能大幅下降。如果你的任务里有大量回退最终耗时反而会超过纯 CPU 模式。排查时可以在代码里打印每个模块的设备位置确认哪些层发生回退再去考虑换实现或者重写算子。6.2 内存暴涨甚至直接卡死系统M 系列芯片的统一内存对“能不能分配”这件事非常宽容但正是因为宽容OOM 反而更隐蔽——系统内存不断被吃卡到鼠标都挪不动最后不得不强制重启。我的经验是训练脚本从 batch size 8 开始跑先观察一轮内存趋势再逐步翻倍。同时写训练循环保持torch.mps.empty_cache()的习惯如果模型特别大配合PYTORCH_MPS_HIGH_WATERMARK_RATIO限制水位。宁可小步快跑也不要一把梭把系统搞崩溃。6.3 冷启动和缓存问题第一次在 Mac 上用 GPU 跑一个新模型时Metal 会现场编译算子内核这个过程很慢而且 CPU 占用会突然拉满。跑第二次的时候就快很多因为编译结果被缓存了。这个坑直接影响性能评估。如果你拿第一次运行的结果和 CPU 对比会得出“MPS 完全没优势”的错误结论。正确做法是同一个模型至少跑两遍用第二次或者第三次的数据作为基准。6.4 数据加载才是隐形瓶颈MPS 训练时GPU 计算速度提上来了数据加载的瓶颈就会立刻凸显。你会在活动监视器里看到 GPU 占用忽高忽低训练总时间却下不来。问题通常出在 DataLoader 的 CPU 预处理上。解决方案是提高num_workers和prefetch_factor让数据在 GPU 算完上一批之前就准备好下一批。但要注意 Mac 上num_workers不是越大越好它吃的是 CPU 和内存资源开太高反而互相抢。建议从 2 开始慢慢升找到平衡点。7. 选型建议到底什么时候该在 Mac 上折腾 GPU7.1 训练和推理的最终结论根据我这段时间的实际体验可以给你一份比较明确的决策清单只想在本地做小规模训练、调参、跑实验优先用PyTorch MPS投入产出比最高要低延迟推理、模型要嵌入 AppCore ML值得投入时间去学现有代码深度绑定 CUDA 生态大量使用 CUDA 专属算子不要硬搬要么重写要么远程跑 GPU 机器大规模分布式训练、超大 batch 训练不应该在 Mac 上死磕统一内存再大也扛不住多机多卡的需求。7.2 什么时候真不用折腾 GPU模型参数总量小于十万、单次前向计算低于几毫秒的纯 CPU 完全够用折腾 GPU 反而是负优化如果你的日常任务是处理大量 CSV 表格、跑传统机器学习算法GPU 也帮不上忙瓶颈在 IO 和特征工程。反过来如果模型主体是几个大矩阵乘和标准化卷积层MPS 或者 MLX 的收益会非常可观。这类模型在 Mac 上吃 GPU 是稳赚不赔的。7.3 一个值得长期留着的混合调度技巧不要把你的设备定义写成全局常量。我更建议把设备选择封装成可配置函数允许用环境变量强制指定 CPU 或 MPS这样调参、对比、线上容错都能共用同一套代码。我自己最后形成的习惯是默认自动选择设备但总能通过环境变量手动覆盖排查性能问题时特别好用。import os import torch def get_device(): forced os.environ.get(ML_DEVICE, ) if forced in (cpu, cuda, mps): return torch.device(forced) if torch.backends.mps.is_available(): return torch.device(mps) if torch.cuda.is_available(): return torch.device(cuda) return torch.device(cpu)最后分享一点个人感受Mac 上让机器学习使用 GPU 加速真正难的从来不是把.to(mps)写对而是搞清楚你的任务到底适合哪条路径以及你的性能瓶颈到底在计算、内存还是数据加载上。先在自己的机器上跑一组小实验把活动监视器里 GPU、CPU、内存三条曲线都看明白再决定要不要继续投入。这条路我前前后后走了大半年踩过的坑基本都写在上面了希望这篇内容能帮你少搭进去几个周末。