編集（2026-04-11）： 修正 — 私のNIAH 28/28の結果はTurboQuantのみで、TriAttentionの組み合わせではありません。~6.8×という数値は算術的な積み上げ推定（5.12× × 1.33×）であり、検証済みのエンドツーエンド取得（retrieval）主張ではありません。TriAttentionの統合はPPLの経路では有望ですが、取得（retrieval）についてはまだ検証されておらず、特にハイブリッドなアーキテクチャでは未検証です。厳密なテストについてはTheTomのV3分析をご覧ください。
llama.cppでAMD/HIP上において、KVキャッシュ削減手法を2つ組み合わせた結果：
- TurboQuant KVキャッシュ圧縮（turbo3）：~5.1×削減
- TriAttention KVキャッシュ剪定（75%保持）：~1.33×削減
- 合計（Combined）：~6.8×の全体KV削減
131Kコンテキスト時：f16 KV = 8.2 GiB → コンボ ≈ 1.2 GiB。
TurboQuantの数値（Qwen3.5-27B、RX 7900 XTX）： - GSM8K：1319問で72.0%（f16は66%） - NIAH：64Kコンテキストまで28/28 - ツール呼び出し：26/26 - PPL：4Kで+0.02%、16Kで-0.9% - スピードオーバーヘッド：約1〜2%
TriAttention は最近のNVIDIA/MITの論文（arXiv:2604.04921）に基づいています。私の実装はC/ggmlであり、実行時にPythonは不要です。Qwen3ファミリー向けの事前ビルド済みキャリブレーション統計が含まれています。
私の知る限り、これは現在、llama.cpp向けHIP/ROCmのTurboQuant実装として唯一のものです。また、TriAttentionについては唯一のC/ggml実装です。
リポジトリ： - TurboQuant（HIP）：llama.cpp-turboquant-hip - TriAttention（C/ggml）：triattention-ggml - llama.cppの議論：#20969
現在、3人のユーザーがStrix Halo（gfx1201）およびRDNA3（gfx1100）でテストしています。フィードバックやテスト結果を歓迎します。
[link] [comments]
