许欣然 2024-06-28 22:18 北京

转发一下 kimi 许欣然的最新文章，也欢迎关注他们最新的 Tech Report：GitHub - kvca

转发一下 kimi 许欣然的最新文章，也欢迎关注他们最新的 Tech Report：GitHub - kvcache-ai/Mooncake。未来的推理优化还有巨大空间...就比如apple intelligence目前的这套系统，留出了推理优化和架构创新的各种可能性...

本论文与很多 Prefill/Decoding 分离的论文不同的是，这套方案已经在大规模集群上进行几个月的验证并证明了方案的有效性。目前这套系统承载了 Kimi 线上80% 以上的流量，效果很好也为产品带来了更多的设计空间。这也是为什么一个 POC 写在所有业内论文之前的系统，直到今天才发布出来跟大家见面。

系统是需要跟随着应用快速变化的，同时也需要 硬件厂商 和 云厂商 早点接受新的理念才能跟上浪潮。发出这篇论文，主要是希望给各方提供一些信心，提供一些推理规模足够大场景下的必然优化思路。

趁这个机会，希望给各家硬件厂商和云厂商一些“暴论”

Mooncake 这类的存算分离策略会是一个长期趋势。

现在、立刻、马上真能省很多钱（毕竟不能公开规模和每日请求的 pattern，如果你说省不了那你都对）。

KVCache 的容量会长期保持高位，因此围绕着 KVCache 来优化是非常有必要的。"private memory per request” 是整个推理系统优化中的关键瓶颈（否则 groq 万岁），会有很多努力来降低 KVCache 的大小，但同时会有更多动力来增大。

分离之后，允许整个系统往 “算力/$” 和 “带宽/$” 的两个方向独立发展，对硬件优化是更友好的。AR 的模型架构惯性在短期内难以颠覆，因此总可以认定 decoding 的成本总会跟 bandwidth 成本有非常强的正相关性质。“带宽/$” 低一个数量级的硬件方案已经在肉眼可见的范围内了。纵观历史，“算力/$” & “带宽/$” 同时最优的芯片似乎还没出现过，集群上必然要拆分成异构的两个部分。

Mooncake 方案和 MLA、各种 KVCache 的压缩方案 都是正交的，KVCache 变小了意味着 Mooncake 的方案收益会更明显。

的确，有很多方向可能会让 Mooncake 的架构变成没必要的方案。

given hardware lottery，新架构演进会是一个相当缓慢的过程（不 AR、用 RAG 做 Attention 等等方案），不能因噎废食。

包括我们自己也在投入很多资源在 break 现有框架上，因此有理由相信在可见的未来推理方案还会变动。

由于目前海量的推理压力，所以软件系统做为一个迭代速度极快的方案，就应该一代模型一次跟进。

预测这个状态至少会持续2~3年，因此集群层面现在已经值得做拆分了。

芯片层面值得做为一个重要的设计考量，在芯片的 IO 能力上要多预留一些能力。