MLXは速くない。M1 Max上で4つの実ワークロードに対してMLXとllama.cppをベンチマークしました。実効トークン/秒は大きな問題です。何を見逃しているのでしょう？ベンチマークとM2〜M5の比較をお願いします。

免責事項: ローカルのLLMの運用はまだ初心者ですが、知識を得て、測定し、物を作るのが好きです。

だから、どこを見ても「MacでMLXを使えば2倍速い」という話を見かけました。中古で買ったM1 Max 64GBにQwen3.5-35B-A3Bをロードしました。
LM Studioでは、同じGGUFモデルで生成が57トークン/秒、29トークン/秒でした。明らかに思えました。すべてがサクサク動くと思っていました。ところが…結局は違いました。

それから実際のタスクを計測しました。GGUFは文書分類で速かったが、マルチターンのエージェント対話ではそれほど速くありませんでした。それが私をさらに深い洞察の旅へと導きました。

そのtok/sの値は生成（トークンを1つずつ出力すること）だけを測定します。プリフィルはコンテキスト長に比例してスケールします。生成はそうではありません。約8.5千トークンのコンテキストでは、プリフィルがMLXの総応答時間の約94%を占めていました。これは非常に誤解を招く。したがってカウンターが「速い」と言っていても、実際には非常に遅いのです。

個人的には、実効トークン毎秒はより興味深い指標です。メッセージを送信して最後のトークンまでの平均トークン/秒です。

コンテキストサイズ	MLX 実効	GGUF 実効	UIに表示される値（tok/秒）
~655 トークン	13 tok/s	20 tok/s	MLX: 57, GGUF: 29
~1,453 トークン	10 tok/s	16 tok/s	MLX: 57, GGUF: 29
~3,015 トークン	6 tok/s	11 tok/s	MLX: 57, GGUF: 29
~8,496 トークン	3 tok/s	3 tok/s	MLX: 57, GGUF: 29

表はプリフィルが優勢で、実効トークン/秒（ユーザーが実際に体感するトークン/秒）は、コンテキストが大きくなるほど急降下します。8千トークン程度でもそれほど大きくはありません。したがって、周知されている60〜200トークン/秒程度の数字は、エンドユーザーの実体験からはかなり距離があります。

MLXがまだ勝つ局面: 短い文脈で長い出力。クリエイティブな、単一プロンプト推論では非常に高速です。しかし、日常のワークロードである8ターンのエージェント対話で300〜400トークンの返信となる場合、結果は前後します。出力が十分にあるときには2倍の生成速度がプリフィルの遅さを補うため、十分な出力がある場合はMLXが多くのターンで勝ちます。GGUFは6ターン目、MLXは8ターン目で勝つことがあります。その出力長さでは、どれだけモデルが1ターンあたり書くか次第で基本的にはコイン投げです。

GGUFは再び、長い入力プロンプトと短い出力のケースで有利です。私の文書分類のユースケースのように。

詳しい解説を用意しました。興味がある方はどうぞ。

セットアップ: Mac Studio M1 Max、64 GB。LM Studio 0.4.5。Qwen3.5-35B-A3B、MLX 4-bit 対 GGUF Q4_K_M。予備モデル、温度0.6、思考モードオフ。
これからOllamaとの比較も行う予定ですが、もう少し時間が必要です。
最適化のテストはまだ未実施です。これもまた非常に深い話題です。

私のデータはM1 Maxのみです。M2〜M5はメモリ帯域幅が高く、プリフィルを直接改善するはずです。新しいシリコンではギャップが狭まるのか広がるのか気になります。

何を見逃しているのでしょうか？

プリフィルを最適化するためのチューニングパラメータを見つけました（リポジトリ参照）。これらを使ってもう一度試し、bare llama.cppを使ってLM StudioとOllamaを比較します。

自分でベンチマークを試してみてください！ 私が設定したシナリオで今後さらなる数字が出ると嬉しいです。
新しいチップがプリフィルの問題をどれだけ解決するか、非常に気になります。

git clone https://github.com/famstack-dev/local-llm-bench cd local-llm-bench python3 bench.py --model llama3.1:8b python3 bench.py --model qwen3.5:35b-a3b