在此前的大模型技术实践中，我们介绍了加速并行框架Accelerate、DeepSpeed及Megatron-LM。得益于这些框架的助力，大模型的分布式训练得以化繁为简。

然而，企业又该如何将训练完成的模型实际应用部署，持续优化服务吞吐性能？我们不仅要考量模型底层的推理效率，还需从请求处理的调度策略上着手，确保每一环节都能发挥出最佳效能。

本期内容，优刻得将为大家带来vLLM[1]，一款高性能推理服务框架的相关内容。vLLM于近期推出了0.6.0版本[2]。那么，相比旧版本推出了什么新功能，又做了哪些优化呢？

**优刻得模型服务平台UModelVerse现已同步上线vLLM0.6.0。**仅需几步，即刻畅享新版vLLM带来的极速推理体验。文末为您带来详细的使用教程。

API服务端-推理引擎进程分离

推理服务框架需要考虑服务部署的两个要素：面向客户请求的服务端，以及背后的模型推理端。在vLLM中，分别由API服务端 (API Server) 和**模型推理引擎 (vLLM Engine)**执行相应任务。

1.1 进程共用 vs. 进程分离

根据旧版vLLM设计，负责处理请求的API服务端与负责模型推理的推理引擎，共用同一个python进程；

0.6.0版本将API服务端和推理引擎分离，分别由两个python进程运行。进程之间的信息交互由ZeroMQ socket进行传输 [3]。

上：API服务端与推理引擎共用同一个python进程；

下：API服务端与推理引擎各自独用python进程。

API服务端需要承担一系列处理HTTP请求等任务。通过对旧版本的性能分析，vLLM团队发现API服务端消耗大量CPU资源。

举个例子，在推理引擎端，轻负载下使用Llama3 8B模型推理生成1个token的耗时约为13ms；而相对应地，API服务端需要能够每秒处理76个token才能跟上推理引擎的速度。由于python GIL的存在，推理引擎还会与服务端争抢CPU资源。CPU端负载巨大无法及时处理计算，则会使得GPU端因等待CPU而产生空闲，无法充分利用性能[3]。

在0.6.0版本中，将API服务端与推理引擎端分离为两个进程后，两个进程可以各自专注于份内职责，而不会受GIL的影响。而在分离后，团队后续可以更好地对两端分别进行更细致的性能优化和打磨。

1.2 TTFT、TPOT和ITL

在进入测试对比前，先了解一下衡量语言模型服务推理效率通常参照的三个指标，即：

首个token响应时长 (Time to first token, TTFT）

每个token输出时长 (Time per output token, TPOT)

跨token延迟 (Inter-token latency, ITL)

TTFT顾名思义，就是从客户端发出请求后开始计时，直到服务端返回第一个输出token的耗时。过程中，由服务端收到请求后着手处理，交由调度器准备推理。推理引擎需要完成prefill任务。基于prefill得到的kv值，decode得到第一个输出token后返回。

而TPOT和ITL概念相对接近，表达的都是后续一连串decode的耗时。根据vLLM测试代码 [4]，我们定义如下：

TPOT是在一个请求从发出后，不纳入TTFT的耗时 (主要是为了排除prefill耗时)，到所有token全部decode完成并返回的整体耗时除以一共返回的token数量，即每个token输出的平均时长；

而ITL是在计算每次请求返回部分token时所需的时长，即服务端每次decode后返回一个或一批token所需的时长。

举个例子，如果每次服务端返回1个token，则ITL耗时应与TPOT接近；而当每次服务端返回5个token，则ITL耗时应接近于5倍的TPOT耗时 (因为ITL计算单次的时长，而TPOT计算单token的时长)。

1.3 测试&对比

在优刻得云主机上开展对比测试。

利用vLLM官方提供的benchmark_serving基准测试，我们可以模拟真实的客户端请求，从而对比vLLM 0.6.0与旧版vLLM (0.5.5)在进程分离上的优化导致的性能差异。关闭其他优化方法后，在保持其他参数不变的情况下，在opt-125m模型上开展测试。

在服务端，我们分别在0.6.0和旧版本上使用以下的参数：

#vLLM 0.5.5（共用进程）

vllm serve facebook/opt-125m \

--max-model-len 2048 \

--use-v2-block-manager

#vLLM 0.6.0（分离进程）

vllm serve facebook/opt-125m \

--max-model-len 2048 \

--use-v2-block-manager \

--disable-async-output-proc #关闭0.6.0的新优化方法：异步输出处理。下文有详解～

而在客户端，我们统一采用以下脚本。我们模拟100个请求同时发出，请求数据随机取自ShareGPT v3数据集。

python vllm/benchmarks/benchmark_serving.py \

--backend vllm \

--model facebook/opt-125m \

--tokenizer facebook/opt-125m \

--request-rate inf \ #所有请求无间隔同时发送

--num-prompts 100 \ #共100条请求发出

--dataset-name sharegpt \

--dataset-path dataset/ShareGPT_V3_unfiltered_cleaned_split.json \

--sharegpt-output-len 1024 \

--seed 42 #固定种子控制变量

经过测试，结果如下 (左旧版本0.5.5；右新版本0.6.0)：

进程分离以牺牲TTFT指标为代价 (笔者推测进程间ZeroMQ通信带来开销)，测试整体时长(Benchmark duration)比进程共用快近14秒，提速约40%。该模型参数量较小，GPU压力较小，瓶颈主要在于CPU。进程分离消除了CPU争抢造成的开销。

多步调度（Multi-step scheduling）

在请求调度层面，vLLM 0.6.0的更新中引入了多步调度 (Multi-step scheduling)的方法 [2]，使得请求处理的调度更高效。为了更好地理解多步调度的意义，我们简单了解一下vLLM调度器。

2.1 调度器 (Scheduler)

vLLM推理引擎LLMEngine中存在调度器 (Scheduler)的概念。调度器控制来自服务端的输入请求会以什么顺序送入模型执行推理。

对于一个输入请求，我们需要首先对输入的句子执行prefill计算，并基于prefill得到的kv值开展decode计算，即预测下一个token。而调度器的职责就是以合理的调度策略，安排模型执行prefill或是decode的顺序 (篇幅限制，具体调度细节这里不展开)。

2.2 单步调度 vs. 多步调度

在旧版vLLM中，每次调度器只会为下一次的模型推理安排优先顺序，即每次调度对应一次模型推理。该方法被称为单步推理；

0.6.0引入多步推理，每次调度器调度会安排接下来的多次模型推理，即每次调度对应n次推理。多步推理可以减少调度次数，降低CPU开销，从而让模型推理充分利用GPU资源，尽量保持运行。

上：一次调度后执行1步推理；

下：一次调度后执行3步推理。

据vLLM团队测试，4张H100环境下运行Llama 70B，多步推理的吞吐量比单步推理提升了28%[3]。

2.3 测试&对比

利用上述基准测试，对比单步调度与多步调度的性能差异。这次我们统一使用0.6.0版本。在保持其他设置相同的情况下，设置服务端启动参数分别如下。而客户端方面设置与上文相同，在此不再赘述。

#单步/多步调度

vllm serve facebook/opt-125m \

--max-model-len 2048 \

--use-v2-block-manager \

--disable-async-output-proc \ #关闭异步输出处理

--num-scheduler-steps 1/10 #每次调度1步/10步

以下为测试结果 (左单步调度，右多步调度step=10)：

多步调度(step=10)的情况下，基准测试仅耗时7.69秒；而单步调度耗时21.68秒，整体速度上快近3倍。（由于opt-125m模型的参数量较小，计算瓶颈主要位于CPU端，因此对CPU端的优化效果极其显著；对于更大规模的模型，瓶颈位于GPU端，加速效果相对没有这么明显。）

使用NVIDIA Nsight systems [5]进一步分析profile (NVTX中绿色块表明执行调度)。多步调度中每个绿色块之间有10组CPU epoll_pwait和read，即执行10次GPU上的模型推理，并读取结果；而单步推理中每个绿色块之间仅有1组epoll_pwait和read，即1次模型推理。