Apache 2.0 · macOS 26.4 以降 · Apple Silicon M1〜M5

圧倒的な速度、
圧倒的な品質。

mlx_lm.server のドロップイン代替として設計された、Apple Silicon 向けの MLX ベース推論エンジン。同じ Mac、同じ重み、同じプロンプトで 最大 2.4 倍の decode 速度を実現 (long_gen decode でのピーク値、ファインチューニングなし)。Ollama 比では同じピーク条件で最大 4.5 倍です。

Apache 2.0 · macOS 26.4 以降 · Python 3.11 / 3.12 / 3.13 / 3.14 · Apple Silicon M1 〜 M5

v1.1.4 · 公開リリース 最新更新 — v1.1.4: 新 CLI サブコマンド + ストリーミング pull + 24 GB → 20 GB Metal 上限 (2026-04-22)
$pip install m5-infer
Benchmarks

数字で見る速度と品質

2.4×
vs mlx_lm.server
decode tok/s (40.0 vs 17.0) · 同一モデル · long_gen ピーク
1.5×
vs mlx_lm.server · thinking ON
decode tok/s (28.8 vs 18.6) · 推論モード
4.5×
vs Ollama (参考)
decode tok/s (40.0 vs 8.9) · 同一モデル · long_gen ピーク
+11%
vs Ollama · 出力スコア
採点者は Opus-4.7 · 同一の Qwen 3.5 9B 4-bit · 10 タスク平均
Full Benchmark

ベンチマーク詳細(Qwen 3.5 9B 4-bit)

指標 Ollama mlx_lm.server m5-infer
Decode tok/s · long_gen 512 token (高いほど良い) 8.9 17.0 40.0
Decode tok/s · thinking ON (高いほど良い) 11.2 18.6 28.8
長 context needle retrieval (6 位置 · 高いほど良い) 2 / 6 0 / 6 * 6 / 6
Thinking-ON 短答 QA · 3 問 (高いほど良い) 0 / 3 0 / 3 * 3 / 3
出力スコア · 同一モデル · 採点者 Opus-4.7 (10 タスク平均 · 高いほど良い) 5.28 / 10 5.85 / 10

mlx_lm.server の 0-scores について: これは Qwen 3.5 の reasoning フィールドの扱い方の差です。mlx_lm.server は回答を content ではなく reasoning 側に出力するため、ベンチの substring 判定では検出できません。モデル自体は回答している可能性がありますが、engine がユーザー可視フィールドに出していないという差です。m5-infer の think-aware parser は、この出力先の違いを考慮して判定します。

Honesty

得意・不得意を隠しません

mlx_lm.server が速い指標もあります

Warm 総レイテンシ · 12 K schema · 2 回目 (30 トークン応答): mlx_lm 2.3 s vs m5-infer 11.1 s。5 ターン session · turn 5: mlx_lm 1.6 s vs m5-infer 7.5 s。mlx_lm.server の in-process prefix cache はこの用途で本当に速いです。m5-infer の CTRSP は別の軸 — プロセス再起動を越えてディスクに state を永続化する (in-process cache にはできない) — を最適化しており、その代わりに warm hit 自体は遅めです。どちらが正解ということはなく、ワークロードに合う方を選んでください。
Under the Hood

3つの技術革新

01

GDN 状態を O(1) 復元する hybrid 対応 speculative decoding

問題: Standard speculative decoding は pure transformer を想定。GDN 層は recurrent state と convolutional buffer が draft window 全体を進んでしまっている。KV だけ truncate しても GDN state は壊れたまま残り、モデルは異なる出力を静かに続けます。私たちの方法: 各 verify 呼び出しの前に、全 GDN 層の (recurrent_state, conv_buf) ペアを事前確保した tensor pool に snapshot。reject 時は snapshot から O(1) で復元。hot path で alloc は発生しない。GDN state は layer あたり数十 KB、24 層合計の snapshot でも verify あたり 1 ms 未満。実測値: Output equivalence: byte = greedy (mlx_lm.generate との出力等価性)。Acceptance rate: ~70% (4-token draft)。

02

CTRSP — エージェント向けの disk 永続化 recurrent state

KV ページだけでなく GDN recurrent + convolutional buffer も含めて prefix cache する。トークン列のバイト列ハッシュを key に、プロセス再起動を越えてディスクに永続化。in-process での warm 総レイテンシ絶対値は mlx_lm.server のほうが速く、CTRSP の価値はプロセス / セッションを跨いで state が残ることにあります。

03

think-aware response parser for reasoning_mode

Qwen 3.5 は thinking_mode で reasoning フィールドに思考過程を流しますが、出力は content フィールドに行きます。mlx_lm.server はこの出力先の違いを正しく処理していない。m5-infer の parser は reasoning stream を監視し、実際の答え出力を正確に捕捉します。needle retrieval と短答 QA で 100% catch。