Google把32B模型壓到5GB顯存，實測后我發現3個坑

周末我在自家K8s集群上跑了組數據：TurboQuant把KV緩存壓到3比特，理論壓縮率4.57倍。這個數字夠漂亮，但生成速度掉了5-6倍——沒人提前告訴你這個。

如果你本地跑過大模型，應該熟悉這個場景：32B模型權重占20GB，上下文拉到32K，顯存直接飆到28GB。權重沒變，是KV緩存跟著序列長度線性膨脹。每個token在每層每個注意力頭都要存key和value向量，FP16精度下，32K上下文能吃8GB以上。

Google這篇ICLR 2026的論文，解法是給KV向量先做Walsh-Hadamard變換（WHT旋轉），把分布"高斯化"，再標量量化到3比特。產物叫TQ3_0，從16比特壓到約3比特，理論省4.57倍空間。

我的測試環境：不是實驗室，是客廳

硬件叫ShadowStack，一臺家用推理服務器。軟件是我寫的LLMKube，開源K8s operator，管llama.cpp的模型下載、GPU調度、多卡分片、健康探針和Prometheus指標。

TurboQuant用的animehacker/llama-turboquant分支，帶CUDA實現的WHT核函數。注意這是Stage 1實現，沒論文里的QJL殘差校正。我用Kaniko直接在集群里編譯，目標SM 86（Ampere）和SM 120（Blackwell）。

LLMKube的InferenceService CRD還沒--cache-type參數，我打了個Docker鏡像，用entrypoint腳本透明注入TurboQuant開關：

#!/bin/bash TQ_CACHE_TYPE="${TQ_CACHE_TYPE:-tq3_0}" TQ_ENABLED="${TQ_ENABLED:-true}" if [ "${TQ_ENABLED}" = "true" ]; then exec llama-server "$@" --cache-type-k "${TQ_CACHE_TYPE}" --cache-type-v "${TQ_CACHE_TYPE}" else exec llama-server "$@" fi

exec很關鍵，讓llama-server當PID 1，K8s的探針和信號處理才能正常工作。

對照組設計：只動一個變量

相同模型權重、相同上下文、相同并發，只換KV緩存類型（FP16 vs TQ3_0）。全部開Flash Attention。

吞吐量測試：4并發、8K上下文，持續壓測5分鐘。

上下文掃描：從4K到131K逐檔部署，每檔壓測2分鐘，nvidia-smi記錄顯存。

結果：省顯存是真的，慢也是真的

生成吞吐量（tokens/秒）全模型掉5-6倍。prompt處理速度倒是沒明顯變化，因為預填充階段KV緩存還沒膨脹。

顯存節省符合預期：32B模型+32K上下文，FP16要28GB，TQ3_0壓到約18GB。131K上下文時差距更夸張，FP16直接OOM，TQ3_0能跑完測試。

但延遲結構變了。首token時間（TTFT）幾乎沒動，可生成階段每個token要解碼，WHT旋轉+3比特量化/反量化的開銷全堆在這里。用戶體感就是"第一個字很快，后面越寫越卡"。

精度方面，我用lm-evaluation-harness跑了幾個標準任務。TQ3_0在HellaSwag和MMLU上掉點1-2%，日常對話幾乎無感，數學推理能察覺。Stage 1沒做QJL殘差校正，論文說加上能追回大部分精度，但代碼還沒開源。

最意外的發現：顯存省下來的空間，我沒法直接開更大模型。llama.cpp的模型加載和KV緩存是分開的內存池，TQ3_0省出的10GB碎片化了，不夠再塞一個7B模型。除非重寫內存分配策略，否則"省顯存=跑更大模型"這個等號不成立。

另一個沒寫進論文的細節：WHT旋轉在消費級GPU上的實現，SM 86和SM 120效率差很多。Blackwell的Tensor Core有原生支持，Ampere靠模擬，差距能到30%。Google的基準測試用的TPU，CUDA路徑屬于"能跑"級別。

誰該用，誰再等等

我的判斷分三層。

第一類用戶：顯存硬瓶頸，寧愿換延遲換容量。比如要在單卡24GB上跑32B+64K上下文，TQ3_0是目前唯一解。接受每秒10 token的輸出速度，能換來不爆顯存。

第二類用戶：追求吞吐，別碰。量化開銷把生成速度砍到腳踝，并發上去后GPU利用率反而下降。這類場景等QJL實現+ kernels優化，或者直接用FP8權重+FP16 KV的混合方案。

第三類用戶：精度敏感，等Stage 2。數學、代碼、長文檔摘要，TQ3_0的1-2%掉點可能觸發連鎖錯誤。論文里的QJL殘差校正號稱能壓到0.3%以內，但代碼還沒放出來。

一個有趣的旁支發現：我的LLMKube wrapper被社區fork了十幾個，有人拿去接vLLM，有人試了CPU offload混合策略。開源社區的標準做法——論文放出來，實現靠民間——這次依然成立。Google的reference implementation還在"coming soon"，animehacker的分支已經能跑生產流量。

最后留個數據：131K上下文測試時，TQ3_0的顯存曲線在壓測第90秒有個詭異抖動，從14GB瞬間跳到19GB又回落。我翻了三個小時代碼，確認不是內存泄漏，是llama.cpp的KV緩存預分配策略和TurboQuant的變長編碼沖突。這個抖動在FP16模式下不存在。

如果你也在測TurboQuant，有沒有遇到同樣的抖動？或者QJL的代碼放出來了的話，誰踢我一腳。