LocalLLaMA、RTX 5090 1枚で Gemma 4 31B の 256K context benchmark を共有

r/LocalLLaMA の benchmark post が注目されたのは、local model ユーザーが何度も直面する問いを真正面から扱っていたからだ。KV cache compression を強くかけたとき、consumer GPU 1 枚で Gemma 4 の context length をどこまで伸ばせるのか。投稿者は custom llama.cpp fork と TurboQuant KV cache を使い、RTX 5090 1 枚で gemma-4-31B-it-UD-Q4_K_XL を 256K full context で動かしたと報告した。

setup の公開内容は unusually transparent だった。GPU は 32GB VRAM の RTX 5090、CPU は Ryzen 9 9950X3D、memory は 64GB DDR5、OS は Windows 11。build は TheTom/llama-cpp-turboquant branch に最近の Gemma 4 support を取り込んだものだという。KV cache には turbo3 mode を使い、投稿者は f16 比でおよそ 4.5 倍の compression だと説明している。262K context 時の VRAM usage は 27.7GB で、card には約 4.3GB の headroom が残ったとしている。

• prompt processing は 4K context で 3,362.71 tokens/s、262K context で 899.55 tokens/s と報告された。
• token generation は 61.51 tokens/s だった。
• compressed KV cache がなければ、32GB VRAM で 256K context は現実的ではないという見方が示された。
• さらに Gemma 4 向けの Windows/MSVC build fix も具体的に共有された。

この post の価値は、benchmark 数字だけでなく engineering caveat を併記している点にある。投稿者は 575W 付近で thermal throttling があったことを認め、prompt processing の低下を quadratic attention cost と結びつけて説明した。一方で generation speed は memory bandwidth bound だと切り分けている。加えて、GGUF bool array を読む std::transform が Release build で問題を起こし、Gemma 4 の sliding-window attention pattern を壊したという低レベルな debugging note まで残している。

コメント欄は適切に懐疑的だった。上位の反応は、これほど強い KV quant で品質がどこまで落ちるのか、256K token を入れたあとでも本当に long-context recall が保たれるのかを問うものだった。だからこの thread は単なる bragging post ではない。local LLM community が it fits から it still works へと評価軸を移しつつあり、他の人が再現や反証をしやすいだけの config と failure detail が共有されている点に意味がある。