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
| 指標 | 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 は、この出力先の違いを考慮して判定します。
問題: 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)。
KV ページだけでなく GDN recurrent + convolutional buffer も含めて prefix cache する。トークン列のバイト列ハッシュを key に、プロセス再起動を越えてディスクに永続化。in-process での warm 総レイテンシ絶対値は mlx_lm.server のほうが速く、CTRSP の価値はプロセス / セッションを跨いで state が残ることにあります。
Qwen 3.5 は thinking_mode で reasoning フィールドに思考過程を流しますが、出力は content フィールドに行きます。mlx_lm.server はこの出力先の違いを正しく処理していない。m5-infer の parser は reasoning stream を監視し、実際の答え出力を正確に捕捉します。needle retrieval と短答 QA で 100% catch。