Neural Magic专家深度解析vLLM性能提升2.7倍的秘籍

vLLM 0.6.0性能优化深度解析：Neural Magic专家揭秘2.7倍加速秘诀

Neural Magic的工程负责人Rob，加入公司已有两年，深度参与vLLM社区并成为其上游核心贡献者。今天分享的主题聚焦于近期备受关注的vLLM 0.6.0版本发布，该版本在H100 GPU上实现了显著的性能飞跃。

该版本在H100 GPU上运行Llama 8B和70B模型时，速度得到了大幅提升。为了让读者深入了解这些性能提升背后的技术原理，下面我们将详细剖析所采用的关键优化细节。

今天的分享将涵盖以下几个方面：

1. 语言模型推理的基本原理：为何这是一项极具挑战性的任务；

2. vLLM的内部架构：如何支持核心优化技术——连续批处理（Continuous Batching）；

3. 性能瓶颈诊断与优化：在vLLM 0.6.0版本之前的架构中存在哪些问题，以及过去几个月中通过哪些关键优化手段得以解决；

4. 未来规划：继续提升性能的待完成项目与路线图。

值得注意的是，本次分享的重点在于降低vLLM调度器层面的开销，而非讨论GPU执行性能。如果您对GPU执行优化感兴趣，可以参考Tyler上周关于Cutlass的精彩演讲。

LM推理的基本原理

大语言模型（LM）的核心功能是预测序列中的下一个Token。具体而言，它根据输入序列的前N-1个Token，计算出第N个Token的概率分布。基于这一原理，LM通过逐个生成Token来完成文本生成任务。举例来说：输入包含3个Token，模型生成第4个Token；接着使用前4个Token生成第5个Token，以此类推。

这种逐次生成的方式意味着，要生成1000个Token，需要通过模型进行1000次推断，每次生成可能耗时数秒。用户在交互过程中会明显感受到这一延迟，这给推理服务器带来了设计挑战：如何高效处理多个并发请求，同时保证低延迟？

连续批处理的原理

传统的推理服务器通常采用动态批处理，通过将多个请求合并为一个批次执行来提升GPU利用率。但这种方法在处理LM推理时效果不佳，因为每个请求可能需要多次模型推断。例如：如果一个请求需要生成1000个Token，而其他请求只需生成1个Token，那么批次中的所有请求都必须等待最长请求完成，导致GPU利用率低下且延迟增加。

为解决这一问题，vLLM引入了连续批处理策略。核心思路是：按迭代级别而非请求级别进行批处理；当某个请求完成一部分计算后，立即将其从批次中移除，并引入新请求。这种方法显著提高了GPU利用率，同时降低了用户感知的端到端延迟。

vLLM的内部架构

为了支撑连续批处理，vLLM架构中设计了一个核心组件：LLM引擎。该引擎在一个主循环中运行，主要包含以下三个步骤：

1.调度：决定哪些任务需要执行，分配内存并管理KV缓存。

2.执行：将调度好的任务传递给GPU工作线程。vLLM原生支持Tensor并行，可以将模型拆分并分布到多个GPU上。

3.处理输出：包括将结果流式传递到API服务器、检查结束标志以及移除已完成的任务。

这套架构在CPU端完成了大部分内存管理与状态跟踪工作，从而实现了高效的连续批处理。

挑战与未来

虽然vLLM已经在减少调度开销方面取得了长足进步，但面对H100等新一代GPU的超高性能，仍需优化系统的其他部分，例如内存管理和通信开销，以充分发挥硬件潜力。通过这些改进，vLLM可以为语言模型推理提供更强大的支持，并继续作为AI生态系统的核心平台。

在大语言模型（LLM）的解码阶段，性能主要受限于将权重从GPU内存传输到芯片内存的速度。以H100 GPU为例，其内存带宽高达3.35 TB/s。一个16GB的模型（约8亿参数），从GPU内存传输到芯片内存所需的时间约为5毫秒。GPU内部执行速度极快，每次迭代仅需5到7毫秒。

然而，随着批处理规模从1增加到256，由于内存带宽的限制，执行时间的增长非常有限。例如，批大小为1时，解码100个token的延迟约为0.8秒；而批大小为64时，延迟略低于1秒。这表明GPU执行时间几乎保持不变，而输入准备、调度和输出处理（主要在CPU上完成）会随着批处理规模线性增长。

CPU的处理包括调度操作和输出处理，这些运行在单一的Python进程中，受制于全局解释器锁（GIL），阻止了任何实际的并发执行。这种架构严重限制了系统的吞吐量。

性能瓶颈分析与优化方案

在一个实际运行LLM的48秒任务中，仅有25秒用于模型执行，剩余时间大多花在输入准备、调度和输出处理上。而API服务器引入的额外30%的开销，使GPU操作的占比降至38%。因此，提升CPU部分性能成为关键突破口。

优化一：解耦API服务器与LLM引擎

通过与Neural Magic和IBM的深度合作，vLLM将API服务器与LLM引擎拆分为两个独立的进程。Python的GIL限制了多线程的并发能力，因此这种解耦可以有效避免两部分争夺CPU资源。同时引入ZeroMQ作为消息传递协议，经过对多种协议的评估，ZeroMQ表现出优异的性能和开发便利性。该优化带来了25%的吞吐量提升，未来计划在更多核心环节中采用ZeroMQ。

优化二：异步输出处理

CUDA的异步特性使得GPU计算和主机代码可以并行执行。通过调整LLM引擎的工作方式，使输出处理与GPU前向传播并行，而非同步等待。这一改动消除了数据依赖性，实现了7.5%的吞吐量提升。

优化三：多步调度

传统的逐步调度需要每次迭代都进行内存分配和调度操作。而多步调度将多次调度合并为一次，大幅减少了CPU工作量。此方法有效降低了输入准备的频率和函数调用次数，实现了70%的吞吐量提升。

成果与展望

通过上述优化，LLM引擎在CPU侧的开销大幅减少。例如，运行Llama-70B模型时，虽然GPU执行速度受限于较慢的显存带宽，吞吐量依然提升了近2倍；而在执行速度较快的Llama-38B模型上，整体速度提升达到了2.7倍。

这一成果得益于Neural Magic、IBM、Databricks、AnyScale和伯克利大学的紧密合作。未来将继续优化现有技术：

1.引入ZeroMQ至核心循环：目前LLM引擎内部使用asyncio管理并发，但其任务切换存在显著开销。通过ZeroMQ替代asyncio，进一步减少切换开销，可实现更高的吞吐量。

2.异步流式生成：多步调度的一个问题是每生成一个新token的延迟较高。通过ZeroMQ实现异步流式生成，成功降低了token间延迟，同时对整体输出时间几乎没有影响。

3.兼容更多优化策略：正在扩展多步调度的适用范围，例如结合预填充和解码批处理的Chunk Prefill技术，以进一步平滑token生成延迟。

通过这些改进，我们希望持续推动LLM解码阶段的性能边界，为用户提供更高效、更流畅的模型推理体验。

在以下场景中，假设有一个长度为8000的提示（prompt）。将其分成2000长度的块，然后在vLLM内部使用解码操作重叠这些块。通过块预填充（chunk prefill），能够实现更平滑的每个输出token的生成时间，避免因处理新的预填充数据并将其引入BLM而导致的长时间停顿。

启用块预填充后（目前已经有一个草案PR），可以显著减少每个输出token所需的时间。这项改进预计将在6.2版本中上线，目前仍在积极开发中。我们的目标是持续提升性能，提供更优的推理体验。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：Neural Magic专家深度解析vLLM性能提升2.7倍的秘籍要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题