# vLLM 推理原理（一）：从一条 HTTP 请求，到第一个输出 token
> **摘要：** 一次大模型请求从进入接口到返回文字，背后经历了哪些步骤？本文沿着 vLLM 的请求链路，串起分词、Prefill、Decode、KV Cache、模型前向与流式输出，说明 API Server、调度器和 GPU Worker 如何分工，并解释首 token 延迟、输出间隔与吞吐的区别，为理解推理服务建立完整的执行视图。

![vLLM 推理原理（一）封面：一次请求如何变成输出]![cover-01.png](https://developer.qcloudimg.com/http-save/yehe-12628201/57d0adc1d8ec275c9307c443b151af00.png)
调用过大模型接口的开发者，大概都熟悉这样的过程：提交一组 messages，等待片刻，答案开始逐字出现。

如果把接口地址换成自己部署的 vLLM，表面上仍然是一次 HTTP 请求。但服务端要完成的工作，远不止“把字符串交给模型”：它需要处理输入、维护请求状态、组织 GPU 计算、保存中间结果，再把生成结果持续送回来。

这组文章沿着一条主线展开：**vLLM 如何把模型的一次次前向计算，组织成能同时服务许多用户的推理系统？**

本篇先讲单个请求的完整路径；第二篇讲调度与显存管理；第三篇讲 GPU 执行优化、多卡协作以及性能排查。

> 版本与范围：实现说明以 [vLLM v0.32.0](https://github.com/vllm-project/vllm/releases/tag/v0.32.0) 的 V1 引擎为参照，资料核对日期为 2026-10-22。主线采用常见的 decoder-only 文本生成模型，先不启用推测解码。图中 token、时间轴和内存块均为机制示意，不是性能实测。

## 1. vLLM 在系统里处于什么位置？

先区分三件东西：

- **模型**：网络结构、训练好的权重，以及配套的 tokenizer 等文件。
- **推理计算**：给定输入张量，执行网络的前向计算，得到后续 token 的分数。
- **推理服务**：管理许多请求，让计算资源持续工作，并把结果可靠地送回调用者。

vLLM 同时参与后两部分：既提供面向服务的请求管理，也有适合推理的模型执行实现、算子集成和分布式执行能力。它会加载已训练的权重，通常不在处理生成请求时训练这些权重。

![图 1：应用、vLLM 与 GPU 的职责分工] ![01-system-stack.png](https://developer.qcloudimg.com/http-save/yehe-12628201/fa040a38464765785fc105d25968736d.png)

*图 1：应用决定要完成什么业务任务；vLLM 管理生成请求及执行资源；模型权重决定前向计算的内容。*

对应用开发者，可以类比数据库：一条 SQL 能描述计算需求，但服务端仍需要处理连接、排队、内存与执行。类比的边界在于，LLM 生成具有逐 token 的依赖关系，单个请求的结束时间也难以事先准确知道。

## 2. 第一步：messages 需要变成模型认识的数字

模型并不直接接收 JSON 中的 `role`、`content` 字段。对于常见聊天模型，输入处理通常包括：

1. 按模型的聊天模板，把不同角色的消息组织成带有特殊标记的序列。
2. 通过 tokenizer，把序列编码为 token IDs。
3. 准备采样参数、停止条件和请求标识等元数据。

一个 token 可能对应一个词、词的一部分、一个标点，或某种字节片段。中文“逐字出现”的视觉效果，不代表模型内部一次恰好生成一个汉字。

聊天模板同样属于模型输入的一部分。把角色标记、换行或者历史消息组织方式改掉，即使业务文本看起来差不多，模型实际看到的 token 序列也可能不同。

完成输入处理后，请求会进入引擎。此时它带着的核心信息，可以理解为：

```text
request_id
prompt_token_ids
sampling_params
已计算到的位置 / 已生成的 token / 停止状态
```

这只是帮助理解的结构，并非完整 API 定义。在线服务中的输入处理与结果回传职责，可对照官方的 [Architecture Overview](https://docs.vllm.ai/en/v0.32.0/design/arch_overview/#api-server-process)。

## 3. Prefill：同时处理提示词，但不同时生成整段答案

假设 tokenizer 把输入变成了三个 token：`p1、p2、p3`。

模型首先处理这段已知的提示词，这一阶段通常称为 **prefill**。由于提示词的所有 token 已经给定，可以将多个位置组织进同一次前向计算。

在因果注意力中，位置 3 可以关注位置 1、2、3，位置 1 不能关注后面的 2、3。这个限制通过因果掩码及对应算子实现，不需要把三个位置完全拆成三个串行的模型调用。

提示词处理完成后，最后一个位置的输出被映射到词表上的分数，也就是 logits。采样过程根据这些分数选择第一个生成 token，记作 `y1`。

![图 2：prefill 与后续 decode 的输入输出关系]![02-prefill-decode.png](https://developer.qcloudimg.com/http-save/yehe-12628201/98c0f3b42ec78a23a12c741eaa5f0ae5.png)

*图 2：每一行表示一次逻辑前向；实际引擎可以将多个请求一起执行，也可以把很长的 prefill 拆成多轮。*

这里有两个容易误解的细节。

首先，prefill 能并行处理已知提示词，并不意味着能一次预测出所有未来答案。正常自回归生成中，`y2` 依赖 `y1`，而 `y1` 在采样前还不知道。

其次，prefill 得到 `y1` 时，通常已经缓存的是提示词各位置的 K、V。`y1` 自己的 K、V，要在下一轮将 `y1` 输入模型时才产生。**采样得到一个 token，与计算这个 token 的中间表示，是相邻但不同的步骤。**

## 4. Decode：每次前进一点，复用已经算过的历史

下一轮，将 `y1` 输入模型，得到 `y2`；再把 `y2` 输入，得到 `y3`。

如果每一步都把 `p1、p2、p3、y1……` 整段重新跑一遍，会产生大量重复计算。这里需要引入 **KV Cache**。

在 Attention 中，输入表示会被投影为 Q、K、V。只展开一个注意力头，可以用下面的形式理解：

```text
Q = XWq
K = XWk
V = XWv

Attention(Q, K, V) = softmax(QKᵀ / √d + mask) V
```

对于当前 decode 位置，Q 表示“这一步要查询什么”；历史 K 用来计算匹配权重；历史 V 则参与加权汇总。这个比喻只帮助理解数据流，实际内容都是学习得到的向量。

![图 3：当前查询与历史 KV 的关系] ![03-kv-attention.png](https://developer.qcloudimg.com/http-save/yehe-12628201/b576241bf02c1e6f9cab940e1591ee3e.png)

*图 3：真实模型有多层、多头，还包括位置编码、归一化和残差连接。图中仅展开单层中的一条 Attention 数据流。*

历史位置不会因为右侧又追加一个 token，就需要重新生成所有历史 K、V。因此，可以把各层的历史 K、V 缓存起来，只计算本轮新位置的相关表示。这也是 [Hugging Face 的缓存说明](https://huggingface.co/docs/transformers/main/en/cache_explanation) 所解释的基本原理。

但缓存并没有消除历史上下文的成本：当前 query 仍然需要读取适用的历史 K、V，并完成注意力计算。上下文越长，这部分工作通常越多。

KV Cache 也不是之前某次提问的答案缓存，更不是模型参数。它是**特定输入序列在模型各层计算出的中间状态**，后续如何分配、复用和释放它，是推理引擎的核心职责之一。

## 5. 一次模型前向，还会做哪些计算？

Attention 是理解缓存的关键，但一次前向并不只有 Attention。

以常见的 Llama 类结构为例，token ID 先通过 embedding 变成向量，再经过多层网络。每层包含归一化、QKV 投影、位置编码、Attention、输出投影、MLP 与残差连接等步骤，最后通过输出头产生词表 logits。不同模型可能采用不同的位置编码、激活函数、专家层和缓存结构。

这里的很多工作最终是矩阵乘法、向量运算和数据搬运。vLLM 的模型实现会把这些操作连接到适合推理的执行路径。例如 [v0.32.0 的 Llama 实现](https://github.com/vllm-project/vllm/blob/v0.32.0/vllm/model_executor/models/llama.py) 使用了并行线性层和独立的 Attention 接口，方便结合分片权重与不同 Attention 后端。

所以，vLLM 的价值既包括“安排谁先算”，也包括“把已经选定的计算高效地执行出来”。第三篇会展开这一层。

## 6. 调度器、执行器、GPU Worker 各管什么？

现在沿着一次请求，走过实际的软件组件。

![图 4：V1 在线服务的主要进程职责] ![04-process-architecture.png](https://developer.qcloudimg.com/http-save/yehe-12628201/7a97b77588b9565e5a31c43cc269334e.png)

*图 4：以一份模型采用 TP=2 为例，两张 GPU 协作执行同一份模型。图中省略部分管理与通信细节。*

按照 V1 的主要职责，可以理解为三段：

| 组件 | 主要职责 | 本轮要解决的问题 |
| --- | --- | --- |
| API Server | 接收请求、输入处理、输出处理 | 用户发来了什么，结果怎样交付？ |
| Engine Core | 请求状态、调度、KV 管理、协调执行 | 这一轮处理哪些 token，缓存够不够？ |
| GPU Worker / Model Runner | 准备设备输入、模型前向、采样相关执行 | 如何把执行计划落实为张量计算？ |

在这个多进程架构中，API 与引擎核心通过消息通信解耦；GPU Worker 持有设备侧资源。这有助于避免把 HTTP、分词与 GPU 执行的全部职责挤进同一条应用调用路径。具体职责见 [V1 Process Architecture](https://docs.vllm.ai/en/v0.32.0/design/arch_overview/#v1-process-architecture)。

下面是逻辑循环的简化示意：

```python
# 教学伪代码，不是可直接运行的 vLLM API。
while engine_has_work():
    receive_new_requests_and_cancellations()
    plan = scheduler.schedule()       # 请求、待计算 token、KV 分配等
    result = executor.execute(plan)  # 设备输入、模型前向、采样等
    outputs = scheduler.update(result)
    send_outputs_to_frontend(outputs)
```

可以对照 [EngineCore.step()](https://github.com/vllm-project/vllm/blob/v0.32.0/vllm/v1/engine/core.py#L657) 阅读：调度、执行、采样与状态更新在源码中有明确的连接。实际还存在异步执行及批次队列等路径，不能把上面的同步伪代码当作所有模式的精确时序。

## 7. 采样、停止与流式输出：最后一段也有工作要做

模型产出的是词表分数，服务还要决定最终选择哪个 token。

按请求设置，可能涉及温度缩放、top-k / top-p、重复惩罚，或者结构化输出的候选约束。具体步骤和支持范围依赖配置。选择最高分 token 的 greedy decoding 只是其中一种方式。

采样后，引擎更新序列状态并检查停止条件，例如结束 token、最大输出长度和请求取消。字符串停止规则还会涉及输出处理与增量文本判断。

生成 token ID 经过增量解码，才成为用户收到的文本。一个流式网络事件不一定恰好对应一个 token：分词边界、字符编码、停止规则与缓冲都可能影响输出片段。

请求结束后，其活跃执行资源需要回收；启用前缀缓存时，部分无活跃引用的 KV 块仍可能保留为可复用缓存。这个区别会在第二篇解释。

## 8. 为什么要区分首字慢、输出慢和整体吞吐？

把一条请求沿时间展开，可以看到不同性能问题落在不同阶段。

![图 5：TTFT 与 ITL 的含义] ![05-latency.png](https://developer.qcloudimg.com/http-save/yehe-12628201/4972e3694eaf2fd20b0222739693456d.png)

*图 5：客户端观测的 TTFT 还包含网络与输出处理；这里强调从请求到首 token，以及相邻 token 之间的不同时间段。*

- **TTFT（Time To First Token）**：等待第一个输出 token 的时间。排队、输入处理、prefill 和首次采样等都会参与。
- **ITL（Inter-Token Latency）**：相邻输出 token 的间隔，反映持续生成时的响应节奏。
- **吞吐**：单位时间完成的请求量或 token 量，需要说明统计的是输入还是输出、单请求还是整个服务。

这些指标不能相互替代。服务可以通过更大的批次提高总吞吐，同时让单个请求等得更久；一个很长的提示词，也可能带来较长 TTFT，但之后输出相当平稳。服务端指标的定义可进一步参照 [vLLM Metrics](https://docs.vllm.ai/en/v0.32.0/design/metrics/)。

测量时还要区分 token 与流式事件：本文所说的 ITL 是逐 token 的概念；参照版本中的 `inter_token_latency_seconds` 实际按连续输出事件的间隔记录，一个事件可能包含多个 token。若关注每个请求的平均输出 token 时间，可以同时查看 TPOT，避免把不同统计口径混为一谈。

现在，我们已经能把一次生成拆成：输入处理、等待调度、prefill、循环 decode、采样与输出。接下来真正的问题是：当一百条请求处于不同阶段、共享有限 GPU 显存时，vLLM 怎样安排它们？

下一篇：[vLLM 推理原理（二）：请求怎么排队，KV Cache 怎么住进显存？] (https://cloud.tencent.com/developer/article/2767041)

## 参考资料与源码入口

1. [vLLM v0.32.0 Release](https://github.com/vllm-project/vllm/releases/tag/v0.32.0)
2. [vLLM Architecture Overview](https://docs.vllm.ai/en/v0.32.0/design/arch_overview/)
3. [Hugging Face：How caching works](https://huggingface.co/docs/transformers/main/en/cache_explanation)
4. [v0.32.0：Engine Core](https://github.com/vllm-project/vllm/blob/v0.32.0/vllm/v1/engine/core.py)
5. [v0.32.0：GPU Model Runner](https://github.com/vllm-project/vllm/blob/v0.32.0/vllm/v1/worker/gpu_model_runner.py)
6. [v0.32.0：Llama 模型实现](https://github.com/vllm-project/vllm/blob/v0.32.0/vllm/model_executor/models/llama.py)
7. [vLLM Metrics](https://docs.vllm.ai/en/v0.32.0/design/metrics/)


摘要： 一次大模型请求从进入接口到返回文字，背后经历了哪些步骤？本文沿着 vLLM 的请求链路，串起分词、Prefill、Decode、KV Cache、模型前向与流式输出，说明 API Server、调度器和 GPU Worker 如何分工，并解释首 token 延迟、输出间隔与吞吐的区别，为理解推理服务建立完整的执行视图。

vLLM 推理原理（一）：从一条 HTTP 请求，到第一个输出 token

一次大模型请求从进入接口到返回文字，背后经历了哪些步骤？本文沿着 vLLM 的请求链路，串起分词、Prefill、Decode、KV Cache、模型前向与流式输出，说明 API Server、调度器和 GPU Worker 如何分工，并解释首 token 延迟、输出间隔与吞吐的区别，为理解推理服务建立完整的执行视图。

云平台负责人

人工智能

后端

架构设计

vLLM推理原理解析：从HTTP请求到首个token的完整路径，涵盖输入处理、Prefill与Decode阶段、KVCache机制、调度器与GPU Worker协作，并区分TTFT、ITL及吞吐等关键性能指标，揭示vLLM如何高效组织多请求推理服务。

代码解释

数据库

数据流

Python

JSON

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

vLLM 推理原理（一）：从一条 HTTP 请求，到第一个输出 token-腾讯云开发者社区-腾讯云

vLLM 推理原理（一）：从一条 HTTP 请求，到第一个输出 token

vLLM 推理原理（一）：从一条 HTTP 请求，到第一个输出 token

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐