batching VS. continuous batching

batching是所有requests的output都生成完毕之后，才能开始处理下一个batch。一般要做input padding，要等待凑够batch才运行（也有超时bar）。

continuous batching是每完成1个request，就让1个新request加入到batch里。好处：可以让decode阶段的一个batch的token数目不减少，确保计算密度。

continuous batching VS. chunked prefill

VLLM里，前者是prefill优先。新到的prefill请求，打断所有decode请求。且prefill和decode不batching。

后者是decode优先。且prefill请求和decode请求可以batching到一起。decode那个batch的token较少填不满batch时，才会把prefill加进来。prefill的tokens太多时，分chunk每次做一段。

如下图，chunked prefill，deepspeed的论文：

2024年初；VLLM是prefill和decode不batch到一起。Orca是两者batch到一起。DeepSpeed是chunked prefill，即把input拆分，和decode阶段的batch到一起。

如何评测：模拟同时有1~32个并发用户（每个用户，拿到AI回复后，才会立即发送下一个prompt）（这里的“立即发送”，其实，跟现实用户想一会儿再打字一会儿，是不符合的）。prompt长度和output长度各自是某个值为均值的正态分布。

为什么用4张A100来测1份LLama-70B: 我猜想，1. 为了让batch能大些，1张卡可能batch大小太受限制；2. 为了推理速度快些，A100之间有NVLink，TP-4速度比TP-1要快。（我的猜测：可能因为我自己的实验是1张A100，所以chunked prefill优势不明显？）

用LLama2-13B测试，相比LLama2-70B，好处不那么明显了：

有效吞吐：

每张图，是人为规定的decode阶段SLA bar（按照人的阅读速度来定的）。

长尾延迟表现好：