mlx-tune：Unsloth互換APIでMac上にファインチューニング環境を載せる
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.
ひと目でわかる
- これは何？
- Apple Silicon上のMLXでSFT・DPO・GRPO・Vision・音声・OCRのファインチューニングを回すライブラリ。狙いは性能ではなく、Macで書いた学習スクリプトをCUDAクラスタへそのまま持っていける移植性にある。
- 誰に向いている？
- Mac上で学習パイプラインを組み、同じスクリプトをCUDA側のUnslothへ持ち込む予定がある開発者には向く。GGUF変換の制約や量子化ベースの保存まわりを許容できない場合、あるいは学習の再現性を最優先する本番運用には向かない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 85 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Macで学習スクリプトを書き、CUDAで走らせるための橋
mlx-tuneが解こうとしているのは計算速度の問題ではない。READMEの作者の説明によれば、クラウドGPUではUnslothを常用しているが、M4のMacBookで作業するようになって摩擦を感じた。UnslothはTritonに依存しており、MacにはTritonがないためローカルでは動かせない。そこでMac上での試作とクラウド側での本学習の間で、学習スクリプトを書き直す手間が発生する。mlx-tuneはこの切り替えコストを消すために、AppleのMLXをUnsloth互換のAPIで包む。対象読者は、Macで小さいデータセットを回して反復し、その後にNVIDIA GPUへ移す個人開発者や小規模チームだ。プロジェクト自身が「Unslothの代替ではなく、Macを使う人のための橋」と位置づけており、性能でUnslothに勝つことは目標に置かれていない。
importの一行を差し替えるだけで済むAPI設計
互換性の実体はimport文の置換にある。READMEの例では、CUDA側の `from unsloth import FastLanguageModel` と `from trl import SFTTrainer` を、それぞれ `from mlx_tune import FastLanguageModel` と `from mlx_tune import SFTTrainer` に変えるだけで、残りのコードは同一のままだと説明されている。学習ループの書き方ではなく、モデル読み込みとトレーナーの呼び出し規約を合わせにいっている。この設計は、Macで書いたスクリプトをそのままクラウドへ持っていく用途では効く。逆に、MLX固有の最適化を直接触りたい場合には抽象が邪魔になる。互換APIは便利さと引き換えに、下位のMLX機能へのアクセスを一段遠ざける。
モデル読み込みと学習手法の対応範囲
READMEの機能表によれば、SFT、DPO、ORPO、GRPO、KTO、SimPOがStableとして並ぶ。DPOとORPOは完全な損失、GRPOは複数生成と報酬、KTOは二値フィードバックとKTOConfig、SimPOは参照モデルなしとSimPOConfigという注記が付く。モデル読み込みは量子化・非量子化を問わず任意のHuggingFaceモデルに対応すると記載されている。チャットテンプレートはllama、gemma、qwen、phi、mistral系の16モデル分が用意され、`train_on_responses_only()` による応答部分のみの学習、`to_sharegpt()` と `conversation_extension` によるマルチターン統合、`apply_column_mapping()` による列名の自動リネーム、`HFDatasetConfig` によるデータセット読み込みもStable扱いだ。Visionはmlx-vlm経由のVLMファインチューニング、音声はTTS 5モデル（Orpheus、OuteTTS、Spark、Sesame、Qwen3-TTS）とSTT 7モデル（Whisper、Moonshine、Qwen3-ASR、NVIDIA Canary、Voxtral、Voxtral Realtime、NVIDIA Parakeet TDT）が挙げられている。
v0.6.0で入ったJEPA系の入口
最新リリースのv0.6.0はJEPA（Joint-Embedding Predictive Architecture）を追加している。LeJEPAはEMA teacher、predictor、stop-gradientを使わないSIGReg目的関数でVision Transformerを事前学習する。I-JEPAは `facebook/ijepa_*` の学習済み画像エンコーダを読み込み、凍結・LoRA・全パラメータ分類でファインチューニングする。V-JEPA 2は `facebook/vjepa2-*` の動画世界モデルを読み込み、動画分類、クリップ特徴、masked-latent predictor（`predict_latents` と `latent_energy`）、MetaのSSv2行動分類器（174クラス、追加学習なし）を扱う。LLM-JEPAはarXiv 2509.14252の目的関数をLLMファインチューニングに持ち込み、次トークン予測に、同じ項目の二つの見方（説明文とそのコードなど）を整列させるJEPA項を加える。成果物は通常のLoRAモデルになると記載されている。新しい入口は `FastJEPAModel`、`FastVideoJEPAModel`、`LLMJEPATrainer` の三つで、詳細はJEPAのドキュメントに分離されている。
GGUFエクスポートの制約と量子化ベースの保存
保存と書き出しはHF形式とGGUF（Ollamaやllama.cpp向け）に対応するが、READMEの機能表はGGUFについて既知の制約へのリンクを付けている。制約の全文は与えられた材料からは確認できないため、ここでは「制約が明示されている」以上のことは言えない。バージョン履歴から読み取れる事実のほうが具体的だ。v0.5.1は「量子化ベースに対する `save_pretrained_merged` の修正（issue #15）」と題されている。つまり量子化済みモデルをベースにマージ保存する経路には、少なくともこの修正以前に不具合があった。量子化モデルを読み込んでマージ書き出しする予定があるなら、v0.5.1以降を選ぶ理由がここにある。v0.5.0は全トレーナーにわたる性能改善とされているが、その数値は材料に含まれていない。
Unslothとの違いは速度ではなく実行環境の前提
比較対象として最も自然なのは本家のUnslothだ。両者はAPIの形を揃えているが、前提が違う。UnslothはCUDAとTritonを要求し、クラウドGPUでの本格学習に向く。mlx-tuneはAppleのMLX上で動き、Macのユニファイドメモリをそのまま使う。READMEはMac Studioで最大512GBまで、とメモリの利点を挙げている。ただしこれはモデルを載せられる余地の話であり、学習速度でUnslothを上回るという主張はどこにもない。作者自身が「性能で優位に立つことを主張しない」と書いている。選択の基準は、その時点で手元にあるハードウェアがどちらか、そして最終的に学習をどこで回すかである。最終的な本番学習をNVIDIA側で行うなら、Mac側は試作専用と割り切る使い方が設計意図に合う。
導入コマンドと前提バージョン
インストールはPyPIから `pip install mlx-tune` で行う。旧名の `unsloth-mlx` から移る場合は、このコマンドに切り替えたうえで、importを `unsloth_mlx` から `mlx_tune` へ書き換える。READMEのバッジが示す前提は、Python 3.9以上、MLX 0.20以上、プラットフォームはApple Silicon、ライセンスはApache-2.0だ。学習側の入口は `FastLanguageModel` と各トレーナー（`SFTTrainer` など）で、JEPA系は `FastJEPAModel`、`FastVideoJEPAModel`、`LLMJEPATrainer` を使う。データセットは `HFDatasetConfig` で構造化して読み込み、列名が合わない場合は `apply_column_mapping()` で揃える。応答部分だけを学習させたいときは `train_on_responses_only()` を呼ぶ。これらはREADMEに記載されたAPI名であり、実際の挙動は手元で確認する必要がある。
Apache-2.0であることの実務的な意味
ライセンスはApache-2.0で、変更点を明示すれば改変物の配布が許され、特許条項も含む。商用利用を妨げる条項はない。ただしここで注意すべきは、mlx-tune自体のライセンスと、読み込むモデルやデータセットのライセンスは別物だという点である。`facebook/ijepa_*` や `facebook/vjepa2_*`、各種TTS・STTモデル、そして学習に使うデータセットにはそれぞれ条件があり、mlx-tuneがApache-2.0だからといってそれらが自由に使えるわけではない。法務判断はここでは扱わないが、書き出したLoRAやマージ済みモデルを配布する前に、ベースモデル側の条件を確認する作業は残る。
向く使い方と向かない使い方
Macで小さいデータセットを回し、学習スクリプトを書き直さずに後でCUDA側へ移す、という流れを想定している人には素直に合う。Visionや音声、埋め込みまで同じ枠組みで触りたい場合も、複数のライブラリをまたぐ手間が減る。逆に、Mac上だけで完結する本番学習を回したい場合や、量子化ベースのマージ保存を前提にしたワークフロー、GGUF変換の細かい制御が必要な場合は、制約に当たりやすい。互換APIはあくまで互換であり、MLXの内部まで踏み込んだ調整をしたい人には抽象が余計になる。導入時に最初に確かめるべきは、自分のベースモデルが量子化・非量子化どちらの経路で読み込めるか、そして書き出したGGUFがOllamaやllama.cppで実際に動くかだ。この二点はREADMEの機能表でも別扱いされており、手元での検証を飛ばせる記述は材料の中にない。
編集部の結論
Mac上で学習パイプラインを組み、同じスクリプトをCUDA側のUnslothへ持ち込む予定がある開発者には向く。GGUF変換の制約や量子化ベースの保存まわりを許容できない場合、あるいは学習の再現性を最優先する本番運用には向かない。導入前に確認すべきは、自分のベースモデルがREADME記載の量子化・非量子化の経路で読み込めるか、そして書き出したGGUFをOllamaやllama.cppで実際に動かせるかである。v0.5.1が量子化ベースへのsave_pretrained_mergedの修正である以上、量子化モデルを扱うならこの版以降を使う。
コミュニティノート