【免费下载链接】turboquantTurboQuant: Near-optimal KV cache quantization for LLM inference (3-bit keys, 2-bit values) with Triton kernels vLLM integration项目地址https://gitcode.com/gh_mirrors/tu/turboquant点击查看免费下载TurboQuant 是一个面向 LLM 推理的 KV Cache 压缩方案ICLR 2026用 3-bit 量化 Key、2-bit 量化 Value配合 Triton 融合内核与 vLLM 集成实测可释放约 30% 的 KV Cache 显存、把上下文容量翻倍。这篇文章不谈基础用法而是聚焦它最有想象力的部分——full_tq 零分配模式的设计思路以及 KV Cache 压缩接下来最值得关注的 4 个演进方向 先回顾TurboQuant 的 4 种工作模式TurboQuant 通过钩子monkey-patch方式接入 vLLM 的注意力层定义了 4 种模式见 turboquant/integration/vllm.py模式行为状态off不启用纯直通可用capture_only把 KV 捕获进压缩存储但计算仍走原始 flash attention默认hybrid历史部分走压缩存储 最近 token 走精确环形缓冲可用full_tqTQ 接管一切包括 prefill规划中future目前的hybrid模式已经能拿到主要收益prefill 结束后释放掉 vLLM 的 paged KV Cachefree_kv_cache 函数decode 阶段的历史部分直接从压缩存储读取。在 8 卡 3090 上Qwen3.5-35B-A3B 的 KV 占用每档上下文稳定节省 30.9%等效多撑 3 个 131k 并发的请求数据详见 README.md 的 Benchmark 章节。而full_tq的目标更进一步——让压缩存储成为唯一真相从 prefill 开始就不分配 paged cache。full_tq 零分配模式它想解决什么问题1. 当前 hybrid 的浪费prefill 仍在用 paged cacheREADME 的 Limitations 部分讲得很直白Prefill still uses paged cache: KV cache is allocated at engine init and used during prefill. TQ frees it after.True zero-allocation requires deeper vLLM integration.也就是说现在的流程是先正常分配 → 计算完 prefill → 捕获压缩 → 再释放。对于长上下文场景这块先占后放的显存峰值其实可以省掉。2. 代码里的两条 no_alloc 通路full_tq 的核心机制已经写进了代码只是还没成为默认路径入口enable_no_alloc() 要求在创建vllm.LLM()之前调用它会 patch vLLM 的Executor.get_kv_cache_specs让 TQ 钩子在引擎初始化时自动安装而不是事后补挂prefill 直算当no_allocTrue时prefill 不再依赖 paged cache而是直接用原始张量走F.scaled_dot_product_attention_no_alloc_prefill_attention——反正 prefill 只需要算一次注意力根本不需要把 KV 落到池化的页表里。这两条通路拼起来就是 full_tq 的完整图景初始化即接管 → prefill 不落盘 → decode 全程读压缩存储。理论上对纯 dense 模型3-bit Key 2-bit Value 对应约 4.4 倍压缩、77% 的 KV 节省README.md 中 MoE 章节的推算。3. 写路径的配套设计环形缓冲 懒合并full_tq 要成立写路径必须足够便宜。TurboQuant 的捕获引擎turboquant/capture.py用了两个设计RingBufferdecode token 先进一个 128 token 的 bf16 精确环形缓冲满溢时才整块压缩避免每个 token 都量化的热路径开销CompressedKVStore 的懒合并各 chunk 以列表存放首次读取才拼接成扁平视图get_flat_cache写入使缓存失效。所有写操作都是 chunk 级没有 per-token 开销。这套结构保证了零分配模式下稳态内存只有压缩历史 128 token 环形缓冲不再有 paged cache 的影子。full_tq 还差什么三个现实障碍障碍一hybrid decode 每步全量反量化这是目前最大的算力痛点。README 明确指出Hybrid decode dequantizes all history: During compute, all compressed tokens are expanded to float32.The papers fused Triton kernels exist but the hybrid path doesnt use them yet.也就是说存储是省的但每一步 decode 仍要把全部历史 key/value 展开回 float32 再算注意力——Storage yes, compute no。好在内核已经写好了只差接上下一节展开。障碍二MLA 等新后端尚未覆盖integration/vllm.py 能识别 MLA 实现但 MLA 路径目前是纯直通TQ MLA path is deferred。deepseek 系模型的 KV 布局与普通 MHA 不同full_tq 要接管一切就必须先把这类后端啃下来。障碍三linear-attention 层不可压缩Qwen3.5 MoE 这类混合架构里30 个 linear-attention 层的状态占 KV 的 60%不在 TQ 的压缩范围内。full_tq 的收益会随模型架构的多样化而分化纯 dense 模型吃满 77%混合架构只能拿到 30% 左右。KV Cache 压缩的下一步方向结合代码现状社区接下来最值得盯的方向有四个方向 1融合 Triton 内核上线消灭 float32 反量化turboquant/triton_kernels.py 已经实现了三个融合内核其中turboquant_fused_decode_attention最有价值它在单次 pass内直接对压缩数据约 3 bit/元素算出 softmax 加权的注意力输出用 flash-attention 式的 online softmax 逐块推进全程不物化完整的 FP16 KV。关键技巧在 Kernel 1 的注释不是把 key 旋转回来而是把 query 前向旋转qPi^T从而完全避免展开 D 维反量化向量。把这个内核接到 hybrid 路径上存储省、计算不省的短板就补上了full_tq 才能真正叫满血。方向 2Value 量化升级与质量-容量权衡实测数据显示质量瓶颈不在 Key 而在 Value3-bit Key 的 cos_sim 是 1.000000近无损而 2-bit Value 只有 0.940换 4-bit 后升到 0.997quantize_values 已支持 2/4-bit 切换。下一步的合理演进是按业务场景动态选择 value_bits——吞吐敏感场景用 2-bit 换最大容量质量敏感场景用 4-bit 换近无损压缩率从 4.4x 平滑过渡。方向 3分层、自适应的 bit 分配当前 install_hooks 已经预留了initial_layers_key_bits参数前 4 层多给 1 bit Key说明不同层敏感度不同的思路已经落地了一半。更进一步的自适应方向按层实测注意力输出误差动态分配 bit 数把预算集中到敏感层在总容量不变的前提下进一步压质量损失。方向 4把不可压缩的部分也卷进来MLA 后端支持低秩 KV 布局kv_lora_rank下 TurboQuant 的旋转码本方案需要适配_is_mla_impl的检测逻辑已就位vllm.pylinear-attention 状态压缩Mamba/GDN 类的状态缓存目前被完整保留若能对其做类似的分组量化混合架构的压缩率将从 30.9% 向 dense 模型的 77% 靠拢更深的 vLLM 原生集成把 no_alloc 钩子从 monkey-patch 演进为 vLLM 内建选项消除 patch 兼容成本也才能可靠地做到初始化即零分配。写在最后TurboQuant 现在的 hybrid 模式已经交出了2.0x 上下文容量、30% KV 节省的答卷而 full_tq 零分配模式把目标定在了初始化即压缩、全程零 paged cache的终局状态。写路径环形缓冲 懒合并存储已经铺好剩下的关键拼图是让融合 Triton 内核接管 decode 计算——存储压缩与计算融合合流之后KV Cache 压缩才真正从省内存变成又快又省。对关注长上下文推理成本的读者建议重点跟踪 proof.py 和 benchmark.py 两套 A/B 基准脚本它们就是 full_tq 上线前后硬数据对拍的依据 赞分享【免费下载链接】turboquantTurboQuant: Near-optimal KV cache quantization for LLM inference (3-bit keys, 2-bit values) with Triton kernels vLLM integration项目地址https://gitcode.com/gh_mirrors/tu/turboquant点击查看免费下载相关推荐TurboQuant 上游化实战指南llama.cpp KV Cache 压缩分支的 4 阶段 PR 重构路线图TurboQuant 上游化实战指南llama.cpp KV Cache 压缩分支的 4 阶段 PR 重构路线图 本文档围绕仓库 docs/upstreamTurboQuant 实验全景Layer-Adaptive KV Cache、Temporal Decay 与 4.6x KV 压缩的工程实践TurboQuant 实验全景Layer Adaptive KV Cache、Temporal Decay 与 4.6x KV 压缩的工程实践 本指南以 dMLX Quality Suite 上下文规模扩展实测Qwen3.5-2B-8bit 在 TurboQuant turbo4 压缩 KV Cache 下的吞吐与峰值内存MLX Quality Suite 上下文规模扩展实测Qwen3.5 2B 8bit 在 TurboQuant turbo4 压缩 KV Cache 下的吞吐创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考