量子化Gemma 4 31B、メモリ半分でtokens/secをほぼ2倍へ引き上げつつ99%精度を維持
Original: What compression looks like on @vllm_project. Same Gemma 4 31B. Red Hat AI's quantized version runs at nearly 2x tokens/sec, half the memory, 99%+ accuracy retained. Open source. Quantized with LLM Compressor. Links in comments. @_soyr_ for the 2-minute demo. View original →
このポストが示した数字
Quantizationは、数字だけ派手でも本番でqualityが落ちれば意味が薄い。だからこそRed Hat AIが2026年4月13日のXで示した要約はシンプルでも強い。
“nearly 2x tokens/sec, half the memory, 99%+ accuracy retained.”
比較軸も分かりやすい。同じGemma 4 31Bを使い、quantized variantがtokens/secをほぼ2倍まで押し上げ、メモリ消費を半分にし、それでもaccuracyを99%+保つという主張だ。もしこの数字が一般的なinference構成でも再現されるなら、31B級open modelをどのhardware tierで回せるか、batchingやlatency budgetをどこまで詰められるかが変わってくる。
open-sourceの文脈
Red Hat AIのアカウントはconsumer向けteaserより、open model serving、quantization、vLLM ecosystemの実務情報を流すことが多い。今回もその流れにあるが、単なる「速くなった」では終わらない。コメントには LLM Compressor と複数の Gemma 4 quantized checkpoint が直結している。GitHubではLLM Compressorを、vllm向けdeployment最適化のためのlibraryとして説明しており、weight-only/activation quantization、Hugging Face integration、safetensors互換を備える。
さらにRed Hat AIは後続replyで、teamがquantized modelsに対して500,000 evalsを回し、その知見を “Give Me BF16 or Give Me Death?” に結び付けていると補足した。ポイントはcheckpointを小さくすること自体ではなく、formatを適切に選べばbaseline accuracyの99%+を回復しながら、servingコストを実務レベルで下げられるという点だ。
次に見るべきは再現性である。Xではthroughput screenshotが速く広がるが、現場ではGPU差、prompt length、tool calling trace、chat template依存のタスクでqualityがどう保たれるかが重要になる。independent builderがopen Gemma 4 variantsの品質維持とメモリ圧縮を確認できれば、このpostは単なるbenchmarkの見栄えではなく、強いopen modelをより安く回せるという実務シグナルになる。
Sources: Red Hat AI X post · LLM Compressor · quantization paper · Red Hat AI Hugging Face models
Related Articles
約350ポイントを集めたLocalLLaMA投稿は、Gemma 4 26B A3Bが適切なruntime設定と組み合わさると、ローカルのcoding-agentやtool-calling workflowで非常に強く感じられると主張している。投稿者は他のローカルモデル環境で経験したprompt cachingやfunction callingの問題と対比して語っている。
高評価のLocalLLaMA投稿は、Qwen3.5-27BのQ4 GGUF群をBF16基準で比較し、「忠実度優先」と「効率優先」の選択を分けて示した。
LocalLLaMAがざわついたのは「新モデルが出た」からではない。RTX 5090 1枚で Qwen3.6-27B を約80 t/s、218k context で回したという具体的な数字が付いていたからだ。