[TOC]
Translate and Note from http://www.anyscale.com/blog/continuous-batching-llm-inference
由于 LLM 通过迭代生成其输出，并且 LLM 推理通常涉及内存而不是计算，因此在很多实践中，优化系统级批处理可以使性能差异达到10倍甚至更多。
Continuous batching = 动态批处理 = 基于迭代级的批处理
两个重要的结论：
-
LLM 推理是内存 IO 限制，而不是计算限制。换句话说，目前加载 1MB 的数据到 GPU 所需的时间比 1MB 的数据在GPU上计算所需的时间长。这意味着 LLM 推理的吞吐量很大程度上取决于您能将多少批数据装入到高速 GPU 内存中。
-
GPU 内存的消耗量随着基本模型大小和标记长度的增加而增加。如果我们将序列长度限制为 512，那么在一个批处理中，我们最多只能处理28个序列；一个序列长度为 2048 则批处理大小最多只能为7个序列。需要注意的是，这只是一个上限，因为中间计算结果没有留下存储的空间。
静态批处理
LLM 驱动的聊天机器人服务不能假定固定长度的输入序列，也不能假定固定长度的输出序列。在撰写本文时，专有模型提供的最大上下文长度超过8K个标记。使用静态批处理，生成输出的变化可能会导致GPU严重未充分利用（未充分利用部分是右图中的 blank cell ）。
Baseline：Orca (osdi22)
一旦批中的一个序列完成生成，就可以在其位置插入一个新的序列，从而实现比静态批处理更高的GPU利用率。
现实情况比这个简化模型更复杂：因为预填充阶段需要计算，并且与生成阶段的计算模式不同，因此它不能很容易地与令牌的生成一起进行批量。
问题：计算模式有什么不同？
refer to Flexgen：prefill是矩阵x矩阵，generation是向量x矩阵
Continuous Batching
连续批处理框架目前通过超参数来管理这个问题：等待已服务比和等待结束序列标记的请求比（waiting_served_ratio）。
Experiments
Baseline
Throughputs测试
- Metrics
Tokens/second
- design
使用一个简单的基准测试脚本向我们的模型服务器提交 HTTP 请求。基准测试脚本以突发方式提交所有请求，使计算饱和。
- result
Laterncy测试
- Metrics
Second
- Design
在一个真实的用例上进行延迟-吞吐量权衡优化：对每个框架进行基准测试，并测量随着每个框架的累积分布函数（CDF）的变化，该函数如何随着每个框架的部署而变化。
实验没有像在吞吐量基准测试中那样同时提交所有请求。而是通过预先延迟每个请求一定的时间来进行基准测试。
通过泊松分布来确定每个请求提交后等待多长时间。泊松分布由λ和Queries Per Second（即每秒击中模型端点的查询数量，QPS）进行参数化。我们测量在 QPS 为1和 QPS 为4时的延迟，以了解随着负载的变化，延迟分布如何变化。
可以看到，在提高吞吐量的同时，连续批处理系统也改善了中位数延迟。这是因为连续批处理系统允许在有空间的情况下，将新的请求添加到现有的批次中。
并且在所有百分位数上都得到了改进：
However, like static batching, continuous batching is still limited by how much space is available on the GPU. As your serving system becomes saturated with requests, meaning a higher on-average batch size, there are less opportunities to inject new requests immediately when they are received.
随着QPS增加，GPU预留空间的期望变小，因此static和continous的差距也在变小：
we have shown that continuous batching significantly improves over static batching by
- reducing latency by injecting new requests immediately when possible
- enable advanced memory optimizations (in vLLM’s case) that increase the QPS that the serving system can handle before becoming saturated.
