一、TurboQuant 速览
| 项目 | 内容 |
|---|---|
| 发布方 | Google Research（Amir Zandieh & Vahab Mirrokni） |
| 论文 | TurboQuant / PolarQuant(AISTATS 2026) / QJL(AAAI 2025)，ICLR 2026 报告 |
| 定位 | KV 缓存量化算法（不是权重量化） |
| 核心 | PolarQuant（笛卡尔→极坐标映射消常量）+ QJL（1-bit 残差纠错） |
| 压缩比 | KV 缓存 ≥6×（输出 3-bit） |
| 精度 | LongBench / RULER / Needle-In-A-Haystack 等零损 |
| 训练 | 无需训练、无需校准（data-oblivious，即插即用） |
| 现状 | 算法已公开；llama.cpp 对应 PR #21089(tbq3_0/tbq4_0) 待合入，目前 CPU-only |
| 一句话 | 压的是"占显存大户"的 KV 缓存，长上下文本地推理的显存账要重算 |
二、核心亮点
1. 它压的是 KV 缓存，不是权重------这是多数指南跳过的区别。 权重量化（Q4_K_M 等）压缩的是模型" permanent 知识"，让模型塞进显存；KV 缓存量化压缩的是推理时每个 token 的"临时工作记忆"。当上下文从 4K 拉到 128K，权重一分没涨，涨的全是 KV 缓存。一个 70B 模型在 128K 上下文下的 KV 缓存本身就能吃掉 40GB+ 显存------比很多量化后的权重（Q4 约 35--40GB）还大，甚至比权重更先顶爆单卡。TurboQuant 瞄准的正是这个被忽视的瓶颈：很多人以为把权重压到 Q4 就能本地跑长上下文，结果卡在 KV 缓存上。
2. PolarQuant + QJL 两步，做到"零额外开销"。 传统向量量化要为每个小块存全精度量化常数，额外吃掉 1--2 bit，部分抵消收益。TurboQuant 先随机旋转向量、转成极坐标（半径+角度），映射到固定的"圆形网格"，省掉昂贵的归一化与常量存储；再用 QJL（基于 Johnson-Lindenstrauss 变换）把残差压成单个符号位（+1/-1）做误差纠错。两步叠加，3-bit 输出、6× 压缩，且不需要任何校准数据。
3. 6× 压缩、零损、即插即用。 Google 在 Gemma / Mistral 上跨 LongBench、RULER、NIAH、ZeroSCROLLS、L-Eval 五套长上下文基准验证：下游任务结果"完美"（非可接受区间，是零损）；4-bit TurboQuant 在 H100 上注意力计算较 32-bit 基线最高 8× 加速 。最关键的是不需要重训、不需要微调------这点让它在生产侧一旦集成就能直接 drop-in。它还是 data-oblivious 的：不依赖任何数据集做校准，理论上能套到任意 transformer 架构，不用像 GPTQ / AWQ 那样逐模型调参，工程落地成本极低。
4. 对本地推理的意义：长上下文不再被 KV 卡死。 研究侧给的极端例子：原本 16GB 设备只能跑 16K 上下文的模型，6× 压缩后理论可到 96K+。更现实的是------你现在就能在 llama.cpp 开 q8_0 KV 缓存，把缓存直接砍半，质量几乎无感；开 q4_0 再砍到四分之一。这是"免费改一个参数"就能把可用上下文翻倍的操作，比换卡划算得多。
5. 现状：今天能用的是 q8_0/q4_0，TurboQuant 在路上。 TurboQuant 的 llama.cpp 实现（PR #21089，格式 tbq3_0/tbq4_0）截至本文撰写尚未合入主线 ，且当前仅 CPU 路径。所以本文的"部署实战"聚焦已稳定可用的 q8_0/q4_0 路径，并把 TurboQuant 标成"下一代升级项"------等你常用的后端合入后，直接换格式即可。
6. 为什么是现在？ Google Research 本周发布官方博客把这套算法推到台前，外部解读称其触发了 AI 内存概念股 3--5% 的回调------市场开始给"软件把显存压下来"定价。对本地部署者而言，信号更实在：长上下文推理的性价比拐点正在从"堆显存"转向"压缓存"，这是今年最值得跟的推理优化方向之一。另外提醒，GQA / MQA 架构（Llama 3.x、Qwen3 系列、Mistral）在训练时就靠减少 KV 头数天然缩小了缓存，选长上下文模型时顺手看一眼 KV 头数，能少压一档。
三、部署实战
环境准备（任选其一，均开源）：
bash
bash
# 方案 A：llama.cpp 最新版（需 Flash Attention 才能用非 f16 缓存）
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp && make -j && pip install -r requirements.txt
# 方案 B：Ollama（0.3.7+ 起在配置面板提供 KV cache 量化开关）
# macOS / Linux 手动启动
export OLLAMA_FLASH_ATTENTION=1
export OLLAMA_KV_CACHE_TYPE=q8_0
ollama serve启动推理服务（以任意一个长上下文 GGUF 为例，把缓存压到 8-bit）：
bash
bash
llama-server \
-m ./Qwen3-VL-30B-A3B-Q4_K_M.gguf \
-c 131072 \
-fa \
--cache-type-k q8_0 \
--cache-type-v q8_0 \
-ngl 99说明：
-fa开启 Flash Attention 是前置条件，否则-ctk/-ctv低于 f16 会失败；K 和 V 可独立设，显存极紧时可用-ctk q8_0 -ctv q4_0（V 比 K 更耐压）。TurboQuant 的tbq3_0待 PR 合入后再替换格式名即可。验证是否生效：启动时加--verbose，日志会打印每层的 cache 类型与大小；部分构建会悄悄回退到 F16，看不到确认就是没生效。
下面这段脚本按架构估算 KV 缓存显存，帮你判断该压到哪一档（来源：标准 KV 公式，非本机实测）：
python
python
def kv_cache_gb(n_layers, n_kv_heads, head_dim, ctx_len, bits):
# K、V 两套缓存；每元素字节数 = bits / 8
per_token = 2 * n_layers * n_kv_heads * head_dim * (bits / 8)
return per_token * ctx_len / 1e9
# 以 80 层 / 8 KV 头 / head_dim 128 的 70B 类模型、128K 上下文为例
spec = dict(n_layers=80, n_kv_heads=8, head_dim=128, ctx_len=128_000)
for name, bits in [("FP16", 16), ("Q8_0", 8), ("Q4_0", 4), ("TurboQuant(3bit)", 3)]:
print(f"{name:14s} KV 缓存 ≈ {kv_cache_gb(**spec, bits=bits):6.2f} GB")效果验证（连本地服务做长文档问答，顺带计时）：
python
python
from openai import OpenAI
import time
client = OpenAI(base_url="http://localhost:8080/v1", api_key="sk-noauth")
long_doc = ("【项目周报】..." * 300) # 模拟一份长文档
t0 = time.time()
stream = client.chat.completions.create(
model="local",
messages=[{"role": "user", "content":
f"基于下文回答问题：\n{long_doc}\n\n问题：本周完成的核心任务有哪些？"}],
max_tokens=512, stream=True,
)
n, ttft = 0, None
for chunk in stream:
delta = chunk.choices[0].delta.content
if delta:
if ttft is None:
ttft = time.time() - t0
n += len(delta)
print(f"生成 {n} 字，首字延迟 {ttft:.2f}s（KV 缓存已量化，长上下文不爆显存）")四、性能测评
| 方案 | KV 压缩比 | 质量影响 | 注意力加速 | 本地可用性 |
|---|---|---|---|---|
| FP16（默认） | 1×（基准） | 无损 | 1× | llama.cpp / Ollama 默认 |
| Q8_0 | ≈2× | 几乎无感（社区盲测难分） | 略增 | 立即可用 |
| Q4_0 | ≈4× | 聊天/RAG 可接受，代码生成掉 2--4% PPL | 略增 | 立即可用 |
| TurboQuant(3bit) | ≥6× | 长上下文基准零损 | H100 上最高 8× | llama.cpp PR #21089 待合入（目前 CPU-only） |
显存实例（70B 类 / 128K 上下文，按第三节脚本估算）：FP16 ≈ 41GB → Q8_0 ≈ 20GB → Q4_0 ≈ 10GB → TurboQuant(3bit) ≈ 7.7GB。对比社区实测参考（craftrigs，同档 70B@128K）：FP16 42.9GB / Q8_0 21.4GB / Q4_0 10.7GB，量级一致。
数据来源：Google Research 官方博客（ICLR 2026，6× 压缩 / 零损 / 8× H100 加速 / 无训练校准）、s5labs 与 themenonlab 对论文的拆解、llama.cpp / Ollama 官方 KV 缓存量化文档、craftrigs 社区实测。本文所有 tok/s 与显存均为官方 / 社区口径或公式估算，本机无 GPU 未实测，TurboQuant 的 6×/8× 数字来自 Google 研究侧 H100 基线，非消费级卡复测。
选型一句话 ：聊天 / 通用问答无脑 q8_0（质量几乎无损、缓存减半）；RAG 检索嵌入用 q4_0（只匹配不生成，掉点可接受）；代码生成等精度敏感任务保留 FP16 或只压到 q8_0；等 TurboQuant 的 tbq3_0 合入后，长上下文场景可优先切 3-bit 档拿满 6× 收益。
五、使用建议
- 适用场景 ：长上下文问答、RAG 检索增强、多轮 Agent 对话、32K+ 上下文且显存紧张的消费级 / 单卡部署。先把 KV 缓存开到
q8_0（质量几乎无损，缓存直接减半），再视余量考虑q4_0。 - 不适用场景 ：超长、精度敏感的代码生成------
q4_0KV 缓存曾在 Python 函数签名上出现可感知的错误（F16/Q8_0 正确），这类任务保留 FP16 或只压到 Q8_0。 - 调优提示 ：① KV 缓存与权重量化是正交的两件事，可叠加（权重 Q4 + KV Q8 同时省）；② 显存极紧用
-ctk q8_0 -ctv q4_0的非对称组合；③ 压完缓存记得把num_ctx调大，否则省下的显存没转化成可用上下文；④ 关注 llama.cpp PR #21089，合入后把格式换成tbq3_0/tbq4_0即可上 TurboQuant 的 3-bit 档。
显存档位参考（以 70B 类 / 128K 上下文估算，已与社区实测交叉验证）：
| 显卡 | 不开 KV 量化可用上下文 | 开 Q8_0 后 | 开 Q4_0 后 |
|---|---|---|---|
| RTX 4060 8GB | 不现实（权重都放不下） | 仅作参考 | 仅作参考 |
| RTX 4070 12GB | ~8K | ~16K | ~24K+ |
| RTX 4080S 16GB | ~16K | ~32K+ | ~48K+ |
| RTX 4090 24GB | ~32K | ~64K+ | ~96K+ |
说明：上表为"缓存主导显存预算"时的经验翻倍关系，实际取决于模型权重占用；小模型（7B/14B）权重本就宽松，压缓存主要换来更长上下文而非救命。
你本地跑长上下文时，是被权重还是被 KV 缓存先顶爆显存的？开 q8_0 后上下文拉长了多少？
数据口径提醒 ：TurboQuant 为 Google Research 研究算法（ICLR 2026），其 6× 压缩 / 零损 / 8× H100 加速均来自研究侧报告，尚未在消费级硬件广泛复测；llama.cpp 主线当前仅提供 q8_0/q4_0 KV 缓存量化（已稳定可用），TurboQuant 格式待 PR 合入。本文显存数字为按标准 KV 公式的架构估算，已与社区实测量级交叉验证，但不替代你的本机测量。
往后回顾：