文章核心观点 - vLLM是一套针对大语言模型推理优化的高性能开源推理框架，通过创新的显存管理、并行调度和KV缓存技术，在保持模型准确性的同时大幅提升吞吐量与响应速度[1] - 该博客文章对vLLM的架构、代码和原理进行了深入分析，涵盖了从基础推理流程到高级功能、扩展能力和分布式系统部署的完整技术栈[3][4][6] - 文章采用倒金字塔结构写作方式，从宏观层面入手逐步深入细节，帮助读者建立对整个系统的清晰整体认知而不被繁琐技术细节淹没[6] LLM引擎核心架构 - LLM引擎是vLLM的核心构建模块，单独使用时能够实现高吞吐量推理但仅限于离线场景[7][8] - 引擎构造函数包含多个子组件：vLLM配置、处理器、引擎核心客户端、输出处理器、模型执行器、结构化输出管理器和调度器[14][15] - 调度器内部包含策略设置、等待队列与运行队列以及KV缓存管理器，其中KV缓存管理器维护一个可用KV缓存块的池子，数量可达几十万甚至更多[16] - 模型执行器在构造过程中会创建Worker对象并执行三个关键步骤：初始化设备、加载模型和初始化KV缓存[19][20][21] 推理流程与调度机制 - Generate函数处理每个提示词时创建唯一请求ID并记录到达时间，通过输入预处理器进行分词后打包成EngineCoreRequest传递到引擎核心[24][25][29] - 每个推理步骤包含三个阶段：调度阶段选择本步骤要执行的请求，前向传播阶段运行模型并采样新token，后处理阶段进行去分词和停止条件检查[32][33][34][35] - 推理引擎主要处理两类工作负载：Prefill请求对所有提示token执行一次前向传播通常是计算受限的，Decode请求仅对最新生成的一个token执行前向传播是内存带宽受限的[38] - V1调度器可以在同一个step中混合处理prefill与decode请求，优先处理decode请求，调度器会计算需要生成的新token数并调用KV-cache管理器的allocate_slots函数[39][40][41][42] 高级功能特性 - 分块预填充将预填充步骤拆分为更小块执行，避免长提示词请求独占计算资源，通过设置long_prefill_token_threshold正整数启用[57] - 前缀缓存避免重复计算多个提示词开头部分共享的token，当提示词长度超过一个KV-cache块（默认16个token）时可显著加快预填充请求速度[62][70][73] - 引导式解码在每一步解码时通过基于语法的有限状态机对logits进行约束，确保只有符合语法规则的token被采样，支持正规文法和上下文无关文法[93][94][97] - 推测解码通过引入较小草稿模型快速生成k个候选token，然后使用大模型进行验证，在统计上等价于标准自回归解码但潜在更快[106][107][112] 系统扩展与分布式部署 - 从UniProcExecutor扩展到MultiProcExecutor支持多GPU进程，通过张量并行将模型分片到同一节点多张GPU上，节点内带宽显著高于节点间带宽[141][143][149] - 分布式系统部署示例使用两台8×H100节点，一台以headless模式运行引擎，另一台作为API服务器，通过数据并行在多个节点上复制模型[153][156] - API服务节点实例化AsyncLLM对象创建DPLBAsyncMPClient，通过FastAPI应用暴露OpenAI兼容接口，整个堆栈通过Uvicorn对外提供服务[172][175] - 完整请求生命周期从终端发送请求到API服务器，经过负载均衡选择引擎，执行推理步骤后将结果返回，复杂分布式系统对用户透明[177][183] 性能测量与基准测试 - 推理系统性能有两个互相制约的指标：延迟从请求提交到返回token的时间对交互式应用重要，吞吐量系统每秒能够生成或处理的token/请求数量对离线工作负载关键[185][186][189] - 常见推理性能指标包括TTFT从请求提交到接收第一个输出token的时间，ITL两个连续token之间的时间，TPOT请求中所有输出token的平均ITL，以及端到端延迟[190] - vLLM提供CLI工具vllm bench {serve,latency,throughput}进行基准测试，latency脚本使用短输入并生成128个输出token，throughput脚本一次性提交固定prompt集测量吞吐量[196][197] - 延迟和吞吐量存在竞争关系，当批大小B较小时每个token的间隔延迟下降，当B增大时间隔延迟上升但吞吐量提高直到达到峰值性能[192][193]

软件编程与人工智能建模的范式转变 - 传统软件编程依赖明确的指令代码，适合确定性场景但缺乏动态适应能力[2] - AI软件建模通过数据训练学习模式，使用概率推理处理不确定性，模型复杂度体现在参数规模而非代码量[3] - 高级AI模型如LLM包含数千亿至数万亿参数，依赖多维矩阵数学运算，每个时钟周期并行处理所有参数[3] 处理硬件的影响 - CPU采用串行执行架构，多核多线程提升并行性但仍无法满足AI模型的并行需求[4] - 高端CPU计算能力达几GigaFLOPS，内存带宽峰值500GB/s，内存容量达TB级[5] - GPU提供PetaFLOPS级性能，比CPU高两个数量级，但运行GPT-4时效率可能降至理论峰值的5%[6] - GPU高功耗引发可持续性问题，专用AI加速器（如ASIC）在计算效率和能耗上更具优势[7] AI加速器的关键属性与挑战 - 关键指标包括批处理大小和token吞吐量，需平衡延迟与吞吐量需求[8] - 大批量提升吞吐量但增加内存带宽压力，实时应用（如自动驾驶）需批量大小为1以最小化延迟[12] - 连续批处理技术动态添加输入，减少延迟并提升整体效率[13] - Token吞吐量依赖计算效率和数据移动优化，需首次token输出时间最短[14][15] 内存与计算瓶颈 - 内存带宽是主要瓶颈，大批量导致缓存未命中及访问延迟增加[9][19] - 高带宽内存（HBM3）和智能片上缓存可缓解内存瓶颈[21] - LLM依赖并行矩阵运算和注意力机制，计算瓶颈需专用硬件（如矩阵乘法单元）和混合精度计算（FP8）解决[19][22] 优化方向 - 硬件创新包括类似寄存器的缓存结构、专用加速器设计及高效数据流架构[21][22] - 软件优化涵盖定制化内核、梯度检查点减少内存占用、管道并行提升吞吐量[23] - 混合精度计算在保持模型精度前提下降低内存带宽需求和计算开销[22] 行业技术趋势 - Transformer架构需每个token关注全部历史token，增量Transformer按序计算token提升流式推理效率但增加内存需求[16] - 不规则token模式和自回归模型依赖可能导致硬件管道停滞，需优化调度策略[17] - AI加速器仍处早期阶段，需结合内存架构创新与数据流优化以突破性能限制[18][20][24]