vLLM推理框架详解：吞吐优化核心原理与面试攻略

引言：为什么大模型推理优化是面试高频题

在大模型工程化落地的过程中，推理吞吐（Throughput）优化几乎是绕不开的核心话题，也是算法工程师面试中被反复追问的经典问题。要真正回答好这个问题，我们需要理清三件事：什么是吞吐？大模型推理的本质是什么？以及如何对推理过程进行优化。

本文从最基础的概念出发，逐层拆解 vLLM 这一主流推理框架的核心原理，帮助零基础读者建立完整的知识框架。

延伸背景：vLLM 的诞生背景 vLLM 由加州大学伯克利分校 Sky Computing Lab 于 2023 年开源发布，论文《Efficient Memory Management for Large Language Model Serving with PagedAttention》发表于 SOSP 2023。在发布基准测试中，vLLM 相比 HuggingFace Transformers 原生推理实现了高达 24 倍的吞吐提升，相比当时已有优化的 FasterTransformer 也有 3.5 倍以上的提升，迅速成为工业界部署大模型推理服务的首选框架。其核心贡献 PagedAttention 已被 TensorRT-LLM、LMDeploy、SGLang 等主流推理框架广泛借鉴和实现。

值得补充的是，vLLM 的开源恰逢大模型推理服务规模化部署的关键节点——彼时 ChatGPT 引爆市场，各大云厂商和创业公司都面临如何以有限 GPU 资源服务海量并发请求的工程挑战。vLLM 通过将操作系统内存管理的经典思想迁移到 GPU 显存管理，提供了一个优雅且高效的解决方案，迅速获得工业界认可。

这边有同学说QPS请求处理能力吗

一、理解吞吐：为什么用 tokens/s 而不是 QPS

吞吐（Throughput）指的是在单位时间内系统能够处理完成的请求数量。有同学将其理解为「QPS 请求处理能力」，这个方向是对的——吞吐衡量的正是系统的请求处理速率。

但对于大语言模型（LLM）推理而言，吞吐的衡量单位需要更精细。我们通常不以「请求数」为单位，而是以 token 数 为单位——即「单位时间内能处理多少个 token」。原因很简单：不同请求的输入输出长度差异悬殊，用 token 作为统一计量单位，才能更精确地反映系统的真实处理能力。

这个细节非常关键：「tokens/s」才是评估 LLM 推理框架性能的核心指标，而非简单的请求条数。

延伸背景：Token 计量的工程意义 在实际工程中，token 计量不仅用于衡量吞吐，也直接影响推理服务的计费模型和资源规划。主流大模型 API 服务（如 OpenAI、Anthropic）均以 token 数为计费单位，因为它能更公平地反映实际计算消耗。此外，tokens/s 指标还细分为两个子维度：**首 token 延迟（Time to First Token, TTFT）**衡量用户等待第一个输出的响应时间，与用户体验直接相关；**生成速率（Generation Throughput）**衡量后续 token 的输出速度，决定整体推理流畅度。在面试中能主动区分这两个子维度，往往会给面试官留下深刻印象。

此外，不同模型的分词器效率差异也会影响实际吞吐感知——同样的自然语言文本，GPT-4o 的 tiktoken 与 LLaMA 的 SentencePiece 分词结果可能相差 10%～20%，在跨模型性能对比时需注意归一化处理。

老师本人从事算法十多年

二、大模型推理的本质：自回归生成

逐 token 预测的生成过程

要优化推理，首先必须搞清楚大模型推理到底在做什么。大模型的本质，是在不断预测下一个 token（词元）。

Token（词元）是大模型处理文本的基本单位，由分词器（Tokenizer）将原始文本切分而成。常见的分词算法包括 BPE（Byte Pair Encoding）、WordPiece 和 SentencePiece 等。以 GPT 系列模型使用的 BPE 为例，英文单词"running"可能被切分为"run"和"ning"两个 token，而中文则通常以字或字组为单位切分。一般来说，1000 个英文 token 约对应 750 个英文单词。这种粒度设计在词汇表大小与表达能力之间取得平衡——词汇表通常在 32,000 到 100,000 个 token 之间，既能覆盖大多数语言现象，又不会使模型参数规模失控。理解 token 的粒度，也有助于工程师在实际部署中估算显存需求和吞吐上限。

以一个经典例子说明整个生成过程，假设初始输入是「the dog」：

第一步（time step 1）：将「the dog」输入模型，模型预测出下一个词，比如「sat」；
第二步（time step 2）：将输出拼接回输入，新输入变为「the dog sat」，模型继续预测，得到「down」；
第三步（time step 3）：输入进一步变为「the dog sat down」，模型输出特殊标识符 EOS（End of Sentence）。

当模型输出 EOS 时，生成结束。最终输出为「the dog sat down」，EOS 本身不打印。

延伸背景：自回归生成的数学本质 自回归生成从概率论角度可以表述为：模型对文本序列的联合概率进行链式分解，即 P(x₁, x₂, ..., xₙ) = ∏P(xᵢ | x₁, ..., xᵢ₋₁)。每一步生成都是在给定历史上下文的条件下，从词汇表上的概率分布中采样（或取 argmax）得到下一个 token。这一数学结构决定了生成过程天然是串行的——第 i 步的输出必须等待第 i-1 步完成，无法在 Decode 阶段实现跨步并行。这与 Prefill 阶段形成鲜明对比：Prefill 处理用户输入时，所有输入 token 的位置已知，可以完全并行计算注意力矩阵，是计算密集型操作。

大模型逐时刻生成token的过程

自回归带来的性能瓶颈

这种「每一步都基于前面所有内容预测下一个 token」的机制，称为自回归（Auto-regressive）生成。它与 Transformer 的解码器（Decoder）架构密切相关：在每个生成步骤中，模型需要通过注意力机制（Attention Mechanism）计算当前 token 与序列中所有历史 token 之间的相关性权重，这一计算的时间复杂度为 O(n²)，其中 n 为序列长度。

延伸背景：为什么注意力计算是 O(n²)？ 在标准的 Scaled Dot-Product Attention 中，设序列长度为 n、隐藏维度为 d，则 Query 矩阵 Q（形状 n×d）与 Key 矩阵 K（形状 n×d）做矩阵乘法，得到 n×n 的注意力分数矩阵，这一步的计算量为 O(n²·d)。随着序列长度 n 增大，计算量以平方速度增长。正因如此，业界在探索更高效的注意力变体，如 FlashAttention（通过 IO 感知的分块计算大幅降低显存带宽消耗）、线性注意力（将复杂度降至 O(n)）等。但在当前主流大模型部署中，标准 Multi-Head Attention 仍是主体，O(n²) 瓶颈依然真实存在。

延伸背景：Prefill 与 Decode 两阶段的硬件特性差异 自回归推理实际上分为两个性质截然不同的阶段。Prefill 阶段处理用户输入的 prompt，所有输入 token 可以并行计算注意力，是计算密集型（Compute-bound）操作，GPU 的 CUDA Core 和 Tensor Core 得到充分利用，算力利用率可达 60%～80%。Decode 阶段则逐个生成输出 token，每步只有一个新 token 需要计算，但必须读取所有历史 token 的 KV Cache，是显存带宽密集型（Memory-bandwidth-bound）操作，GPU 算力严重闲置。这一本质差异催生了近年来「Prefill-Decode 分离部署」（PD 分离）架构——将两种工作负载调度到不同类型或配置的 GPU 集群，分别针对算力和带宽进行优化，是目前大规模推理集群的前沿实践方向。

这意味着随着生成序列不断增长，每步的计算量呈二次方增长，重复计算量呈线性乃至更高速度膨胀。每生成一个新 token，都需要重新处理前面已生成的全部序列。 这是大模型推理性能瓶颈的根源，也是 vLLM 等推理优化框架重点攻克的核心问题。

EOS是一个特殊的标志位

三、vLLM 如何优化推理吞吐：三大核心技术

理解了自回归推理的本质，优化方向也就清晰了。vLLM 主要通过以下三项关键技术实现高吞吐推理。

1. KV Cache：消除重复计算

最直接的优化思路是：把前面已经计算过的中间结果缓存起来，避免每步都从头计算。这就是 KV Cache（键值缓存）的核心思想。

KV Cache 的设计基于 Transformer 注意力机制的数学特性。在标准的 Multi-Head Attention 中，每个 token 会生成 Query（Q）、Key（K）、Value（V）三个向量。计算注意力时，当前 token 的 Q 需要与所有历史 token 的 K 做点积运算，再用得到的权重对所有历史 V 加权求和。关键在于：历史 token 的 K 和 V 向量在生成新 token 时并不会改变，因此可以安全地缓存起来复用。KV Cache 正是将这些已计算的 K、V 矩阵存储在 GPU 显存中，使得每个新 token 生成时只需计算自身的 Q、K、V，而非重新计算全部历史序列，将单步计算复杂度从 O(n²) 降低到 O(n)。

延伸背景：KV Cache 的显存消耗量化分析 KV Cache 的显存占用可以精确估算。对于拥有 L 层、隐藏维度为 d 的模型，每个 token 的 KV Cache 大小约为 2 × L × d × sizeof(dtype) 字节（2 表示 K 和 V 两个矩阵）。以 LLaMA-2-7B 为例（32 层，d=4096，FP16 精度），每个 token 约占 512KB。若系统需支持 100 个并发请求、每请求平均 2048 token，则 KV Cache 总量约为 100GB，接近 A100-80G 的显存上限。这一估算揭示了一个核心矛盾：模型参数本身（7B × 2 bytes ≈ 14GB）只占显存的一小部分，KV Cache 才是大并发场景下显存的主要消耗者，这正是 PagedAttention 着力解决显存利用率问题的根本动因。

然而，KV Cache 也带来了新的挑战——随着序列长度增加，KV Cache 占用的显存也线性增长，对于长上下文场景（如 128K token 的上下文窗口），显存持续增长与碎片化问题，正是后续技术要进一步解决的难题。

2. 连续批处理（Continuous Batching）：最大化 GPU 利用率

批处理是提升吞吐的经典手段，即同时处理多个请求以充分发挥 GPU 并行计算能力。但传统的静态批处理（Static Batching）将一组请求打包成固定批次，等所有请求均完成后才处理下一批，存在明显的效率短板：不同请求的生成长度各异，可能相差数十倍——有的请求只需输出 20 个 token，有的需要输出 2000 个。短请求完成后必须等待同批次中最长的请求结束，导致大量 GPU 资源空转浪费。

延伸背景：GPU 利用率与推理效率的关系 传统静态批处理的低效根源在于「木桶效应」：批次吞吐由最慢的请求决定。若一个批次中有一个需要生成 2000 个 token 的长请求，即便其他 31 个请求在 100 步内就已完成，整个批次也必须等待 2000 步才能释放，导致 GPU 后 1900 步只在处理 1/32 的工作量。NVIDIA A100 的理论 FP16 峰值算力约为 312 TFLOPS，但在朴素的 LLM 推理场景下，GPU 利用率常常不足 30%。连续批处理通过「迭代级调度」彻底打破这一限制：每一次前向传播（forward pass）结束后，调度器立即检查完成的请求并补入新请求，将批次填充度始终维持在接近上限的水平。实测数据显示，在高并发场景下，连续批处理相比静态批处理可将 GPU 利用率从 30%～40% 提升至 70%～85%，是提升吞吐最直接有效的调度策略之一。

vLLM 采用的连续批处理机制（也称 Iteration-level Batching）将调度粒度细化到每个生成步骤：每完成一步迭代，调度器就检查哪些请求已结束（输出 EOS），立即将其从批次中移除，并补入等待队列中的新请求。这种「即完即补」的机制使 GPU 始终处于高利用率状态，从而显著提升整体吞吐。

3. PagedAttention：显存管理的革新

vLLM 最具代表性的技术创新是 PagedAttention。它借鉴操作系统「虚拟内存分页」的设计理念——在操作系统中，物理内存被划分为固定大小的「页」（Page），进程的逻辑地址空间通过页表映射到物理页，使得内存可以非连续存储，从而大幅减少外部碎片。

PagedAttention 将同样的思路引入 KV Cache 管理：将每个请求的 KV Cache 划分为等大小的「块」（Block），每个块存储固定数量 token 的 K、V 向量，块与块之间无需在显存中连续存放。调度器维护一张块表（Block Table），记录每个请求的逻辑块到物理块的映射关系。不同请求的 KV Cache 可以灵活共享和复用物理显存块，避免了传统方案中因预分配最大序列长度而导致的大量显存浪费。

延伸背景：传统 KV Cache 管理的碎片化问题 在 PagedAttention 出现之前，主流推理框架通常在请求开始时就为其预分配能容纳最大输出长度的连续显存块。由于实际输出长度无法预知，系统往往按最坏情况（最大序列长度）预留显存，造成大量「内部碎片」——预留的空间从未被用到。同时，不同大小的请求被分配不同大小的连续内存块，随着请求不断创建和销毁，显存中会出现大量无法被新请求利用的「外部碎片」。vLLM 论文的测量数据显示，这两类碎片导致传统方案的实际 KV Cache 利用率仅有 20%～40%，其余显存均被浪费。

延伸背景：Copy-on-Write 与前缀共享的工程价值 PagedAttention 的物理块共享机制还衍生出两个重要的工程特性。其一是前缀缓存共享（Prefix Caching）：在 RAG 系统或带固定 System Prompt 的对话场景中，多个请求共享相同前缀对应的 KV Cache 物理块只需计算一次，后续请求可直接复用，在高重复前缀场景下可将 Prefill 计算量降低 30%～70%。其二是**写时复制（Copy-on-Write）**机制：Beam Search 或并行采样生成多个候选序列时，所有候选共享前缀物理块，仅在序列分叉后才各自分配新块，显存消耗从 O(beam_width × sequence_length) 降至接近 O(sequence_length)。这两个特性使 PagedAttention 在复杂推理场景中的实际收益远超简单的碎片消除，在 RAG（检索增强生成）和 Beam Search 等实际场景中均有重要的工程价值。

实测数据显示，PagedAttention 将 KV Cache 的内存利用率从不足 40% 提升至接近 100%，在相同硬件下可支持数倍于传统方案的并发请求数量，最终带来整体吞吐的显著跃升。

4. 智能调度：整合一切的指挥中枢

vLLM 架构中的智能调度模块负责协调请求接入、KV Cache 的分配与回收，以及批次的动态组织。正是这套调度机制，将 KV Cache、连续批处理、PagedAttention 有机整合，共同构成高吞吐推理的完整解决方案。

延伸背景：调度器的多目标权衡挑战 vLLM 的调度器需要在多个相互冲突的目标之间实时权衡。核心矛盾有三：一是吞吐与延迟的权衡——批次越大吞吐越高，但单请求排队等待时间也越长，影响 P99 延迟；二是显存利用率与 OOM 风险的权衡——激进地接入更多请求提升利用率，但一旦显存耗尽会触发代价高昂的抢占（Preemption）；三是公平性与效率的权衡——优先处理长请求避免 KV Cache 换出，但可能导致短请求长时间饥饿。当显存不足时，调度器执行抢占策略：将低优先级请求的 KV Cache 块换出到 CPU 内存（Swap）或直接丢弃并重新计算（Recompute），两种策略各有时延代价。这些权衡的最优解至今仍是学术界和工业界的活跃研究方向，Sarathi-Serve、Orca 等系统均提出了不同的调度改进方案，也是面试中展示系统思维深度的绝佳切入点。

总结：三步回答推理优化面试题

回到最初的面试场景，只要理清以下三个层次，答案便自然浮现：

吞吐是什么：单位时间处理的 token 数量（tokens/s），是衡量 LLM 推理系统处理能力的核心指标；进一步可细分为首 token 延迟（TTFT）和生成速率两个子维度；
推理本质是什么：自回归逐 token 生成，本质是对序列联合概率的链式分解，分为 Prefill（并行处理输入，计算密集）和 Decode（逐步生成，带宽密集）两个阶段，核心瓶颈在于序列增长带来的 O(n²) 重复计算开销；
如何优化：用 KV Cache 将单步计算复杂度从 O(n²) 降至 O(n) 以消除重复计算，用连续批处理与智能调度最大化 GPU 利用率（可从 30% 提升至 80% 以上），用 PagedAttention 解决显存碎片化问题、将 KV Cache 利用率提升至接近 100%，并支持前缀共享和写时复制等高级特性。

这三个环节层层递进，构成了理解现代大模型推理框架的完整逻辑链。掌握了这套思路，你不仅能从容应对面试，更能真正理解为何 vLLM 能成为大模型推理部署的主流选择。

核心要点

技术	解决的问题	核心机制	效果
KV Cache	自回归重复计算	缓存历史 K/V 向量	单步复杂度 O(n²)→O(n)
连续批处理	GPU 空转浪费	迭代级动态补入新请求	GPU 利用率从 ~30% 提升至 ~80%
PagedAttention	显存碎片化与浪费	非连续分块 + 块表映射	KV Cache 利用率从 ~40% 提升至接近 100%
智能调度	资源协调与抢占	动态优先级 + 显存换出/重计算	整合三项技术，最大化整体吞吐