128GB の Mac で Qwen3.8 Flash Next をどう動かすか ─ 3つのランタイムを実測で比べた

ローカル LLM を Mac で動かす際、ランタイム選択が結果に大きく影響する。Qwen Flash Next を 128GB Mac で動かす 3 つのランタイムを実測した結果、mlx-serve が速度で全項目最速。プレフィルは llama.cpp の 2.6 倍、デコードは 2 倍以上という圧倒的な差が出たが、実務での完成度ではそれが報いられなかった。llama.cpp は 2 件の実装課題を完走し、テスト結果も正確。mlx-serve は 1 件が失敗、もう 1 件は完走したがテストを 7 倍多く回していたため、同じ課題で 4 分余分に時間を要した。エージェントの所要時間は 1 トークン当たりの速度ではなく、試行回数で決まるという発見が重要だ。速度が速くても判断を誤ればやり直す。その試行回数が違うのはなぜか、現在の測定では説明できない。量子化精度や内部の キャッシュ戦略が関係している可能性もある。oMLX は KV キャッシュの不具合でエージェントループ中に速度が崩壊した。ベンチマークでは動くが実務では動かない、という典型的な落とし穴に直面する。中小製造業がローカル LLM 導入を検討する際、カタログスペックの速度数字は参考程度。重要なのは自社の実務で何度もやり直す羽目になるのか、一発で済むのか。その差を生む要因は推論速度ではなく、判断精度や内部状態管理にある。実際に試してみる価値がある。