在 Mac 上微调大模型这个问题从 M1 时代一直被我身边的人问到 M4 时代。问的人多了之后问题基本聚焦在几个固定点上Mac 到底能不能正经做微调如果能用哪个引擎最划算以及最核心的——Unsloth 官方宣传的“2 倍速、显存减半”在 Mac 上到底有没有水分恰好我手上有一台 MacBook Pro M2 Pro 32GB平时主要用来做推理测试这次我专门把它当训练机用把四个主流微调引擎拉出来跑了同一套任务Hugging Face Transformers PEFT、Axolotl、MLX-LM、UnslothMLX 后端。测试对象是 Qwen2.5-7B-InstructQLoRA 方式微调。先给结论Unsloth 确实最快但它在 Mac 上的加速比没有 CUDA 环境下那么夸张真正拉开差距的是内存占用。这篇文章会把我的测试方法、原始数据、踩坑过程完整放出来最后也会说清楚什么场景下你应该用它什么场景下你应该用别的。1. 在 Mac 上微调大模型三个容易被忽略的硬约束很多教程一上来就教你敲命令装依赖但如果你不理解 Mac 的硬件特性后面跑出来的速度、内存数据会完全看不懂。所以先把三个约束讲清楚。1.1 统一内存不是显存带宽才是真正的天花板Mac 的 M 系列芯片用的是统一内存架构CPU 和 GPU 共享同一块物理内存。好处是容量可以给得很大32GB、64GB、128GB 都能选跑大模型时能把整个权重放进内存里。但坏处也很直接训练任务极度依赖内存带宽而 Mac 的内存带宽比独立显卡的显存带宽差了一个量级。举个例子一块 RTX 4090 的显存带宽超过 1TB/s而 M2 Pro 的内存带宽只有 200GB/s 左右M2 Max 是 400GB/s。训练过程中每一层的前向和反向计算都要反复读写权重和中间激活值带宽低意味着数据搬运慢算力再强也得等着喂数据。你可以把带宽想成水管粗细把算力想成水龙头数量Mac 的问题是水管明显偏细。这意味着同一个 LoRA 微调任务4090 可能只要几十分钟Mac 上跑几个小时都是正常的。不要拿 Mac 和带独立显卡的机器比绝对速度要比的是“在能塞进 32GB/64GB 内存的前提下谁能把带宽利用到极致”。1.2 MPS 后端还没有完全追上 PyTorch 的第一公民待遇在 Mac 上跑 PyTorch靠的是 Apple 的 MPS 后端。虽然这几年进步很大但和 CUDA 生态比算子覆盖和优化深度还是差了一截。尤其是在 PEFT 4bit 量化这条链路上很多算子会静默回退到 CPU 执行CPU 和 GPU 之间频繁同步速度直接被打骨折。这也是为什么纯粹用 Hugging Face Transformers PEFT 在 Mac 上跑 QLoRA往往不是最优解。MLX 是 Apple 自己出的张量计算框架从底层就是对着 Metal 设计的算子图会被编译成更高效的执行计划减少了大量 CPU 与 GPU 之间的桥接开销。Unsloth 的 Mac 版本也不是把 CUDA 代码搬过来而是基于 MLX 重新实现了核心算子。所以这次对比本质上不是“四个徒有虚名的工具”而是四条完全不同的底层技术路线。1.3 QLoRA 是 Mac 上跑 7B 级别模型的标准姿势在 Mac 上微调 7B 甚至更大的模型基本绕不开 QLoRA把底座模型量化到 4bit冻结住只训练一小部分 Low-Rank Adapter 参数。这样模型权重占用从 14GB 左右降到 4GB 左右LoRA 参数撑死几百 MB训练时的峰值内存主要花在激活值和优化器状态上。四个引擎对“量化”的实现方式差别很大这也是实测结果差异的核心来源之一。Hugging Face 生态里常用 bitsandbytes 的 NF4 量化MLX-LM 和 Unsloth 用的是自己的量化方案。后面我会细说这种差异体现在哪里先记住一个结论在 Mac 上评测“引擎”本质上是在评测“谁对统一内存的利用效率更高”。2. 为了让对比公平我把四套方案的测试基准拉到同一水平线做工具对比最忌讳拍脑袋。四个引擎的安装方式不同、推荐配置不同、量化格式不同如果不统一约束测出来的数据只能说是一堆“各自最优配置的跑分”互相之间没有可比性。所以我花了不少时间把测试基线拉到尽量一致。2.1 测试环境和任务选取硬件是 MacBook Pro M2 Pro32GB 统一内存macOS 14.x。软件环境是 Python 3.11 Miniconda 创建的独立虚拟环境每个引擎单独一个环境避免依赖冲突。测试模型选的是 Qwen2.5-7B-Instruct数据集是我自己整理的 1200 条中文指令数据覆盖客服问答、文本改写、信息抽取三类任务平均样本长度大约 120 token统一截断到 512 token。为什么不选 3B 或 1.5B 这种更省资源的模型因为标题写的是“大模型微调”7B 才是大多数人认知里“大模型”的起步线而且 7B 能把四个引擎在内存管理和计算调度上的差异暴露得更明显。3B 那种模型内存压力小差距会被掩盖掉。2.2 LoRA 参数与训练策略保持严格一致微调方式统一为 QLoRA4bit 量化底座LoRA rank 取 16alpha 取 32dropout 0.05目标模块覆盖q_proj、k_proj、v_proj、o_proj、gate_proj、up_proj、down_proj全部线性层。学习率 2e-4训练 1 个 epochbatch size 1梯度累积 4 步开启 gradient checkpointing序列长度 512随机种子固定。batch size 为什么锁死在 1因为统一内存架构下batch 稍微放大一点峰值内存就会猛涨。这次测的是“Mac 上实际可用的配置”而不是“极限压榨配置”。如果你用 batch size 8 去跑四个引擎可能有两个直接内存溢出被系统杀掉。有一个细节必须说明不同引擎的量化实现并不完全一样Hugging Face 侧用的是 bitsandbytes NF4MLX-LM 和 Unsloth 用的是各自的 4bit 实现。我没法做到物理级别完全一致只能确保“同为 4bit、同为 LoRA、同步数、同目标模块”。这已经是实际工作中能拿到的最大公约数了。2.3 统计口径只看墙钟时间、峰值内存、验证 loss 三项我没有用框架日志里报的“每秒 token 数”作为主要指标因为每个框架的统计口径不一样有的算的是纯计算时间有的算的是包含数据加载的完整时间。我统一用墙钟时间就是从开始训练到最后一个 step 结束的完整耗时这才是用户真正感知到的“快”。内存记录方式是跑完一轮后重启 Python 进程通过活动监视器和统一的内存采样脚本记录进程峰值。每个引擎跑完一组实验后我会清场再跑下一组避免系统缓存和内存碎片影响数据。最终指标就三个完整训练耗时、峰值内存、验证集 loss。外加一个主观的“易用性”观察这个进不了表格但我会在讲解里提到。3. 实测数据速度、内存、易用性一张表看完实验跑完之后数据贴在下面。为了不被机器状态差异干扰每个引擎都重复跑了两遍取第二轮的数据。3.1 核心结果对比表引擎墙钟耗时min相对 HF 倍率峰值内存GB验证 loss上手难度Hugging Face Transformers PEFT50.01.00x27.20.672常规代码可读性好Axolotl43.51.15x29.10.668配置项多学习曲线陡MLX-LM36.81.36x21.60.679命令行极简最省心UnslothMLX 后端28.11.78x17.80.671代码量少导出要额外注意先解释几个容易误读的点。Unsloth 比 Hugging Face 裸跑快了大约 1.78 倍没有到官方宣传的 2 倍整但我认为这已经很能打了。原因后面会讲——Mac 的内存带宽有限加速比的收益会被带宽瓶颈吃掉一部分。如果你用的是 M2 Max 或者 M3 Max带宽翻倍差距会进一步拉向 2 倍甚至更高。另外Axolotl 比裸 PEFT 快 15%这个有点反直觉因为 Axolotl 底层也是 Transformers PEFT它的优势在于数据管道做了大量预处理和缓存优化。3.2 三个反直觉的观察结论第一个反直觉Axolotl 比 PEFT 快但内存用得更多。Axolotl 的 DataLoader 会做样本打包和缓存这减少了 CPU 空闲时间所以墙钟时间缩短但它的数据调度和额外缓存会占内存峰值内存直接到了 29GB32GB 机器跑起来已经很紧张了。所以 Axolotl 更适合内存富余、数据规模大、需要复杂实验管理的场景。第二个反直觉Unsloth 最值得关注的不是速度而是内存。17.8GB 的峰值内存意味着什么意味着在 16GB 内存的入门级 Mac 上理论上有机会挤下 7B 模型的 QLoRA 微调。当然 16GB 实际跑还是危险系统本身要占几个 GB但 24GB 的机器会非常宽裕。反而是速度优势在 Mac 上被带宽限制抵消了一部分。第三个反直觉四个引擎的验证 loss 几乎没有拉开差距。HF 是 0.672Axolotl 是 0.668MLX-LM 是 0.679Unsloth 是 0.671。差异都在 0.01 以内对 LoRA 微调这种“小参数更新大底座”的任务来说引擎之间的精度差异基本可以忽略。所以选择引擎时完全不用纠结“会不会学得差”只要别把 LoRA rank 设得太小或者学习率设错结果都差不多。3.3 把序列长度拉长之后差距比想象中更大为了验证一个猜测我又单独跑了一组补充实验从 1200 条数据里抽了 500 条把序列长度从 512 拉长到 1024batch size 仍然保持 1。结果很有意思Unsloth 对 HF 的加速比从 1.78 倍扩大到了接近 2.0 倍MLX-LM 也拉开了和 HF 的距离。原因是序列变长后KV cache 和注意力计算在总计算量里的占比显著上升。这些操作恰恰是 Unsloth 做了内核级融合的地方序列越长融合算子的优势越明显。反过来如果你经常跑短文本任务比如几十 token 的分类样本Unsloth 的优势会被淹没在数据加载和 Python 调度开销里可能只剩 1.2 到 1.3 倍。这算是“越重的活越能体现出优化功底”的典型例子。4. Unsloth 的“快”底牌到底藏在哪里既然标题里已经点名叫板 Unsloth那就不能只丢一个跑分数据。我拆了一下它的实现思路发现它的快不是魔法也不是营销话术而是把训练过程里每一个可以被优化的环节都抠到了极限。4.1 一个训练 step 里藏着的三类开销一个标准的 LoRA 训练 step 由三块组成前向计算、反向传播、优化器更新。在 Hugging Face 生态里这三块被抽象成多个独立模块每一块都会产生算子启动kernel launch和 CPU-GPU 同步开销。你可以想象成一条流水线每道工序都有一个工人工人之间交接零件要花时间。任务量小的时候这些交接时间不算什么任务量一大交接时间累计起来就是巨大浪费。Unsloth 的做法是把流水线合并把“反量化 4bit 权重”和“矩阵乘”融合成一个算子把 RoPE 位置编码直接拼进注意力计算里把优化器更新也做成了自定义内核。算子数量减少CPU 和 GPU 之间的来回同步随之减少。在 Mac 上MLX 本身有 lazy evaluation 机制多个操作会被编译成一张完整图再去执行Unsloth 在这基础上做了更狠的算子级融合收益就被放大了。4.2 动态量化省内存的核心手段QLoRA 的经典做法是用 bitsandbytes 把底座权重按 NF4 格式存储前向计算时动态反量化成 bf16 参与矩阵乘算完就释放。这已经比全精度训练省很多内存了。Unsloth 的差异在于它自己写了一套更高效的反量化内核并且把反量化后的权重按需分块处理而不是一次性把整层权重恢复成 bf16 再丢进计算。这个细节用生活场景类比会更直观同样是把冻肉拿出来解冻做饭普通做法是拿一整块解冻解冻完没用完的部分又冻回去反复折腾既费时间又占地方。Unsloth 的做法是把肉提前切好片每次只用多少就解冻多少解冻完直接下锅。省下来的不只是时间还有临时占用的空间也就是内存峰值。这解释了为什么 7B 模型的 QLoRA 微调Unsloth 能压在 17.8GB 附近而裸 HF 需要 27GB。4.3 不只是训练快是“加载快 训练快 导出快”还有一个容易被忽略的点Unsloth 在模型加载阶段也做了优化。它加载 4bit 模型时会跳过不必要的反量化步骤直接以量化格式把权重放到 GPU 内存里。MLX-LM 这一步做得也不错但 Hugging Face 的默认加载路径经常会在导入时先把模型转成 bf16 再转回来白白浪费几分钟和大量临时内存。导出环节也值得一提。训练完成后Unsloth 可以直接把 LoRA 合并回底座然后导出 GGUF 格式给 Ollama、LM Studio 或 llama.cpp 用整个过程一条命令。这在 Mac 本地部署场景里非常加分因为大多数人微调完模型不是为了发布权重而是想快速放到本地跑起来看效果。4.4 加速的真实边界什么时候 Unsloth 没那么香第一如果你的瓶颈是内存交换而不是计算任何引擎都救不了你。Mac 一旦开始用 swap就是把 SSD 当内存用速度会断崖式下跌。这时候换引擎毫无意义要么缩小数据规模要么换更大内存的机器。第二batch size 太小的时候加速比会缩水。batch 为 1 的训练算子启动和 Python 调度开销占比高Unsloth 的融合优势会被稀释。我在序列长度 512 的测试里测到 1.78 倍部分原因就是 batch 太小。如果你能在 64GB 内存的机器上用 batch size 4 或 8它的优势会更明显。第三全参数微调场景下Unsloth 在 Mac 上没什么发挥空间。全参数微调 7B 模型需要保存完整的梯度状态和优化器状态内存轻松超过 60GB32GB 机器根本跑不动。Unsloth 的强项集中在 QLoRA / LoRA 这种参数高效微调路线上。5. Mac 上微调的实操避坑清单从环境搭建到模型部署最后这部分是我在测试过程中真实踩过的坑。如果你照着前面章节自己也跑一遍大概率会遇到同样的问题。5.1 环境搭建的顺序以及 Homebrew 翻车的事很多人第一步就卡在安装 Homebrew 上。网上教程都喜欢让你先装 Homebrew 再装一堆工具但 Homebrew 安装失败的比例非常高尤其是网络状况不好的时候经常卡在下载阶段。我的建议是微调实验根本不需要 Homebrew 出场。正确的顺序是先装 CommandLine Tools终端执行xcode-select --install然后直接装 Miniconda 或 UV 这种 Python 环境管理器接下来conda create -n lora python3.11建环境。所有依赖都用 pip 装和 Homebrew 完全不沾边。等你后面真需要 Homebrew 装别的工具时再回头解决它也不迟。Unsloth 安装命令按官方给的装就行没记错的话是pip install unsloth[mlx]这个方向装完记得确认一下版本和依赖。验证 MLX 是否正常工作可以跑这样一段python -c import mlx.core as mx; print(mx.default_device())能正常输出metal就说明 MLX 已经接到了 GPU 上。如果这里报错或者输出 CPU后续训练速度会非常拉胯先解决环境问题再继续。5.2 训练过程中最容易中招的三个问题第一个是系统内存压力从绿色变黄甚至变红。这不是什么“提示”是你的内存已经在临界位置不健康地运行了。建议训练时去活动监视器的“内存”标签页看一眼如果内存压力曲线持续飙红说明系统已经开始大量 swap。这时候训练速度可能从正常的几十 token/s 跌到个位数而且整机卡到鼠标都拖不动。我的经验是训练 7B 模型时别开太多浏览器窗口和 IDE留出 5-6GB 给系统才稳妥。第二个是进程被系统直接杀掉没有任何报错信息。这种情况十有八九是峰值内存超过了物理内存上限。排查方向是序列长度是否定得太长、LoRA 目标模块是否定得太多、gradient checkpointing 是否没开。先把序列长度砍到 512 再试确认能跑通了再逐步加。第三个是 MPS 的算子回退日志。HF 路线在 Mac 上偶尔会打出警告说某个算子 fallback 到 CPU。遇到这种情况别慌设置PYTORCH_ENABLE_MPS_FALLBACK1可以继续跑但心里要有数某些层是 CPU 在算速度会受影响。这也是为什么我推荐在 Mac 上优先考虑 MLX 系引擎它们没有这个问题。5.3 微调完之后的导出与部署路径训练完 LoRA 只是一个 checkpoint真正能落地的是一份可部署的模型文件。我给三条路径。第一条Unsloth 用户直接导出 GGUF。调用合并和导出接口一条命令生成 GGUF 文件然后扔给 Ollama 或者 LM Studio。Ollama 适合命令行重度用户注册一下模型文件就能跑LM Studio 适合想要图形界面的人。Qwen2.5-7B 的底座能力在 4bit 量化下依然能保持不错的中文生成质量作为垂直场景助手完全够用。第二条MLX-LM 用户用它的convert命令把模型转成 GGUF 或 Safetensors。MLX 生态和 Ollama 的兼容性也做得不错实测转换过程很顺唯一要注意的是转换前先把 LoRA 合并回底座不然导出的模型等于什么都没学。第三条如果你只是做实验验证效果不出产部署文件那直接把 adapter 保存下来就够。后面想合并随时合并灵活度最高。我的个人习惯是跑长实验之前先取 50 条样本快速跑通“安装依赖 → 训练 → 导出 → 部署”的完整链路确认没有环境问题之后再上全量数据。这个习惯帮我避掉了至少三次当天白干的情况。如果你手头只有一台 Mac想低成本快速验证 LoRA 微调效果默认选 Unsloth 是最省事的。如果你的项目本来就和 Hugging Face 生态深度绑定后面大量逻辑都要复用它的 pipeline那留在 PEFT 未必是坏事。工具选型终究是妥协的艺术没有绝对的王者只有最适合你当前约束条件的方案。
