Qwen 3.6-35B-A3B KVキャッシュベンチ：M5 Maxで0〜100万コンテキストにおけるf16、q8_0、turbo3、turbo4比較

llama.cpp（github.com/TheTom/llama-cpp-turboquant、feature/turboquant-kv-cache ブランチ）の TheTom の TurboQuant Metal フォークを使って、Qwen 3.6-35B-A3B Q8 で深さスイープ（depth sweep）を実行しました。TheTom はすでに M5 Max の数値を 32K まで公開していました。押し広げたときにカーブがどう見えるのかを確認したかったのです。

ハードウェア: MacBook Pro M5 Max、128 GB のユニファイドメモリ。フォークを cmake -B build -DGGML_METAL=ON でビルドしました。llama-bench、1セルあたり 3 レップ、flash-attn オン、mlock オン、8 時間の壁時計（overnight）で実行。

キャッシュ種別: f16、q8_0、turbo3、turbo4。K と V は対称（-ctk と -ctv を同じタイプに設定）。深さは 0〜1M トークン。

生成スループット（tok/s）:

プロンプト処理スループット（tok/s）:

目立った点

深さ 0 では標準的なストーリーどおりです。プリフィル（prefill）では f16 がわずかに勝ち、デコード（decode）では turbo3 が約 10% 遅いです。ほとんどのまとめはここで止まっています。

128K では 3-bit キャッシュがプリフィルで 8-bit キャッシュに追いつきます（turbo3 253 対 q8_0 245）。キャッシュが小さいほど、注意（attention）の間の帯域圧（bandwidth pressure）が減ります。このハードウェアでは、文脈が約 100K を超えてくると、帯域が律速の領域で turbo3 が有利になります。

より大きな驚きは turbo3 と turbo4 の比較です。両者はフェーズで分かれました。256K では turbo3 がプリフィルで turbo4 に +27% 勝ちました（128 対 101 tok/s）; しかしデコードでは turbo4 が turbo3 に +11% 勝ちました（25.5 対 22.9 tok/s）。512K ではデコードの差が +20% まで広がります（turbo4 16.0 対 turbo3 13.3）。プリフィルとデコードでボトルネックとなる領域が異なるため、適切なキャッシュ種別はワークロード次第になります。

そこから自分が得た結論:

• コーディングエージェント（深い文脈、ターンあたり生成トークンが多い）: turbo4
• RAG やバッチ QA（重いプリフィル、短い回答）: turbo3
• 純粋なコンテキストウィンドウ最大化（1M）: turbo3、これが収まる唯一のもの
• 短いインタラクティブ（32K 未満）: はまるなら f16、そうでなければ q8_0

turbo3 の 1M セルではデコードが 6.5 tok/s でした。チャット速度ではありませんが、夜間のエージェント的なバッチジョブなら実用的です。メモリは 1M で約 89 GB（重みが 37 GB、KV キャッシュが約 52 GB）で、OS の予約領域込みでも 128 GB に収まりました。

注意点

これは 1 台の M5 Max です。クロスオーバー（入れ替わり点）と、プリフィル／デコードの分岐は、メモリ帯域幅と GPU のコア数でおそらく変わります。対称な K と V の組み合わせだけをテストしました。(-ctk q8_0 -ctv turbo4) のような非対称（asymmetric）をデフォルトとして推すスレッドを見かけましたが、まだベンチしていません。TheTom のフォークは研究レベルで、まだ llama.cpp の main に取り込まれていないため、アップストリーム側の移動に合わせて rebase が必要になります。

M5-Max 以外の Apple Silicon（M2 Pro/Max、M3 Ultra、M4 Max）を使っていて、同じスイープを回したい場合は、下に数値を貼るか DM してください。カーブはハードウェアで変わる可能性が高く、2 つ目のデータ点があるとクロスオーバーの特徴づけに役立ちます。

詳しい版が必要なら、完全なグリッドと手法をこの書き込みに載せています: https://llmkube.com/blog/turboquant-m5-max-long-context