1. 简介

在前面的学习中，我们主要使用 Transformers 完成模型推理：加载模型与分词器，组织输入，再通过 model.generate() 或 pipeline() 获得生成结果。这种方式能够让我们直接观察模型的调用过程，也方便测试不同模型、调整生成参数和验证任务效果。

但是，能够完成一次推理，并不等于已经具备高效处理大量请求的能力。当需求从“自己运行模型进行测试”变成“让多个用户同时访问，或者批量处理大量资料”时，需要考虑的问题就发生了变化。

假设我们准备搭建一个课程资料问答系统。

最初只有开发者自己测试，每次发送一个问题，等待模型回答即可。在这种情况下，使用 Transformers 框架结合 Serve 部署能力或许还能支撑。

但当整个班级同时使用时，情况就不同了。有人只发送一句简短的问题，有人附带了很长的资料；有人的回答已经结束，有人的回答仍在生成，同时还有新的请求不断进入。如果程序只是按照“处理完一个请求，再处理下一个”的方式运行，后面的用户就需要持续等待。即使将多个请求组成固定批次一起处理，也需要考虑较短的请求完成后，能否及时加入新的请求，而不是始终等待整个批次结束。这些问题需要请求调度机制，而不只是调用模型生成文本的接口。

在 Transforms 官方文档也将 Serve  这一服务方式定位为适合本地或自托管、实验评估和中等负载的轻量方案；对于大规模生产部署，则建议考虑 vLLM 或 SGLang 等专门的推理引擎。因此，两者的区别不宜简单理解为“一个只能推理，另一个才能部署”，而应关注它们的定位与适用场景。

所以当我们进一步关注多人并发、批量任务吞吐量，以及有限显存和计算资源的利用效率时，就需要使用一些专门的大模型优化框架，其中最常被业界所使用的就是 vLLM 框架。vLLM 是一个面向大语言模型的开源推理与服务框架。它不仅提供运行模型的接口，还通过请求调度、缓存管理和计算优化等机制，提高模型推理的资源利用效率，并支持将模型部署成可供其他程序调用的服务。

具体来说，vLLM 不只是分别执行每个请求，还会组织多个请求共同参与计算：通过连续批处理动态安排请求，通过分页式 KV Cache 管理提高推理缓存的显存利用效率，并结合其他计算优化机制改善服务表现。这些能力围绕的是同一个目标：在给定的硬件条件下，更有效地完成持续到来的推理任务。至于实际能提高多少吞吐量、降低多少延迟，仍需要结合模型、硬件和请求负载进行测试，不能仅凭更换框架就认定所有场景都会更快。

因此，接下来学习 vLLM，并不是否定此前使用 Transformers 的方式，而是将关注点从“怎样让模型完成推理”，进一步推进到“怎样高效地组织模型推理，并把它提供给实际应用使用”。

2. vLLM 的应用流程

理解 vLLM，不能只看“启动服务”和“获得回答”这两个动作，还需要看清它们之间发生了什么。其中包括应用提交的请求怎样变成模型输入，多个请求怎样被安排执行，模型生成的结果又怎样回到用户手中等。

下面以课程资料问答系统为例，按照 vLLM V1 的典型 GPU 文本生成服务架构，沿着一次请求理解各部分的分工。整体关系可以先概括为：

这里，vLLM 并不是在应用与模型之间简单地转发消息，而是负责组织模型推理的执行过程。它内部的服务接入、请求调度与 GPU 计算由不同组件协作完成。

2.1 应用组织请求：决定给模型提供什么信息

假设学生在网页上提出一个问题：

这周的实验要提交什么？

在我们设计的问答系统中，这个问题会先到达应用后端。后端查询课程知识库，找到相关实验要求，再将这些资料与学生的问题整理成对话消息。

因此，准备提交给模型的内容，并不一定只有用户刚刚输入的那句话，还可能包含系统提示词、检索到的资料和需要保留的历史对话。这些内容由应用根据业务需要组织。

完成这些准备后，后端通过 API 客户端向 vLLM 发送请求。在这个方案中，查找哪些资料、提供哪些上下文，由应用后端负责；根据收到的输入组织模型推理，由 vLLM 负责。如果应用没有找到正确的实验要求，后面的模型推理也无法凭空补齐这份私有资料。

2.2 服务处理输入：把对话消息转换成模型输入

当请求到达 vLLM 后，首先进入的是 API 服务层（API Server），而不是直接进入 GPU 进行模型回复计算。服务端需要接收并检查请求，再进行相应的输入处理。

以对话接口为例，应用提交的是带有角色信息的消息，如 system、user 和 assistant。这些消息需要按照模型适用的聊天模板（Chat Template）组织，再通过分词器转换为模型使用的 Token ID 序列。聊天模板负责整理角色、消息边界和生成起点等信息，分词器则负责将相应内容编码为数字序列。

2.3 引擎调度请求：安排计算并复用已有结果

输入准备完成后，请求会进入 引擎核心（Engine Core）。此时，服务中可能已经存在其他任务：有的请求刚刚到达，有的正在处理输入，有的已经开始生成回答。因此，请求被服务接收，并不等于它已经立即获得 GPU 计算资源。引擎需要持续跟踪请求状态，并安排后续执行。

其中，调度器（Scheduler）负责决定当前这一轮计算处理哪些请求，以及为它们安排多少 token 的计算。这个安排受到调度预算和可用缓存空间等条件的影响，而不是简单地把所有请求同时交给 GPU。

例如，学生甲的请求已经开始输出回答，学生乙刚刚提交了一段很长的资料，学生丙的回答则已经结束。接下来一轮计算需要考虑：继续推进甲的生成，安排乙的输入处理，并让丙不再占用后续的计算名额。这些都属于推理引擎需要协调的工作。

2.4 执行模型计算：从处理输入到逐步生成回答

调度完成后，vLLM 通过 GPU Worker 组织实际的模型计算。模型权重通常已经在服务初始化阶段加载完成，并不是每收到一个用户请求，就重新加载一次模型。前面介绍的调度器决定“当前哪些请求参与计算”，接下来则需要进一步理解：被选中的请求进入模型以后，输入是怎样逐步变成回答的。

2.4.1 Prefill：处理已有输入，并保存可复用的结果

对于普通的自回归文本生成，模型首先需要处理请求中已有的输入，这个阶段称为 Prefill。以前面的课程问答为例，回答规则、课程资料和学生问题共同构成了输入上下文。模型对这些输入 token 进行计算，并在输入处理完成后，根据计算结果选出第一个输出 token。因此，Prefill 首先是一个输入计算阶段，而不只是把输入内容保存起来。

但得到第一个 token，并不意味着整段回答已经完成。模型后面还需要继续生成，而且每一步都要利用此前的上下文。假设输入包含一段很长的课程资料，后续每生成一个 token，是否都需要把这段资料重新计算一遍？这就引出了缓存（Cache）：把已经得到、后续还会使用的计算结果保存下来，需要时直接复用，从而减少重复计算。

KV Cache 就是大模型推理过程中保存的一类计算缓存。 在处理输入时，模型会将后续生成需要使用的一部分中间结果保留下来。这里暂时不需要深入理解其内部的数值结构，只需要注意：缓存保存的是模型计算产生的中间结果，不是聊天文字本身，也不是提前准备好的答案。

如图所示，没有缓存时，模型每生成一个新的 token，都需要重新执行大量与前文有关的计算；使用缓存后，前面已经处理过的内容所对应的部分结果可以直接复用，后续再继续处理新增的 token。模型并不是不再参考前文，而是通过已经保存的计算结果继续利用上下文。

这种方式本质上是用空间换时间。保存缓存需要额外的存储空间，在常见的 GPU 推理配置中通常会占用显存。因此，部署时不仅要考虑模型权重能否放入显存，还要为运行过程中的缓存留出空间。这也解释了为什么前面的调度器需要考虑可用缓存空间：缓存不足时，能够同时推进的请求就会受到限制。

需要注意，Prefill 是处理输入的一个阶段，并不意味着全部输入必须在一轮计算中完成。对于较长的输入，vLLM 可以分块处理；但从单个请求的生成过程来看，仍然是先完成必要的输入处理，再根据结果选出第一个输出 token。

2.4.2 Decode：利用缓存逐步生成后续内容

得到第一个输出 token 后，模型进入 Decode 阶段。此时，前面的输入已经处理过，模型可以读取已有的 KV Cache，并处理刚刚生成的 token，继续预测下一个 token。处理这个新增 token 时产生的相应计算结果，也会加入缓存，供后续步骤使用。

例如，假设输入共有 1,000 个 token。Prefill 完成后，模型已经保存了这些输入对应的缓存，并选出了第一个输出 token。接下来预测第二个输出 token 时，模型会处理刚刚选出的第一个 token，同时复用前面 1,000 个输入 token 的缓存；再下一步，则处理第二个 token，并继续利用已有结果。这个过程不断重复，回答也就逐步延长。

因此，Prefill 负责处理已有输入，Decode 负责在已有上下文的基础上继续生成，而 KV Cache 则连接了这两个阶段。它在输入处理过程中建立，又在后续生成中不断被读取和更新。对于这里讨论的普通逐 token 生成过程，整段回答不是一次计算就直接产生的，而是通过连续的预测逐步形成的。

2.4.3 一次模型调用如何经历多轮计算

在 vLLM 中，上述生成过程会与调度机制结合起来。引擎持续安排模型计算，并根据执行结果更新请求状态，随后再决定下一轮推进哪些请求。例如，某一轮可能继续为学生甲生成内容，同时处理学生乙的一部分输入；下一轮参与计算的请求组合还可能发生变化。一个请求不必从开始到结束始终独占 GPU，多个请求可以在持续调度中共同推进。

因此，应用发出的一次模型调用，在 vLLM 内部通常会对应多轮调度和模型计算。应用不需要为了获得每一个新 token 而重新发送一次 HTTP 请求，而是由推理引擎持续推进生成。模型负责根据上下文预测后续内容，vLLM 则负责组织请求、安排计算和管理缓存，让多个请求能够更高效地共同使用计算资源。

拓展：不同请求之间的缓存复用与调用成本

前面讨论的是一次生成过程中如何复用已有计算结果。进一步考虑，如果下一次请求也包含相同的课程资料、回答规则或对话历史，是否能够继续利用之前的结果？当服务支持前缀缓存（Prefix Caching），且新请求具有可匹配、仍可复用的前缀时，就可以复用这部分内容对应的缓存，减少重复的输入计算。它主要节省的是 Prefill 阶段的开销，并不意味着后面的回答无需继续生成。

这种复用也可能直接反映在 API 调用费用上。例如，DeepSeek 的价格表将输入区分为缓存命中与缓存未命中，命中部分采用更低的输入单价。需要区分的是，这里的计费优惠针对服务端认定的缓存命中，并不是只要模型在生成过程中使用了 KV Cache，所有输入就都会自动按优惠价格计费。

以一个多轮执行的 Agent 为例，每次调用模型时，都可能继续携带系统提示词、工具说明、任务要求和已有历史，再在末尾追加新的工具结果。这种组织方式可能形成较长的重复前缀，为缓存复用创造条件。不过，任务长并不等于一定命中缓存，关键仍是前缀是否匹配，以及相应缓存是否可用。对于这类应用，保持固定内容与可变内容的合理组织，才有机会同时减少重复输入计算和调用成本。

2.5 处理输出并返回：从 token 变回用户看到的回答

前面已经介绍了模型如何处理输入，并利用缓存逐步生成后续 token。接下来，还需要完成输出转换与结果返回，让模型生成的内容最终成为用户在页面上看到的回答。

2.5.1 输出转换：将 token ID 还原为可读文本

模型生成的新 token 在程序内部通常以 token ID 的形式表示，而不是直接以网页文字的形式出现。因此，服务需要利用与模型配套的分词器，将这些编号转换成可读的文本，并与已经生成的内容衔接起来。这个过程称为反分词（Detokenization）。它处理的是已经生成的结果，不是再让模型重新组织一次答案，也不同于前面介绍的、持续预测后续 token 的 Decode 阶段。

完成文本转换后，服务还需要按照 API 的格式要求组织响应，再通过网络返回给客户端。也就是说，模型计算产生的结果，并不会直接变成网页上的文字：服务负责返回数据，应用负责读取这些数据，并决定如何展示给用户。

2.5.2 返回方式：一次返回完整结果，或逐步返回已有内容

模型服务通常支持非流式返回和流式返回两种方式。使用非流式返回时，服务会等待本次生成结束，再将结果统一返回给客户端；使用流式返回时，服务则可以在生成过程中持续发送已经产生的输出片段，客户端接收后逐步更新页面。对于用户来说，前者表现为等待一段时间后看到整段结果，后者则表现为回答不断向后延长。

这里需要注意，两种方式主要区别在于结果什么时候返回，而不是模型是否逐步生成。即使采用非流式返回，模型内部仍然需要经历前面介绍的生成过程，只是中间结果没有立即展示给用户。流式返回也不要求应用为每个新 token 重新发送请求，而是在同一次请求的响应过程中持续接收数据；一次收到的文本片段，也不一定恰好对应一个 token。

2.5.3 结束生成：返回结束信息，并交由应用处理

生成过程需要明确的停止条件。常见情况包括：模型生成了结束标记，输出匹配了指定的停止内容，或者已经达到设置的最大输出 token 数。满足相应条件后，该请求不再继续生成，服务会返回相应的结束信息。需要特别注意，生成结束不一定意味着回答已经完整表达完毕：如果是因为达到长度上限而停止，最后一句话或最后一部分内容就可能尚未完成。

因此，应用除了读取回答内容，也应关注返回的结束原因，而不是只要收到文字就默认任务已经完整完成。例如，在课程问答场景中，应用可以将结果展示给学生、保存问答记录；如果发现输出受到长度限制，则提示回答可能不完整，再根据业务需要决定如何处理。

至此，一次课程问答的流程就完整串联起来了。学生看到的是整理后的实验提交要求，而这段回答已经经过了资料准备、输入处理、请求调度、模型计算和输出返回等多个环节。回顾这个过程，可以更清楚地区分三者的职责：应用决定要完成什么业务、提供什么信息以及如何使用结果；模型依据输入进行计算，逐步预测后续内容；vLLM 则负责接入请求、调度执行、管理缓存，并组织结果返回。 三者共同构成了一个可以实际使用的大模型应用。

3. 总结

本节以课程资料问答系统为例，介绍了 vLLM 如何组织一次模型请求的执行。学习的重点从“怎样让模型生成回答”，进一步转向了“怎样让多个请求在有限的显存和计算资源下高效完成推理”。因此，vLLM 的价值不只是提供一个调用接口，更在于将请求接入、输入处理、调度执行、缓存管理和结果返回组织成完整的服务过程。

从应用发出请求到用户看到回答，中间需要经过应用组织请求、服务处理输入、引擎调度、模型计算和输出返回等环节。其中，应用负责准备业务所需的信息，vLLM 负责组织模型推理，模型则依据输入逐步预测后续内容。应用发出的一次调用，在引擎内部通常对应多轮调度与计算；采用流式返回时，已经生成的内容还可以在这个过程中持续传回应用，而不必等待整段回答生成结束。

在模型计算内部，需要重点理解 Prefill、Decode 和 KV Cache 之间的关系：Prefill 处理已有输入，并根据计算结果选出第一个输出 token；Decode 利用已有计算状态，逐步生成后续 token；KV Cache 则保存可以复用的中间结果，连接这两个阶段。缓存减少了重复计算，但也需要占用存储空间，因此，计算如何安排与缓存如何管理，是紧密关联的两个问题。

建立这条执行主线以后，再学习连续批处理、分页式缓存管理等优化机制，就不只是记住技术名称，而是能够判断：它们作用于哪个环节，减少了哪些重复计算、等待或资源浪费。至于实际能够提升多少吞吐量、改善多少延迟，仍然需要结合模型、硬件和请求负载进行测试。理解执行过程，是进一步理解推理优化、部署配置和性能评估的基础。