高性能 LLM 推理框架的设计与实现

高性能 LLM 推理框架的设计与实现

与传统的 CNN 模型推理不同，大语言模型的推理通常会分成 prefill 和 decoding 两个阶段。每一个请求发起后产生的推理过程都会先经历一个 Prefill

过程，prefill 过程会计算用户所有的输入，并生成对应的 KV 缓存，再经历若干个 decoding 过程，每一个 decoding 过程，服务器都会生成一个字符，并将其放入到 KV 缓存当中，之后依次迭代。

由于 decoding 过程是逐个字符生成的，每一段答案的生成都需要很长时间，会生成很多字符，所以 decoding 阶段的数量非常多，占到整个推理过程的 90% 以上。

在 Prefill 过程中，虽然计算量很大，因为要一次性完成用户输入的所有词的计算，但它只是一次性的过程，所以在整个推理中只占不到 10% 的时间。

在大语言模型推理中常会用到四个指标：Throughput（吞吐量）、First Token Latency（首字延迟）、Latency（延迟）和QPS
（每秒请求数）。这四个性能指标会从四个不同的方面来衡量一个系统的服务提供能力。

首先来介绍 Throughput（吞吐量）。从模型推理层面上看，最先关注的就是吞吐量。吞吐量是指当系统的负载达到最大的时候，在单位时间内，能够执行多少个 decoding，即生成多少个字符。测试吞吐量的方法是，假设所有用户都会在同一时刻到来，并且这些用户问的都是一样的问题，这些用户可以同时启动和结束，且他们生成的文本的长度和输入的文本长度都是一样的。通过使用完全相同的输入，组成一个完整的 batch。在这种情况下，系统的吞吐量会达到最高。但这种情况是不合实际的，所以这是一个理论的最大值。我们会测量在一秒钟之内，系统能够执行多少个独立的 decoding 阶段。

第二个指标是 First Token Latency（首字延迟）。指的是当一批用户进入到推理系统之后，用户完成 Prefill 阶段的过程需要花多长时间。这也是系统生成第一个字符所需的响应时间。很多需求关注这一指标，希望用户在系统上输入问题后得到回答的时间小于 2~3 秒。

第三个指标是 Latency（延迟）。指的是每一个 decoding 所需要的时长。它反映的是大语言模型系统在线上处理的过程中，每生成一个字符的间隔是多长时间，也就是生成的过程有多么流畅。大部分情况下，我们希望生成的延迟小于 50 毫秒，也就是一秒钟生成 20 个字符。这样大语言模型的生成是比较流畅的。

最后一个指标是 QPS（每秒请求数）。反映了在线上系统的服务当中，一秒钟能够处理多少个用户的请求。这一指标的测量方式比较复杂，后面会展开介绍。

对于 First Token Latency 和 Latency 这两个指标，我们都进行了相对完善的测试。这两个指标会因为用户输入的长度不同、batch size 的不同而发生非常大的变化。

在上表中可以看到，对于同样的 7B 模型，如果用户的输入长度从 8 变成 2048，Prefill 的时间将从 6.78 毫秒，直到变成 2078 毫秒，即 2 秒的时间。如果有 80 个用户，每一个用户都输入 1,024 个词，那么 Prefill 在服务端就要跑 2 秒左右，这个时间已经超出了可以接受的范围。但如果用户输入长度都很短，比如每次访问只输入 8 个词，哪怕 768 个用户同时到来，首字延迟也只有 165 毫秒左右。

与首字延迟最相关的就是用户的输入长度，用户输入的长度越长，首字延迟也会越高。用户输入长度如果很短，那么首字延迟在整个大语言模型推理过程中都不会成为瓶颈。

而后面的 decoding 延迟，通常只要不是千亿级别的模型，decoding 的延迟都会控制在 50 毫秒以内。它主要受到 batch size 的影响，batch size 越大，推理延迟也会越大，但基本上增加的幅度不会很高。

吞吐量其实也会受到这两个因素的影响。如果用户输入的长度和生成的长度很长，那么系统吞吐量也不会很高。如果用户输入长度和生成长度都不是很长，那么系统吞吐量可能会达到一个非常离谱的程度。

再来看 QPS。QPS 是一个非常具体的指标，它表示系统中每秒可以处理多少个请求，在进行这个测试的时候，我们会使用实际的数据。（关于这份数据，我们已经做好了采样，并且放在了 github 上。）

QPS 的测量跟吞吐量不太一样，因为在实际使用大语言模型系统的时候，每一个用户到来的时间是不确定的。有的用户可能早来，有的用户可能晚来，并且每一个用户做完 Prefill 之后的生成长度也是不确定的。有的