如何评价DeepSpeed-FastGen这项工作？

首先，还是老套路，先来看看在FastGen之前已有的技术方案，以及这些技术方案面临的问题。

FastGen前的方案及问题

1. vLLM以及其Blocked KV Caching，详见：牛大脑袋：VLLM-PagedAttention评述 。其主要含义为将KVCache在内存上整合，以避免内存脆片，提升并发能力。
2. Orca及连续批处理。其主要技术推动点就是在每次前向推理时独立做调度策略，也就是token级独立处理。

基于这两点，一个模型推理系统的大致流程是这样的：在每一步推理中，首先判断有没有需要处理的Prompt，如果有，并且序列数量未达上限，那么就停下来处理Prompt，然后把处理后的KVCache交给Decoding阶段做批推理。否则直接做批推理。

但这种方法有一个问题，生成过程会中断。这带来的影响是，占用率和响应速度下降了。什么意思呢？当batch很大的时候，每次Prompt计算一次，会让全部的batch都停下来等待，这就会让所有的生成时间都变长，尤其是当Prompt也很长的时候，这个等待时间就很长。同时，在这个阶段当中，因为生成过程停下来再重启，GPU利用率也在下降，同时这部分时间内，带宽利用率也下降。（因为Prompt阶段是一个计算密集型，带宽未到极限）。

FastGen的出发点和解决方案

FastGen主要解决的就是Prompt延时问题，解决的核心思路：“通过对提示（prompt）和生成（generation）的动态分拆与融合，进一步改进了连续批处理和系统吞吐量。”

这篇文章基于三个观点：

Token latency的耗时和batchsize无关，和token长度基本线性，所以token数量是影响延迟的核心。这里，对token latency具体是什么没有明确说，有两种可能，一种是prefill阶段的耗时；一种是decode阶段的耗时，随着seq长度增加，decode延时也增加。我更倾向于认为是prefill阶段的耗时，因为这和后文拆分prefill强相关，反之如果是decode延时的话，就不太对了，因为图上显示推理时间的增加几乎和token长度正比例增加，在我的经验中，应该是有一个基础的耗时，然后token增加带来的单token推理长度增加比较缓慢。

当token比较长时，计算效率达到最大。对计算来说，无论token多少，都需要加载全部weight，这部分带宽占用是固定的。在token较少的阶段，这部分受限于weight带宽，无法完全发挥算力。当token数增加后，带宽占用基本不变下，算力线性上升，因此算力逐渐增加达到GPU算力上限。这个GPU效率随着token变化的关系是一个凹的。

为了让效率最高，理想的做法是让大任务和小任务结合起来，这样才能让效率最大化。展开来说，就是在prefill阶段，计算效率比较高，因为相对来说token数要多一些，而在decode阶段，计算效率相对较低，因为token数是1。把prefill和decode结合起来，效率要比prefill和decode分时做要高。对prefill来说是个计算密集型，对decode来说是个访存密集型，结合起来的话，计算利用率就会高。

但是为了做这个结合，在prefill和decode当中就需要做同步。特别是对prefill来说，需要把比较长的那种prefill拆分为短的prefill，也就是说做多次短prefill后再开始decode。理论上来说，这相当于在decode中间把prefill藏到流水线中，确实降低了prefill延时，但实现起来要考虑到decode延时（prefill和decode放在一起拖慢decode速度），因此提升效果有限，特别是对于decode比较长的。

总结

文章中的仿真结果也印证了这点。仿真的做法是挺鸡贼的，鸡贼之处在于，测试数据用的是长Prompt，短decode的。本来，Prompt和decode的长度分布是有一个固定分布的，绝不是这样。

真实数据分布和文章中测试数据对比

FastGen给出的算法，核心是解决了Prompt的耗时问题，以及如何把Prompt放在decode阶段的问题。但是为了解决这个问题，将Prompt的过程插入到decode阶段，造成了decode效率的某种降低。在其文章的测试中，鸡贼地用长Prompt短decode这种case，就是希望避免长decode过程把整体效果降低。

这篇文章的核心创新是将Prompt拆分后，藏到decode阶段上，以此降低系统总延时。但问题也是不少，第一，文章很多点没说清楚，比如延迟究竟是推理延迟还是prefill延迟，一个时钟片段做多长的prefill、多长的decode，这些统统没有说，更别说展开讨论了，要是有这部分，文章效果会好很多。第二，在测试时全部用的是长Prompt，短decode这种组合，不能证明实际算法的有效性，只能看成在某些特定场景下的优化，这点不指出的话有点误导人。不过话说回来，站在未来的视角去苛责过去的进步，也是有些强人所难，希望AI Infra领域可以有更多突破成果吧！