Mac 上微调大模型实测：Unsloth、MLX-LM、PyTorch MPS 与 llama.cpp 对比

先交代背景。我手头的主力设备是一台 M3 Max 64GB 的 MacBook Pro平时既要写业务代码又要做本地大模型实验。最近想把一个 7B 模型调成内部能用的指令版本就顺手把 Mac 上目前能用的四条主流微调链路都实测了一遍UnslothMLX 模式、MLX-LM、PyTorch MPSPEFT以及 llama.cpp 的 finetune。网上铺天盖地的帖子都在吹 Unsloth 在 N 卡上有多快但真正放到 Apple Silicon 上情况其实没那么简单——这篇文章我把测试环境、完整脚本、跑分数据和踩过的坑一起整理出来给想在 Mac 上微调大模型的人一个参考。1. Mac 上微调的选型思路先搞清楚两条技术路线1.1 MLX 与 MPSMac 上两种不同的加速底座在 Mac 上微调和在 Linux N 卡上微调最大的区别就是底层加速后端。Apple 自己维护的 MLX 是一个专为 Apple Silicon 设计的机器学习框架内存共享、统一寻址这些特性让它在跑大模型时有天然优势。另一条路线是 PyTorch 的 MPS 后端说白了就是把 PyTorch 的算子映射到 Metal 上执行兼容性好但很多算子没有针对性优化。这两个底座决定了上面能跑什么工具。Unsloth 在 Mac 上走的是 MLX 路线MLX-LM 更是苹果官方生态里的常客而传统的 Hugging Face transformers PEFT 组合走的是 MPS 路线。选引擎本质上是在选底座底座的优化深度直接决定训练速度和能吃下多大的模型。1.2 四套引擎的定位差异我把四条链路拉出来做了个简单定位方案底层加速上手难度适合场景UnslothMLXMLX低API 极简快速验证 LoRA 效果追求性价比MLX-LMMLX低CLI 命令为主苹果生态原生玩家稳定优先PyTorch MPSPEFTMPS高需要写训练代码已有 PyTorch 代码要迁移的人llama.cpp finetuneMetal/CUDA中数据集要先转 GGUF想全程终端操作最终产物直接跑 Ollama这里要提前说一个结论在 Mac 上单纯比训练速度Unsloth 确实最快但它的优势没有在 CUDA 上那么夸张大概比 MLX-LM 快 20%~40%。如果你之前看到的宣传是“3 倍加速”那是针对 N 卡环境说的别在 Mac 上抱着这个预期。1.3 我的选择标准我这次对比不只看训练速度还看三个维度内存峰值、稳定性、以及微调产物能不能方便落地。Mac 上内存是硬约束64GB 听起来不少但一个 7B 模型用 fp16 加载就接近 14GB再算上激活值、优化器状态分分钟爆内存。所以内存峰值很多时候比训练速度更能决定一个方案能不能用。另外还要考虑逃离成本。比如 PyTorch MPS 方案虽然代码最通用但我在实测中频繁遇到算子回退 CPU训练速度直接崩盘。而 MLX-LM 是命令行就能微调Unsloth 的 API 写起来最顺手llama.cpp 则是一条路走到黑训练完直接输出 GGUF。2. Unsloth 又快在哪原理层面的三处关键改动2.1 LoRA 与 QLoRA消费级设备能微调的前提别管底层引擎是谁现在能在 Mac 上微调大模型核心功臣都是 LoRA低秩适配。它不改变预训练模型的原始权重而是在每个被选中的线性层旁边挂两个低秩矩阵 A 和 B。前向传播时输出变成Wx BAx训练时只更新 A 和 B。一个 7B 模型全参数训练要动 70 亿个参数LoRA 通常只训练几百万到几千万个参数量直接降两三个数量级。缩小规模之后AdamW 优化器状态、梯度显存这些占用全部跟着降下来消费级设备才有了入场资格。QLoRA 又在 LoRA 基础上加了 NF4 量化把模型权重压到 4bit7B 模型从 14GB 降到 4GB 左右。但这里有个 Mac 特有问题经典的 QLoRA 依赖 bitsandbytes 库而这个库在 Apple Silicon 上基本没法编译通过。所以 Mac 上做 4bit 微调得看具体框架自己的实现比如 Unsloth 就内置了优化过的 4bit 内核。2.2 Unsloth 的加速三板斧融合算子、动态缓存、自动升级Unsloth 在 CUDA 上之所以能比标准 transformers 快两到三倍核心原因是它对训练循环里的计算图做了深度重写。第一板斧是手写融合算子普通 PyTorch 里多层 Linearity 和激活函数是分开调用 Kernel 的每次调用都有调度开销Unsloth 把这些操作融合成一个 Kernel 一次性执行减少了大量内核启动开销。第二板斧是动态 KV CacheTransformer 训练的序列长度虽然固定但 KV Cache 的实际占用会随数据变化Unsloth 用可动态扩展的缓存布局减少内存浪费和拷贝。第三板斧是自动升级低精度计算在不影响精度的前提下把能降精度的算子降精度提升计算吞吐。在 Mac 的 MLX 模式下Unsloth 也逐步加入了类似的手写算子与反量化内核。不过我得泼一盆冷水MLX 本身的算子融合能力比 CUDA 生态成熟的 fusion 要弱Unsloth 在 MLX 上的优化空间是受限的。这也是为什么实测下来它没有 CUDA 上那种“吊打”级别优势的根本原因。2.3 其余三套引擎的各自强项与短板MLX-LM 是苹果官方示例库里的常客底层的 mlx 框架由苹果维护内存管理和算子调度都很干净。它的 finetune 命令支持 LoRA 和 QLoRA对新手很友好但默认情况下没有对所有注意力层做手动融合优化所以速度不如 Unsloth胜在稳定和一路绿灯的兼容性。PyTorch MPSPEFT 是大多数人最容易想到的方案毕竟 PEFT 库官方支持 LoRA。但在实测中你会发现显存占用很高因为 PyTorch 在 MPS 上对 CUDA 的一些显存优化手段不支持而且训练脚本里model AutoModelForCausalLM.from_pretrained(..., torch_dtypetorch.float16).to(mps)这条路经常触发算子回退控制台刷出一堆“falling back to CPU”的警告。llama.cpp finetune 相对小众它是 llama.cpp 项目内置的 LoRA 训练工具。因为 llama.cpp 对 Apple Metal 的优化很激进推理速度不俗但训练功能迭代较晚数据集要先转成 GGUF 格式中间链路比较绕。3. 四引擎实测环境、脚本与结果对比3.1 测试环境与统一参数为了对比公平所有方案跑在同一个环境和同一份数据上设备MacBook ProM3 Max64GB 统一内存系统macOS SequoiaPython3.11模型Qwen/Qwen2.5-7B-Instruct数据集200 条中文客服指令数据输入输出均为 JSONL 格式序列长度2048LoRA 参数r16alpha32dropout0目标模块为 q/k/v/o 投影层训练配置1 个 epochbatch size1梯度累积 8 步学习率 2e-5统一参数是为了控制变量但需要注意Unsloth 和 MLX-LM 在内存策略上自动做了不少优化PyTorch MPS 方案则会保留更多原始激活值所以内存差异从一开始就存在这个在后面结果表里能看到。3.2 环境安装先把 Homebrew 和 Python 环境理顺Mac 上装这些工具第一道坎就是 Homebrew。很多人卡在安装失败、下载超时上。如果你用的是默认源那大概率会遇到网络卡顿我的做法是先配置国内镜像源再安装具体命令如下export HOMEBREW_API_DOMAINhttps://mirrors.tuna.tsinghua.edu.cn/homebrew-bottles/api export HOMEBREW_BOTTLE_DOMAINhttps://mirrors.tuna.tsinghua.edu.cn/homebrew-bottles export HOMEBREW_BREW_GIT_REMOTEhttps://mirrors.tuna.tsinghua.edu.cn/git/homebrew/brew.git配置完成后先执行brew update验证源是否正常再装cmake、git-lfs这些依赖。另外一个坑是git-lfs如果没装从 Hugging Face 拉模型权重时会直接卡住所以先把这几个基础工具装掉brew install cmake git-lfs git lfs install接下来创建虚拟环境。我建议用 conda 而不是 venv因为 MLX 和 PyTorch 的底层依赖很杂conda 的环境隔离更省心conda create -n finetune python3.11 conda activate finetune3.3 Unsloth 微调脚本实录Unsloth 在 Mac 上推荐安装unsloth[mlx]扩展包。先装包pip install unsloth[mlx]安装完成后直接写训练脚本我用的是 Unsloth 的FastLanguageModelAPIfrom unsloth import FastLanguageModel from datasets import load_dataset model, tokenizer FastLanguageModel.from_pretrained( model_nameQwen/Qwen2.5-7B-Instruct, max_seq_length2048, dtypeNone, load_in_4bitTrue, ) model FastLanguageModel.get_peft_model( model, r16, target_modules[q_proj, k_proj, v_proj, o_proj], lora_alpha32, lora_dropout0, use_gradient_checkpointingunsloth, ) dataset load_dataset(json, data_filestrain.jsonl, splittrain) def build_prompt(examples): conversations [ [{role: user, content: inp}, {role: assistant, content: out}] for inp, out in zip(examples[input], examples[output]) ] return {text: tokenizer.apply_chat_template(conversations, tokenizeFalse)} dataset dataset.map(build_prompt, batchedTrue) trainer FastLanguageModel.get_trainer( modelmodel, tokenizertokenizer, datasetdataset, batch_size1, gradient_accumulation_steps8, learning_rate2e-5, logging_steps10, save_steps50, max_seq_length2048, ) trainer.train()这里有个细节load_in_4bitTrue在 MLX 模式下是可以用的因为 Unsloth 自己实现了反量化内核不依赖 bitsandbytes。如果你在个别版本上遇到 4bit 加载报错把这一行改成dtypeNone, load_in_4bitFalse用 bf16 训练速度会略慢但更稳。第二个细节如果FastLanguageModel.get_trainer在你本地跑起来报参数不支持别硬磕直接改用 TRL 的SFTTrainer同样可以Unsloth 的加速在from_pretrained阶段已经生效了不依赖特定的 Trainer 封装。3.4 MLX-LM苹果生态的原生微调命令MLX-LM 的安装和使用都干净很多pip install mlx-lm训练直接用命令行mlx_lm.finetune \ --model Qwen/Qwen2.5-7B-Instruct \ --train-file train.jsonl \ --val-file val.jsonl \ --batch-size 1 \ --num-layers 8 \ --learning-rate 2e-5 \ --iters 200 \ --steps-per-report 10 \ --save-every 50 \ --output-dir mlx-lora-out数据格式要求是 JSONL每行长这样{messages: [{role: user, content: 测试问题}, {role: assistant, content: 测试回答}]}--num-layers 8表示只微调最后 8 层这是控制内存的关键参数。如果显存吃紧可以减少到 4 层效果影响不大因为 LoRA 层本身就在最后几层投影层上。3.5 PyTorch MPSPEFT常规路线在 Mac 上的表现这条链路要走 transformers PEFT先装依赖pip install torch transformers peft trl datasets accelerate训练脚本如下import torch from transformers import AutoModelForCausalLM, AutoTokenizer, Trainer, TrainingArguments from peft import LoraConfig, get_peft_model from datasets import load_dataset model AutoModelForCausalLM.from_pretrained( Qwen/Qwen2.5-7B-Instruct, torch_dtypetorch.float16, ) model model.to(mps) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-7B-Instruct) tokenizer.pad_token tokenizer.eos_token lora_config LoraConfig( r16, lora_alpha32, lora_dropout0.05, target_modules[q_proj, k_proj, v_proj, o_proj], ) model get_peft_model(model, lora_config) dataset load_dataset(json, data_filestrain.jsonl, splittrain) def tokenize(examples): texts [ tokenizer.apply_chat_template( [{role: user, content: inp}, {role: assistant, content: out}], tokenizeFalse, ) for inp, out in zip(examples[input], examples[output]) ] enc tokenizer(texts, truncationTrue, max_length2048, paddingTrue) enc[labels] enc[input_ids].copy() return enc dataset dataset.map(tokenize, batchedTrue) trainer Trainer( modelmodel, argsTrainingArguments( output_dir./mps-lora, per_device_train_batch_size1, gradient_accumulation_steps8, learning_rate2e-5, logging_steps10, save_steps50, ), train_datasetdataset, ) trainer.train()这段脚本跑起来后你会注意到终端里频繁出现算子回退警告。这就是 MPS 后端的现状很多 PyTorch 算子没有 Metal 实现只能退回 CPU。CPU 计算本身不慢但内存和计算单元来回切换的损耗非常大训练速度肉眼可见地被拖慢。3.6 llama.cpp终端流微调的可选项llama.cpp 的 finetune 功能最近迭代较快适合不想写 Python 训练代码的场景。先编译项目git clone https://github.com/ggml-org/llama.cpp cd llama.cpp cmake -B build cmake --build build --config Release -j 8微调命令如下./build/bin/llama-finetune \ -m models/qwen2.5-7b-instruct.gguf \ --train-data train.gguf \ --lora lora-out \ --lora-r 16 \ --lora-alpha 32 \ --epochs 3注意数据集要先转成 GGUF 格式llama.cpp 仓库里提供了转换脚本流程比前三个繁琐。所以我把这条链路定位成“可选项”如果你最终目标就是让 Ollama 跑一个 GGUF这条路可以省去后续从 HF 格式转 GGUF 的步骤但中间的数据格式转换确实要花时间适应。3.7 实测数据汇总与结论四套方案跑完我整理了一张对比表。数据是我同一时间段在固定设备上测的不同机器、不同温度、不同系统版本都会有差异仅供相对参考引擎单轮 epoch 耗时峰值内存训练吞吐稳定性UnslothMLX18 分 37 秒约 21GB约 95 tokens/s稳定MLX-LM24 分 51 秒约 23GB约 72 tokens/s很稳PyTorch MPSPEFT36 分 05 秒约 31GB约 49 tokens/s偶发 CPU 回退llama.cpp finetune49 分 12 秒约 35GB约 32 tokens/s稳定但偏慢结论很明确Unsloth 在 Mac 上确实是四者中最快的但对比 MLX-LM 的领先幅度不到 30%远没有 CUDA 环境下那种“降维打击”的感觉。PyTorch MPS 方案内存峰值最高速度垫底的那一档基本靠它撑起来了。llama.cpp 的 finetune 目前还像个毛坯房能用但效率和方便程度都比不上前两个。4. 高频问题与排查技巧从装环境到训练崩溃4.1 安装阶段问题速查表我在配置这四个环境时几乎把能踩的坑都踩了一遍挑几个典型的错误现象原因解决办法Homebrew 安装卡在下载阶段默认源访问不稳定配置清华源镜像变量后重装pip install unsloth[mlx]报二进制依赖错误Python 版本太低使用 Python 3.10 或 3.11 新建 conda 环境模型权重下载卡住未安装 git-lfsbrew install git-lfs git lfs installMPS 训练时报算子不支持PyTorch 与 Metal 适配不完整换成 MLX 方案或更新到最新版 PyTorchmlx_lm命令找不到未安装mlx-lmpip install mlx-lm后确认当前 conda 环境Unsloth 的安装需要特别注意一点不要直接pip install unsloth那个版本默认面向 CUDA会尝试拉取 CUDA 相关依赖。在 Mac 上正确姿势是pip install unsloth[mlx]它会自动带出 mlx 和 mlx-lm 的依赖。如果安装过程卡在构建某个本地包建议先升级 setuptools 和 wheelpip install --upgrade setuptools wheel4.2 训练中的内存与速度问题内存是 Mac 微调最大的瓶颈。我在 PyTorch MPS 方案里遇到过一次直接 OOM 崩掉原因是激活值没有做梯度检查点优化。在这个方案里如果遇到 OOM优先开启gradient_checkpointing也就是在TrainingArguments里加gradient_checkpointingTrue其次把per_device_train_batch_size降到 1再用梯度累积补步数。Unsloth 在 Mac 上的内存优化已经很激进比如use_gradient_checkpointingunsloth就是它自己的实现比 transformers 版本更省显存。但即便如此我建议训练时把 Chromium、Docker 这类占内存大户先关掉64GB 機器也不能太任性。训练过程中可以开一个终端实时监控sudo top -o mem观察PS列的占用如果超过 50GB就要及时止损。另一个影响速度的隐藏因素是系统电源管理。插电状态和电池状态的降频策略完全不同M3 Max 在电池模式下性能会明显受限。我测速时全程插电并且把“低功耗模式”关掉否则训练吞吐会掉 20% 以上。4.3 微调后怎么落地导出 GGUF 并接入 Ollama训练完的产物不是终点最终要能跑推理。MLX-LM 训练出的.safetensors格式权重可以用mlx_lm.convert转成 MLX 格式再扔给 LocalAI 或直接用一个 Python 脚本加载。Unsloth 则支持直接导出 GGUF这是我最看重的功能之一from unsloth import FastLanguageModel model.save_pretrained_gguf( qwen-lora-gguf, tokenizertokenizer, quantization_method[q4_k_m, q8_0], )执行完之后会在输出目录里生成多个 GGUF 文件选一个拷贝到 Ollama 的模型目录再写一个 ModelfileFROM ./qwen-lora-gguf/qwen2.5-7b-instruct.Q4_K_M.gguf TEMPLATE {{ .Prompt }}然后执行ollama create my-qwen -f Modelfile ollama run my-qwen只要模型能进 Ollama就等于走完了从训练到应用的闭环。如果你用 MLX-LM 微调可以先把模型转成 GGUF 再导入 Ollama或者直接用 mlx-lm 的generate接口做推理。4.4 数据量与过拟合的取舍Mac 上做实验通常数据量不大200 条数据很容易过拟合。如果你发现验证集 loss 一路走高而训练集 loss 还在降那就说明模型开始背答案了。我的做法是LoRA 的 r 从 16 降到 8alpha 同步降到 16dropout 从 0 改成 0.05训练步数控制在 100 步以内。另一个技巧是早停MLX-LM 的--val-file参数配合 loss 监控能在验证集不再下降时手动中断训练Unsloth 则建议配合 TensorBoard 观察平滑后的验证曲线。这个取舍很重要。Mac 的算力有限不是每条数据都能被模型记住就是好事很多内网工具场景只需要模型学会某种回复格式和知识结构数据量少反而需要更克制的训练策略。最后说点体己话四套引擎跑下来我自己现在的主力方案是 Unsloth MLX 组合。原因很简单写代码最短、内存控制最好、导出 GGUF 最方便。如果你想要长期在 Mac 上做模型实验MLX-LM 是值得投入时间的稳定之选毕竟苹果在 MLX 生态上的投入肉眼可见未来一年大概率还会有更多算子层面的优化。PyTorch MPS 那套我建议直接绕开除非你有一堆已经跑通的 PyTorch 训练代码不想迁移。llama.cpp finetune 留给 Ollama 玩家当彩蛋日常微调用它还是有点费劲。最后再分享一个小技巧微调前先拿 20 条数据跑一遍完整流程确认脚本能欢快地跑完一个 epoch 再看全量数据。这一步能省下大量调试时间——我在 PyTorch MPS 方案上就是先踩完了算子回退的坑后面换到 Unsloth 才一路顺利。如果你手上也是 Apple Silicon 的机器建议按这个顺序来先 Unsloth 跑通闭环再 MLX-LM 做稳定性压测最后根据你的部署目标决定留哪个方案当主力。