MLXは、Appleの機械学習研究チームがGitHubのml-exploreで公開している配列計算フレームワークです。PyPIの最新は0.32.3(2026年9月29日公開)で、ライセンスはMITです。この記事では、MLXの設計上の特徴であるユニファイドメモリと遅延評価、pipでの導入要件、mlx-lmを使ったLLMの生成・量子化・OpenAI互換サーバ・LoRA学習の手順を、公式ドキュメントとPyPI・GitHubの実測値で整理します。M5世代の速度やOllamaのMLX対応を踏まえ、GGUFやvLLMとの使い分けも、条件付きで結論を示しました。ローカルLLMそのものの考え方はローカルLLMの全体像と構築手順をまとめた記事で扱っています。
まとめ:MLXを選ぶ条件とOllama・llama.cpp・vLLMとの分岐点
MLXが力を発揮するのは、Apple Siliconの手元機でモデルを試し、量子化し、LoRAで追加学習するところまでです。ユニファイドメモリのおかげで、GPUの専用VRAMに収まらない規模のモデルもメモリ量の範囲で載せられます。mlx-lmを入れれば、Hugging Face上のモデルの取得から生成、量子化、OpenAI互換APIの起動、LoRA学習までがコマンド1本ずつで回ります。
一方、社外の利用者を相手にする本番推論には使いません。mlx-lmのHTTPサーバは公式ドキュメント自身が本番非推奨と明記しており、同時接続をさばく設計にもなっていないためです。本番はLinuxのGPUサーバでvLLMへ渡し、Macは検証と学習の場に置く。この分業が、MLXを採用するときの基本形になります。Ollamaで十分な用途なら、MLXを直接触る必要すらありません。
MLXの設計とユニファイドメモリ・遅延評価が推論速度に効く仕組み
MLXのAPIはNumPyに近い書き味で、Python・C++・C・Swiftから使えます。PyTorchやJAXと並べたときの差は、メモリの持ち方と評価のタイミングの2点に集約されます。
ml-exploreが公開するMLXの位置付けと0.32系の更新頻度
リポジトリのml-explore/mlxはスター数28,599(2026年9月29日時点)で、リリースはv0.32.0(7月7日)からv0.32.3(9月29日)まで約3か月で4本出ています。Swift版のmlx-swiftも9月28日に0.32.2が出ており、Python版と歩調を合わせて進む体制です。
更新が速いぶん、古い版では新しいモデルのアーキテクチャに対応していないことがあります。検証環境で動いたモデルを別の端末で再現するときは、mlxとmlx-lmの版を両方固定してください。
CPUとGPUが同じメモリを読むユニファイドメモリの実装上の意味
Apple SiliconはCPUとGPUが同じメモリプールへ直接アクセスする構造です。公式のユニファイドメモリ解説にあるとおり、MLXでは配列を作るときにデバイスを指定しません。実行先は演算ごとにstreamで選びます。
import mlx.core as mx
a = mx.random.normal((100,))
b = mx.random.normal((100,))
c = mx.add(a, b, stream=mx.cpu) # CPU で実行
d = mx.add(a, c, stream=mx.gpu) # GPU で実行。c の完成を待ってから走る
PyTorchで書き慣れた.to("cuda")のようなデバイス間コピーが存在しません。2行目のcはCPUで作られた配列ですが、GPU側の演算へそのまま渡せます。依存関係はスケジューラが解決するため、順序を手で管理する必要もありません。LLM推論でこれが効くのは、重み全体をGPU専用メモリへ転送する工程がなく、搭載メモリの範囲まで大きなモデルを置ける点です。
mx.evalを呼ぶ位置で決まる遅延評価のオーバーヘッドと書き方
MLXの演算は、書いた時点では計算されません。printやNumPyへの変換、item()、mx.eval()の呼び出しで初めてグラフが評価されます。学習ループでは、公式の遅延評価の解説が次の書き方を推奨しています。
for batch in dataset:
loss, grad = value_and_grad_fn(model, batch)
optimizer.update(model, grad)
mx.eval(loss, model.parameters())
評価には1回ごとに固定のオーバーヘッドがあり、グラフが巨大すぎてもコストが膨らみます。公式が目安に挙げるのは1回あたり数十〜数千の演算です。ループの内側で毎回printすると、そのたびに評価が走って遅くなります。ログ出力は数十ステップおきに間引いてください。
pip install mlxの動作要件とmacOS 14以上・ネイティブarmの確認手順
導入はpip install mlxの1行ですが、要件を外すと入らないか、入っても遅い状態で動きます。公式のインストール手順が挙げる条件は、Apple Silicon、ネイティブのPython 3.10以上、macOS 14.0以上の3つです。
RosettaのPythonで入れてしまう失敗をuname -pで防ぐ
最も多い失敗は、Intel向けのPythonをRosetta経由で動かしたまま入れてしまうケースです。ターミナルやPythonがx86として動いていないかを先に確かめます。
# arm と出れば OK。x86 や i386 なら Rosetta 経由
uname -p
python -c "import platform; print(platform.processor())"
pip install mlx
python -c "import mlx.core as mx; print(mx.__version__, mx.default_device())"
最後の行で版番号とDevice(gpu, 0)が表示されれば、Metalのバックエンドで動いています。x86と出た場合は、Finderでターミナルの情報を開き「Rosettaを使用して開く」のチェックを外してください。Homebrewやpyenvで入れたPythonが古いIntel版のまま残っている開発機もよく見かけます。
LinuxのCUDA 12・13とCPU専用で入れるextrasの選び方
0.32系のMLXは、Mac専用ではありません。LinuxでもNVIDIA GPUとCPUのバックエンドが公式の導入手順に載っています。
# NVIDIA GPU(CUDA 12 系ドライバ 550.54.14 以上)
pip install "mlx[cuda12]"
# NVIDIA GPU(CUDA 13 系ドライバ 580 以上)
pip install "mlx[cuda13]"
# CPU のみ
pip install "mlx[cpu]"
# mlx-lm も CUDA 付きで入れる場合
pip install "mlx-lm[cuda13]"
CUDA版の条件は、GPUアーキテクチャがSM 7.5以上、CUDAツールキット12.0以上、glibc 2.35以上のディストリビューションです。Ubuntuなら22.04以降が該当します。PyPIのmlxにはWindows向けのホイールも並んでいますが、公式の導入手順には記載がないため、業務の検証環境には使わないでください。Macで書いたMLXのコードをLinuxのGPUサーバで再現できるようになった点は、チーム開発の前提を変えます。
mlx-lmでHugging Faceのモデルを生成・チャット・量子化する手順
LLMを扱うなら、MLX本体ではなくmlx-lmから入るのが近道です。PyPIの最新は0.31.3(2026年4月22日)で、依存としてmlx 0.31.2以上とtransformers 5.0.0以上を引き込みます。
mlx_lm.generateとPython APIで最初の1回を動かす手順
モデルを指定しない場合はmlx-community/Llama-3.2-3B-Instruct-4bitが使われます。変換済みモデルの多くはHugging Faceのmlx-communityで配布されており、リポジトリ名をそのまま渡せば初回に自動で取得されます。
pip install mlx-lm
mlx_lm.generate --model mlx-community/Mistral-7B-Instruct-v0.3-4bit \
--prompt "日本の首都はどこですか" --max-tokens 200
# 対話モード
mlx_lm.chat --model mlx-community/Mistral-7B-Instruct-v0.3-4bit
アプリへ組み込むときはPython APIを使います。チャットテンプレートの適用を忘れると、指示に従わない出力が返るので注意してください。
from mlx_lm import load, stream_generate
model, tokenizer = load("mlx-community/Mistral-7B-Instruct-v0.3-4bit")
messages = [{"role": "user", "content": "MLXの特徴を3行で"}]
prompt = tokenizer.apply_chat_template(messages, add_generation_prompt=True)
for r in stream_generate(model, tokenizer, prompt, max_tokens=256):
print(r.text, end="", flush=True)
mlx_lm.convertの-qとq-modeで自前の量子化モデルを作る
配布されていないモデルは、Hugging Faceの元モデルから自分で変換します。-qを付けると量子化が有効になり、ビット数は--q-bits、グループサイズは--q-group-sizeで指定できます。
mlx_lm.convert --model mistralai/Mistral-7B-Instruct-v0.3 -q \
--mlx-path ./mistral-7b-4bit
# 方式を変える場合(affine が既定)
mlx_lm.convert --model mistralai/Mistral-7B-Instruct-v0.3 -q \
--q-mode mxfp4 --mlx-path ./mistral-7b-mxfp4
--q-modeの選択肢はソース上でaffine・mxfp4・nvfp4・mxfp8の4種です。出力先を省くとmlx_modelに書き出され、同名のディレクトリが既にあると例外で止まります。量子化方式ごとの精度と容量のトレードオフはLLM量子化の仕組みと採用判断をまとめた記事で整理しています。
wired_limit_mbを引き上げて大きなモデルを載せるときの注意
搭載メモリに対してモデルが大きいと、生成が極端に遅くなります。macOSがGPUに固定で割り当てるメモリ量には上限があり、mlx-lmのREADMEはmacOS 15.0以上で上限を引き上げる方法を示しています。
# 例:64GB 機で GPU 側へ 56GB まで割り当てる(再起動で元に戻る)
sudo sysctl iogpu.wired_limit_mb=57344
上げすぎるとOSや他のアプリの分が足りなくなり、システム全体が不安定になります。検証機で一時的に使う設定として扱い、共用の開発機では既定値に戻してください。
mlx_lm.serverでOpenAI互換APIを立てて既存コードから呼ぶ手順
mlx-lmには、OpenAIのChat APIに似た形のHTTPサーバが同梱されています。既存のOpenAI SDKを使うコードの接続先を差し替えるだけで、ローカルのモデルへ向け直せます。
mlx_lm.serverを8080番で起動してチャットAPIへ送る例
mlx_lm.server --model mlx-community/Mistral-7B-Instruct-v0.3-4bit
curl localhost:8080/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"messages": [{"role": "user", "content": "Say this is a test!"}], "temperature": 0.7}'
既定の待ち受けは127.0.0.1の8080番で、エンドポイントは/v1/chat/completionsと/v1/modelsです。OpenAI SDKからはbase_urlをhttp://localhost:8080/v1へ向ければ呼べます。--hostで外部に公開すること自体は可能ですが、次の理由で勧めません。
mlx_lm.serverを公式が本番非推奨とする理由と社内PoCでの線引き
SERVER.mdは、基本的なセキュリティチェックしか実装していないため本番での利用は推奨しない、と明記しています。認証もレート制限もなく、1台のMacのメモリ帯域を全リクエストで分け合う構造です。
線引きは単純で、使ってよいのは開発者本人か、閉じたチーム内の数人が試すPoCまでです。業務部門へ公開する段階に入ったら、推論はvLLMの仕組みと導入手順を解説した記事で扱ったLinuxのGPUサーバ構成へ移してください。
mlx_lm.loraでLoRAとQLoRAの追加学習をMac上で回す手順
MLXは推論専用ではなく、学習もこなせます。mlx-lmのLoRAの解説によると、微調整の種類はlora(既定)、dora、fullの3つで、量子化済みモデルを指定すると自動的にQLoRAになります。
train.jsonlとvalid.jsonlの配置と学習コマンドの最小形
データディレクトリにtrain.jsonlを置くのが必須で、valid.jsonlは任意です。形式はchat・tools・completions・textから選べます。
# data/train.jsonl の1行(chat 形式)
{"messages": [{"role": "user", "content": "返品期限は?"}, {"role": "assistant", "content": "到着後14日以内です。"}]}
# 学習(4bit モデルを指定すると QLoRA になる)
mlx_lm.lora --model mlx-community/Mistral-7B-Instruct-v0.3-4bit \
--train --data ./data --iters 600
# アダプタを使って生成、または本体へ統合
mlx_lm.generate --model mlx-community/Mistral-7B-Instruct-v0.3-4bit \
--adapter-path ./adapters --prompt "返品期限は?"
mlx_lm.fuse --model mlx-community/Mistral-7B-Instruct-v0.3-4bit
評価はtest.jsonlを用意して--testを付けると、テストデータのパープレキシティが出ます。LoRAとQLoRAの仕組みそのものはQLoRAの仕組みとVRAM目安を解説した記事を参照してください。
メモリ不足を避けるbatch-sizeとnum-layersの下げ方
メモリが足りないときに公式が挙げる対処は3つです。効きが大きい順に、--batch-sizeを下げる、--num-layersでLoRAを掛ける層を減らす、--grad-checkpointで勾配チェックポイントを有効にする、の順で試します。
層を減らすと学習の効きも弱くなるため、まずバッチサイズから触るのが定石です。バッチを下げた分は--grad-accumulation-stepsで勾配を複数ステップ分ためて補えます。
M5のNeural AcceleratorsとOllamaのMLX対応で変わる速度の前提
2025年11月以降、MLXの速度を語る前提が2つ変わりました。M5チップのGPUに載ったNeural Acceleratorsと、OllamaによるMLXの取り込みです。
M4比でTTFT最大4倍・生成1.2倍前後というApple公表値の読み方
Appleの機械学習研究ブログによると、M5はM4に比べて最初のトークンが出るまでの時間(TTFT)が3.33〜4.06倍速く、後続トークンの生成は1.19〜1.27倍の伸びにとどまります。Neural Acceleratorsを使うにはmacOS 26.2以上が要ります。
伸び方が違う理由は、同じ記事が説明しています。後続トークンの生成は演算能力ではなくメモリ帯域に律速され、帯域はM4の120GB/sからM5の153GB/s(28%増)にしか増えていません。長い文書を読ませるRAGのように入力が長い用途ほどM5の恩恵が大きく、短い質問に長く答えさせるチャット用途では差が小さい、と読むのが正確です。なお、ここで言うNeural AcceleratorsはGPU内の演算器で、Core MLが使うNeural Engine(ANE)とは別物です。
Ollama 0.19がMLXを取り込んだ意味とGGUFとの使い分け
Ollamaの公式ブログは2026年3月30日、0.19でApple Silicon上の推論をMLXで加速するプレビューを発表しました。Qwen3.5-35B-A3B(NVFP4)の計測で、prefillは毎秒1,154から1,810トークン、decodeは毎秒58から112トークンへ伸びています。推奨は32GB以上のユニファイドメモリです。
チャットで使うだけなら、MLXを直接触らずにOllamaを入れれば済む時代になりました。MLXを直接使う理由が残るのは、量子化方式を自分で選ぶ、LoRAで学習する、Pythonのコードへ組み込む、の3場面です。一方、WindowsやLinuxのCPU環境まで同じモデルファイルで配りたいなら、GGUFの仕組みと採用判断をまとめた記事で扱った形式のほうが運べる範囲は広くなります。
MLXを採用しない案件条件と本番推論をvLLMへ渡す分岐の引き方
ここからは、受託開発の現場でMLXをどこまで使うかの線引きです。
開発機はMLX・本番はLinux GPUで分ける構成が合う案件
社内文書を扱うLLMシステムのPoCで、データを社外のAPIへ出せない場合がこの構成の出番です。開発者のMacでmlx-lmを使ってモデルを選び、LoRAで業務データに合わせ、OpenAI互換APIで画面から呼べるところまで作ります。評価が通ったら、同じ元モデルとアダプタをLinuxのGPUサーバへ持ち込み、vLLMで提供します。
このときMLX形式の重みをそのまま本番へ運ぶことはしません。本番側は元のHugging Face形式から組み直す前提で、MLX側の成果として持ち出すのはモデル選定の結論、学習データ、ハイパーパラメータの記録です。0.32系でLinuxのCUDAバックエンドが入ったとはいえ、同時接続をさばくサーバ機能はvLLM側に分があります。
MLXを選ぶと遠回りになる案件を端末構成・同時利用数・配布先で見分ける
次の条件に当てはまるなら、MLXは選びません。
- 開発メンバーの端末にWindowsやIntel Macが混ざる:同じ手順で再現できず、検証結果が人によって変わる
- 最初から数十人以上の同時利用を前提にする:Macで作った構成は捨てることになり、初手からvLLMで組んだほうが早い
- iPhoneやiPadのアプリへモデルを同梱したい:配布の経路はCore MLが担う領域で、MLXは研究と開発機での利用が主軸
逆に、端末がApple Siliconで揃い、データを外へ出せず、学習まで手元で回したいチームには、MLXほど手数の少ない選択肢はありません。PoCから本番のLLM基盤への載せ替えまでをまとめて任せたい場合は、生成AI開発・AI受託開発で相談を受け付けています。
よくある質問
MLXの導入検討でよく挙がる質問を、公式ドキュメントとPyPI・GitHubの実測値をもとに整理します。
MLXとPyTorchのMPSはどちらを使えばよいですか?
既存のPyTorchのコード資産をMacでも動かしたいならMPS、Apple Siliconで新規にLLMを動かすならMLXです。MLXはユニファイドメモリを前提に設計されており、デバイス間のコピーを書く必要がありません。LLMの生成・量子化・学習はmlx-lmでコマンド化されているため、同じことをPyTorchで組むより手数が少なく済みます。最終的にLinuxのGPUで本番を回すなら、本番側のコードはPyTorch系で書く前提に置いてください。
メモリは何GBあれば動きますか?
目安は、モデルの重みのサイズに生成時のキャッシュ分を足した量です。4bit量子化の7〜8Bモデルなら重みは4〜5GB程度で、16GB機でも生成できます。30B級を扱うなら32GB以上が現実的で、Ollamaも0.19のMLXプレビューで32GB以上を推奨しています。載り切らない場合はmacOS 15.0以上でiogpu.wired_limit_mbを引き上げる方法もありますが、OS側の余裕を削る設定です。
MLXはWindowsやLinuxでも使えますか?
Linuxは使えます。公式の導入手順にmlx[cuda12]、mlx[cuda13]、mlx[cpu]が載っており、glibc 2.35以上が条件です。CUDA版はSM 7.5以上のGPUと、CUDA 12ならドライバ550.54.14以上、CUDA 13なら580以上が要ります。Windowsは、PyPIにホイールが並んでいるものの公式の導入手順に記載がないため、2026年9月時点では業務利用の前提に置かないでください。
GGUFとMLX形式のモデルは何が違いますか?
GGUFはllama.cppが使う単一ファイルの形式で、CPUやWindowsを含む幅広い環境で動きます。MLX形式はsafetensorsの重みと設定ファイルの組で、Apple SiliconのMetal上で速く動くことを優先した形です。Mac専用で速度を取るならMLX形式、配布先の環境が読めないならGGUFを選びます。どちらも元のHugging Faceモデルから変換して作るため、元モデルを保管しておけば後から切り替えられます。
mlx-lmで作ったLoRAアダプタは他の環境へ持ち出せますか?
MLXの環境内であれば、--adapter-pathで読み込むか、mlx_lm.fuseで本体へ統合して使えます。PyTorch系の推論環境へそのまま載せる手順は公式ドキュメントに書かれていないため、本番をvLLMで回す予定なら、学習データとハイパーパラメータを残し、本番側の学習環境で同じ条件で学習し直す計画にしておくのが確実です。
関連記事
- ローカルLLMとは?クラウド型との違い・必要スペック・Ollamaでの構築手順を解説:MLXを検討する前段の、ローカルLLMを選ぶかどうかの判断。
- GGUFとは?量子化モデルフォーマットの仕組みとGPTQ・AWQとの違い・採用判断を解説【2026年版】:MLX形式と並ぶもう一つのローカル実行用フォーマット。
- vLLMとは?PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いを実装者目線で解説:Macで検証したモデルを本番で提供する側の推論エンジン。
- QLoRAとは?4bit量子化+LoRAの仕組み・VRAM目安・実装手順と採用判断を解説【2026年版】:mlx_lm.loraが量子化モデルで行う学習方式の詳細。