【免费下载链接】turboquant
TurboQuant: Near-optimal KV cache quantization for LLM inference (3-bit keys, 2-bit values) with Triton kernels + vLLM integration
TurboQuant是一个针对 LLM 推理的 KV Cache 量化开源方案:Key 压到 3-bit、Value 压到 2-bit,配合 Triton 融合内核和 vLLM 集成。实测表明,单张 RTX 5090 的最大上下文容量直接翻倍到 91.4 万 token,8 卡 RTX 3090 跑 MoE 模型时每卡稳定省 30.9% 显存,而且推理质量几乎无损。
一句话看懂:TurboQuant 是什么 💡
跑大模型时,KV Cache(注意力缓存)是显存里最会"膨胀"的部分——上下文越长吃得越多。TurboQuant 的思路是:
- 随机正交旋转:先把向量信息"摊平"到各维度;
- Lloyd-Max 最优量化:对 Key 做 3-bit(或更高)标量量化,配合预生成码本;
- QJL 投影:用 1-bit 符号位保留残差信息;
- 分组量化 + 位打包:Value 按 2-bit/4-bit 分组压缩,4 个值塞进 1 个字节。
核心实现分布在 turboquant/quantizer.py(量化算法)、turboquant/codebook.py(Lloyd-Max 码本)和 turboquant/codebooks/(预生成码本文件)。
实测一:单卡 RTX 5090,上下文容量翻倍 🚀
测试环境:单张 RTX 5090(32GB),vLLM 0.18.0,Qwen3.5-27B-AWQ(dense 模型,4-bit 权重)。
| 指标 | 基线(bf16 KV) | TurboQuant(3b Key / 2b Val) |
|---|---|---|
| Prefill 吞吐(30k 上下文) | 1,804 tok/s | 1,907 tok/s(+5.7%) |
| Decode 吞吐(30k 上下文) | 1.264 tok/s | 1.303 tok/s(+3.1%) |
| 释放的 KV Cache | — | 30.0 GB(4 卡合计) |
| 最大 token 容量 | 457,072 | 914,144(2.0x) |
| 峰值激活内存 | 644.6 MB | 599.2 MB(-7.0%) |
三个值得注意的结论:
- 容量 2 倍:同样的显存,能装下的上下文直接翻倍;
- 速度不降反升:更小的 KV 读写让 prefill 快了 5.7%;
- 理论压缩比 4.4x:dense 模型上纯注意力层的 KV 可省约 77%(这是混合 MoE 模型只能省 30.9% 的原因,下文解释)。
实测二:8 卡 RTX 3090 跑 MoE,每卡省 30.9% 显存 📉
测试环境:8 张 RTX 3090(24GB,TP=8),Qwen3.5-35B-A3B MoE 剪枝版(10 层 full-attention + 30 层 linear-attention,共 40 层)。
TurboQuant 只压缩 10 层 full-attention 的 KV,各上下文长度下的每卡显存对比:
| 上下文 | 基线 KV/卡 | TQ KV/卡 | 每卡节省 | 节省比例 |
|---|---|---|---|---|
| 8,000 | 55.7 MB | 38.5 MB | 17.2 MB | 30.9% |
| 32,000 | 191.5 MB | 132.3 MB | 59.3 MB | 30.9% |
| 64,000 | 374.3 MB | 258.5 MB | 115.8 MB | 30.9% |
| 100,000 | 578.1 MB | 399.2 MB | 178.8 MB | 30.9% |
| 131,000 | 755.7 MB | 521.9 MB | 233.8 MB | 30.9% |
省下的显存能拿来干什么?
- 上下文容量:1,411,680 →2,043,808 token(1.45x);
- 或者让再多 3 个并发的 131k 上下文请求挤进同一批卡里——对生产部署来说往往更值钱。
💡 为什么是 30.9% 而不是 77%?因为这个 MoE 模型 60% 的 KV 来自 linear-attention 层,这类状态本身不可压缩,TurboQuant 只能覆盖那 40%(10/40 层)× 约 77% 的压缩收益 ≈ 30.9%。纯 dense 模型才能吃满完整压缩比。
质量验证:压缩了,模型"变笨"吗?🧪
这是量化方案最容易被质疑的点。项目用了一整套测试来回答:
| 测试 | 结果 |
|---|---|
| 单针大海捞针(512 ~ 131k token) | 全部长度PASS |
| 近满上下文 5 针检索 | 5/5全部找回 |
| 3 针多事实一致性 | 3/3全部找回 |
| 黄金比例续写 | PASS,困惑度 1.05~1.35 |
| 3-bit Key 量化余弦相似度 | 1.000000(近无损) |
| 2-bit Value 量化余弦相似度 | 0.940 |
| 4-bit Value 量化余弦相似度 | 0.997 |
结论很明确:3-bit 的 Key 压缩几乎无损,质量瓶颈在 2-bit 的 Value。对质量敏感的场景建议把 Value 提到 4-bit(0.997),牺牲一点压缩比换回精度。
怎么上手:3 步跑起来 ⚡
git clone https://gitcode.com/gh_mirrors/tu/turboquant cd turboquant pip install -e .之后按需运行:
| 脚本 | 用途 |
|---|---|
| proof.py | 基线 vs TurboQuant 的 A/B 对比基准(README 推荐脚本) |
| benchmark.py | 综合基准:显存、吞吐、质量、上下文容量 |
vLLM 接入通过install_turboquant_hooks(...)注入注意力层的 KV 捕获钩子,关键逻辑在 turboquant/integration/vllm.py,解码阶段则依赖 turboquant/triton_kernels.py 里的 3 个融合 Triton 内核。完整架构说明见 README.md。
已知局限(诚实版)⚠️
- Value 量化是瓶颈:2-bit 时 cos_sim 只有 0.94,质量敏感任务建议 4-bit;
- 只压 full-attention 层:linear-attention / Mamba 混合模型收益打折(上文 30.9% 的由来);
- Prefill 阶段仍走 paged cache:TurboQuant 是在 prefill 之后才释放内存,真正的零分配需要更深的 vLLM 集成;
- 项目的"对抗性审计"章节(见 README.md 的 Adversarial Audit 一节)主动标注了部分宣传口径偏激进的地方,这种诚实度在同类项目里比较少见。
总结
TurboQuant 给出的组合拳是:3-bit Key 近无损 + 2-bit Value 省显存 + Triton 内核不掉速 + vLLM 无缝集成。如果你正被长上下文的显存瓶颈卡住,或者想在现有 GPU 上多塞几个并发请求,这套方案是目前 KV Cache 量化里值得优先尝试的选择之一。
【免费下载链接】turboquant
TurboQuant: Near-optimal KV cache quantization for LLM inference (3-bit keys, 2-bit values) with Triton kernels + vLLM integration
相关推荐
TurboQuant快速上手教程:5步接入vLLM,省30%显存让长上下文容量翻倍
TurboQuant快速上手教程:5步接入vLLM,省30%显存让长上下文容量翻倍 TurboQuant 是一款面向 LLM 推理的 KV Cache 量化工具
LMDeploy KV Cache 量化实战:INT4/INT8 在线量化与 TurboQuant 深入解析
LMDeploy KV Cache 量化实战:INT4/INT8 在线量化与 TurboQuant 深入解析 本篇技术指南以 LMDeploy 的 KV Cac
人工智能大模型模型推理服务推理引擎本地部署模型量化Strata 社区基准实测:RTX 5090 上 IQ2_XS 量化 128K 上下文的吞吐、复现方法与内存遥测
Strata 社区基准实测:RTX 5090 上 IQ2_XS 量化 128K 上下文的吞吐、复现方法与内存遥测 本文基于 Strata 仓库中归档的一份社区基
人工智能大模型本地部署推理引擎模型推理服务模型量化
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考