r/LocalLLaMA、M1 Maxでの MLX と llama.cpp の実効レイテンシ差を検証

最近の r/LocalLLaMA では、Apple Silicon で local LLM を動かすときによく語られる「MLX に変えれば常に速い」という見方に対して、かなり実務的な benchmark 投稿が注目を集めた。この投稿の主張は MLX が遅いということではない。むしろ、多くの比較は generation tok/s だけを見せており、実際の user-facing latency を大きく左右する prompt ingestion や context 処理のコストを見落としている、という点にある。coding agent、document classification、multi-turn RAG のように長い context を扱う workload では、この違いが重要になる。

セットアップも具体的だ。投稿者は M1 Max 64GB 上で LM Studio 0.4.5 を使い、Qwen3.5-35B-A3B を MLX 4-bit 経路と llama.cpp ベースの GGUF Q4_K_M 経路で比較した。純粋な generation speed だけを見ると、MLX は期待通り強い。数字はおよそ 57 tok/s 対 29 tok/s だった。ところが prompt が大きくなると話が変わる。約 655 token の短い prompt では、request 開始から最後の token までの effective throughput は MLX が約 13 tok/s、llama.cpp が約 20 tok/s。約 8,496 token の長い prompt では、両者とも end-to-end で約 3 tok/s まで近づいた。

鍵になったのは prefill だ。長い context のケースでは、MLX 実行の総応答時間のうち約 94% が prefill に費やされたという。つまり、decode が速くても user が待つ総時間は必ずしも短くならない。だから結論も単純な勝ち負けではない。出力が長く prompt が短いときは MLX が依然として有利だが、retrieval-heavy あるいは agentic な workload で入力 context が膨らむと、宣伝されがちな speedup は急速に縮む。コメントでは、今回の Qwen3.5 の hybrid attention path が現時点では llama.cpp でより良く最適化されている可能性も指摘されていた。

実務的な教訓は明快だ。local LLM の比較では単一の generation 数字ではなく、実際の workload を benchmark すべきだ。システムが大部分の時間を大きな context の読込に使うなら、prompt processing 効率が raw decode speed より重要になる。逆に短い prompt から長い出力を流す用途なら、MLX はなお有力だ。投稿者が公開した再現可能な harness は github.com/famstack-dev/local-llm-bench。