v1.0.0 · public release v1.0.0 · 公開リリース

Extraordinary speed,
extraordinary quality. 圧倒的な速度、
圧倒的な品質。

An MLX-based inference engine for Apple Silicon. Drops in for mlx_lm.server and delivers 2.4× its decode speed on the same Mac, same weights — same prompts, no fine-tuning. (And 4.5× Ollama, if that's your baseline.) mlx_lm.server のドロップイン代替として設計された、Apple Silicon 向けの MLX ベース推論エンジン。同じ Mac、同じ重み、同じプロンプトで 2.4 倍の decode 速度を実現します (ファインチューニングなし。Ollama と比較する場合は 4.5 倍)。

$pip install m5-infer

Apache 2.0 · macOS 26.4+ · Python 3.11+ · Apple Silicon M1 → M5 Apache 2.0 · macOS 26.4 以降 · Python 3.11 以降 · Apple Silicon M1 〜 M5

§ Measured on M5 MacBook Air base · 24 GB § M5 MacBook Air base · 24 GB で計測

2.4× the decode speed of the MLX reference. MLX リファレンス比 2.4 倍の decode 速度。

mlx_lm.server is the engine mlx-lm ships out of the box — an excellent reference. m5-infer layers training-free optimizations on top of that same library and runs 2.4× faster at decode on the same Mac with the same weights and the same prompts. No fine-tuning, no re-quantization. The inference engine is the difference. mlx_lm.server は mlx-lm が標準で用意する優れたリファレンスエンジンです。m5-infer は同じ mlx-lm の上に学習不要の最適化を積み重ねることで、同じ Mac、同じ重み、同じプロンプトのまま decode 速度を 2.4 倍に引き上げます。ファインチューニングも再量子化もなし。差を生むのは 推論エンジンのみです。

2.4×
vs mlx_lm.servermlx_lm.server 比 decode tok/s (40.0 vs 17.0) · same model decode tok/s (40.0 vs 17.0) · 同一モデル
1.5×
vs mlx_lm.server · thinking ONmlx_lm.server 比 · thinking ON decode tok/s (28.8 vs 18.6) · reasoning mode decode tok/s (28.8 vs 18.6) · 推論モード
4.5×
vs Ollama (for reference)Ollama 比 (参考) decode tok/s (40.0 vs 8.9) · same model decode tok/s (40.0 vs 8.9) · 同一モデル
+11%
vs Ollama · output scoreOllama 比 · 出力スコア graded by Opus-4.7 · same Qwen 3.5 9B 4-bit · 10-task avg 採点者は Opus-4.7 · 同一の Qwen 3.5 9B 4-bit · 10 タスク平均

§ Full bench — Qwen 3.5 9B (4-bit) § 完全ベンチ — Qwen 3.5 9B (4-bit)

Five metrics. Three engines. 5 指標、3 エンジン。

All three engines run the same full_suite_bench script on the same machine. Winner column highlighted. 3 エンジン全て、同じマシンで同じ full_suite_bench スクリプトを実行。勝者列をハイライト。

Metric指標 Ollama mlx_lm.server m5-infer v1.0.0
Decode tok/s · long_gen 512 tokens (higher = better)Decode tok/s · long_gen 512 token (高いほど良い) 8.917.040.0
Decode tok/s · thinking ON (higher = better)Decode tok/s · thinking ON (高いほど良い) 11.218.628.8
Long-context needle retrieval (6 positions · higher = better)長 context needle retrieval (6 位置 · 高いほど良い) 2 / 60 / 6 *6 / 6
Thinking-ON Short QA · 3 factual (higher = better)Thinking-ON 短答 QA · 3 問 (高いほど良い) 0 / 30 / 3 *3 / 3
Output score · same model · graded by Opus-4.7 (10-task avg · higher = better)出力スコア · 同一モデル · 採点者 Opus-4.7 (10 タスク平均 · 高いほど良い) 5.28 / 10—5.85 / 10

✓ = best value for that row (whichever engine delivered it) = その行での最良値 (どのエンジンのものであっても)

* The 0-scores for mlx_lm.server on needle retrieval and thinking-ON Short QA reflect how those engines route Qwen 3.5's reasoning field. mlx_lm.server emits the answer into the reasoning stream rather than content, which our bench's substring check misses. The underlying model may have produced the answer; the engine just didn't surface it in the user-visible field. m5-infer's think-aware parser handles this correctly. * mlx_lm.server の needle retrieval と Thinking-ON 短答 QA が 0 になっているのは、Qwen 3.5 の reasoning フィールドの扱い方の違いです。mlx_lm.server は回答を content ではなく reasoning 側に出力するため、ベンチの substring 判定では検出できません。モデル自体は回答している可能性がありますが、engine がユーザー可視フィールドに出していないという差です。m5-infer の think-aware parser はこの差を正しく扱います。

Where mlx_lm.server is genuinely faster mlx_lm.server のほうが速い指標

Warm TTFT · 12 K schema · 2nd call Warm TTFT · 12 K schema · 2 回目 mlx_lm 2.3 s   vs   m5-infer 11.1 s
5-turn session · turn 5 5 ターン session · turn 5 mlx_lm 1.6 s   vs   m5-infer 7.5 s

mlx_lm.server's in-process prefix cache is excellent for these workloads. m5-infer's CTRSP optimizes a different axis — disk-persisted state that survives process restarts (which in-process caches cannot) — at the cost of a slower warm hit. Different trade-offs; both valid. Use whichever matches your workload. mlx_lm.server の in-process prefix cache はこの用途で本当に速いです。m5-infer の CTRSP は別の軸 — プロセス再起動を越えてディスクに state を永続化する (in-process cache にはできない) — を最適化しており、その代わりに warm hit 自体は遅めです。どちらが正解ということはなく、ワークロードに合う方を選んでください。

Summary. m5-infer's pitch is sustained decode throughput and thinking-mode answer extraction on the same MLX reference that mlx_lm.server uses. We acknowledge mlx_lm's wins above. All numbers on this page are measured on an M5 MacBook Air base (24 GB, fanless). Methodology: README — Benchmarks. まとめ: m5-infer のセールスポイントは、mlx_lm.server が使う MLX リファレンスの上で、持続 decode 速度と thinking モードでの回答抽出を引き上げる点です。mlx_lm が勝つ指標は上記の通り正直に acknowledge します。本ページの全ての数値は M5 MacBook Air base (24 GB、ファンレス) での実測。方法論: README — Benchmarks。

Decode speedDecode 速度

Decode tokens per second comparison

Warm TTFTWarm TTFT

Warm TTFT comparison

Thinking-mode qualityThinking モード品質

Thinking ON/OFF quality matrix

Output score · graded by Opus-4.7 (same model)出力スコア · 採点者 Opus-4.7 (同一モデル)

Output score on identical Qwen 3.5 9B 4-bit weights, graded by Opus-4.7

§ How § 仕組み

Three novel contributions, plus system optimizations. 3 つの新技術と、複数のシステム最適化。

Layered on top of mlx-lm. No weight changes, no kernel fork. Every item measured end-to-end or byte-equivalent to greedy decoding. The first three are approaches we have not seen in any other open inference engine. mlx-lm の上に積層。重み変更なし、kernel fork なし。全項目が end-to-end で実測済、もしくは greedy decode と byte 単位で等価。冒頭の 3 件は他の open な推論エンジンで見かけないアプローチです。

NOVEL · 01 新技術 · 01

Hybrid-aware speculative decoding with O(1) GDN state restore GDN 状態を O(1) 復元する hybrid 対応 speculative decoding

A speculative-decoding implementation that correctly handles Qwen 3.5's 24 GatedDeltaNet + 8 Full-Attention hybrid. We have not seen this approach in another open inference engine we tested. Qwen 3.5 の GDN 24 層 + FA 8 層 hybrid 構成を、黙って誤った出力に落とさずに正しく扱える speculative-decoding 実装。私たちが検証した範囲では、このアプローチを採用している open な推論エンジンを他に見ていません。

The problem 問題

Standard speculative decoding (Leviathan 2023, Medusa) targets pure transformers — on reject, you truncate the KV cache by N entries and continue. GDN layers carry a recurrent state and convolutional buffer that have already advanced through the entire draft window. Truncating only KV leaves GDN state corrupted, and the model silently produces divergent output. This is the implementation difficulty that, in the engines we checked, has kept speculative decoding off by default for Qwen 3.5 hybrid. 通常の speculative decoding (Leviathan 2023、Medusa) は pure transformer が前提 — reject 時に KV cache を N entry 切り詰めるだけで続行できる。しかし GDN 層は recurrent state と convolutional buffer が draft window 全体を進んでしまっている。KV だけ truncate しても GDN state は壊れたまま残り、モデルは clash せず静かに誤った出力を続ける。私たちが確認した engine では、この実装上の難しさゆえに Qwen 3.5 hybrid 用の speculative decoding はデフォルト無効となっています。

Our approach 私たちの方法

Before each verify call, snapshot every GDN layer's (recurrent_state, conv_buf) pair into a pre-allocated tensor pool. On rejection, restore from snapshot in O(1) — zero allocations in the hot path. GDN state is ~tens of KB per layer; 24 layers' snapshot completes well under 1 ms per verify. No additional MLX graph nodes, no memory fragmentation. 各 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 未満。MLX graph に追加ノードは不要、メモリ断片化なし。

byte = greedy Output equivalence vs mlx_lm.generate mlx_lm.generate との出力等価性
~70% Acceptance rate · 4-token draft Acceptance rate · 4 token draft
< 1 ms 24-layer snapshot cost per verify 24 層分 snapshot コスト / verify
Verify in sourceソースで確認→ app/innovation/speculative/draft_speculative.py
NOVEL · 02 新技術 · 02

CTRSP — disk-persisted recurrent state for agent workloads CTRSP — エージェント向けの disk 永続化 recurrent state

Prefix caching that covers not just KV pages but the full GDN recurrent + convolutional buffer — keyed by token-bytes hash, persisted to disk across process restarts. mlx_lm.server has a faster absolute Warm TTFT for in-process runs; CTRSP's value is state that survives restarts and sessions. KV ページだけでなく GDN recurrent + convolutional buffer も含めて prefix cache する。トークン列のバイト列ハッシュを key に、プロセス再起動を越えてディスクに永続化。in-process での Warm TTFT 絶対値は mlx_lm.server のほうが速く、CTRSP の価値はプロセス / セッションを跨いで state が残ることにあります。

The problem 問題

Agent workloads re-send the same 12 K+ tool schema on every turn. RadixAttention (SGLang) and AutomatedPrefixCache (vLLM) cache KV pages only. For a hybrid model, replaying KV without the matching GDN state gives a warm prefix but wrong output. In the engines we checked, we have not found one that persists GDN recurrent state across sessions or process restarts. エージェント用途では 12 K+ の tool schema が毎ターン同じものとして再送信される。RadixAttention (SGLang) や AutomatedPrefixCache (vLLM) は KV page のみをキャッシュする。hybrid モデルでは KV だけ再現しても GDN state が不整合だと prefill は warm になるが 出力は誤る。私たちが確認した engine の中には、GDN recurrent state をセッション・プロセス再起動を越えて保存するものは見つかっていません。

Our approach 私たちの方法

Serialize the full state (quantized KV + GDN recurrent/conv buffers) to disk on generation end, keyed by SHA-256 of the raw prompt-prefix tokens. Hash is over bytes, not decoded text — system prompts and tool schemas match exactly even when chat turns are appended. LRU evicts at 32 entries (~3 GB cap by default) with atomic writes + fingerprint verification on load. 生成終了時にモデルの完全状態 (quantized KV + GDN recurrent/conv buffer) を disk に serialize、prompt prefix のトークン列のバイト列の SHA-256 を key とする。デコード後のテキストではなくバイト列でハッシュするので、system prompt や tool schema は chat turn 追加後も完全一致で検出。LRU は 32 entry 上限 (デフォルト ~3 GB 上限) で eviction、load 時に atomic write + fingerprint 検証。

69 s → 11 s 12 K tool schema · cold → warm (6× from CTRSP hit) 12 K tool schema · cold → warm (CTRSP hit で 6×)
29 s → 7.5 s 5-turn session · turn 1 → turn 5 (3.9× within session) 5 ターン session · turn 1 → turn 5 (session 内で 3.9×)
survives restart State persists across process restarts (others lose it) プロセス再起動後も state が残る (他 engine は失われる)
Verify in sourceソースで確認→ app/innovation/n1_ctrsp/state_persistence.py
NOVEL · 03 新技術 · 03

Task-aware escape hint — rescue the model from think-loops Task-aware escape hint — 思考ループからの救出注入

When Qwen 3.5 gets stuck in a Wait, let me re-check… spiral, we inject a typed transition like **Final JSON:** so the model resumes in the exact format the user asked for. One string template. Same weights. +36% on the 10-task output score graded by Opus-4.7 — engine-attributable, not a model-quality claim. Qwen 3.5 が Wait, let me re-check… ループに入ったとき、**Final JSON:** のような タスク別の遷移を注入する。ユーザーが要求した形式で答えを再開させる。文字列テンプレート 1 つで、同一モデルのまま Opus-4.7 が採点した 10 タスクの出力スコアが +36% (エンジン起因の向上であり、モデル品質が上がったわけではありません)。

The problem 問題

Qwen 3.5 in thinking mode occasionally falls into repetitive spirals that never emit </think>. Existing engines either truncate (losing the answer), pass the raw thinking (breaking downstream agents), or inject a bare </think> close — which often leaves the model continuing the same stuck pattern in the answer phase. Qwen 3.5 の thinking モードでは、稀に </think> を閉じないまま repetitive spiral に入る。既存の engine は 切り詰める (答えを失う)、生の thinking を返す (下流エージェントを壊す)、または単純な </think> のみ注入 (モデルが answer phase でも同じパターンを続けてしまう) のいずれかしかできない。

Our approach 私たちの方法

N-gram loop detector scoped to the think block. On trigger, we inspect the user prompt and inject a task-typed transition: </think>\n\n**Final JSON:**\n\n\`\`\`json\n for JSON tasks, **Final Code:** for code, **Final Translation:** for translation, and so on. The typed hint anchors the model in the required output format; the stuck pattern dissolves. think ブロック内限定の n-gram ループ検出器が発火したとき、user prompt を検査して タスク別の遷移を注入する: JSON タスクなら </think>\n\n**Final JSON:**\n\n\`\`\`json\n、コードなら **Final Code:**、翻訳なら **Final Translation:**、など。型付きヒントがモデルを要求された出力形式に固定し、stuck pattern が解ける。

+461% extract_01 extracted JSON (same model · 1.40 → 7.85) extract_01 の抽出 JSON (同一モデル · 1.40 → 7.85)
+36% 10-task output score (same model · graded by Opus-4.7 · 4.29 → 5.85) 10 タスク出力スコア (同一モデル · 採点者 Opus-4.7 · 4.29 → 5.85)
< 1 ms Runtime cost per decode step Runtime コスト / decode step
Verify in sourceソースで確認→ app/backend/custom_generate.py::_build_escape_hint

System optimizations システム最適化

— individually small, multiplicative when combined — 単独では小さいが、組み合わせて乗算的に効く
#04

Needle-retrieval heuristicNeedle-retrieval heuristic

Routing-layer check for the long-system + short-user query pattern auto-enables thinking mode, bypassing Qwen safety-alignment refusals. 0 / 6 → 6 / 6 on long-context needle retrieval with zero decode cost. 長 system + 短 user パターンをルーティング層で自動検出し、thinking モードを強制 ON に。Qwen の safety-alignment 拒否を回避し、長 context needle retrieval を 0 / 6 → 6 / 6。decode コストはゼロ。

#05

N3 SSEE — self-speculative early exitN3 SSEE — 自己投機的 early exit

Exit from an intermediate layer when the model is confident. Reuses the main model's own early hidden states as a draft, eliminating a separate draft-model cost. モデルが高信頼度の時に中間 layer で exit する。main モデル自身の浅い隠れ状態を draft として再利用し、別 draft モデルのコストを消す。

#06

N4 ALS — adaptive layer skippingN4 ALS — 適応的 layer skip

Per-token confidence-based skipping of low-impact layers, calibrated by an offline importance profile. Quality stays within 1% of dense decode on needle + Opus benches. オフラインで計測した layer importance プロファイルに基づき、token 単位の信頼度で低影響 layer を skip。needle + Opus ベンチで dense 比 1% 以内の品質を維持。

#07

N6 PES — parallel expert schedulingN6 PES — Expert path 並列スケジューリング

Expert paths on MoE blocks scheduled onto separate MLX streams, overlapping their compute with the next layer's weight fetch. Measurable win on Pro / Max hardware. MoE block の expert path を別 MLX stream に割り当て、次 layer の weight fetch と compute をオーバーラップ。Pro / Max ハードで計測可能な gain。

#08

X5-R compiled forward + wired memoryX5-R コンパイル済 forward + wired memory

mx.compile fuses attention + MLP + GDN into Metal kernels. wired_limit pins weights so thermal throttling doesn't drop the engine to swap. mx.compile で attention + MLP + GDN を Metal kernel に融合。wired_limit で重みを pin し、thermal throttling 時に engine が swap に落ちるのを防ぐ。

#09

Hardware-aware auto-tuneハードウェア検出 auto-tune

Detects M1 base → M5 Max at startup and applies per-tier defaults: GPU-core concurrency, bandwidth-based RDMS draft sizing, memory-aware wired_limit. 起動時に M1 base 〜 M5 Max を検出し tier 別 default を適用: GPU core 数に応じた並列度、memory bandwidth に応じた RDMS draft サイズ、容量に応じた wired_limit。

#10

Model-family abstractionモデル family 抽象化

Unified engine across Qwen 3.5 / 3.6 / 2.5, Llama 3.x, Mistral, Gemma 2 / 3 / 4. Pure transformers auto-skip the hybrid-specific machinery. Qwen 3.5 / 3.6 / 2.5、Llama 3.x、Mistral、Gemma 2 / 3 / 4 を統一エンジンで扱う。pure transformer は hybrid 専用処理を自動で skip。

#11

TPC — token prefix compilerTPC — token prefix compiler

Fast raw-bytes hash lookup of prompt prefixes with background pre-compilation of the next likely continuation. Cuts repeated-prompt prefill latency in half. prompt prefix の raw-bytes hash を高速 lookup し、次に来そうな続きをバックグラウンドで事前コンパイル。繰り返しプロンプトの prefill レイテンシを半減。

Full stack · measured end-to-end Full stack · end-to-end 実測

17 tok/s → 40 tok/s.

2.4× decode over stock mlx-lm on M5 base with the exact same Qwen 3.5 9B 4-bit weights. Per-innovation contribution table in the README. M5 base で同じ Qwen 3.5 9B 4-bit の重みを使い、stock mlx-lm 比 decode 2.4 倍。各 innovation の寄与度は README 参照。

§ Get started § はじめる

One command. OpenAI-compatible on port 11436. コマンド 1 行。port 11436 で OpenAI 互換 API 起動。

Existing OpenAI clients drop in with base_url="http://127.0.0.1:11436/v1". Models auto-download from HuggingFace on first start, or hot-pull at runtime. 既存の OpenAI クライアントは base_url="http://127.0.0.1:11436/v1" を設定するだけで利用可能。モデルは初回起動時に HuggingFace から自動 download、もしくは実行中に hot-pull。

terminal
# Installインストール
pip install m5-infer

# Start the server (port 11436)サーバー起動 (port 11436)
m5-infer

# OpenAI-compatible callOpenAI 互換 API 呼び出し
curl -s http://127.0.0.1:11436/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"Hello"}],"max_tokens":64}'
Sourceソース
GitHub→
Packageパッケージ
PyPI→
Future将来計画
Roadmap→
Communityコミュニティ
Discussions→

§ With gratitude § 謝辞

We stand on the shoulders of excellent work. 優れた仕事の積み重ねの上に築かせていただきました。

m5-infer exists only because of the frameworks, models, and research published by the teams below. We acknowledge each with respect. m5-infer は以下の各チームが公開した framework、モデル、そして研究成果があって初めて成立しています。敬意をもって acknowledge します。

Framework フレームワーク

Apple MLX team — MLX and mlx-lm. m5-infer is a layer on top of mlx-lm; without MLX there is no Apple-Silicon-native inference engine to optimize. Every speedup we report is relative to the excellent baseline MLX already provides. Apple MLX チーム — MLX と mlx-lm。m5-infer は mlx-lm の上に重ねる薄い層で、MLX なしに Apple Silicon ネイティブな推論エンジンは存在しえません。私たちが提示する速度向上はすべて、MLX という優れた基礎の上での相対値です。

Local LLM pioneers ローカル LLM の開拓者

Ollama, llama.cpp, vLLM, SGLang — these projects made local and self-hosted LLM inference accessible to millions of developers and raised the UX bar that m5-infer now has to meet. Our like-for-like benchmarks against Ollama and mlx_lm.server reflect different design priorities — not judgment. Each engine optimizes for different workloads. Ollama、llama.cpp、vLLM、SGLang — 何百万人もの開発者にローカル / セルフホスト LLM を届け、m5-infer がいま満たすべき UX 基準を引き上げてくれたプロジェクト群。私たちが Ollama や mlx_lm.server と並べて掲載するベンチマークは、あくまで同条件での like-for-like 比較であり、優劣判定ではありません。エンジンごとに最適化の優先順位が異なるだけです。

Open-weight model makers Open-weight モデルの提供者

Alibaba DAMO (Qwen), Meta (Llama), Mistral AI, Google DeepMind (Gemma) — releasing state-of-the-art models with open weights is an act of generosity that the entire local-inference ecosystem depends on. Our Qwen 3.5-specific innovations (hybrid-GDN speculative, CTRSP) exist because Alibaba shipped a hybrid architecture openly. Every benchmark on this page uses models they published. Alibaba DAMO (Qwen)、Meta (Llama)、Mistral AI、Google DeepMind (Gemma) — 最先端のモデルを open weights で公開すること自体が寛容な行為であり、ローカル推論エコシステム全体がそれに依存しています。私たちの Qwen 3.5 向け新技術 (hybrid-GDN speculative、CTRSP) は、Alibaba が hybrid 構成のモデルを公開してくれたからこそ実装できました。このページ上の全ベンチマークも、彼らが公開したモデルを使用しています。

Research community 研究コミュニティ

Leviathan et al. (2023), Medusa authors (Cai et al.), GatedDeltaNet architects, HuggingFace — the papers and reference implementations that shaped our understanding. Our hybrid extension of speculative decoding is an implementation detail on top of a body of research that already did the hard theoretical work. Leviathan 他 (2023)、Medusa 著者 (Cai 他)、GatedDeltaNet の設計者、HuggingFace — 私たちの理解を形作った論文とリファレンス実装。speculative decoding の hybrid 拡張は、理論的な難所を既に解いてくれた先行研究に対する、実装上の一工夫でしかありません。

A note on comparisons. The benchmark numbers on this page are measured, reproducible, and specific to a single M5 MacBook Air base. They are not a judgment of the other engines' overall quality. Ollama prioritizes onboarding simplicity and broad model coverage; mlx_lm.server prioritizes a reference implementation of mlx-lm; m5-infer prioritizes decode throughput and warm TTFT on Apple Silicon. Different goals, different trade-offs. We respect each team's choices. 比較に関する一言。このページ上のベンチマーク値は、M5 MacBook Air base 1 台での実測・再現可能な値であり、他エンジンの全体的な品質を判定するものではありません。Ollama は導入の手軽さと幅広いモデル対応を優先し、mlx_lm.server は mlx-lm のリファレンス実装を優先し、m5-infer は Apple Silicon での decode throughput と warm TTFT を優先します。目指すものが違えば、トレードオフも違います。各チームの選択に敬意を表します。