当百万级上下文开始进入实际需求，部署大模型最先撞上的往往不是'模型够不够强'，而是内存和算力到底够不够用。谷歌研究院的 TurboQuant 和 RWKV 开源基金会的 RWKV-6，正好从两个方向把这堵墙往后推了一截：前者盯住 KV 缓存压缩，后者直接把架构复杂度往线性方向拉。
两种思路，解决的是同一个问题
TurboQuant 解决的是 Transformer 推理里最扎眼的内存占用。RWKV-6 解决的是长序列计算时越来越不划算的二次方复杂度。一个减内存，一个减计算，路子不同，但目标一致：让大模型别只停留在'跑得动 demo'的阶段。
- TurboQuant：围绕 KV 缓存做 3-bit 量化，结合 PolarQuant 坐标变换和 QJL 误差校正，在官方测试里把 KV 缓存内存占用压到原来的 16.7%，注意力计算速度提升到 8 倍。
- RWKV-6：用线性复杂度的时间序列混合架构替代传统注意力的 O(n²) 开销，在长序列场景里把训练和推理成本都往下压。
对部署侧来说，这种变化很实在。同样一块卡，能塞下更长上下文；同样的吞吐预算，能撑住更多请求。这个价值不花哨，但很直接。
TurboQuant 为什么盯着 KV 缓存
Transformer 推理时，KV 缓存会随着上下文长度线性增长。序列越长，占的显存越夸张。原文里给了一个很直观的例子：LLaMA-3 70B 在 32K 上下文下，KV 缓存就要吃掉 10.7GB；如果拉到 100 万 token，需求会涨到 343GB。这个数字已经不是'优化一下能不能省点'的问题，而是硬件根本扛不扛得住。
TurboQuant 的思路不是去改模型结构，而是先把缓存压缩下来。
PolarQuant：先换坐标，再谈量化
PolarQuant 做的是坐标变换，把向量从笛卡尔坐标系转到极坐标系：
(x, y, z) → (θ, φ, r)
这里的想法不复杂，但挺顺手。角度参数在变换后分布更规整，半径的统计特征也更稳定，量化时不容易在局部区域堆出一坨误差。原文强调的一个点我觉得很关键：这种做法还能把额外归一化参数压到很少，工程上比每个维度单独维护统计量省事。
QJL：把量化偏差拉回来
压缩后的问题通常不在'能不能算'，而在'算出来偏不偏'。TurboQuant 里的 QJL（Quantization Jacobian-Lagrange）就是做误差校正的。它的核心结论可以概括成一句话：在合适的偏置项修正下，量化结果的期望值可以回到原始向量。
原文给出的形式是：
E[Q(x) + b·δ] = x
这里的 b 由向量自身特征推导，不需要额外存储。对部署来说，这种设计很讨喜：不靠堆额外参数硬补，而是把修正逻辑嵌进量化流程里，省空间，也省一次传输。
官方测试结果
谷歌团队在 Gemma 2B、Mistral 7B、LLaMA-3 8B 等模型上做了测试，结果比较亮眼：
- KV 缓存内存占用降到原来的 16.7%，也就是约 6 倍压缩
- 注意力计算速度提升约 8 倍（H100 GPU）
- 端到端延迟下降 35% 到 50%
- MMLU 精度损失小于 0.5%
- 10 万 token 的'大海捞针'测试里，准确率保持 99.8%
这些数据的意义不只是'快了多少'。更重要的是，它说明 TurboQuant 没有把压缩做成纯粹的精度交换。对很多场景来说，只要误差别明显抬头，部署侧就愿意拿显存和速度换这个收益。
RWKV-6 为什么被拿来和 Transformer 对照
RWKV-6 走的是另一条路。它不去挤 Transformer 的缓存，而是把序列建模方式改成线性复杂度。对长上下文来说，这种差别很大：序列长度翻 10 倍，Transformer 的注意力计算不是翻 10 倍，而是接近翻 100 倍。这个增长方式在中短文本里还能忍，拉到几十万 token 后就很难看了。
RWKV 的基本思路，是把 RNN 的状态累积和 Transformer 的训练友好性揉到一起。原文给的简化形式是：
output_t = σ(W_r * x_t) ⊙ (W_k * x_t) + (1 - σ(W_r * x_t)) ⊙ state_{t-1}
它的重点不是公式长什么样，而是每一步只依赖当前输入和历史状态，不需要像注意力那样把整个上下文两两比一遍。这样一来，时间复杂度就从 O(n²) 降到了 O(n)。
