从训练转向推理：企业如何评估Prefill与Decode分离的AI算力架构？

智能体应用把企业的 AI 推理从“把模型跑起来”变成了“持续处理复杂任务”。一次请求可能包含长篇文档、工具调用结果、历史对话和外部检索内容，输入处理时间、首个 Token 延迟、后续生成速度以及长期记忆访问效率，都会影响用户体验。因此，企业评估 AI 推理算力时，不能只比较单张 GPU 的峰值算力，而应把芯片、显存、互连网络、服务器、调度系统和模型运行时作为一个整体。

为什么智能体推动推理架构重新分工

传统问答通常是短输入、短输出，单机或单组 GPU 通过批处理即可获得较高利用率。智能体任务则不同：它可能先读取大量上下文，再调用搜索、数据库或业务系统，随后根据工具结果继续推理。每次调用都可能产生新的输入，历史状态也需要被保留和复用。

这会同时放大几类指标的重要性：

• 首个 Token 延迟（TTFT）：用户提交请求后，系统多久开始返回结果，主要受输入处理阶段影响。
• 每输出 Token 延迟（TPOT）：开始生成后，系统输出后续 Token 的速度，直接影响流式响应体验。
• 吞吐量：单位时间可以完成的请求数或生成的 Token 数。
• 上下文容量：模型能否稳定处理长输入，以及 KV Cache 是否有足够空间保存历史状态。
• 尾延迟：高并发或长任务下，P95、P99 请求是否明显变慢。
• 单位 Token 成本：包括 GPU、CPU、内存、网络、存储和运维资源，而不只是芯片租赁价格。

因此，企业需要从“哪张卡最快”转向“哪种系统组合能在目标负载下稳定交付”。

Prefill与Decode分别解决什么问题

大语言模型推理通常可以分为两个阶段。

Prefill：集中处理输入

Prefill 负责读取用户提示词、历史对话、检索结果和工具返回内容，并完成上下文的初始计算，同时形成后续生成所需的 KV Cache。输入越长，Prefill 的计算量和显存访问压力通常越大。

它的核心目标是缩短 TTFT。适合 Prefill 的资源配置，往往更重视并行计算能力、较大的张量并行规模和输入处理吞吐。

Decode：逐步生成输出

Decode 根据已有上下文和 KV Cache，逐步生成后续 Token。每生成一个 Token，系统都要访问相关 KV Cache，因此其性能往往更容易受到显存带宽、缓存布局和调度效率影响。

它的核心目标是降低 TPOT，并在多个请求之间提高批处理效率。Decode 节点通常需要稳定地承载动态请求，而不能被某个超长输入突然占满计算资源。

为什么要分离

当 Prefill 和 Decode 共用同一组 GPU 时，两种阶段会争抢计算、显存和调度资源。长文本 Prefill 可能让正在生成的请求出现延迟尖峰；大量 Decode 请求又可能挤压新请求的输入处理时间。

分离后，企业可以为两个阶段分别设置资源池、批处理策略和扩缩容规则：

AWS 的公开实践资料将两阶段的延迟目标概括为 Prefill 关注 TTFT、Decode 关注 TPOT，并展示了通过物理分离分别优化两类节点的方案。NVIDIA Dynamo 文档也将分离式服务描述为一种支持按阶段扩缩容、提升资源利用率的架构。实际收益仍取决于模型、上下文长度、并发模式和软件栈，不能直接套用其他环境的测试结果。

分离式架构不是简单地“多买一组 GPU”

Prefill 与 Decode 分开后，系统新增了跨节点的数据传输路径。Prefill 生成的 KV Cache 或相关中间状态，需要被 Decode 节点及时接收；路由器还要根据节点负载、缓存状态和健康状况选择执行位置。

一个完整的服务通常至少包括四层：

1. 请求入口与路由层：接收请求，识别模型和租户，选择 Prefill 与 Decode 节点。
2. Prefill 节点池：完成输入计算并产生 KV Cache。
3. Decode 节点池：承接状态并持续生成输出。
4. 网络与状态传输层：负责节点间的 KV Cache、控制消息和调度通信。

SGLang 的公开实践中，PD 分离方案包含 Prefill 节点、Decode 节点和 Router；Router 负责负载均衡、重试、熔断、健康检查以及节点自动发现。这说明分离式推理的难点不仅在 GPU 部署，还在于路由和故障处理是否已经生产化。

CPU、GPU与分层存储的协同变化

在单机推理中，GPU 通常承担主要计算任务，CPU 更多负责请求接入、数据准备和任务调度。进入智能体场景后，CPU 的职责会扩大：

• 管理多轮对话和工具调用状态；
• 执行请求排队、优先级和超时策略；
• 处理检索、重排、数据格式转换等前后处理；
• 协调 Prefill 与 Decode 节点之间的状态传递；
• 维护缓存索引、租户隔离和故障重试。

这并不意味着应当用 CPU 替代 GPU，而是要避免 CPU 调度、网络处理或数据搬运成为 GPU 的等待来源。采购时，如果只测 GPU 利用率而不测 CPU 核数、内存带宽和网络处理能力，可能会低估整机瓶颈。

长期记忆也会引入分层存储问题。高频、正在生成的 KV Cache 适合放在 GPU 显存中；暂时不用但可能复用的状态，可以考虑放在主机内存或更大容量的缓存层；更长期的会话和业务数据则需要由数据库、向量检索或对象存储管理。公开资料中已有将 CPU、DRAM、SSD 与高速网络用于分级缓存的架构探索，但企业应根据数据生命周期、访问频率和一致性要求验证，而不是默认所有记忆都应驻留在 GPU 显存。

显存带宽和互连网络决定分离方案的上限

显存容量决定能否承载上下文

模型权重只是显存占用的一部分。运行时还需要为 KV Cache、激活值、批处理请求和通信缓冲区预留空间。长上下文、高并发和多轮智能体任务叠加时，显存容量不足会导致请求排队、缓存淘汰，甚至转移到更慢的存储层。

企业应至少按以下变量建立容量模型：

• 模型权重精度和分片方式；
• 输入与输出 Token 的长度分布；
• 同时活跃的请求数；
• 每个请求的 KV Cache 大小；
• 是否支持跨请求前缀缓存；
• 是否需要为故障转移保留冗余容量。

显存带宽影响 Decode 的持续速度

Decode 每次只生成少量新 Token，却需要反复读取历史 KV Cache。对于这类负载，峰值计算能力并不等于实际生成速度。显存带宽、访问模式、缓存命中率和动态批处理策略，可能比理论算力更直接地影响 TPOT。

采购测试不应只看厂商提供的峰值 FLOPS，而应同时测：

• 不同上下文长度下的 TPOT；
• 并发增加时的吞吐变化；
• P50、P95 和 P99 延迟；
• 显存占用与缓存淘汰行为；
• 长输出和短输出混合时的稳定性。

网络决定PD分离是否值得

PD 分离的代价主要来自节点间通信。若网络带宽不足、延迟过高或拥塞控制不稳定，Prefill 节点完成计算后，Decode 节点可能仍在等待状态传输，分离带来的收益就会被网络开销抵消。

大型 MoE 模型还可能带来更复杂的专家路由和跨节点通信。AWS 公布的一项案例针对 750B MoE 模型，对比了基于 RoCE 的自建集群与使用 EFA 的云上环境，并采用 Prefill 节点与 Decode 节点物理分离的部署方式。这个案例可以说明网络是架构的一等要素，但其中的硬件、模型和部署规模具有特定性，不能直接作为其他企业的性能承诺。

什么时候适合采用Prefill与Decode分离

企业可以从以下几个信号判断是否值得进入 PD 分离评估：

适合优先评估的情况

• 输入长度和输出长度差异很大，短问答与长文档请求混在一起；
• 智能体需要多次调用工具，单个用户任务会产生连续推理请求；
• TTFT 与 TPOT 都有严格要求，且两者经常互相干扰；
• Prefill 和 Decode 的负载峰值出现时间不同，需要独立扩缩容；
• 模型规模较大，单组 GPU 无法同时满足上下文容量和并发要求；
• 企业已经具备高速互连网络、成熟的容器编排和监控能力；
• 不同模型或不同业务需要使用不同的 Prefill、Decode 资源比例。

不宜急于分离的情况

• 请求短、并发低，单机部署已经满足目标延迟；
• 模型较小，拆分后的网络和调度开销高于收益；
• GPU 之间互连能力有限，跨节点传输会成为主要瓶颈；
• 推理框架尚未稳定支持目标模型或目标硬件；
• 团队缺少端到端监控，无法定位排队、通信和缓存问题；
• 业务更关心最低成本，而不是高并发下的稳定延迟。

“模型越大就越应该分离”并不是充分条件。真正的判断依据是：分离后节省的计算和调度成本，能否覆盖额外的网络、节点、软件与运维成本。

企业采购前的评估清单

1. 先定义真实业务负载

不要只使用平均输入和平均输出长度。应采集至少一段时间的真实请求，形成长度和并发分布，包括：

• 输入 Token、输出 Token 的P50、P95和最大值；
• 并发请求数及其日内波动；
• 工具调用次数和单任务持续时间；
• 长上下文请求占比；
• 流式输出的首 Token 和后续 Token 要求；
• 不同模型、租户和优先级的流量比例。

2. 分别设定Prefill与Decode目标

将“响应时间”拆成两个可验证指标：

• TTFT 是否满足交互体验要求；
• TPOT 是否满足连续输出要求；
• 总完成时间是否满足任务时限；
• 高峰期 P95、P99 是否可接受；
• 节点故障或扩缩容时是否出现明显抖动。

3. 按系统而不是按芯片报价

硬件评估应覆盖：

• GPU 显存容量与带宽；
• GPU 间互连和跨节点网络；
• CPU 核数、内存容量与内存带宽；
• 网卡、RDMA 或其他高速通信能力；
• 本地 SSD 与远端存储的访问延迟；
• 机架功耗、散热和部署密度；
• 备件、故障替换和容量扩展方式。

4. 验证软件适配

需要在目标环境中确认：

• 模型是否被推理框架完整支持；
• Prefill、Decode 分离是否为成熟能力，而非实验功能；
• 是否支持动态批处理、前缀缓存和 KV Cache 管理；
• Router 是否具备负载感知、重试、熔断和健康检查；
• 监控系统能否分别采集 TTFT、TPOT、Token 吞吐和网络等待；
• 升级后模型、驱动、通信库和运行时是否仍能稳定协同。

5. 用端到端Token成本做决策

单位 Token 成本应包含两阶段资源和共享资源：

单位 Token 成本
= GPU资源成本
+ CPU与内存成本
+ 网络与存储成本
+ 软件与运维成本
+ 冗余与故障成本
÷ 有效输入和输出Token数

对于 PD 分离架构，还应分别计算 Prefill 节点和 Decode 节点的利用率。如果其中一类节点长期闲置，独立扩缩容带来的收益可能不如预期；如果两类节点的峰值错开，则分离更可能产生资源复用价值。

建议采用渐进式验证路径

第一步，使用真实业务流量建立非分离基线，记录 TTFT、TPOT、吞吐、显存占用、CPU 利用率和网络流量。

第二步，在相同模型、相同精度、相同输入输出分布下，部署小规模 PD 分离环境。不要只比较峰值吞吐，还要观察跨节点传输、排队和故障恢复。

第三步，分别改变输入长度、输出长度、并发数和缓存命中率，绘制性能拐点。某种架构可能在短请求下没有优势，却在长上下文或高并发下明显改善。

第四步，加入智能体真实流程，包括检索、工具调用、重试和多轮记忆。只有端到端测试，才能发现 CPU 调度、路由和状态传输对总体延迟的影响。

第五步，计算三种方案的总拥有成本：单机或单池部署、非分离多节点部署、Prefill 与 Decode 分离部署。最终选择应由业务目标和成本边界决定，而不是由架构名称决定。

结论：先判断负载，再决定是否分离

智能体基础设施的变化，本质上是推理负载结构的变化。长输入提高了 Prefill 压力，连续生成放大了 Decode 对显存带宽和调度稳定性的要求，多轮工具调用又增加了 CPU、网络和长期状态管理的复杂度。

Prefill与Decode分离提供了一种有价值的系统化方法：让不同阶段使用更匹配的资源，并支持按阶段扩缩容。但它同时引入了网络通信、路由、缓存、故障恢复和运维成本。企业真正需要评估的不是“是否采用某种热门架构”，而是当前模型类型、并发量、Token分布、延迟目标和软件成熟度，是否足以覆盖分离部署的额外复杂性。

当 TTFT 与 TPOT 已经相互干扰、Prefill 和 Decode 的负载峰值明显错开，并且企业具备高速网络与成熟推理软件栈时，分离式推理值得进入正式采购和压测流程。否则，先优化单池部署、缓存策略和调度系统，往往是更稳妥的路径。