Continous Batching、Inflight Batching、Prefill Decode分离、SpecDecode

Continous Batching（也叫Iteration Batch，vllm是这种思路）

简单来说就是batch内的请求长度和回复长度长短不一，存在Early-Finished的情况，但是空占着GPU的情况。Orca: A Distributed Serving System for Transformer-Based Generative Models这篇论文解决了这个问题，解决思路可以参考以下两个视频：

• Continous Batching：https://www.youtube.com/watch?v=oYUz0phWFEU&list=TLGGQ-lnizqcSg0wNzAyMjAyNQ
• 传统的Batching：https://www.youtube.com/watch?v=DnFH9d_nHPU&list=TLGGf4I7wLCYLRIwNzAyMjAyNQ

具体来说要处理3类问题：

• 对Early-finished Requests的处理。不同请求所生成的文本长度不一致，可能差别很大，并且不易预测。如果没有一个将已生成结束的请求从Batch中移除并提前返回结果的机制，那么只能等一个Batch内所有请求都完成生成后才返回生成结果，导致生成短文本的用户则需要多“陪跑”数秒到数十秒才能得到结果，这对于服务响应时间是不利的；
• 对Late-joining Requests的处理。完整生成一段文本需要长达数秒或数十秒的时间，是漫长的。所以如果没有一个将新请求插入到推理Batch的机制，那么只能像CV业务那样，等前面的请求都完成推理了才进行后续请求的推理。这会导致请求需要在系统中长时间等待排队，表现为服务响