昨日の投稿へのフォローアップです： https://www.reddit.com/r/LocalLLaMA/comments/1sy7srk/。コメントでは、パープレキシティ、KLダイバージェンス、非対称K/Vの組み合わせ、そして64Kのデータポイントを求められていました。今晩（夜間）かけて回しました。同じM5 Max、同じQwen 3.6-35B-A3B Q8、同じTheTom TurboQuantフォーク（feature/turboquant-kv-cache）です。
品質（wikitext-2に対するperplexity + KLダイバージェンス）
u/milpster と u/Karyo_Ten 向け。コンテキストサイズは4096です。標準の512ではKVキャッシュの量子化による効果が十分に出ないためです。f16は --kl-divergence-base でベースラインのlogitsを保存し、その後の各量子化実行ではそれに対してKLを計算します。
| キャッシュ | PPL | f16に対するKL | Top-1トークン一致率 |
|---|---|---|---|
| f16 | 5.7438 | ベースライン | n/a |
| q8_0 | 5.7433 | 0.0016 | 98.64% |
| turbo3（約4.9x） | 5.8092 | 0.0199 | 93.93% |
| turbo4（約3.8x） | 5.7810 | 0.0131 | 95.28% |
q8_0のKVは、この深さでは実質コストゼロです。PPLの差分は-0.0005で、±0.036のstderrの範囲内。KLは0.0016です。量子化されたキャッシュは、f16と同じTop-1トークンを98.6%の確率で選びます。昨日のコメントで懸念されていたのは「品質がどれくらい犠牲になるか」でしたが、4kコンテキストではノイズ程度です。
turbo3は、PPLが約1%増え、Topトークンの不一致が5パーセンテージポイント増える程度で、KLはq8_0の約12倍です。turbo4はその中間で、圧縮率が低い分だけ整合しています。品質コストは圧縮に比例して増えるだけで、驚きはありません。
非対称K/V（深さスイープ）
u/Sabin_Stargem 向け、そして昨日の私の未検証の注記（いわゆる caveat）です。decode tok/sは、対称スイープと同じ llama-bench のフラグ：
| 深さ | q8_0 K / turbo4 V | q8_0 K / turbo3 V | f16 K / turbo4 V |
|---|---|---|---|
| 0 | 82.9 | 81.8 | 72.8 |
| 8K | 75.4 | 75.6 | 16.9 |
| 32K | 66.0 | 63.2 | 8.6 |
| 128K | 41.0 | 38.2 | 2.8 |
| 256K | 27.1 | 25.0 | skipped |
| 512K | 16.5 | 14.8 | skipped |
-ctk q8_0 -ctv turbo4 が特に目立ちます。256Kでは、昨日の対称q8_0のスループットに一致しています（pp 128 vs 124、tg 27.1 vs 26.6）。さらに、対称q8_0が512KでOOM（メモリ不足）になったのに対し、こちらは512Kに収まります。つまり、turbo4のコンテキスト上限を持ちながら、q8_0級のプリフィル挙動が得られます。Vは安く圧縮でき、Kは高くつくというSabinの仮説は、スループット面ではその通りに見えます。品質面については、非対称コンボでPPLを回してループを完全に閉じたいところです。
-ctk q8_0 -ctv turbo3 は同じトリックですが、decodeが悪化します。V側の量子化をきつくすると、生成側への負担がより大きくなります。
-ctk f16 -ctv turbo4 は、このフォーク上のMetalでは壊れています。このFlashAttentionカーネルは、そのK/Vタイプの組み合わせをfast-pathしないため、汎用の「dequantしてからattentionする」経路にフォールバックします。8Kでは対称f16より34倍遅いです。128Kでは78倍遅くなります（4.1 t/s pp）。128Kを超えるセルは最後まで埋める価値がありませんでした。この組み合わせは使わないでください。
64K行
u/ocarina24 向け。プリフィル曲線の32K〜128K間のギャップを埋めます。深さ65536で7つの全設定を実行：
| キャッシュ | pp512 | tg128 |
|---|---|---|
| f16（対称） | 602.0 | 59.8 |
| q8_0（対称） | 479.2 | 57.9 |
| turbo3（対称） | 469.8 | 49.9 |
| turbo4（対称） | 418.0 | 55.2 |
| q8_0 K / turbo4 V | 468.2 | 55.9 |
| q8_0 K / turbo3 V | 465.6 | 52.6 |
| f16 K / turbo4 V | 8.3 | 4.9 |
目立ったのは2点です。1つ目、プリフィル曲線は64Kではほぼ収束しています。turbo3（470）はq8_0（479）から2%以内です。昨日のデータではturbo3が128Kで実際に先行していました（253 vs 245）。なので、このハードウェアでは64K〜128Kのどこかで帯域（バンド幅）制約のレジームに切り替わるようです。私の推定よりも早めに切り替わっています。2つ目、非対称のq8_0/turbo*の行も、この深さでは対称q8_0のプリフィル挙動にかなり追随しています。より深い行と同じ話です。
ここから私が受け取ったこと
昨日のキャッシュ種別の推奨を更新します：
- コーディングエージェント（深いコンテキスト、生成トークンが大量）： -ctk q8_0 -ctv turbo4 が新しい推奨です。K側はq8_0の品質、V側はturbo4の節約で、512Kに収まります。
- RAGまたはバッチQA（プリフィルが重い、回答は短い）：同じコンボ、あるいは最深部では対称turbo3。
- 純粋な1Mコンテキストを最大化：引き続き対称turbo3。これだけが収まります。
- 短いインタラクティブ（32K未満）：メモリが許せばf16、そうでなければq8_0。品質コストは本当にゼロです。
注意点
- PPLは4096コンテキストで測定しました。キャッシュがより飽和する深いコンテキストでの品質は、別の結果になり得ます。
- 非対称の品質数値はまだ保留です。スループットデータはV側圧縮が安いことを示唆していますが、非対称コンボでのKLまたはPPLはまだ測定していません。
- f16 K + turbo* は、Metal上のこのフォークではカーネルフォールバックになります。他のバックエンドでもこのコンボが動くと決めつけず、事前に確認してください。
- 単一のハードウェアデータポイント（M5 Max、128 GB）です。クロスオーバーする深さや、プリフィル/デコードの分岐は、メモリ帯域とGPUコア数で変わる可能性があります。
引き続き進行中
- u/GCoderDCoder。f16、turbo3、turbo4（q8_0は今週初めで62.2%、n=225）に対するAiderのPolyglotパス。各Polyglot実行は約6〜12時間なので、数晩分の直列になります。今週後半に実行予定です。
- u/noctrex。より広い量子化タイプ（q4_0、q4_1、iq4_nl、q5_0、q5_1）で深さスイープを拡張。Aiderの後に実施。
- u/Able_Librarian1569。転用可能性を確認するため、MoEでもDeltaNetでもないモデルで同じスイープを実施。より広い量子化タイプの後に。
昨日と同じオファーです。M5-Max以外のApple Siliconをお持ちで、この行列の一部を回したい場合は、下に数値を貼るかDMしてください。各セルの統計を掘り下げたい人には、rawのllama-benchおよびllama-perplexityの出力を送れます。
手法と、セルごとのstderrの数値を含む完全な書き起こし： https://llmkube.com/blog/turboquant-m5-max-quality-and-asymmetric
[link] [comments]
