Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

プロローグ — Mac で LLM が急に速くなった本当の理由

2023 年末、Apple の ML チームが GitHub に静かにあるフレームワークを公開した。名前は mlx。コミットの名前は見覚えのある面々 — PyTorch と JAX の主要コントリビューター。今回のターゲットは NVIDIA GPU でも TPU でもなく、Apple Silicon 専用 に書き直した配列フレームワークだった。

2 年が過ぎた 2026 年、Mac でローカル LLM を動かす人たちのワークフローはほぼすべて MLX に収束した。LM Studio、Ollama、Hugging Face のデモ、そして無数のインディー製デスクトップアプリのバックエンドが MLX を使っている。

理由はひとつの命題で済む。

「M シリーズの GPU は CPU と同じ RAM を使う。だからホストとデバイスの間に複製がない。」

この一文が、MLX と PyTorch の MPS バックエンドとの間にある桁違いの性能差をすべて説明する。本記事はこの命題を端から端まで広げる — 統合メモリ、遅延グラフ、mlx-lm と mlx-vlm、Python と Swift の API、そして実ワークロードでのトークン/秒まで。

1. 統合メモリ命題 — MLX の出発点

Apple Silicon のメモリ構造は NVIDIA のそれと違う。 すべての MLX の議論はここから始める必要がある。

NVIDIA システムでは、GPU は自身の VRAM を持つ。CPU の RAM と GPU の VRAM は物理的に別のチップで、両者の間のデータは PCIe を介して明示的に複製する必要がある。

       従来の GPU (NVIDIA)              Apple Silicon (M-series)
       ──────────────────              ────────────────────────
       ┌────┐    PCIe    ┌─────┐       ┌─────────────────────┐
       │CPU │ ◀────────▶ │ GPU │       │    CPU  +  GPU      │
       │RAM │            │VRAM │       │   同じメモリプール    │
       └────┘            └─────┘       └─────────────────────┘
       複製が必要                       複製がない

PyTorch の典型的なイディオムはその分離を前提にしている。x.to("cuda")、tensor.cpu() — その一行一行が PCIe をまたぐ複製だ。大きなモデルではこの複製が推論レイテンシの相当部分を食う。

Apple Silicon では CPU と GPU が同じメモリプールを見る。 CPU 上で作ったテンソルを GPU が読める — 複製なし、共有ポインタだけで。これが 統合メモリ (unified memory) だ。

MLX はこの事実をフレームワークの最深部に焼き付けた。MLX の配列はデバイスを持たない — デバイスは 演算の時点で 決まる。

import mlx.core as mx

a = mx.array([1.0, 2.0, 3.0])
b = mx.array([4.0, 5.0, 6.0])

# CPU で計算
c_cpu = mx.add(a, b, stream=mx.cpu)
# GPU で計算 — 同じ a, b。複製なし。
c_gpu = mx.add(a, b, stream=mx.gpu)

PyTorch なら a.to("mps") が必要だ。MLX にそんな呼び出しは存在しない。「デバイスへ移す」という概念自体がモデルにない。

これは単なる API の見栄えの差ではない。これは Mac で LLM が速い理由そのもの だ。

2. MLX vs PyTorch MPS vs JAX-Metal vs llama.cpp

Mac で LLM を動かす方法は複数ある。まずはそれぞれの実際の命題を並べる。

選択肢	命題	長所	短所
MLX	Apple Silicon 専用のネイティブフレームワーク	統合メモリ・遅延グラフ・GPU フル活用	Apple Silicon 限定・エコシステムが小さい
PyTorch MPS	PyTorch に Metal バックエンドを足した	既存の PyTorch コードがほぼそのまま動く	CUDA スタイルのアダプテーション・4GB テンソル上限・遅い
JAX-Metal	JAX の実験的 Metal バックエンド	JAX コードを再利用できる	実験的・機能差・更新が遅い
llama.cpp	C++ 推論エンジン (Metal/CPU/CUDA)	どこでも動く・小さい・標準形式	推論専用・ファインチューニング不可

PyTorch MPS は「十分」か

PyTorch の Metal Performance Shaders バックエンドは CUDA スタイルの演算を Metal にアダプテーションしている。 これが二つの問題を生む。

メモリモデルが統合メモリに最適化されていない。 PyTorch はテンソルを「デバイスメモリ」に置く前提でモデル化している。だから統合メモリの利得を取り切れない。
テンソルサイズの上限がある。 PyTorch MPS にはおよそ 4GB のテンソル上限があり、2k トークンを少し超える程度のコンテキストで頻繁に OOM する。

ベンチマークでは差が明確だ — Llama 推論で MLX が約 230 トークン/秒、PyTorch MPS が 7〜9 トークン/秒 (同じチップ・同じモデル)。一桁と三桁の戦いだ。

PyTorch MPS で「十分」な場面: 既存の学習コードをひとまず Mac に持ってきて小さく実験する、あるいは CUDA クラスタに移す前のプロトタイピング。プロダクションでのローカル推論には合わない。

JAX-Metal — おもしろいが実験的

Apple の JAX-Metal プラグインは存在する。動く。ただし 実験的 で、JAX の全機能をカバーしておらず、更新は遅い。すでに JAX のコードベースがあって、その一部を Mac で動かしたいときだけ意味がある。

llama.cpp — CPU だけで足りるとき

llama.cpp は C++ で書かれた推論エンジンだ。Metal・CUDA・CPU のいずれでも動き、フットプリントが小さく、量子化形式 (gguf) が事実上の標準になっている。

llama.cpp が勝つ場面:

組み込み・CLI 環境で小さなフットプリントで推論だけしたい。
Mac と Linux を同じバイナリでサポートする必要がある。
ファインチューニングは別の場所、ローカルは推論のみ。

MLX が勝つ場面:

同じ Mac でファインチューニングもやりたい。
同じ重みを Swift アプリ (iOS/macOS) に組み込みたい。
Python でテンソルを直接扱い、新しいモデル構造を実験する。

3. 遅延計算グラフ — JAX の後継

MLX のもうひとつの中心的な設計判断は 遅延 (lazy) 評価 だ。同じチームが JAX から持ち込んだアイデアである。

PyTorch はデフォルトで 即時 (eager)。a + b を呼ぶとその場で計算が走る。MLX は違う — mx.add(a, b) は グラフノード を作るだけで、実際の演算は 結果が必要になった時点 で走る。

import mlx.core as mx

a = mx.array([1.0, 2.0, 3.0])
b = mx.array([4.0, 5.0, 6.0])

# この時点でまだ何も計算されていない
c = a + b           # グラフノードのみ
d = c * 2.0          # もうひとつのノード

# 結果を具現化したときに計算が走る
mx.eval(d)
# print(d) のような呼び出しが暗黙に eval を呼ぶこともある

なぜこれが良いのか:

演算融合 (operator fusion) — a + b と c * 2.0 をひとつの Metal カーネルに合体できる。メモリ往復が減り、GPU の使用率が上がる。
メモリ確保の最適化 — 中間結果を実メモリに置かずに済むことがある。
グラフ単位の最適化 — JAX の jit 相当のコンパイルが可能 (MLX の mx.compile)。

即時評価が恋しくなる場面: デバッグだ。print(x) で各段階の値を見たいとき、PyTorch のほうが直感的だ。MLX では mx.eval(x) を明示的に呼ぶか、NumPy に変換するなどして強制的に具現化する必要がある。

これはトレードオフだが、同じグラフを何度も繰り返し実行する — 局所 LLM はまさにこれだ — ワークロード では遅延グラフの利得が圧倒的に勝る。

4. mlx-lm — LLM 推論とファインチューニングの標準ツール

MLX そのものは低レベルの配列ライブラリだ。LLM を扱うには mlx-lm を入れる。

pip install mlx-lm

これでできること:

Hugging Face モデルのダウンロードと変換 — Llama・Qwen・DeepSeek・Phi・Mistral など主要な Transformer 系の大半。
量子化 — 4 bit / 8 bit にしてメモリに収める。
ローカル推論 — CLI 一行、または Python から。
OpenAI 互換のサーバモード — mlx_lm.server を立てれば OpenAI SDK がそのまま向けられる。
LoRA / QLoRA / DoRA ファインチューニング — 同じコマンドラインで。

CLI — Llama 3.x を動かす

# 4bit 量子化の Llama 3.1 8B をダウンロードして推論
mlx_lm.generate \
  --model mlx-community/Meta-Llama-3.1-8B-Instruct-4bit \
  --prompt "Apple Silicon が LLM に向く理由を一段落で。" \
  --max-tokens 256

この一行でモデル取得・変換・量子化・トークン生成までが終わる。初回はモデルを取りに行き、以降はキャッシュを使う。

Python から

from mlx_lm import load, generate

model, tokenizer = load("mlx-community/Qwen2.5-7B-Instruct-4bit")

response = generate(
    model,
    tokenizer,
    prompt="MLX の統合メモリ利得を 3 行で。",
    max_tokens=256,
    temp=0.7,
)
print(response)

load() はモデルとトークナイザをまとめて返す。generate() がテキストを生成する。事実上これで終わり だ — 別途の .to(device) も、.eval() モード切り替えもない。

OpenAI 互換サーバ

mlx_lm.server --model mlx-community/Meta-Llama-3.1-8B-Instruct-4bit --port 8080

立てれば、OpenAI Python SDK が base_url="http://localhost:8080/v1" を変えるだけで使える。デスクトップアプリや LangChain / LangGraph のようなフレームワークから、ローカル Mac を推論バックエンドとして使うときに最もよく見るパターンだ。

5. mlx-vlm — ビジョン言語モデル

テキストだけでは足りないとき、mlx-vlm がある。

pip install mlx-vlm

対応モデルは LLaVA、Qwen-VL、Phi-Vision、Idefics、PaliGemma など主要な VLM ファミリのほとんど。使い方は mlx-lm とほぼ同じだ。

from mlx_vlm import load, generate

model, processor = load("mlx-community/Qwen2-VL-7B-Instruct-4bit")

response = generate(
    model,
    processor,
    image="./screenshot.png",
    prompt="この画面に表示されているエラーメッセージを日本語で要約して。",
    max_tokens=256,
)
print(response)

Mac での VLM に意味がある理由: スクリーンショット・ドキュメント・UI キャプチャを扱うローカルワークフロー (ノートアプリ・自動化ツール・アクセシビリティ補助) では、画像をクラウドに送らないこと自体が価値だ。そして統合メモリのおかげで、大きな画像を GPU にコピーするオーバーヘッドがない。

6. Python と Swift — 同じコア、二つの入り口

MLX のコアは C++ で書かれ、その上に Python と Swift の高水準 API が乗る (C / C++ の中核演算も公開されている)。

   ┌─────────────────────────────────────────┐
   │  Python API     │     Swift API         │
   │  (Jupyter,       │   (iOS, macOS,        │
   │   研究・サーバ)    │  visionOS アプリ)      │
   ├─────────────────────────────────────────┤
   │              MLX コア (C++)              │
   │      配列・自動微分・遅延グラフ           │
   ├─────────────────────────────────────────┤
   │            Metal バックエンド             │
   │   (M シリーズ GPU・Neural Accelerators)  │
   └─────────────────────────────────────────┘

Python API — 研究・サーバ用

mlx.core で配列と演算、mlx.nn でモジュール、mlx.optimizers でオプティマイザを使う。PyTorch とほぼ 1 対 1 に対応する API なので、移行コストが低い。

import mlx.core as mx
import mlx.nn as nn

class SmallModel(nn.Module):
    def __init__(self, dim=128):
        super().__init__()
        self.linear1 = nn.Linear(dim, dim)
        self.linear2 = nn.Linear(dim, dim)
    def __call__(self, x):
        x = mx.maximum(self.linear1(x), 0.0)  # ReLU
        return self.linear2(x)

model = SmallModel()
x = mx.random.normal((4, 128))
y = model(x)
mx.eval(y)

Swift API — iOS / macOS / visionOS アプリ向け

mlx-swift は同じコアを Swift で公開する。何が面白いのか: 学習を Python で行い、まったく同じ重みを Swift から読み込んで iOS アプリに埋め込める。PyTorch なら ONNX / CoreML 変換という追加段階が必要な場所で、MLX は同じフォーマット・同じコアを使う。

import MLX
import MLXNN

let model = SmallModel()
let x = MLXRandom.normal([4, 128])
let y = model(x)
eval(y)

同じモデルコードが Mac・iPhone・iPad・Vision Pro で動く。 これは PyTorch や JAX が簡単には占めにくいポジションだ。

7. Metal バックエンド — TensorOps と Neural Accelerators

MLX の GPU バックエンドは Metal だ — Apple 自身のグラフィックス・コンピュート API、NVIDIA における CUDA の位置にあたる。

M5 チップからは Metal 4 で導入された TensorOps と Metal Performance Primitives フレームワーク経由で、Neural Accelerators のテンソル演算が直接公開される。MLX はその上で行列積・attention・畳み込みなどの中核演算を実装している。

開発者が知っておくべきこと:

MLX 利用者が Metal コードを直接書くことはほとんどない。新しい演算を足したいときに Metal シェーダを書ける口は残っている。
量子化は MLX 内部で処理される。4 bit / 8 bit が Metal カーネルレベルで最適化されている。
M2 → M3 → M4 → M5 と進むほど GPU コア数、メモリ帯域、Neural Accelerators が増える。MLX のコードはリコンパイル不要で新しいチップ上で即座に速くなる。

8. 小さなファインチューニング — M シリーズで LoRA を一周

理論はもう十分だ。実際にファインチューニング を回してみよう。シナリオ: 5000 件ほどのドメイン特化 Q&A で Llama 3.1 8B を LoRA 適応する。

データ準備

mlx-lm の LoRA は JSONL を受け取る。一行に一例:

{"text": "<s>[INST] 質問 [/INST] 回答 </s>"}

あるいはチャットテンプレート形式:

{"messages": [{"role": "user", "content": "..."}, {"role": "assistant", "content": "..."}]}

data/ ディレクトリに train.jsonl と valid.jsonl を置く。

LoRA 学習コマンド

mlx_lm.lora \
  --model mlx-community/Meta-Llama-3.1-8B-Instruct-4bit \
  --train \
  --data ./data \
  --batch-size 4 \
  --lora-layers 16 \
  --iters 1000 \
  --learning-rate 1e-4 \
  --adapter-path ./adapters

4 bit 量子化モデルに --train を組み合わせると 自動的に QLoRA になる — ベース重みは 4 bit で固定、LoRA アダプタだけが full precision で学習される。M2 Pro で 7B モデル・500 サンプルなら 20〜25 分ほど。M3 Max・128GB なら 70B モデルまで QLoRA が回る。

学習後の推論

mlx_lm.generate \
  --model mlx-community/Meta-Llama-3.1-8B-Instruct-4bit \
  --adapter-path ./adapters \
  --prompt "ドメイン質問..." \
  --max-tokens 256

学習スループットの現実

NVIDIA H100 と比べれば学習スループットは大きく劣る — おおよそ 1〜3 tok/s 対 30〜50 tok/s。つまり Apple Silicon でのファインチューニングは「時間単位を分単位に縮める」ものではない。 向いているポジションはこうだ。

プロトタイピング: 新しいデータセット・新しいプロンプト形式の実験。
実験と学習: ファインチューニングのパイプラインに手を慣らす。
小規模ドメイン適応: 数千〜数万件・7B〜32B モデル。

本気で大きな学習はクラウドの H100/A100 のほうが経済的だ。MLX のファインチューニングは 手元のマシンで閉じたループ を組みたいときに本領を発揮する。

9. 性能 — M シリーズ別トークン/秒

ベンチマークは常にモデル・量子化・コンテキスト長・温度に依存する。それでも 2026 年 5 月時点でよく引用されるおおよその数値 (公開報告の中央値近傍) はこのようになる。

モデル	M2 Pro	M3 Max	M4 Max	M2/M3 Ultra
Llama 3.1 8B (4bit)	30〜40 t/s	60〜85 t/s	80〜110 t/s	100〜140 t/s
Qwen 2.5 7B (4bit)	30〜45 t/s	65〜90 t/s	90〜120 t/s	110〜150 t/s
Qwen3 0.6B (4bit)	~250 t/s	~400 t/s	~525 t/s	~600 t/s
Llama 3.1 70B (4bit)	(OOM)	8〜12 t/s	10〜15 t/s	15〜22 t/s

同じチップでの PyTorch MPS バックエンドと比べれば、MLX が一桁速いケースも珍しくない。報告事例のなかには MLX 約 230 t/s 対 PyTorch MPS 7〜9 t/s のような極端な差もある。

最も強い命題: ファインチューニングと推論を 同じ Mac の、同じコードで 閉じたループとして回せる。これは NVIDIA クラウドワークフローに対する、消えない構造的優位だ。

10. 実ワークロード — Llama・Qwen・DeepSeek をローカルで

シナリオ 1 — ノート PC でのコーディングアシスタント

M3 Pro / 36GB。
Qwen 2.5 Coder 7B / 4bit。
mlx_lm.server を OpenAI 互換モードで起動し、エディタの LLM 統合を localhost:8080 に向ける。
約 50〜70 t/s。オフラインでも動く。

シナリオ 2 — 営業ノート要約をローカル限定で

M2 Air / 16GB。
Llama 3.2 3B / 4bit (8B は 16GB でややきつい)。
Python スクリプトがミーティングノートを受け取り、要約と次アクション抽出を行う。
データが端末外に出ない。

シナリオ 3 — 70B 推論ワークステーション

Mac Studio M2 Ultra / 192GB。
DeepSeek 70B / 4bit または Llama 3.1 70B / 4bit。
mlx_lm.server を社内ネットワークに公開 — チーム規模でコスト効率の良い推論バックエンド。

シナリオ 4 — VLM で文書 OCR・要約

M3 Max / 64GB。
mlx-vlm + Qwen2-VL 7B / 4bit。
スクリーンショットや PDF ページ画像を受け取り、テキスト抽出と要約を返す。

四つに共通するのは モデル・データ・推論がすべてひとつの箱で閉じる ことだ。Mac というフォームファクタが、MLX の収まりの良いポジションそのものでもある。

11. 意思決定フレームワーク — いつ MLX で、いつ別ものか

                ローカル推論が必要か?
                          │
                ┌─────────┴─────────┐
                ▼                   ▼
            はい (Mac)         いいえ (サーバ)
                │                   │
                ▼                   ▼
        同じ箱でファインチューン?    PyTorch + CUDA
                │
        ┌───────┴───────┐
        ▼               ▼
       はい           いいえ
        │               │
        ▼               ▼
       MLX           推論のみ → llama.cpp / Ollama
                     PyTorch のみ → MPS (性能差を受け入れる)
        │
        ▼
   iOS / Swift 統合が必要?
        │
   ┌────┴────┐
   ▼         ▼
  はい      いいえ
   │         │
   ▼         ▼
 mlx-swift Python MLX

早見表

状況	推奨
Mac でのローカル LLM 推論 (個人用)	MLX または llama.cpp 系ツール (Ollama, LM Studio)
Mac でのローカルファインチューニング + 推論	MLX (mlx-lm)
同じモデルを iOS / macOS / visionOS アプリに埋め込む	MLX (mlx-swift)
既存の PyTorch コードを手早く Mac で動かす	PyTorch MPS (限界を承知の上で)
Mac と Linux 両対応の単一推論エンジン	llama.cpp
大規模分散学習	NVIDIA + CUDA + PyTorch
JAX コードベースを Mac で動かす必要がある	JAX-Metal (実験的)

12. 限界とトレードオフ

MLX は魔法ではない。 継ぎ目を正直に書き留めよう。

Apple Silicon 限定

MLX は Intel Mac でも Linux / Windows でも動かない。これは設計判断だ — フレームワーク自体が Apple Silicon の統合メモリに最適化されているからだ。同じコードを Linux サーバでも動かす必要があるなら、PyTorch か JAX の実装を併存させる必要がある。

PyTorch よりエコシステムが小さい

PyTorch の巨大なエコシステム — Hugging Face Accelerate、DeepSpeed、axolotl など — は MLX には存在しない。mlx-community Hub には変換済みモデルが多くあるが、最新のモデルが MLX に届くまで数日〜数週間遅れる ことは珍しくない。mlx-lm が Hugging Face のチェックポイントを自動変換できるため、その差は急速に縮まっている。

分散学習が未成熟

複数ノードにまたがる分散学習は MLX の強い場所ではない。スイートスポットは単一の Mac、または一つのシステム内だ。大規模な事前学習はいまも NVIDIA の領分だ。

デバッグの微妙さ

遅延評価はときに混乱を生む。print(x) で値を見たいとき、実はその時点までの保留分グラフが一気に走る。大きなグラフではデバッグの瞬間がコストの瞬間になる。明示的に mx.eval() を挟む癖を付けると助かる。

学習スループットは H100 に届かない

ファインチューニングのスループットは H100 の数分の一だ。大きな学習はクラウドのほうが依然として経済的だ。

Linux / Windows ワークフローとの差

チームのメインパイプラインが Linux Docker / NVIDIA / PyTorch なら、MLX を中心に据えるのは難しい。一部メンバーの Mac ワークステーション上の補助ツールとして置くのが現実的だ。

13. MLX と Mac ネイティブな未来 — 半年後の見立て

2026 年後半に見えてくる流れ:

M5 世代と TensorOps 活用の拡大 — MLX は既に M5 のテンソル加速を使っており、四半期単位で性能向上が続いている。
Ollama・LM Studio が MLX バックエンドを採用 — Mac ユーザは意識せずに MLX を使う形になっている。
mlx-vlm の急成長 — マルチモーダルが Mac で一級市民になりつつある。
Swift 陣営の強化 — mlx-swift-lm と、LLM を iOS / Vision Pro に埋め込むパターン。
OpenAI 互換サーバが標準化 — ローカル推論バックエンドが事実上 OpenAI API で公開される形が標準。

ズームアウトすれば、MLX は 「Mac で ML をやるときのデフォルトインフラ」 になりつつある。意識的に使わない方が不自然になりつつあるポジションだ。

エピローグ — Mac が ML ワークステーションになった本当の理由

NVIDIA が ML インフラの標準になるまで 20 年かかった。Apple Silicon が ML ワークステーションとして座を得るまで 2〜3 年だった。差を作ったのは二つ — 統合メモリというハードウェアの命題、そして その命題を正確に引き出すフレームワーク (MLX) だった。

「PyTorch MPS は NVIDIA の流儀を Metal の上で真似ている。MLX は Apple Silicon の流儀そのものだ。同じ GPU、別のフレームワーク、別の結果。」

同じモデルを Mac で動かすとき、MLX はほぼ常にもっとも速く、ほぼ常にもっとも自然だ。 そして、その自然さがファインチューニング・VLM・iOS 埋め込みといった場所までそのまま延びる。

MLX 採用チェックリスト

Apple Silicon (M1 以降) の Mac があるか?
pip install mlx mlx-lm が通ったか? (Python 3.9+)
メモリは足りるか? (8B 4bit は 16GB、70B 4bit は 64GB 以上、100B+ は 192GB Studio)
推論だけか、ファインチューニングもやるか決めたか?
結果を OpenAI 互換サーバで公開する計画はあるか?
同じ重みを iOS / macOS アプリで使う計画はあるか?
既存の PyTorch コードとの差を受け入れているか?
「データが端末外に出ない」が重要なワークロードか?
デバッグ用の mx.eval() の呼び場所を決めたか?
モデルのライセンス (Llama, Qwen, DeepSeek など) を確認したか?

アンチパターン 10 個

MLX を Linux サーバに入れようとする — 別物のフレームワーク。Apple Silicon 専用だ。
PyTorch MPS で長コンテキスト推論をやる — 4GB テンソル上限で OOM。MLX に乗り換えよう。
全テンソルを一度に eval する — 巨大なグラフを一気に評価するとメモリも時間も爆発する。段階的に評価する。
量子化なしで 70B モデルを 16GB Mac で動かそうとする — できない。4 bit + 64GB 以上が現実線。
MLX と NumPy / PyTorch のテンソルを無頓着に混ぜる — 変換コストとデバイス混乱を招く。境界を綺麗にする。
新しいモデルが入らなかったらすぐ PyTorch に逃げる — mlx-lm の自動変換が大半をカバーする。
Mac で H100 クラスのスループットを期待する — ファインチューニングのスループットは大きく劣る。大きな学習はクラウド。
OpenAI 互換サーバを使わずに自分で API を組む — まずは mlx_lm.server を使おう。
mlx-swift の可能性を無視する — iOS / visionOS の価値はそこにある。
MLX を「PyTorch の代替」として評価する — そうではない。MLX は Apple Silicon に特化したツールだ。価値命題が違う。

次の記事予告

候補: ローカル LLM サービングアーキテクチャ — Ollama vs LM Studio vs mlx-lm サーバ深掘り、iOS で LLM を埋め込む — mlx-swift でノートアプリにアシスタントを入れる、量子化深掘り — 4 bit / 8 bit / QLoRA が精度に与える影響を測る。

「M シリーズの GPU は CPU と同じ RAM を使う。だから MLX は速いはずだ。そして実際に速い。」

— MLX 徹底解剖、終わり。