新Inkling模型在MoE设计上改了KV缓存

Thinking Machines 新发布的 Inkling 模型有一个很有意思的架构细节，和 KV 缓存优化有关🧵👇

MoE 设计大体沿用 DeepSeek-V3 的方案（256 个路由专家，2 个共享专家，激活 6 个），但值得注意的是，他们没有采用 DeepSeek V3.x 版本标志性的 KV 缓存压缩技巧 MLA（+DSA）。

相反，Inkling 从完全不同的角度解决 KV 缓存问题：
→ 每 6 层中有 5 层使用滑动窗口注意力（SWA 与全局注意力的比例为 5:1）
→ 仅保留 8 个 KV 头（很可能是配合滑动窗口使用 GQA）

最终结果是：大约 83% 的层里，KV 缓存大小由窗口大小（恒定值）限制，不会随序列长度增长。

这种设计对注意力计算的影响和 DeepSeek 的 DSA 类似（但对 KV 存储的影响不同）：无论上下文规模多大，你始终只处理固定数量的 token。

在 Inkling 的 1M token 上下文场景下，缓存大小减少幅度非常大：在大型上下文场景中，相比全全局注意力设计，缓存大小缩小了约 6 倍，这还没算 GQA 相比 MHA 带来的节省（MLA 不算在内）。

收益不止是内存存储。解码环节受内存带宽限制：每生成一个新 token 都要读取整个 KV 缓存。更小的缓存 = 每个 token 需要读取的字节更少 = 长上下文推理更快、成本更低。

我们可以对比两种方案：DeepSeek 先压缩 KV 表示（MLA），再用 DSA 从上下文里只选出固定最大数量的 token，不随上下文长度变化。但 DSA 选出的 token 不是连续的，所以你仍然需要保存每个位置的 MLA token，只不过每个位置只需要保存一个压缩后的 KV token。

而 Inkling 就是简单地少缓存一部分内容：SWA + GQA。本质上，每 6 层里有 5 层，你可以直接扔掉 SWA 窗口之前所有 token 的 KV 条目。

两种方案都让 1M 上下文部署变得实际可行。但我猜测，DeepSeek v3（被 Kimi 2.x 和 GLM 5.x 使用）在干草堆找针这类测试上表现会更好，因为他们把所有 token 的表示都以压缩格式保留了下来。

尽管 Inkling 宣传了 1M token 的上下文窗口，官方博客并没有给出任何专门的长上下文基准测试结果：没有和其他模型对比 RULER、MRCR、LongBench 或干草堆找针测试。

推荐大家去看 @rasbt 写的关于滑动窗口的很棒的博客文章。@teortaxesTex