Gemma 4 31Bを、TurboQuant KVキャッシュ圧縮を使って、単一のRTX 5090でフル256Kコンテキストとして動かせました。
システム仕様
| コンポーネント | 仕様 |
|---|---|
| GPU | NVIDIA GeForce RTX 5090（32GB VRAM） |
| CPU | AMD Ryzen 9 9950X3D（16コア） |
| RAM | 64GB DDR5 |
| OS | Windows 11 |
セットアップ
- モデル：
gemma-4-31B-it-UD-Q4_K_XL（Unslothより、17.46 GiB） - ビルド：TheTom/llama-cpp-turboquant のブランチ
feature/turboquant-kv-cache。Gemma 4対応のために、最新のアップストリームmasterとマージ済み - KVキャッシュ：
turbo3（3-bit PolarQuant + Hadamard回転、f16に対して約4.5倍圧縮） - 設定：
--n-gpu-layers 99 --no-mmap --flash-attn on --cache-type-k turbo3 --cache-type-v turbo3
ベンチマーク結果
| テスト | 速度（t/s） |
|---|---|
| pp4096 | 3,362.71 |
| pp16384 | 3,047.00 |
| pp65536 | 2,077.96 |
| pp131072 | 1,428.80 |
| pp262144 | 899.55 |
| tg128 | 61.51 |
- VRAM使用量（262K）：27.7 GB / 32 GB（4.3 GBの余裕）
- GPU温度：575W時に78-80°C（262Kの実行中に一部サーマルスロットリングが発生しました。実際にスロットルが無かった場合の速度はおそらく~950+ t/s…かも）
要点
256Kフルコンテキストは単一の5090に収まる — turbo3のKVキャッシュ圧縮により、K/Vが8ビットから実質3ビットにまで圧縮され、品質低下はほぼゼロです（TurboQuant論文、arXiv 2504.19874に基づく）。これがないと、32GB VRAMでは256Kは不可能です。
プロンプト処理は予測可能にスケールする — コンテキストを4倍増やすごとに速度はおおむね半分になる（注意計算がO(n²)のため）。
トークン生成は一定 — コンテキスト長に関係なく61.5 t/s。メモリ帯域が律速。
Gemma 4対応には修正が必要だった — llama.cpp内のMSVCのバグを直す必要がありました。
std::transformで(const bool*)を使うと、ReleaseビルドでGGUFのbool配列のうち~48要素を超える部分を正しく読み取れません。これにより、Gemma 4のハイブリッドアテンションアーキテクチャにおけるSWA（sliding window attention）層のパターンが壊れます。修正：手動のuint8_t*ループに置き換え。
ビルドメモ（Windows/MSVC）
WindowsでTheTomのTurboQuantフォークをビルドする場合：
ggml-turbo-quant.c—#include <math.h>の前に#define _USE_MATH_DEFINESを追加（MSVCはデフォルトではM_PIを定義しないため）ggml-cpu/ops.cpp— ファイルスコープでextern "C" int turbo3_cpu_wht_group_size;を追加（C/C++リンケージの不一致）llama-model-loader.cpp—get_arr()内のstd::transform((const bool*)...)を、手動のuint8_t*ループに置き換え（boolポインタキャストに伴うMSVC最適化バグ）- ターボのグローバルに関連するDLLシンボルエクスポートの問題を避けるため、
-DBUILD_SHARED_LIBS=OFFでビルドする - RTX 5090向けに
-DCMAKE_CUDA_ARCHITECTURES=120aを使用（MXFP4テンソルコア命令にはsm_120aが必要）
[リンク] [コメント]
