mlx-tune：把 Unsloth 的写法搬到 Apple Silicon 上
Fine-tune LLMs on your Mac with Apple Silicon. SFT, DPO, GRPO, Vision, TTS, STT, Embedding, and OCR fine-tuning — natively on MLX. Unsloth-compatible API.
秒懂
- 它是什么？
- 这是一个用 MLX 重写训练器、但保持 Unsloth 导入路径不变的项目，目标是让同一份脚本先在 Mac 上跑通，再原样推到 CUDA 集群。它的价值在代码可移植性，不在性能对标。
- 适合谁用？
- 适合已经在用 Unsloth 写训练脚本、手上只有 Mac、需要在本地做小规模原型验证的人，也适合把 mlx-tune 当作学习 MLX 训练循环的入口。不适合把生产训练放在 Mac 上的人，也不适合指望它替代 Unsloth 的人。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 84 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是脚本重写，不是算力问题
作者在 README 里把动机写得很直白：他日常在云 GPU 上用 Unsloth，换了 MacBook M4 之后发现本地没法复用同一套代码，因为 Unsloth 依赖 Triton，而 Mac 上没有。于是他做了 mlx-tune，把 Apple 的 MLX 包一层，对外暴露和 Unsloth 一样的 FastLanguageModel 与 SFTTrainer。
这一点决定了它的定位。它不是要证明 Mac 能训得比 NVIDIA 快，作者自己也写了「不是要取代 Unsloth，也不主张性能更强」。真正被解决的是一个工作流问题：同一份训练脚本，先在本地小数据集上跑通、调超参、看 loss 曲线，然后不改 import 直接推到 CUDA 机器上做正式训练。README 里的对照很直接，左边是 from unsloth import FastLanguageModel，右边是 from mlx_tune import FastLanguageModel，其余代码保持不变。
所以判断它值不值得看，标准不是「Mac 能不能训大模型」，而是「你有没有一份想两边复用的训练脚本」。如果没有，这个项目的核心卖点对你基本无效。
训练器是原生 MLX 实现，API 只是外壳
从状态表看，SFT、DPO、ORPO、GRPO、KTO、SimPO 都标为 Stable，且各自注明是完整损失函数，比如 DPO 写的是 Full DPO loss，SimPO 注明不需要参考模型并配 SimPOConfig。这说明它不是把 Unsloth 的 Python 代码照抄一遍，而是用 MLX 重新实现了各个训练循环，再套上兼容层的类名和参数签名。
数据处理这一层同样做了对齐。README 列出了 train_on_responses_only()、to_sharegpt() 加 conversation_extension 做多轮合并、apply_column_mapping() 自动改列名、以及 HFDatasetConfig 这套结构化加载配置。这些都是 Unsloth 用户熟悉的入口，迁移时改动量小。
模态覆盖比一般 LoRA 工具宽。除文本外，仓库声称支持视觉模型微调（经由 mlx-vlm）、5 个 TTS 模型（Orpheus、OuteTTS、Spark、Sesame、Qwen3-TTS）、7 个 STT 模型（Whisper、Moonshine、Qwen3-ASR、NVIDIA Canary、Voxtral、Voxtral Realtime、NVIDIA Parakeet TDT），以及 Embedding 和 OCR。v0.6.0 又加进了 JEPA 系列，入口是 FastJEPAModel、FastVideoJEPAModel、LLMJEPATrainer，其中 LLM-JEPA 的做法是在下一 token 预测之外加一个对齐两项「视图」的 JEPA 项，产物仍然是普通的 LoRA 模型。
需要提醒的是，状态表里的 Stable 是项目自己的标注，不是第三方验证结论。模态越多，每个分支能分到的维护精力越少，这一点在选型时应当计入。
安装与环境约束
README 给出的安装命令是 pip install mlx-tune。如果你是老用户，原先叫 unsloth-mlx，迁移方式是换掉安装包名，并把 import 从 unsloth_mlx 改成 mlx_tune，项目说明里明确写了这两步。
环境门槛写在徽章和标题里：平台为 Apple Silicon，Python 3.9 及以上，MLX 0.20 及以上。也就是说这是一条硬边界，Intel Mac、Linux、Windows 都不在支持范围内，因为底层是 MLX 而不是 PyTorch。
内存方面 README 强调的是统一内存，提到 Mac Studio 最高 512GB。这句话描述的是硬件上限，不是项目本身的能力上限，实际能加载多大的模型还要看量化方式和序列长度，仓库材料里没有给出具体的显存或内存对照表，这一点无法从现有信息确认。
导出路径上，README 说可以导出为 HuggingFace 格式，也可以导出 GGUF 给 Ollama 或 llama.cpp 用。但同一份文档又把 GGUF 归到「已知限制」一节里，所以如果你的下游是 Ollama，先去看那一节写了什么，不要只看功能列表。
量化基座上的合并导出曾经是个坑
v0.5.1 的发布说明只有一句：修复量化基座上调用 save_pretrained_merged（issue #15）。这条信息量不小。它意味着在某个版本之前，如果你加载的是量化模型，训练完想把 LoRA 权重合并回基座再保存，会失败或者得到错误结果。
这类问题的麻烦之处在于它出现在流程末端。前面数据准备、训练、评估都跑通了，最后一步导出才炸，而这一步往往是你真正要交付的东西。走量化加载加合并导出这条路线的人，应当把版本升到 v0.5.1 以上再开始，而不是等训练跑完才发现。
另一个需要自己确认的边界是模型支持范围。状态表里「Model Loading」写的是任意 HuggingFace 模型，量化与非量化都可以，但视觉部分明确写着经由 mlx-vlm，也就是说 VLM 的实际支持面由 mlx-vlm 决定，不由 mlx-tune 决定。选模型之前先查 mlx-vlm 的列表，比查 mlx-tune 的文档更直接。
最后是平台本身。MLX 是 Apple 的框架，一旦你的训练需要多卡、需要特定 CUDA 算子，或者需要 Triton 生态里的东西，mlx-tune 帮不上忙，这正好也是作者建议把正式训练放回云端 Unsloth 的原因。
和 Unsloth 的真实差别在哪
最自然的对照就是 Unsloth 本身。两者在 API 层面几乎一致，差别全部落在后端。Unsloth 依赖 Triton 写自定义 kernel，在 NVIDIA GPU 上做算子级优化，目标是训练速度和显存占用；mlx-tune 走 MLX，用的是 Apple 的统一内存架构，能在 Mac 上直接跑，但没有 Triton 那一层优化。
这个差别带来的直接后果是：同一份脚本在两边跑，得到的不是一个可比的性能数字，而是两种不同的资源模型。云端那边你要为 GPU 小时付费，本地这边你要接受 M 系列芯片的算力上限和统一内存的容量约束。作者在 README 里也没有给出任何跨平台的速度对比，这个空白是刻意的。
如果你的目标就是在 Mac 上做端到端的微调并且不打算上云，那么 mlx-tune 的兼容层对你来说是额外负担，直接用 MLX 或 mlx-lm 写训练循环，路径更短，出问题时排查的层数也更少。兼容层的价值只在「同一份代码要跑两个平台」这个前提下才成立。
版本节奏与维护成本
从发布记录看，v0.5.0 是各训练器的性能改进，v0.5.1 是单点 bug 修复，v0.6.0 一次性引入 LeJEPA、I-JEPA、V-JEPA 2、LLM-JEPA 四个方向。跨度不小，而且 JEPA 这一块在 MLX 上此前没有现成实现，属于自己填的空白。
这种节奏对使用者的含义是：接口还在动，尤其是新加的模态。文本 SFT、DPO 这些标为 Stable 的部分相对稳，视觉、语音、JEPA 这些后加的部分要按「可能变」来对待，锁版本比追最新更省事。
许可证是 Apache-2.0，允许商用和修改，附带专利授权条款，通常要求保留版权与许可声明。这是项目自身的许可，不覆盖你加载的基座模型权重，也不覆盖 mlx-vlm 等依赖，那几层的许可需要分别核对。以上是许可条款的一般性说明，不构成法律意见。
另一个实际成本是双平台脚本的维护。既然卖点是同一份代码两边跑，那么任何一处只在 Mac 上验证过的改动，推到云端之前都得再跑一遍。这个成本不会因为 API 兼容而消失，只是从重写脚本变成了重复验证。
谁该用它，谁该绕开
该用的是这样一类人：手上有一份基于 FastLanguageModel 和 SFTTrainer 写的训练脚本，日常在云 GPU 上跑，同时有一台 Apple Silicon 的 Mac，想在本地用小数据集快速试超参和数据格式，试完把同一份脚本推上去。对这类人，改动量基本就是两行 import。
该绕开的是另一类人：把 Mac 当生产训练机的人。统一内存再大也改变不了算力层级，项目本身也没有宣称能替代云端训练。还有一类是只做文本 SFT、根本不打算上云的人，兼容层对他们是纯开销，直接用 MLX 更干净。
上手之前，按顺序确认三件事。第一，你要微调的模型是否在 mlx-vlm 的支持列表内，视觉和语音尤其如此。第二，你的导出目标是 HuggingFace 格式还是 GGUF，后者被 README 归入已知限制。第三，你要用的训练方法在状态表里是不是 Stable，DPO、ORPO、GRPO、KTO、SimPO 都标了 Stable，但新加的 JEPA 系列不在那张表里。
最后一条是版本：如果你走量化加载加 save_pretrained_merged 合并导出，起点放在 v0.5.1 以上，这个修复就是为这条路径准备的。
编辑结论
适合已经在用 Unsloth 写训练脚本、手上只有 Mac、需要在本地做小规模原型验证的人，也适合把 mlx-tune 当作学习 MLX 训练循环的入口。不适合把生产训练放在 Mac 上的人，也不适合指望它替代 Unsloth 的人。上手前先确认三件事：你的模型是否在 mlx-vlm 支持列表内；你的导出目标是 HF 格式还是 GGUF，因为 README 明确把 GGUF 归入已知限制；以及你打算用的训练方法是否在状态表里标为 Stable。v0.5.1 修的是量化基座上的 save_pretrained_merged，如果你走的是量化加载加合并导出的路线，先把版本升到这一版以上再开始。
社区笔记