非算法工程师也能看懂，推理框架的来龙去脉

继 Model、Harness 后，DeepSeek 再次开源了推理框架 DeepInfer，帮助企业彻底玩转智能体的进度条上新增了一块重要拼图，同时也将推理框架一词推向公众。

虽然 Model、Harness 的概念已深入人心，但推理框架这个算法工程师才会使用的概念似乎还略显陌生。不过，它和我们使用模型的费用和体验息息相关，例如为什么的输出价格是输入的 4 倍，缓存命中的价格是未命中的1/50（以 DeepSeek 当前的定价为例）等等，相信本文对这些疑问会提供一些通俗易懂的解答。

本文分为五个章节。

• 推理框架是什么，以及它和模型、智能体的关联；

• 进一步阅读本文需要了解的几个核心概念；

• 梳理主流的开源推理框架的现状和发展趋势；

• 从一个请求开始，看推理框架的工作原理；

• 哪些人群和企业会用到推理框架。

文章较长，您也可以在此处获得更佳的阅读体验：
https://aliyun.github.io/ai-agent-handbook/optimization/chapter-17/inference.html

01

模型和推理框架

Cloud Native

▍1. 模型的一生：从训练到上线

一个大模型从无到有，大致要经过四个阶段。先是预训练，用海量文本让模型学会语言和知识；再是后训练，通过监督微调、强化学习、蒸馏等手段，让模型学会遵循指令、使用工具、完成特定任务；然后是评测，确认模型在目标任务上的表现达标；最后是部署上线，以 API 或私有化服务的形式被应用调用，并在运行中持续监控、迭代。

所谓推理，指的是对模型的推理。就是用训练好的模型，根据输入、计算输出的过程。推理框架，则是负责把这件事做好：把模型加载到各类硬件和软件环境上，接收请求、组织计算，并返回结果。

做好的前提是能跑起来，即支持要部署的模型和所用的硬件，包括兼容性的支持等，这是所有框架型技术的本职工作。

在此基础上，“好”包括五个方面。

一是快，用户发出请求后能尽快看到第一个字，生成过程流畅、不卡顿。

二是多，同样的硬件能同时服务尽可能多的请求。

三是省，把显存和算力用足，已经算过的内容尽量不重复计算，摊薄每一次调用的成本。

四是稳，遇到流量高峰、超长请求或硬件故障时，服务依然可用，并且能随业务规模扩展。

五是准，模型部署之后的输出要与模型本来的能力保持一致，格式符合要求，结果在需要时可以复现。

这五个方面常常相互牵制：一次塞进更多请求能让“多”更好，但每个请求的生成速度会变慢；把数值精度压得更低能让“省”更好，但可能影响“准”。推理框架要做的，就是根据业务需要在它们之间找到平衡。

后文介绍的各种概念和设计，基本都可以归到这五个方面中的一个或几个：比如首字延迟和生成速度对应“快”，批处理和吞吐对应“多”，显存管理、量化和缓存对应“省”，集群调度和容错对应“稳”，对话模板、采样和结构化输出对应“准”。

在模型训练到上线的生命周期中，推理框架不止出现在上线阶段。上线阶段，每一次用户提问、每一次智能体调用模型，背后是推理框架在工作。在后训练阶段，它同样不可或缺：强化学习需要模型反复尝试任务、生成大量轨迹，再根据结果更新参数，其中“生成”这一步往往是整个训练流程中最耗时的部分，所以主流的强化学习训练框架普遍把成熟的推理引擎嵌入进来，专门负责批量生成。评测阶段要让模型跑完成千上万道题，合成数据要让模型批量产出样本，用的也是推理框架。

此外，训练和推理在成本结构上有一个根本差异：训练是一次性的投入，一个模型训练几周或几个月，训完就结束了；推理是持续性的支出，模型上线后，每一次被调用都在消耗算力，调用量越大，账单越长。

▍2. 任务越复杂，对推理框架的要求越高

如果说聊天机器人是一问一答，那么智能体执行一次任务，更像是一场连续的多轮对话。以一个帮您排查线上故障的智能体为例：它先理解问题、拟定计划，然后调用日志查询工具，读取返回结果，判断下一步，再调用监控工具，再判断……一次任务下来，模型可能被调用十几次甚至几十次。阿里云全域运维智能平台 STAROps 中的故障诊断就是这样的场景：用户用自然语言描述问题，智能体通过多轮对话逐步缩小排查范围，把日志、指标、链路、变更等数据串起来分析。

而且，每一次调用，智能体都要把系统提示词、工具、此前每一步的思考和工具返回结果，连同新的内容一起发给模型。随着任务推进，上下文越滚越长，而每一次请求中的绝大部分内容，其实在上一次请求里已经出现过。

这让推理负载呈现出三个特点：输入很长，输出相对较短，前后请求高度重复。同时，智能体的端到端耗时是每一步耗时的累加，每一次调用多等一秒，几十步下来就是几十秒。

这对推理框架提出了新的要求。在聊天场景中，推理框架主要比拼谁算得快；到了智能体场景，还要比拼谁能少算，已经算过的内容能不能记住、能不能复用，这都直接决定了推理的成本和速度。

▍3. 训练框架 vs. 推理框架

很多工程师接触推理框架时，会本能地拿 PyTorch、Megatron-LM、DeepSpeed 这类训练框架来类比。两者都和模型、GPU 打交道，但要解决的问题截然不同。

从这张表可以看出，推理框架更像是一个在线服务系统，它要面对的问题和数据库、Web 服务器有不少相似之处：请求排队、资源调度、缓存命中、负载均衡、故障恢复。只不过它调度的不是 CPU 和磁盘，而是昂贵的 GPU 和显存。

▍4. 推理框架、模型、智能体和 Harness

我们用这些熟悉的概念，来进一步关联理解推理框架。

一个智能体应用，Harness 负责组织提示词、管理上下文、调用工具等；往下是模型服务，可以以 API 的形式或自部署方式进行调用；模型服务的底下是推理框架，是模型在上线后和硬件等环境的中间件层，推理框架之下，才是 GPU 等硬件。

如果您日常使用模型的方式是 API 和订阅，一般不会关注推理框架。但对于自行部署模型的企业，一个好用的推理框架将决定模型的使用成本和体验。因为推理成本、首字等多久、每秒能吐多少字、并发上来后会不会变慢，这些体验都是由推理框架层决定的。

02

进一步阅读本文需要了解的一些核心概念

Cloud Native

▍1. 几个容易混淆的词

在阅读推理相关的文章时，您可能会同时看到推理引擎、推理框架、推理服务、模型服务平台等说法。它们经常被混用。

可以简单理解为一层套一层：推理引擎是心脏，推理框架是包含心脏在内的整套动力系统，推理服务是装好动力系统、可以上路运营的车队，模型服务平台则是面向公众售票的客运公司。本文后续统一使用“推理框架”这个说法。

▍2. Token：模型读写的最小单位

模型并不直接处理文字，而是先把文字切分成一个个 Token，再转换成数字编号。在英文里，一个 Token 大约相当于四分之三个单词；在中文里，一个汉字对应的 Token 数因模型分词器而异。

Token 也是大模型的计费单位。几乎所有模型 API 都把输入 Token 和输出 Token 分开计价，而且输出 Token 通常比输入 Token 贵好几倍。为什么“写”比“读”贵？答案在下一个概念里。

▍3. Prefill 与 Decode：先读题，再作答

模型处理一个请求，分为两个阶段。

第一个阶段叫 Prefill（预填充），相当于“读题”。模型一次性读入全部输入内容，所有输入 Token 可以并行计算，GPU 的计算单元被充分调动起来。这一阶段结束时，模型产出第一个输出 Token。

第二个阶段叫 Decode（解码），相当于“作答”。模型每次只能生成一个 Token，生成之后把它接到已有内容后面，再生成下一个，如此往复，直到写完。每生成一个 Token，都需要把整个模型的权重从显存中读一遍，但只做很少的计算。这就好比为了写一个字，要把整本参考书从头翻一遍。所以 Decode 阶段的瓶颈不在计算能力，而在显存带宽，也就是“翻书”的速度。

两个阶段的特性截然不同：Prefill 吃算力，Decode 吃带宽。这也解释了上一节的问题：输出之所以更贵，是因为它必须一个字一个字地串行生成，单位时间内占用 GPU 更久。后文会看到，推理框架的很多设计，都是围绕这两个阶段的差异展开的。

既然 Decode 最大的开销是“翻书”，那么翻一次书时，能不能同时帮很多个请求各写一个字？这就是批处理（Batching）：把多个请求凑成一批，共享同一次权重读取。处理 1 个请求和处理 64 个请求，Decode 一步的耗时相差不大，产出的 Token 却相差几十倍。早期的批处理要凑齐一批一起出发，等最长的那个请求写完才换下一批；后来的连续批处理（Continuous Batching）以每一步生成为单位调度，写完的请求随时下车，新来的请求随时上车，像一趟随上随下的环线公交。如今，连续批处理已经是主流推理框架的标配。

▍4. KV Cache：模型的草稿纸

大模型在生成每个新 Token 时，都要“回头看”前面所有的内容，判断哪些信息与当前最相关，这就是注意力机制。如果每生成一个 Token 都把前面的内容重新算一遍，计算量会随着长度急剧膨胀。

解决办法是把前面每个 Token 计算过程中的中间结果（称为 Key 和 Value）保存下来，生成新 Token 时直接取用，只需要计算新 Token 本身。这份被保存下来的中间结果，就是 KV Cache。它像是模型的草稿纸，前面算过的都记在上面，后面直接查。

草稿纸并不免费。KV Cache 的大小与上下文长度成正比，与同时处理的请求数成正比。上下文越长、并发越高，草稿纸就越厚，占用的显存就越多。在实际的推理服务中，KV Cache 往往是显存里最紧张的资源，它的容量直接决定了一张卡能同时服务多少个请求。

让草稿纸和模型本身“变薄”的常用办法是量化，即用更低的数值精度来存储权重、KV Cache 或中间计算结果，用一点精度换取大幅的显存节省和速度提升。从 16 位降到 8 位，在多数通用任务上影响较小，已是生产部署的常见选择；降到 4 位甚至更低，压缩更明显，但对效果的影响更依赖具体模型和任务，需要用自己的业务数据验证。此外，不少新模型在设计时就采用了压缩 KV Cache 的注意力结构，从源头上让草稿纸变薄。模型能不能部署，先看权重的显存账；能服务多少人，主要看 KV Cache 的账。

▍5. TTFT、TBT 与吞吐：三个此消彼长的指标

衡量推理性能，最常用的是三个指标。

• TTFT（Time To First Token，首 Token 时延），指从发出请求到收到第一个输出 Token 的时间，也就是用户看到模型“开口”之前要等多久，主要由 Prefill 阶段决定。

• TBT（Time Between Tokens，Token 间时延），也常被称为 TPOT（Time Per Output Token），指连续两个输出 Token 之间的平均间隔，决定了模型“说话”的语速，主要由 Decode 阶段决定。

• 吞吐（Throughput），指整个系统单位时间内处理的 Token 数或请求数，决定了一套硬件能服务多少用户，也直接决定了单位成本。

这三个指标很难同时做到最好。批次越大，吞吐越高，但每个请求分到的“时间片”变少，生成速度会变慢；优先处理新来请求的 Prefill，首字延迟能降下来，但正在生成中的请求会出现卡顿。推理框架所做的大量工作，就是在用户能接受的延迟范围内，把吞吐推到尽可能高。业内常用“有效吞吐”（Goodput）来描述这个目标，即满足延迟要求的那部分吞吐。

对智能体来说，还要多算一笔账：一次任务的总耗时，约等于每一步的首字延迟、生成时长和工具执行时间之和。单步多几百毫秒，几十步累加起来就是用户能明显感知的等待。我们在阿里云 AgentLoop 上看过智能体一次任务的完整轨迹，展示每一次模型推理、每一次工具调用的轨迹，并标出各自的耗时和 Token 消耗。如下图。通过评测阶段的数据，来优化推理框架。

▍6. MoE：参数很多，每次只用一小部分

当前不少主流大模型采用了 MoE（Mixture of Experts，混合专家）结构。模型内部有很多个“专家”子网络，每个 Token 只交给其中少数几个处理。以 DeepSeek-V3 为例，模型总参数量为 6710 亿，每个 Token 实际只激活其中约 370 亿参数，知识容量很大，单个 Token 的计算量却相对较小。代价是所有专家都必须常驻显存，一台机器往往装不下，需要把专家分散到多张卡上，跨卡通信和负载均衡也就成了推理框架要解决的新问题，第四部分会具体展开。

03

业内有哪些主流的开源框架，

他们的发展情况如何

Cloud Native

从 2023 年大模型应用爆发算起，开源推理框架的发展只有短短三年多，却已经形成了几条相对清晰的脉络：服务器端的通用推理引擎、面向个人电脑和端侧设备的本地运行工具、管理整个推理集群的编排层，以及模型厂商和互联网企业开源的自家推理系统。本节按这几条脉络介绍主要项目的来历和发展情况，不做优劣比较。文中的 GitHub 星标数截至 2026 年 10 月，仅用于反映社区关注度。

▍1. 通用推理引擎：从学术项目到行业基础设施

服务器端的通用推理引擎，是目前使用最广泛的一类推理框架。

还有一个值得一提的项目是 Hugging Face 的 TGI（Text Generation Inference），它在 2022 年就已出现，是最早一批面向大模型的推理服务框架。2025 年 12 月，TGI 宣布进入维护模式，并建议用户转向 vLLM、SGLang 等推理引擎。

回顾这几年的发展，一个明显的特点是学术研究和工程实践之间的距离非常近。连续批处理的思想来自 2022 年的 Orca 论文，分页管理 KV Cache 来自 2023 年的 PagedAttention 论文，加速注意力计算的 FlashAttention 发表于 2022 年，投机解码的两篇奠基论文出现在 2022 年底到 2023 年初，PD 分离的代表性研究 DistServe 和 Splitwise 发表于 2024 年。这些成果几乎都在发表后很短的时间内进入了主流推理引擎。

另一个特点是各个项目之间相互借鉴，核心功能日益趋同。连续批处理、分页 KV Cache、前缀缓存、分块预填充、投机解码、结构化输出，如今已是主流推理引擎的共同配置。竞争的焦点逐渐转向了其他方面：新模型发布后能多快支持，能覆盖多少种硬件，在大规模集群部署中表现如何。

▍2. 本地与端侧运行：让模型走进个人电脑

让模型在个人电脑甚至手机上运行。

llama.cpp 由开发者 Georgi Gerganov 在 2023 年 3 月发布，用 C/C++ 实现，可以在普通 CPU、苹果电脑的芯片等消费级硬件上运行大模型。它在 2023 年 8 月推出的 GGUF 格式，后来成为本地运行量化模型最常用的文件格式之一。截至 2026 年 10 月，llama.cpp 的 GitHub 星标超过 13 万。

Ollama 于 2023 年发布，把模型下载、运行和简易 API 封装成一条命令，大幅降低了在本地运行模型的门槛。它早期主要封装 llama.cpp，2025 年起逐步转向基于 GGML 张量库的自研引擎。Ollama 的 GitHub 星标超过 18 万，是推理相关项目中最高的。

此外，MLC-LLM 等项目通过机器学习编译技术，把模型部署到手机、浏览器等更多类型的设备上。

本地运行工具的星标数高于服务器端推理引擎，某种程度上反映了用户群体的差异：在自己电脑上跑模型的个人开发者，数量远多于需要部署推理集群的工程师。

▍3. 集群编排层：竞争重心从单机走向集群

2025 年以后，推理框架领域出现了一类新项目。它们并不替代推理引擎，而是架在推理引擎之上，负责管理整个推理集群：把请求路由到合适的实例，实现 Prefill 与 Decode 的分离部署，管理和传输跨机器的 KV Cache，根据负载自动扩缩容。

英伟达在 2025 年 3 月的 GTC 大会上发布了开源的分布式推理框架 Dynamo，提供 PD 分离、感知 KV Cache 分布的智能路由、KV Cache 管理与高速传输等能力，可以搭配 TensorRT-LLM、vLLM、SGLang 等多种推理引擎使用。

2025 年 5 月，红帽联合 CoreWeave、谷歌云、IBM 研究院、英伟达等发起了 llm-d 社区，基于 vLLM 构建原生运行在 Kubernetes 上的分布式推理方案。

月之暗面的 Mooncake 是 Kimi 背后的推理服务平台，采用以 KV Cache 为中心的 PD 分离架构。它在 2024 年 6 月发布技术报告，此后陆续开源了数据传输引擎、KV Cache 存储等核心组件，相关论文获得了 2025 年存储领域顶级会议 FAST 的最佳论文奖。

这类项目的出现，与前文提到的两个变化直接相关：模型越来越大，一台机器装不下；智能体带来的长上下文、高重复负载，让跨请求、跨机器复用 KV Cache 的价值越来越大。当单机引擎的优化逐渐趋同，推理效率的差距越来越多地拉开在集群调度上。

▍4. 模型厂商与互联网企业开源推理系统

模型厂商和大型互联网企业正在把自己生产环境中使用的推理技术开源出来。

DeepSeek 是一个有代表性的例子。2025 年 2 月，DeepSeek 举办开源周，陆续开源了注意力算子 FlashMLA、专家并行通信库 DeepEP、矩阵乘法库 DeepGEMM、专家负载均衡工具 EPLB、分布式文件系统 3FS 等推理相关组件，并公开了 V3/R1 推理系统的设计概览。2025 年 4 月，DeepSeek 发文说明，其内部推理引擎源自一年多前的 vLLM 早期分支，与内部基础设施耦合较深，因此选择把独立组件和优化贡献给开源社区，并在新模型发布前与社区提前同步，争取实现新模型发布当天即可部署。到了 2026 年 10 月，DeepSeek 正式开源了推理框架 DeepInfer。

除了前面提到的月之暗面 Mooncake，阿里巴巴开源了 RTP-LLM。

这些开源实践的路径不尽相同，有的贡献组件，有的开源完整系统，但背后有一个共同的认识：模型结构越复杂、部署规模越大，推理侧的实现就越成为模型能力的一部分。

▍5. 新模型为什么要等推理框架“适配”

很多工程师都有过这样的经历：一个新模型发布了，下载好权重，却发现常用的推理框架还不支持，或者能跑但效果不对、速度很慢。这是因为推理框架并不能自动运行任意模型，每一个新模型，都需要推理框架做专门的适配工作。

适配要做的事情不少。首先是实现模型结构，新模型往往会引入新的注意力机制、新的专家路由方式，推理框架需要实现对应的计算逻辑，并编写高效的算子，否则即便能跑，速度也会很慢。其次是对齐对话模板和工具调用格式，前文讲过，模板不对，效果就会打折扣。此外还有新的量化格式、新的多模态输入方式等。

近两年的几个例子很能说明问题。2025 年 9 月，DeepSeek 发布了采用稀疏注意力机制的 V3.2-Exp 模型，vLLM 在模型发布当天宣布支持；同月，阿里通义千问发布了采用混合注意力结构的 Qwen3-Next，vLLM 在第二天宣布支持。能做到这么快，是因为模型厂商在发布前就与推理框架社区提前合作。这种“发布当天即可部署”的协同，正在成为行业惯例。

对工程师来说，这意味着部署新模型时，需要特别留意推理框架的版本：新模型发布初期，不同框架、不同版本的支持程度可能不一样，性能和效果也可能还在持续优化中。模型和推理框架，越来越像是一起设计、一起发布的。

▍6. 硬件多元化：从英伟达 GPU 到国产芯片

长期以来，大模型推理主要运行在英伟达 GPU 上，推理框架的算子和优化也大多围绕英伟达的 CUDA 生态展开。这种局面正在发生变化。

一方面，推理框架在架构上为多种硬件留出了空间。以 vLLM 为例，它在 2025 年推出了硬件插件机制，芯片厂商可以在主项目之外独立维护自己的硬件后端。基于这一机制，社区维护了支持华为昇腾的 vllm-ascend，百度推出了支持昆仑芯的 vLLM-Kunlun，沐曦也推出了对应的适配版本。前面提到的京东 xLLM 以支持国产芯片为重点，DeepInfer 同时支持英伟达 GPU 和华为昇腾 NPU。

另一方面，模型厂商在设计模型时，也开始考虑国产芯片的特点。2025 年 8 月，DeepSeek 在发布 V3.1 时表示，模型采用的 UE8M0 FP8 数值格式，是针对即将发布的下一代国产芯片设计的。

此外，Triton、TileLang 等更高层的算子编程语言，让开发者不必针对每种芯片手写底层代码，也在一定程度上降低了把推理框架移植到新硬件上的成本。

对于需要在国产芯片上部署模型的企业，这些进展意味着可选的方案正在变多，但不同芯片、不同框架组合下的模型支持范围和性能表现差异仍然较大，部署前需要逐一验证。硬件越多元，推理框架作为模型与芯片之间适配层的价值就越大。

▍7. 小结：三个方向的变化

纵观开源推理框架这几年的发展，可以看到三个方向的变化：从单机引擎走向集群系统，从通用实现走向与模型协同设计，从单一硬件走向多种硬件。这三个变化的背后，是同一个驱动力：大模型正在从少数人尝鲜的新技术，变成大规模、持续运行的基础设施，推理效率成了决定这一切能否持续的关键。

04

推荐框架的架构：

一个请求是怎么被处理的

Cloud Native

前面介绍了推理框架涉及的各种概念，这一节换一个角度：跟着一个请求走一遍，看看它从发出到返回，在推理框架内部经历了什么，每一站解决了什么问题。

假设您在使用一个企业内部的客服智能体。您输入了一个问题，智能体把系统提示词、十几个工具的定义、前面几轮对话的记录，连同您的新问题打包在一起，组成一个约 8000 Token 的请求，发给了模型服务。

▍1. 入口：从 API 协议到 Token 序列

请求首先到达推理框架的接入层。今天的模型 API 大多兼容几种主流的协议格式，接入层要做的第一件事，是把不同协议的请求统一转换成模型能理解的形式。

这一步的核心是“对话模板”。请求中的系统提示词、用户消息、助手回复、工具调用、工具返回结果，需要按照模型训练时约定的格式，用一系列特殊标记拼接成一个完整的文本序列，再由分词器（Tokenizer）转换成 Token 编号。每个模型的对话模板都不一样，模板拼错了，模型虽然照样能输出，但效果可能明显下降，工具调用也可能频繁出错。

接入层还承担着一项容易被忽视的安全职责。对话模板中的特殊标记相当于模型的“控制指令”，用来区分谁在说话、哪里是工具调用。如果用户输入或工具返回的内容中恰好包含了与特殊标记相同的字符串，接入层必须把它当作普通文本处理，否则就可能被利用来伪造角色或注入指令。

请求处理完返回时，接入层还要做反向的工作：把模型输出的 Token 转回文字，从中解析出思考过程、正文和工具调用参数，再按照对应协议的格式以流式的方式逐段返回。

这一层看起来只是格式转换，却是很多线上问题的源头。接入层决定了同一个模型部署在不同地方，表现能否保持一致。

▍2. 调度：把请求排进批次

转换为 Token 序列后，请求进入调度器的等待队列。调度器是推理框架的“指挥中心”，每一步计算开始前，它都要做一系列决策：这一步处理哪些请求？新来的请求要不要现在就开始 Prefill？正在生成中的请求要不要继续？显存里的 KV Cache 空间还够不够？

连续批处理在这里落地。调度器以每一步生成为单位，把已经完成的请求移出批次，把排队中的请求补进来，让 GPU 始终满载运行。

我们这个 8000 Token 的请求，会让调度器面临一个两难：如果一口气把它 Prefill 完，批次里正在生成的其他请求就要停下来等，用户会感觉到明显卡顿。常见的做法是分块预填充（Chunked Prefill），把长请求切成若干小块，每一步只处理其中一块，与其他请求的 Decode 混在一起计算，既不让新请求等太久，也不让老请求卡顿。

调度器还要考虑显存的承载能力。如果 KV Cache 空间不足，新请求就只能继续排队；极端情况下，调度器甚至要暂停一些正在生成的请求，把它们的 KV Cache 换出到内存，或者干脆丢弃，等空间腾出来再重新计算。

此外，调度本身也有开销。调度决策、准备输入数据、处理生成结果都需要 CPU 参与，如果 GPU 每一步都要等 CPU 忙完才能开始下一步，就会出现空转。现在的推理框架普遍采用异步调度，让 CPU 在 GPU 计算当前这一步的同时，提前准备好下一步，把 GPU 的空档挤掉。

在多机部署时，调度还分为两层：集群层面的负载均衡器先决定把请求分给哪个推理实例，实例内部的调度器再决定请求在哪一步、以什么方式被计算。负载均衡器要综合考虑各实例的排队长度、显存占用，以及请求的前缀在哪个实例上已有缓存。以阿里云 PAI-EAS 的 LLM 智能路由为例，它提供按前缀缓存、按最少请求数、按最少 Token 数等多种路由策略，其中前缀缓存策略会把上下文相同的请求优先发往已经缓存了对应 KV Cache 的实例。调度器要回答的永远是同一个问题：下一步，让 GPU 算什么。

▍3. 执行：模型、并行与算子

调度器确定了批次后，请求进入执行层，开始真正的模型计算。

模型一张卡装不下时，执行层首先要把它拆到多张 GPU 上，这就是并行。常见的方式有四种：张量并行（TP）把每一层的大矩阵切开，分给多张卡共同计算；流水线并行（PP）把不同的层分给不同的卡，像流水线一样接力；数据并行（DP）让多张卡各自完整处理不同的请求；专家并行（EP）专门针对 MoE 模型，把不同的专家分散到不同的卡上。模型规模不大时，单卡或几张卡的张量并行就够了；对于大规模 MoE 模型，往往要组合使用数据并行和专家并行，规模可以达到几十上百张卡。这时 Token 要被送到不同卡上的专家那里计算，卡与卡之间需要频繁交换数据；某些专家特别“热门”，所在的卡会拖慢整体，推理框架通常会把热门专家多复制几份，让每张卡都尽量忙起来。

模型的每一层计算，最终都会落到一个个“算子”（Kernel）上，也就是在 GPU 上直接执行的底层计算程序，比如矩阵乘法、注意力计算、专家路由与通信。同样的计算任务，算子写得好不好，性能可以差出数倍。业内有不少针对推理的经典算子优化，例如通过减少显存读写来加速注意力计算的 FlashAttention。模型厂商和硬件厂商也会针对特定的模型结构和芯片，编写专门优化的算子库。低精度计算同样在这一层落地：用 8 位甚至 4 位精度做矩阵乘法，既省显存，又能利用新一代 GPU 的低精度计算单元提速。

执行层还有一些看不见的优化。比如 GPU 每启动一个算子都有固定开销，Decode 阶段每一步的计算量很小，算子启动的开销占比就显得很高，推理框架会把一整步的算子调用“录制”下来一次性回放，减少启动开销。模型结构决定要算什么，算子决定算得多快。

▍4. 缓存：算过的不再算

我们这个 8000 Token 的请求里，系统提示词和工具定义每次都一样，前几轮对话在上一次请求中也已经算过。如果这些内容的 KV Cache 还保存着，就可以直接复用，只需要计算新增的那一小部分。这就是前缀缓存（Prefix Caching），也是缓存这一环的核心价值。

要高效地复用 KV Cache，首先要管理好它。早期的推理框架为每个请求预留一整块连续显存来存放 KV Cache，由于事先不知道请求会生成多长，只能按最大长度预留，大量显存被浪费。后来出现的分页管理方式借鉴了操作系统管理内存的思路，把 KV Cache 切成固定大小的“页”，按需分配，页与页之间不必连续。这一改进大幅减少了显存浪费，让同一张卡能同时服务更多请求，也让不同请求之间共享相同前缀的 KV Cache 变得容易。

显存容量有限，能保存的 KV Cache 终究不多。于是推理框架开始构建多级缓存：最常用的放在显存里，次常用的放到主机内存里，更多的放到 SSD 甚至独立的分布式存储集群中。在集群层面，负载均衡器会尽量把请求路由到已经缓存了其前缀的实例上，或者让所有实例共享同一个缓存池。阿里云的 Tair KVCache 就属于这类缓存池：它把 GPU 服务器的显存、内存等资源池化管理，让 KV Cache 从只驻留在显存，扩展为显存、内存、存储分级缓存，并适配 vLLM、SGLang、TensorRT-LLM 等推理引擎。

理解了这一点，您就能看懂模型 API 账单上的“缓存命中”价格了。命中缓存的那部分输入 Token 跳过了 Prefill 计算，服务商的成本大幅降低，所以很多厂商对缓存命中的输入 Token 大幅打折，常见的是原价的一到两折。

对智能体开发者来说，这里有一条非常实用的经验：尽量让每次请求的开头保持稳定，把固定不变的系统提示词和工具定义放在最前面，把新增的内容追加在末尾。如果在系统提示词的开头插入当前时间这类每次都变的信息，后面所有内容的缓存都会失效。在智能体场景里，缓存命中率就是成本。

▍5. 集群：从一台机器到一个集群

当模型大到一台机器装不下，流量大到一个实例扛不住时，推理框架就从一个程序变成了一个分布式系统。

第一个变化是 Prefill 与 Decode 分离部署（简称 PD 分离）。前面讲过，两个阶段完全不同：Prefill 吃算力，Decode 吃带宽。把它们放在同一组 GPU 上，难免互相干扰，长请求的 Prefill 会拖慢所有正在生成的请求。PD 分离的做法是，用一组机器专门做 Prefill，另一组机器专门做 Decode，Prefill 完成后，把生成的 KV Cache 通过高速网络传给 Decode 机器继续生成。两组机器可以各自选择最合适的并行方式和规模，分别针对首字延迟和生成速度优化。以阿里云 PAI-EAS 部署 MoE 模型的 PD 分离模板为例，Prefill 实例默认用 8 卡张量并行，Decode 实例默认用 8 路专家并行加 8 路数据并行，用户可以按需调整；平台还可以根据模型特征、机型配置和输入输出长度，推荐 Prefill 与 Decode 的实例配比和并行策略。对于多模态模型，图片、视频的编码环节也可以再拆出来单独部署。

第二个变化是更大规模的并行和更复杂的负载均衡。比如大规模 MoE 模型的 Decode 阶段，可能要几十上百张卡组成一个实例，专家之间的负载是否均衡、卡与卡之间的通信是否高效，直接决定了整体吞吐。

第三个变化是弹性和容错。流量有高峰低谷，推理集群需要根据排队情况自动扩缩容；同时预留一定的冗余，应对突发流量。规模越大，硬件故障越是常态，一个由上百张卡组成的实例，任何一张卡出问题都可能导致整个实例不可用，推理框架要能把受影响的请求迅速转移到其他实例上，并尽快用剩余的健康硬件恢复服务。单机推理比的是算得快，集群推理比的是调度得好。

▍6. 采样与输出：让结果可控、可复现

模型每完成一步计算，输出的并不是一个确定的字，而是词表中每个 Token 被选中的概率。从这个概率分布中选出下一个 Token 的过程，叫作采样。这是请求在推理框架中的最后一站，也决定了输出是否可控。

采样的随机程度由几个参数控制。温度（Temperature）越高，选择越随机，输出越多样；温度越低，越倾向于选概率最高的 Token，输出越稳定。Top-p、Top-k 则限定只从概率最高的一部分 Token 中挑选。

这就解释了一个常见的困惑：同样的问题问两次，为什么答案不一样？首先是因为采样本身带有随机性。但即便把温度设为 0，在很多推理服务中，两次结果仍可能有细微差别。原因在于，GPU 上的浮点运算对计算顺序敏感，同一个请求和不同的请求拼在一个批次里计算时，算子内部的计算顺序可能不同，产生极其微小的数值差异，这些差异偶尔就会让模型在某一步选出不同的 Token，之后的内容也随之改变。为此，一些推理框架开始提供“批不变”或确定性的推理模式，保证相同的输入无论和谁拼在一个批次，都得到相同的结果，代价是一定的性能损失。这对评测结果的可复现性很重要，对强化学习训练也很重要，因为训练时需要推理阶段和训练阶段对同一段内容算出一致的概率。

采样环节还能做两件很有价值的事。

一是结构化输出。智能体调用工具时，需要模型输出严格符合格式要求的 JSON，哪怕少一个括号，程序都无法解析。结构化输出的做法是，把格式要求编译成一个语法规则，每一步采样前，先根据当前已经生成的内容，算出哪些 Token 是合法的，把不合法的 Token 直接排除，从根本上保证输出格式正确。

二是投机解码（Speculative Decoding）。Decode 阶段的瓶颈是“翻书”，计算单元其实有大量闲置。投机解码先用一个小而快的草稿模型（或主模型附带的轻量预测模块）一口气猜出后面几个 Token，再让大模型一次性并行验证这几个猜测，猜对的直接保留，猜错的从出错位置重新生成。在数学上，这种方法可以保证最终输出的概率分布与大模型逐个生成完全一致，却能把生成速度提升不少。猜得越准，加速越明显。

最后，生成完成的 Token 被送回接入层，转换成文字，解析成协议规定的格式，以流式方式返回给智能体。同时，推理服务会记录这个请求的输入 Token 数、其中命中缓存的部分、输出 Token 数，用于计费和监控。采样是请求的最后一站，它决定了模型的输出能否被程序可靠地使用。

▍7. 小结：一个请求的旅程

05

哪些人群或企业会使用到推理框架

Cloud Native

▍1. 模型厂商与云厂商：推理效率就是竞争力

对于提供模型 API 的模型厂商和云厂商，推理框架是核心基础设施。同样一批 GPU，推理效率高一倍，就能服务多一倍的用户，或者把价格降一半。模型 API 的价格竞争，很大程度上就是推理效率的竞争。这类企业通常有专门的推理优化团队，基于开源框架深度定制，或者完全自研，并针对自家模型的结构做专门优化。

▍2. 需要私有化部署的企业：数据不出域

金融、政务、医疗、能源、制造等行业的企业，出于数据安全和合规要求，往往不能把数据发送到外部的模型 API，需要在自己的机房或专属云上部署开源模型。这类企业是推理框架的直接使用者，要自己选型、部署、调优、运维，并且越来越多地需要在国产芯片上完成部署。不少企业会选择软硬件一体的推理一体机或私有化推理平台，把推理框架的复杂性交给供应商，但理解推理框架的基本原理，仍有助于做出更合理的硬件选型和容量规划。

▍3. 做智能体和应用的团队：间接使用，直接受益

大多数智能体和 AI 应用团队通过 API 调用模型，并不直接部署推理框架。但推理框架的特性，会实实在在地影响他们的成本和体验：选择模型服务商时，首字延迟、生成速度、缓存命中价格都是重要的考量；设计提示词和上下文结构时，是否有利于缓存命中，会让成本相差数倍；需要输出结构化数据时，是否支持结构化输出，决定了工具调用的可靠性。要弄清楚这些因素在自己的智能体里各占多少，可以借助可观测工具，比如阿里云 AgentLoop 会记录智能体每一步的模型调用、工具调用和检索，追踪每次模型推理的 Token 消耗和耗时，帮助定位一次任务慢在哪一步、钱花在哪一步。此外，也有越来越多的团队在智能体的某些环节，比如意图分类、信息抽取，自己部署小模型，以降低成本和延迟，这时就要直接面对推理框架了。

▍4. 后训练与科研团队：训练流程中的推理

做模型后训练的团队，是推理框架的另一类重度用户。强化学习需要模型大量生成轨迹，蒸馏需要教师模型批量生成示范或对学生的输出打分，评测需要模型跑完大量测试题，合成数据需要模型批量产出样本。这些场景更看重离线批量处理的吞吐，同时对推理结果与训练过程的一致性有更高要求。

▍5. 个人开发者：在自己的电脑上跑模型

随着本地运行工具的成熟和小尺寸模型能力的提升，越来越多的个人开发者在自己的笔记本或台式机上运行模型，用于学习、开发调试，或者处理不便上传到云端的私人数据。端侧推理也在向手机、个人电脑、汽车等设备延伸。这类场景对推理框架的要求是安装简单、资源占用低、能在消费级硬件上跑得动。

结语

Cloud Native

回到开篇的问题：推理框架和模型、智能体之间的关系？

它既在模型训练的流程之中，负责强化学习的采样、评测和数据合成；也在模型上线之后，承接每一次用户提问和智能体调用。它连接着上层的智能体应用和底层的算力集群，把模型的能力，以尽可能低的成本、尽可能快的速度，交付到每一个请求手中。

智能体越普及，模型被调用的次数就越多，每次调用的上下文就越长。在这道乘法题里，推理效率的每一点提升，都会被调用量成倍放大。

欢迎加入 Alibaba Cloud AI Agent Handbook 开源项目共读群：