一、TurboQuant 速览项目内容发布方Google ResearchAmir Zandieh Vahab Mirrokni论文TurboQuant / PolarQuant(AISTATS 2026) / QJL(AAAI 2025)ICLR 2026 报告定位KV 缓存量化算法不是权重量化核心PolarQuant笛卡尔→极坐标映射消常量 QJL1-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。它还是># 方案 Allama.cpp 最新版需 Flash Attention 才能用非 f16 缓存 git clone https://github.com/ggml-org/llama.cpp cd llama.cpp make -j pip install -r requirements.txt # 方案 BOllama0.3.7 起在配置面板提供 KV cache 量化开关 # macOS / Linux 手动启动 export OLLAMA_FLASH_ATTENTION1 export OLLAMA_KV_CACHE_TYPEq8_0 ollama serve启动推理服务以任意一个长上下文 GGUF 为例把缓存压到 8-bitbashllama-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_0V 比 K 更耐压。TurboQuant 的tbq3_0待 PR 合入后再替换格式名即可。验证是否生效启动时加--verbose日志会打印每层的 cache 类型与大小部分构建会悄悄回退到 F16看不到确认就是没生效。下面这段脚本按架构估算 KV 缓存显存帮你判断该压到哪一档来源标准 KV 公式非本机实测pythondef 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_layers80, n_kv_heads8, head_dim128, ctx_len128_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, bitsbits):6.2f} GB)效果验证连本地服务做长文档问答顺带计时pythonfrom openai import OpenAI import time client OpenAI(base_urlhttp://localhost:8080/v1, api_keysk-noauth) long_doc (【项目周报】... * 300) # 模拟一份长文档 t0 time.time() stream client.chat.completions.create( modellocal, messages[{role: user, content: f基于下文回答问题\n{long_doc}\n\n问题本周完成的核心任务有哪些}], max_tokens512, streamTrue, ) 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}sKV 缓存已量化长上下文不爆显存)四、性能测评方案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同档 70B128KFP16 42.9GB / Q8_0 21.4GB / Q4_0 10.7GB量级一致。数据来源Google Research 官方博客ICLR 20266× 压缩 / 零损 / 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~24KRTX 4080S 16GB~16K~32K~48KRTX 4090 24GB~32K~64K~96K说明上表为缓存主导显存预算时的经验翻倍关系实际取决于模型权重占用小模型7B/14B权重本就宽松压缓存主要换来更长上下文而非救命。你本地跑长上下文时是被权重还是被 KV 缓存先顶爆显存的开q8_0后上下文拉长了多少数据口径提醒TurboQuant 为 Google Research 研究算法ICLR 2026其 6× 压缩 / 零损 / 8× H100 加速均来自研究侧报告尚未在消费级硬件广泛复测llama.cpp 主线当前仅提供q8_0/q4_0KV 缓存量化已稳定可用TurboQuant 格式待 PR 合入。本文显存数字为按标准 KV 公式的架构估算已与社区实测量级交叉验证但不替代你的本机测量。往后回顾单卡 24GB / 手机能跑的端侧 Agent 基座把 MiMo 的 1T 集群故事压到桌面金融增强开源模型Ling-3.0-flash-Fin私有化投研Agent新选择开源计算机/浏览器操作智能体:Nex-N2.5-mini 部署实测,