@huc2 这三种方案都是精度无损的(不考虑 float 不满足交换率)，我们实现过方案 1 和 3 。chunk split 会保存之前算好的 kvcache, 然后当前 chunk 在 attention 的时候使用前面的 kvcache ，这样就无损了。前缀缓存确实也是类似的。
按我的经验，kvcache 只能是前缀匹配，不能随意匹配中间的，要不然结果对不上了。

之前实现过 continuous batching, 会把 prefill 和 decode 拼在一次处理。新 sample 的插入确实会打断 decode ，现象就是用户生成会卡顿，如果 prompt 不长一般影响不大，但长 prompt 高 qps 下会非常影响性能。
对此业界有一些应对方案，1. 前缀缓存 2. chunk split 3. prefill 和 decode 分离 。前两个方案可以缓解打断问题，方案 3 可以彻底解决打断问题。

Z3B0c2h1b0BvdXRsb29rLmNvbQo=

感谢

Z3B0c2h1b0BvdXRsb29rLmNvbQo=

感谢

过来捧捧场，万一中

@Deville 滴滴做生意可以理解，要盈利天经地义。但做生意要将诚信，把虚假的功能放在软件里面，违背了基本的诚信。

@taresky 我是滴滴钻石会员。这里不是插队的问题，我等了 20 分钟的时候已经排到第一位了。

@ioschen 我打的快车单，滴滴软件里面也显示了快车的入口。我不想打拼车单。

@ioschen 快车单：1 个小时都没接。拼车单：立马接单。