TurboQuant 72小时极速实测：超聚变FusionOne AI首批落地实践

　　 TurboQuant是啥：Google Research抛出的一个“极限压缩”思路，主打把LLM推理里的KV Cache压到3bit左右，显存降低≈6倍，在数据中心级高带宽加速器平台的测试中，注意力logits计算最高≈提速8倍，而且不需要再训练，理论与实验都相当硬核。

　　行业为什么沸腾：它正面击中了推理阶段的“内存墙”，而非只在权重量化上做小修小补；媒体持续关注、社交平台热议，相关市场情绪也随之起伏。

　　但Google没放代码：只有博客和论文。超聚变研发团队连夜啃完论文，自己把算法敲了出来，打通自研推理引擎和关键算子，搞到了第一批可用的推理数据。本文记录了全流程的工程要点与坑位。

　　01

　　背景：这波为什么值得“熬夜跟进”

　　3月24-25日，Google Research发了TurboQuant的技术博客，配套论文将分别在ICLR2026/AISTATS2026亮相。核心卖点很直接：KV Cache内存≥6倍压缩、注意力计算最高8倍提速、精度几乎无损，而且零训练/零校准，适合在线推理直接“插拔”。

　　 TurboQuant抓住了当前LLM推理的真瓶颈——KV Cache随上下文长度线性暴涨，吞噬HBM/显存与带宽，长上下文一上来，显存先满、带宽先卡。这也是为什么它能迅速刷屏的根本原因，而不是又一个“论文里好看、工程上难落地”的trick。

　　外部反响你大概也刷到过：媒体把它形容成现实版“Pied Piper”，甚至引申到“Google的DeepSeek时刻”；市场上，存储/内存板块当天明显波动。当然，也有冷静声音提醒——TurboQuant主要影响推理KV内存，不等于整个存储行业的需求瞬间蒸发。

　　02

　　 TurboQuant的“人话拆解”：

　　两步走、把额外开销干没

　　一句话版：TurboQuant是个两段式的量化管线

　　 PolarQuant先把向量做随机旋转/极坐标重排，用(b1)bit做主体压缩，核心是绕开传统量化里那些“每块都要存的归一化常数”；

　　 QJL(Quantized JL)再对残差做1-bit无偏校正，把注意力需要的内积精度拉回到安全线。

　　更严谨一点：论文证明这套做法在MSE/内积失真的率失真界附近，在3.5bit/channel可达质量中性、2.5bit/channel仍然可用。此外，它是数据无关(data-oblivious)、在线可用，不需校准集。

　　为什么这很关键？

　　传统4bit/3bit量化经常“名义上省很多、实际上又被scale/zero-point/归一化元数据吃回去1–2bit”，极限压缩时尤其明显。PolarQuant的巧妙之处就是把这部分“额外税”免了；QJL则保证内积不飘，适配注意力。

　　03

　　 Google没放代码？

　　社区“抬手就干”，我们也“开干了”

　　这次没有“拿来即用”的官方实现，属于“讲清楚数学、指标亮眼，但代码请自理”的路线。媒体也明确提示：这是研究，不是产品。

　　社区反应很快：已经有PyTorch参考实现、Apple MLX/Qwen的KV压缩demo，甚至有PyPI包用来快捷接入KV Cache压缩做A/B。说明工程上落地并不玄。

　　还有开发者面向工程师写的“怎么用、为什么重要”的实操指南，对我们迅速研读论文→搭骨架，也很有参考价值。

　　04

　　超聚变的72小时

　　从论文到产线的“打通记”

　　4.1架构｜我们把TurboQuant放进了哪里

　　推理引擎内核：TurboQuant被我们作为KV Cache后端的一个新profile(kv_backend=tq3b)接入到FusionOne AI平台的Wings推理加速引擎中。

　　4.2关键算子｜“三板斧”啃下来的

　　1.随机正交旋转/极坐标分解(PolarQuant核)

　　难点：旋转矩阵的生成与复用，避免per-token高开销；极坐标角度量化要无元数据开销。

　　解法：

　　旋转矩阵使用种子化Householder/QR生成+head复用；

　　半径/角度分治，角度用预计算Lloyd-Max codebook，常数驻留常量缓存，核内查表。

　　2.残差QJL(1-bit无偏校正)

　　难点：把残差投影+取符号做成完全并行、无临时元数据的核，同时提供内积无偏估计接口给注意力。

　　解法：

　　采用线性同态的投影矩阵(种子化生成)，残差在shared memory聚合后一次性符号化；

　　注意力侧给出dot(u,v_hat)+qjl_corr(u,sign(P.res))的封装算子。

　　3.KV生命周期与调度

　　难点：压缩/解压插入后，KV管理要么“抖动”要么引入额外copy。

　　解法：我们让prefill阶段直接产出压缩态KV，decode期间只对局部块做解码与校正，配合页式KV管理与多租户整形，把读放大压到最小。

　　4.3精度&资源实测：零精度损失、KV内存占用>60%下降、可容纳Token数↑3.76倍

　　为保证不同批次/同事复现实验结论一致，我们按既定验收口径(①内积偏差分布(query-key)；②注意力得分KL与Top-K稳定性；③端到端任务指标逐项评估TurboQuant接入效果。结果如下：

　　1.端到端任务指标｜精度无损

　　在长上下文基准(如Needle-in-a-Haystack、LongBench等)的实测中，TurboQuant版本与FP16基线的主要任务指标无显著差异(“精度无损”)，满足我们对对外口径的“质量中性”要求。

　　2.资源侧收益｜显存使用实测下降>60%

　　 KV Cache的显存占用在相同场景下实测下降超过60%，直接带来更高的并发承载与更平滑的尾延迟。

　　3.容量提升｜相同21.26GB预算下Token容量↑3.76倍

　　基线：在21.26GB KV预算下，可容纳Token数为154,768；

　　启用TurboQuant：同样21.26GB预算下，可容纳Token数提升至582,704；

　　提升倍数≈3.76倍(582,704/154,768)。

　　为便于对比，关键指标汇总如下：

　　05

　　我们踩过的坑：供后来者少走弯路

　　旋转矩阵的复用边界：复用粒度太粗会引入头间相关的小偏差，建议按head/层有节制地复用+随机种子管理(可复现实验)。

　　量化codebook的存取：别在核里搞“二分查找”那套，Lloyd-Max codebook直接LUT+向量化，对齐Google提倡的“加速器友好”。

　　解码路径的读放大：只做局部块恢复+残差校正，慎用“整页解压”，不然带宽又回去了。

　　06

　　这事对“算力经济学”的意义

　　把KV Cache从“最贵的内存消耗项”降到“可忽略级别”，意味着在相同硬件上能跑更长上下文/更高并发，或者在更便宜硬件上跑到“够用”的服务等级。媒体普遍认为：这类效率红利，会让AI服务的单位成本更可控，边缘/端侧也更具现实性。

　　同一时间，行业也在降噪：别把推理侧KV压缩等同于“内存产业不需要了”。训练/存储/数据侧的需求并没被TurboQuant触及。历史反复证明，当AI某个环节的成本大幅下降时，用量的增长往往远超成本的节省。DeepSeek的蒸馏和MoE当初也被认为会减少算力需求，结果呢？需求不减反增。降本在每一个环节都是确定性趋势，但它带来的不是需求萎缩，而是需求爆发。

　　07

　　下一步计划(Roadmap)

　　模型/框架适配：完善与vLLM/FusionXpark的对接适配，给到“一键切KV后端”的体验；跟踪社区MLX/llama.cpp方向的实现，维持互测自证。

　　位宽策略：场景化位宽混用(例如3.5bit默认、2.5bit触发在检索/辅助路径)，配合动态门控。

　　评测公开：等内测稳定后，我们会把端到端评测与可复现实验整理输出，口径与Google博客常用基准对齐。

　　08

　　给工程师的“快用指南”

　　(伪代码示例)

　　仅展示接入思路，便于开发同学一眼看懂，不代表最终代码形态。

　　#1)构建TurboQuant KV后端(极简示意)

　　 rot=make_random_orthogonal(seed=layer_id*131+head_id)

　　 codebook=load_lloyd_max_codebook(bits=b-1)

　　 proj=make_jl_projection(seed=layer_id*13131+head_id)

　　 def tq_encode(k_or_v):

　　 z=rotate(k_or_v,rot)#随机旋转

　　 r,theta=to_polar(z)#极坐标分解

　　 theta_q=quantize(theta,codebook)#(b-1)bit res=z-from_polar(r,dequant(theta_q,codebook))

　　 sgn=jl_sign(res,proj)#1-bit残差校正

　　 return(theta_q,r,sgn)

　　 def tq_attn_dot(query,key_hat,sgn,proj):

　　 return dot(query,key_hat)+qjl_corr(query,sgn,proj)

　　#2)Prefill：直接产出压缩态KV；Decode：局部块解压+QJL校正

　　(对照论文和Google博客里的描述就能对上号：PolarQuant负责主体压缩，QJL负责1-bit校正；“加速器友好”重点就是向量化、查表、无元数据。)

　　09

　　结语：把“论文里的好点子”

　　变成“机房里的好生意”

　　老实讲，TurboQuant不是一个“看一眼就会的花活”，但也绝不是“只能在论文里发光”的高冷数学。真正的壁垒在工程接入、算子优化、系统调度，而非“有没有一个reference”。我们已经把自研推理栈的接口与调度和TurboQuant深度贴合，在缺少官方实现的前提下，依据论文细节与统一验收口径完成算法复现与加速器级优化——这就是我们性能团队这几天的工作日常。把内存墙凿出一道缝，单卡能跑的上下文更长、并发更稳，这就是业务侧能感知到的真实优化。

　　.

　　.

　　.

　　.