MLXとは？mlx-lmの使い方｜生成・量子化・サーバ・LoRAの手順とApple Siliconでの採用判断【2026年10月】

MLXは、Appleの機械学習研究チームがGitHubのml-exploreで公開している配列計算フレームワークです。LLMを動かすときに実際に使うのは、その上に作られたmlx-lmで、Hugging Faceのモデルの取得から生成、量子化、OpenAI互換のAPIサーバ、LoRAによる追加学習までをコマンド1本ずつで回せます。2026年10月24日時点のPyPIの最新は、MLXが0.32.4（10月14日）、mlx-lmが0.32.2（10月16日）です。この記事では、mlx-lmの使い方を手順ごとに実行結果つきで示し、導入要件、M5世代やOllamaのMLX対応で変わった速度の前提、vLLMへ渡す境目までを整理します。ローカルLLMそのものの考え方はローカルLLMとは？クラウド型との違い・必要スペック・Ollamaでの構築手順を解説で扱っています。

まとめ：mlx-lmでできることとOllama・vLLMとの分岐点

• mlx-lmは pip install mlx-lm で入り、mlx_lm.generate（生成）、mlx_lm.chat（対話）、mlx_lm.convert（変換と量子化）、mlx_lm.server（OpenAI互換API）、mlx_lm.lora（LoRA・QLoRA学習）が主なコマンド。0.32.2ではAWQ・GPTQ・DWQの量子化コマンドも同梱される
• Macで使う条件はApple Silicon、ネイティブ（Rosettaでない）のPython、macOS 14.0以上。mlx-lm 0.32.2はPython 3.11以上を要求し、MLX本体の3.10以上より1段高い
• Linuxでも mlx[cuda12]・mlx[cuda13]・mlx[cpu] で動く。Intel Mac向けのホイールは無い
• mlx_lm.server は0.32.2で並列リクエストのバッチ処理（デコード既定32件・プロンプト処理既定8件）に対応したが、公式は今も「本番には推奨しない」と明記している
• チャットで使うだけならOllamaやLM Studioが内部でMLXを使うので、mlx-lmを直接触る理由は、量子化方式を選ぶ、LoRAで学習する、Pythonへ組み込む、の3つに絞られる
• 社外の利用者に向けた本番推論は、LinuxのGPUサーバでvLLMへ渡す。Macは検証と学習の場に置く

MLXの設計とユニファイドメモリ・遅延評価が推論速度に効く仕組み

MLXのAPIはNumPyに近い書き味で、Python・C++・C・Swiftから使えます。PyTorchやJAXと並べたときの差は、メモリの持ち方と評価のタイミングの2点です。

ml-explore/mlxの位置付けと0.32系の更新頻度

リポジトリのml-explore/mlxはスター数28,899（2026年10月24日時点）で、PyPIのmlxには0.32.0（7月7日）から0.32.4（10月14日）まで約3か月半で5本の版が出ています。mlx-lmは0.31.3（4月22日）の後に約5か月あき、10月1日から16日までに0.32.0〜0.32.2の3本が出ました。

更新が速いぶん、古い版では新しいモデルのアーキテクチャを読めないことがあります。検証環境で動いたモデルを別の端末で再現するときは、mlx と mlx-lm の版を両方固定してください。mlx-lm 0.32.2は依存として mlx>=0.32.2 と transformers>=5.7.0 を引き込みます。

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") のようなデバイス間コピーがなく、CPUで作った c をGPU側の演算へそのまま渡せます。LLM推論でこれが効くのは、重み全体をGPU専用メモリへ転送する工程がなく、搭載メモリの範囲であればVRAMの容量に縛られずにモデルを載せられる点です。

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回あたり数十〜数千の演算です。上の mx.eval とは別の位置で未評価の配列を print すると、そこでも評価が走り、グラフが細切れになります。損失のログ出力は数十ステップおきに間引いてください。

MLXとmlx-lmをインストールする手順と動作要件

導入は pip install mlx-lm の1行で、MLX本体も依存として入ります。ただし要件を外すと入らないか、入っても遅い状態で動きます。公式のインストール手順が挙げる条件は、Apple Silicon、ネイティブのPython 3.10以上、macOS 14.0以上の3つです。

Rosetta経由の誤導入を防ぐターミナルとPythonの確認

公式のトラブルシューティングが挙げる失敗が、Intel向けのPythonをRosetta経由で動かしたまま入れてしまうケースです。この場合、pipは「対応する配布物が見つからない」と返します。ターミナルやPythonがx86として動いていないかを先に確かめます。

# arm と出れば OK。x86 や i386 なら Rosetta 経由
uname -p
python -c "import platform; print(platform.processor())"

pip install mlx-lm
python -c "import mlx.core as mx; print(mx.__version__, mx.default_device())"

最後の行で版番号と Device(gpu, 0) が表示されれば、Metalのバックエンドで動いています。x86と出た場合は、Finderでターミナルの情報を開き「Rosettaを使用して開く」のチェックを外してください。

mlx-lm 0.32.2のPython 3.11要件とpip・Homebrew・condaの選び方

見落としやすいのが、mlx-lmのPython要件です。MLX本体は3.10以上で入りますが、PyPIのmlx-lm 0.32.2は requires_python >=3.11 です。3.10の環境では古いmlx-lmが選ばれ、新しいモデルが読めない状態になります。

Homebrewのmlx-lmはApple Silicon向けのビルド済みバイナリだけが配られ、Python 3.15を依存に持つ独立した環境に入ります。コマンドとして使うには手軽ですが、自分のPythonコードから import mlx_lm したいならpipでvenvへ入れてください。[train] を付けずに入れると、mlx_lm.lora の実行時に依存が足りずに止まります。

LinuxのCUDA 12・13とCPU専用、Intel Mac・Windowsの扱い

0.32系のMLXはMac専用ではありません。LinuxでもNVIDIA GPUとCPUのバックエンドが公式の導入手順に載っており、mlx-lmにも同じ名前のextrasがあります。

# NVIDIA GPU（CUDA 12 系ドライバ 550.54.14 以上）
pip install "mlx-lm[cuda12]"

# NVIDIA GPU（CUDA 13 系ドライバ 580 以上）
pip install "mlx-lm[cuda13]"

# CPU のみ
pip install "mlx-lm[cpu]"

CUDA版の条件は、GPUアーキテクチャがSM 7.5以上、CUDAツールキット12.0以上、glibc 2.35以上のディストリビューションです。Ubuntuなら22.04以降が該当します。PyPIのmlx 0.32.4のホイールはmacOS（arm64）、Linux（x86_64とaarch64）、Windows（amd64とarm64）の3系統で、Intel Mac向けはありません。Windows向けは0.32.0でJITコンパイラにも対応しましたが、公式の導入手順には今も記載がないため、業務の検証環境には使わないでください。

mlx-lmでHugging Faceのモデルを生成・チャット・量子化する手順

LLMを扱うなら、MLX本体ではなくmlx-lmから入るのが近道です。変換済みモデルの多くはHugging Faceのmlx-communityで配布されており、リポジトリ名をそのまま渡せば初回に自動で取得されます。モデルを指定しない場合は mlx-community/Llama-3.2-3B-Instruct-4bit が使われます。

mlx_lm.generateとmlx_lm.chatで最初の1回を動かす

mlx_lm.generate --model mlx-community/Mistral-7B-Instruct-v0.3-4bit \
  --prompt "日本の首都はどこですか" --max-tokens 200

# 対話モード（REPL を閉じるまで会話の文脈を保持する）
mlx_lm.chat --model mlx-community/Mistral-7B-Instruct-v0.3-4bit

生成が終わると、プロンプトと生成それぞれの毎秒トークン数と、ピークのメモリ使用量（Peak memory）が表示されます。この値はMLXが確保したメモリの最大値で、キャッシュ用のバッファやOS・他のアプリの分は含みません。メモリが足りるかは、この値を目安にアクティビティモニタでシステム全体の使用状況も見て判断します。0.32.2の mlx_lm.generate には、画像を渡す --image、KVキャッシュを量子化する --kv-bits、投機的デコードの --draft-model もあります。

Python APIでアプリに組み込むときのチャットテンプレート

アプリへ組み込むときは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

# 層ごとにビット数を変える混合量子化
mlx_lm.convert --model mistralai/Mistral-7B-Instruct-v0.3 -q \
  --quant-predicate mixed_4_6 --mlx-path ./mistral-7b-mixed

--q-mode の選択肢はaffine・mxfp4・nvfp4・mxfp8の4種で、--quant-predicate にはmixed_2_6・mixed_3_4・mixed_3_6・mixed_4_6の4つのレシピがあります。affineの4ビットで変換したモデルの config.json には、"bits": 4、"group_size": 64、"mode": "affine" が書き込まれます。出力先に同名のディレクトリが既にあると、ValueError: Cannot save to the path ... as it already exists. で止まるので、作り直すときは先に消してください。量子化方式ごとの精度と容量の差はLLM量子化とは？仕組みとGPTQ・AWQ・GGUFの違い・企業の採用判断を解説【2026年版】で整理しています。

mlx-lm 0.32.2が入れるコマンドの一覧と用途

pipで入れると、次のコマンドがPATHに追加されます。手順の解説で触れられるのは前半の6つ程度ですが、量子化の手法を比べたいときや、学習の前後で精度を測りたいときは後半を使います。

wired_limit_mbを引き上げて大きなモデルを載せるときの注意

搭載メモリに対してモデルが大きいと、生成が極端に遅くなります。mlx-lmのREADMEによると、mlx-lmはモデルとキャッシュが使うメモリを固定（wired）して速くしようとし、この動作にはmacOS 15以上が必要です。[WARNING] Generating with a model that requires ... と出たら、システムの固定メモリの上限を引き上げると速くなることがあります。

# 例：64GB 機で GPU 側へ 56GB まで固定を許す（再起動で元に戻る）
sudo sysctl iogpu.wired_limit_mb=57344

値はモデルのサイズ（MB）より大きく、搭載メモリより小さくします。上げすぎると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番です。0.32.2の server.py が受け付けるのは、POSTが /v1/chat/completions・/chat/completions・/v1/completions、GETが /v1/models と死活監視用の /health です。OpenAI SDKからは base_url を http://localhost:8080/v1 に向ければ呼べます。リクエストに温度などを書かなかったときの既定値は、temperature が0.0、max_tokens が512で、起動時の --temp や --max-tokens で変えられます。

並列リクエストのバッチ処理と逐次処理に切り替わる条件

0.32.2のサーバは、同時に届いたリクエストをまとめて処理します。起動オプションの既定値は、デコードを並行させる --decode-concurrency が32件、プロンプトの処理を並行させる --prompt-concurrency が8件です。1台のMacを数人で共有する検証なら、待ち行列で詰まりにくくなりました。

ただし、次のどれかに当たるとバッチ処理は無効になり、リクエストは1件ずつ処理されます。設定で起きる主な条件は次の3つです。

• 起動時に --kv-bits でKVキャッシュを量子化した（SERVER.mdにも「量子化したKVキャッシュはバッチに対応しない」と明記）
• 起動時に --draft-model で投機的デコードを有効にした
• リクエストに seed を指定した

このほか、画像を含むリクエストは逐次処理され、KVキャッシュがまとめ処理（merge）に対応していないモデルもバッチになりません。

長い文書を読ませるためにKVキャッシュを量子化すると、同時利用には弱くなります。メモリを取るか同時処理を取るか、どちらかを選ぶ設計です。KVキャッシュが何を保持しているかはKVキャッシュとは？LLM推論を高速化する仕組みとメモリ削減・実装判断を実装者向けに解説【2026年版】で解説しています。

mlx_lm.serverを公式が本番非推奨とする理由と社内PoCでの線引き

SERVER.mdは、基本的なセキュリティチェックしか実装していないため本番での利用は推奨しない、と明記しています。0.32.2では、起動するたびに UserWarning: mlx_lm.server is not recommended for production as it only implements basic security checks. が表示されます。認証もレート制限もなく、--allowed-origins の既定は全オリジン（*）です。

線引きは単純で、使ってよいのは開発者本人か、閉じたチーム内の数人が試すPoCまでです。--host で外部に公開すること自体はできますが、業務部門へ公開する段階に入ったら、推論はvLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いを実装者目線で解説で扱った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

train.jsonl の件数がバッチサイズ（既定4）より少ないと、ValueError: Dataset must have at least batch_size=4 examples ... で学習が始まりません。上の1行は形式の例で、実際の追加学習には業務データを十分な件数そろえます。学習の冒頭には、モデル・LoRAを掛ける層数とランク・最適化手法・学習率・バッチサイズの一覧と、学習するパラメータの割合（Trainable parameters）が出ます。既定ではランク8のLoRAが16層に掛かります。chat形式とcompletions形式では、--mask-prompt を付けると質問側の文を損失の計算から外せます。評価は test.jsonl を用意して --test を付けると、テストデータの損失とパープレキシティが出ます。LoRAとQLoRAの仕組みそのものはQLoRAとは？4bit量子化＋LoRAの仕組み・VRAM目安・実装手順と採用判断を解説【2026年版】を参照してください。

メモリ不足を避けるbatch-sizeとnum-layersの下げ方

LORA.mdがメモリ不足の対処として挙げるのは次の5つです。

• QLoRAにする：mlx_lm.convert -q で作った量子化モデルを指定する
• バッチを小さくする：--batch-size の既定は4。2か1に下げ、減った分は --grad-accumulation-steps で勾配をためて補う
• LoRAを掛ける層を減らす：--num-layers の既定16を8か4に。データが多いと仕上がりが落ちることがある
• 学習データの1件を短く分ける
• --grad-checkpoint で中間値を保存せず計算し直す

公式の例では、メモリ32GBの機械でMistral 7Bを --batch-size 1 --num-layers 4 で学習すると、M1 Maxで毎秒約250トークンです。最初は量子化モデルとバッチサイズから触り、層数は最後に減らすのが仕上がりを落としにくい順番です。

Apple Siliconが無い環境でmlx-lm 0.32.2を動かした実測結果

CPU専用版を使えば、Linuxのコンテナでもmlx-lmのコマンドを一通り試せます。2026年10月24日、IntelのMac上のcolima（Linux x86_64、4CPU）で python:3.12-slim のコンテナに pip install "mlx-lm[cpu,train]==0.32.2" を入れ、1.35億パラメータの小さなモデルSmolLM2-135M-Instructで各コマンドを実行しました。入ったのはmlx 0.32.4で、既定のデバイスは Device(cpu, 0) と表示されます。

変換・生成・サーバ・LoRAの各コマンドで確かめた挙動

4ビットを指定しても4.503ビットと出るのは、64個ずつのグループごとにスケールとバイアスを持つ分（約0.5ビット）と、量子化しない層の分を含めたモデル全体の平均だからです。ファイルは元の約28%に縮みました。応答の system_fingerprint には 0.32.2-0.32.4-Linux-... のように、mlx-lmとmlxの版とOSが入ります。複数の端末で結果が食い違ったときは、まずこの値を突き合わせると原因を絞れます。

CPU版で済む作業と、Apple Siliconの実機が要る作業

今回の4CPUのコンテナでは、速度は実用になりませんでした。1.35億パラメータのモデルで生成が毎秒0.9トークン、LoRAでは検証損失の計算2バッチに約160秒かかり、7B級の評価には使えません。この環境でのCPU版の使いどころは、手順書やCIでコマンドの引数・データ形式・APIの応答形式が正しいかを確かめるところまでです。LoRAも同じで、--num-layers 2 --batch-size 1 に絞ると学習するパラメータは全体の0.121%（16.3万個）になり、6反復に約15分かかりました。それでも adapters.safetensors（654KB）が保存され、mlx_lm.fuse で本体へ統合したモデルも書き出されたので、学習データの形式や保存先、統合までの流れを確かめる用途には使えます。一方で、速度、メモリの見積もり、学習の仕上がりは、Metalで動くApple Siliconの実機で測ってください。CPUの数値をMacの性能の目安にしてはいけません。

M5・M6のNeural AcceleratorsとOllama・LM StudioのMLX対応

MLXの速度の前提は、ハードウェアとアプリの両面で変わりました。ハードウェアではM5以降のGPUに載ったNeural Accelerators、アプリではOllamaやLM StudioがMLXを推論エンジンとして使っていることです。

M4比でTTFT最大4倍・生成1.2倍前後というApple公表値の読み方

Appleの機械学習研究ブログによると、M5はM4に比べて最初のトークンが出るまでの時間（TTFT）が3.33〜4.06倍速く、後続トークンの生成は1.19〜1.27倍の伸びにとどまります。計測はメモリ24GBのMacBook Pro同士で、プロンプト4,096トークン、生成128トークンの条件です。たとえばQwen3-14Bの4ビット版はTTFTが4.06倍、生成が1.19倍で、使用メモリは9.16GBでした。M5のNeural AcceleratorsをMLXで使うにはmacOS 26.2以上が要ります。

伸び方が違うのは、後続トークンの生成が演算能力ではなくメモリ帯域に律速されるためです。帯域はM4の120GB/sからM5の153GB/s（28%増）にしか増えていません。長い文書を読ませるRAGのように入力が長い用途ほどM5の恩恵が大きく、短い質問に長く答えさせるチャット用途では差が縮みます。2026年8月に出たM6も、12コアのGPUの各コアにNeural Acceleratorを載せています。GPUのNeural AcceleratorとNeural Engineの違いはNeural Engine（ANE）とは？16コアの意味・Neural Acceleratorとの違い・M6世代の変化で整理しています。

OllamaのMLXエンジンとGGUFの使い分け

Ollamaは2026年3月30日の0.19で、Apple Silicon上の推論をMLXで動かすプレビューを始めました。6月5日の0.30の発表では、llama.cpp経由のGGUF互換を「Apple silicon上のOllamaのMLXエンジンを補うもの」と説明しており、Macでの主役はMLX側に移っています。6月11日にはMLXエンジンの更新で、NVIDIAのNVFP4形式に対応し、出力が最大20%速くなりました。10月24日時点のOllamaの最新版は0.40.10です。

Mac上の推論エンジンとしてはOllamaもMLXを使うため、速度の差でmlx-lmを選ぶ理由は薄れています。WindowsやLinuxのCPU環境まで同じモデルファイルで配りたいなら、GGUFとは？量子化モデルフォーマットの仕組みとGPTQ・AWQとの違い・採用判断を解説【2026年版】で扱ったGGUFを選びます。

LM Studioのmlx-engineとWWDC26でのCore AIとの役割分担

Mac版のLM Studioは0.3.4以降、MLXで推論するmlx-engineを同梱しています。コマンドを使わずにMLX形式のモデルを選んで試すなら、LM Studioが候補になります。設定の詳細はLM StudioのMCP設定とGemma 4のMTP設定｜mcp.json・Web検索・動かない時の対処【2026年10月】にまとめています。

WWDC26でAppleは、アプリへ組み込む推論の層としてCore AIを新設しました。WWDC26の機械学習ガイドは、MLXについてはMetal 4とGPU Neural Acceleratorsへの対応と、Thunderbolt経由のRDMAで複数のMacへ学習を広げる機能を紹介しています。iPhoneアプリへモデルを入れるならCore AIやCore ML、Macでの研究と学習ならMLXという分担です。Core MLとCore AIの使い分けはCore MLとは？Create ML・coremltools 9でのモデル作成とSwift推論、Core AIとの使い分けで解説しています。

MLXを採用しない案件条件と本番推論をvLLMへ渡す分岐の引き方

ここからは、受託開発の現場でMLXをどこまで使うかの線引きです。

開発機はMLX・本番はLinux GPUで分ける構成が合う案件

社内文書を扱うLLMシステムのPoCで、データを社外のAPIへ出せない場合がこの構成の出番です。開発者のMacでmlx-lmを使ってモデルを選び、LoRAで業務データに合わせ、OpenAI互換APIで画面から呼べるところまで作ります。評価が通ったら、同じ元モデルとアダプタの学習条件をLinuxのGPUサーバへ持ち込み、vLLMで提供します。

MLX形式の重みは本番へ運びません。持ち出すのはモデル選定の結論、学習データ、ハイパーパラメータの記録で、本番側は元のHugging Face形式から組み直します。mlx_lm.server がバッチ処理に対応しても、認証や監視を含む提供の機能はvLLM側が厚いためです。

端末構成・同時利用数・配布先によるMLX不採用の判断

次の条件に当てはまるなら、MLXは選びません。

• 開発メンバーの端末にWindowsやIntel Macが混ざる：同じ手順で再現できず、検証結果が人によって変わる
• 最初から数十人以上の同時利用を前提にする：Macで作った構成は捨てることになり、初手からvLLMで組んだほうが早い
• iPhoneやiPadのアプリへモデルを同梱し、OSが提供する最適化や保証を使いたい：Core AIとCore MLの領域。MLX SwiftでもiOSで動く例はあるが、この記事のPython版mlx-lmはMac・Linux向け

逆に、端末がApple Siliconで揃い、データを外へ出せず、学習まで手元で回したいチームには、生成・量子化・API・LoRAが1つのパッケージで揃うmlx-lmが合います。PoCから本番のLLM基盤への載せ替えまでをまとめて任せたい場合は、生成AI開発・AI受託開発で相談を受け付けています。

よくある質問

MLXとPyTorchのMPSはどちらを使えばよいですか？

既存のPyTorchのコード資産をMacでも動かしたいならMPS、Apple Siliconで新規にLLMを動かすならMLXです。MLXはユニファイドメモリを前提に設計されており、デバイス間のコピーを書く必要がありません。LLMの生成・量子化・学習はmlx-lmでコマンド化されているため、同じことをPyTorchで組むより手数が少なく済みます。

メモリは何GBあれば動きますか？

目安は、モデルの重みのサイズに生成時のキャッシュ分を足した量です。4ビット量子化の7〜8Bモデルなら重みは4〜5GB程度で、16GB機でも生成できます。Appleの計測ではQwen3-14Bの4ビット版が9.16GB、Qwen3-30B-A3Bの4ビット版が17.31GBを使っており、30B級を扱うなら32GB以上が現実的です。実際の使用量は mlx_lm.generate が最後に表示する Peak memory で確かめられます。

Homebrewでmlx-lmを入れても問題ありませんか？

コマンドとして使うだけなら問題ありません。2026年10月24日時点のHomebrewのmlx-lmは0.32.2で、PyPIと同じ版です。ただしHomebrewの独立したPython環境に入るため、自分のスクリプトから import mlx_lm したい場合や、LoRA学習用の追加依存を入れたい場合は、venvを作ってpipで入れてください。

GGUFとMLX形式のモデルは何が違いますか？llama.cppとどちらを使うべきですか？

GGUFはllama.cppが使う単一ファイルの形式で、CPUやWindowsを含む幅広い環境で動きます。MLX形式はsafetensorsの重みと設定ファイルの組で、Apple SiliconのMetal上で速く動くことを優先した形です。Mac専用で速度を取るならMLX形式とmlx-lm、配布先の環境が読めないならGGUFとllama.cppを選びます。どちらも元のHugging Faceモデルから変換して作ります。

mlx-lmで作ったLoRAアダプタは他の環境へ持ち出せますか？

MLXの環境内であれば、--adapter-path で読み込むか、mlx_lm.fuse で本体へ統合して使えます。PyTorch系の推論環境へそのまま載せる手順は公式ドキュメントに書かれていないため、本番をvLLMで回す予定なら、学習データとハイパーパラメータを残し、本番側の学習環境で同じ条件で学習し直す計画にしておくのが安全です。LoRAのランクや係数の決め方はLoRA（Low-Rank Adaptation）とは？仕組み・ランクrとalphaの決め方とLoRA-Proの違いで解説しています。

関連記事

• ローカルLLMとは？クラウド型との違い・必要スペック・Ollamaでの構築手順を解説
• GGUFとは？量子化モデルフォーマットの仕組みとGPTQ・AWQとの違い・採用判断を解説【2026年版】
• vLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いを実装者目線で解説
• QLoRAとは？4bit量子化＋LoRAの仕組み・VRAM目安・実装手順と採用判断を解説【2026年版】
• Neural Engine（ANE）とは？16コアの意味・Neural Acceleratorとの違い・M6世代の変化