作者：SuSun
https://zhuanlan.zhihu.com/p/2061411883958137356
从推理角度看一下 Kimi K3，2.8 T， fp4 的话， 1.4 TB，hopper 其实也还行。但肯定这个架构说白了给 B 卡定制的，就是不知道国产卡是否受益了（投机一下，其实应该受益的，没受益的国产卡，只能说视野这块有点拉），说真的，有些交易者，甚至比我们这些推理更懂整个推理链条的生意流转。
核心架构是 KDA + Attn Res，对于推理来说，前者就是线性注意力吧，里面还是有普通注意力的(MLA，前面还加了一个 Gated，可能又是算法的花活吧)，所以就还是一个线性混普通注意力的模型，对于 kv cache 会有一些挑战，所以kimi 后文自己说会给 vllm 一个 pr 做 prefix cache，我也站在 openinfer 的角度聊一下这个等会。
896 个专家，每次激活 16 个，896个专家，常见的 2 倍数也可以，不过 EP 多少需要实际算（不同模型的甜点 EP 区实际上不太一样，比如读者有空实际可以算一下 Qwen 和 GLM 的，可能会得出不一样的结论）。这个要根据实际模型的 shape 压测，还没发权重，先忽略。
LatentMoe，就是压缩 moe all to all 的通信量吧，如果没理解错的话。但根据 Deepseek 的 MegaMoE 里说的，计算比较久，完全可以 overlap 通信，这个时候通信多快影响不大。但是还是那句话，计算多久，通信多久，怎么 overlap（MegaMoE 是切专家 wave overlap，过大的 EP 是否没有 wave 切）。
1M 上下文，不知道实际kv cache 大小了，可能也不大吧。
线性注意力对于 prefill 和 decode 的flops 要求，带宽要求这些，也要profile 然后算。
之后回归线性注意力对 kv cache 带来的挑战，我觉得分为三方面，一方面是 p/d 分离，第二方面是 prefix cache，第三方面是 decode 效率。
先聊 p/d 分离，正如 Mooncake 的新论文， Prefill-as-a-Service: KVCache of Next-Generation Models Could Go Cross-Datacenter ，Prefill As a Service，线性注意力降低了 pd 的传输量，意味着我们可以用更糟糕的网络质量完成 p/d 传输，因为 延迟简单看作 数据量除以带宽，数据量大幅减小，带宽也可以顺带减小，延迟却还保持不变。
好处是什么呢，是可以用一些更具有性价比的硬件做 prefill（怎么感觉 nv 越来越泡沫了），也许是国产卡，也许是一些老卡，甚至有没有可能是一些 spot instance，理想是这样，但现实是，大部分厂商，大部分机房，都只有一种卡，搞不出那种异构的部署。要搞异构硬件，要算很多账，然后说服一个个，也许一些大玩家可以玩这个。对于尔等 Maas 厂商，不可能为了 k3 一个模型下这么大的赌注，万一智谱下一个爆了。所以 infra 还是基模公司自己才能做的猛。
prefix cache 的话，自从前几天fable 哥和我说DP 是Replicated State Machine（复制状态机）后，对这个概念有了新理解。
普通注意力，就是保留全部日志（全部 kv)，想要回到某个状态，必须持有全部日志。持有全量日志，显而易见，大小会太大。
Raft里也不是全存日志的，不然日志无限增长，迟早会爆，所以 Raft有什么呢，有快照！日志积累到一定程度，我就给状态打个快照，然后把之前的日志全丢了。
这个快照就是线性注意力！
但是 Raft 也没有规定什么时候打快照，理论上你可以每个日志后都打一个快照，保留全量快照，也可以隔开 n 个打一个，也可以只打最后一个快照。对于线性注意力来说也是这样，什么时候，什么地方都可以存一个状态，也可以都不存，其实也就是 Deepseek V4 在技术报告里讨论的问题。
暂定把这个叫做快照策略吧，比较 naive 的实现就是，类似传统做法，也是 64 个 token 存一次就好，反正能跑。
快照策略的问题核心是什么？如何在有限的空间内，存储快照，达到最高的 hit ratio。
可以 1token 就存一个，也可以 1024 个 token 存一个，这些都 ok，这取决于在 workload下 cache simulator 的结果。这里存在一些 cache policy 的空间。naive能不能跑，能。只不过确实存在一点“学术”空间。
ok，继续后腿。确定了这个快照策略以后，就是索引问题。模型并不是完整的线性注意力，它还有普通注意力，他两存储的方式不同，当然如果按照前文那样 page style，是可以用一个索引管理的。
如果他两不一致，就会以后两个索引，一个线性注意力的索引，一个kv cache 的索引，处理 起来就头疼，所以应该以线性注意力为准，保持一致性。存线性注意力快照的时候，也保留一份 kv cache 的引用，这样只用查一个线性注意力的索引。调参就还是快照策略。
我觉得这个快照策略最优应该是动态的，比如用 coding agent 聊个 multi turn，我的 hit 边界在 turn 边界，而不是固定长度的。这里需要考虑共享前缀（用个类似 tinylfu 的东西），感觉我可以发论文了哈哈。
另一个问题就是分配策略，根据快照策略不同，实际上线性注意力和 kv cache 占用空间的比例很可能是动态的，比如有时候线性注意力 40%，kv cache 60%，有时候线性注意力 20%，kv cache 80%。这意味着你不能在启动的时候粗暴（虽然也能跑就是）划分一个比例，然后用两个free list 去分别管理。
vllm 和 tokenspeed，也都有探索
https://lightseek.org/blog/tokenspeed-inkling.html#flat-cache-layout-for-heterogeneous-states
https://arxiv.org/pdf/2503.18292
JENGA 写的确实还不错。
对分配的挑战是，之前分配的粒度只有一个常数，比如我只分配 4kb 的 unit，所以理论用 free list 可以 0 碎片。但现在有两个分配粒度，一个是线性注意力的 state,另一个是若干个 token 保存的 kv cache 粒度， 同时无法保证比例，我们该怎么分配，以实现最小的碎片率？
JENGA 的核心思想是，两个粒度求个 LCM，比如 2kB, 3KB，那就以 6KB 为粒度管理 free list，让这个大页都能被两个粒度使用。这里碎片在于有些大页可能用不满。这个取决于 LCM ，如果这两一样大，比如都是 4kb, 那么就完全还是沿用free list，做起来太方便了，不知道 kimi 考虑这个没有。
问问 gpt pro和 fable max 这个问题（AI 始终比我更聪明），他两给的也是 JENGA style（不知道是不是训过）。
看起来碎片问题也不是很严重。到这里 prefix cache 的问题讨论完毕了。
最后是 decode 效率，用了线性注意力，意味着请求 decode 时候占用的 hbm 更小了，进一步意味着更大的 batch size。比如之前 200GB 的 HBM，256k 的请求 decode 之前占用 5GB，那最大的 batch size 就是 40，现在只占用 2GB，最大的 batch size 就是 100。
如果 batch size 可以撑很大意味着什么，意味着 wideep 时候 all to all 通信量会变大很多（这可能也是他们做 LatentMoe 的出发点），同时意味着 group gemm 更容易被打到 compute。
但是在这一系列的看起来是降本的背后，k3 的 output 来到 15 美元/M tokens。
也顺手测一下 Kimi 吧，分配问题，pp 加速 decode 问题, ok, provider error，结束。
但其实 openinfer 还没有支持混合注意力的 prefix cache哈哈，最近有点忙，之后再看。