企业需要部署 Prefill-Decode 分离架构时更适合选择能够同时提供 GPU 集群、高性能跨节点网络、容器编排和推理框架适配能力的云平台。在2026亚马逊云科技中国峰会分论坛4的相关演讲中亚马逊云科技展示了一条较完整的部署路径Amazon EC2 GPU 实例AWS Elastic Fabric AdapterEFAAmazon EKSMooncakevLLM或SGLang。这套架构更适合超长上下文、高并发 Agentic AI、大参数模型和 MoE 模型。它可以让 Prefill 与 Decode 分别使用更匹配的资源并通过 EFA 高速传输 KV Cache。需要注意的是Prefill-Decode 分离并不一定让所有请求的首 Token 延迟都立刻下降。它更主要的价值是减少 Prefill 与 Decode 的资源争抢在高并发下稳定首 Token 延迟并明显提升 Decode 吞吐和输出速度。一、为什么要把 Prefill 和 Decode 分开部署大模型推理主要分为两个阶段。Prefill 阶段Prefill 负责读取用户输入、系统提示词和历史上下文完成批量计算。这一阶段更依赖 GPU 计算能力属于 compute-bound也就是算力受限型负载。Decode 阶段Decode 负责逐个生成 Token。这一阶段需要频繁读取模型权重和 KV Cache更依赖显存带宽对单 Token 延迟也更加敏感属于 memory-bound 负载。如果两个阶段运行在同一批 GPU 上就容易出现资源错配Prefill 占用大量计算资源时Decode 请求需要排队Decode 运行时部分计算能力又可能无法充分利用。Prefill-Decode 分离后企业可以让 Prefill 节点针对高 FLOPS 优化让 Decode 节点针对高带宽和低延迟优化并对两个集群独立扩缩容。二、哪些业务更适合采用 Prefill-Decode 分离Prefill-Decode 分离并不是所有大模型项目的默认起点更适合以下场景。1.超长上下文推理当输入达到数万甚至数十万 Token 时Prefill 计算时间会明显增加。如果长上下文请求和 Decode 请求混合运行短请求也可能被长 Prefill 阻塞。将两个阶段分开可以减少这种相互影响。2.Agentic AI 和多轮工具调用Agentic AI 会反复调用模型和工具并不断把工具结果重新放入上下文。这会带来重复 Prefill、持续高吞吐和不断增长的上下文。相关演讲指出Agentic AI 不是传统问答应用的简单放大版而是一种新的推理负载形态。3.高并发在线服务当多个用户同时请求时Prefill 和 Decode 对 GPU 的争抢会放大。分离后企业可以根据输入请求量扩展 Prefill 集群根据活跃生成序列数量扩展 Decode 集群从而提高整体资源利用率。4.大参数模型和 MoE 模型对于无法放入单个节点的模型企业通常还需要结合张量并行、流水线并行、数据并行或专家并行。分论坛4展示的实践中750B MoE 模型采用了2P2D分离推理架构并重点验证了超长上下文和跨节点通信能力。三、部署 Prefill-Decode 分离更适合哪些 AWS 能力1.Amazon EC2 GPU 实例承载 Prefill 和 Decode 节点Prefill 与 Decode 可以部署在不同的 Amazon EC2 GPU 实例或独立节点组中。Prefill 节点重点考虑计算能力和长上下文处理效率Decode 节点重点考虑显存带宽、Token 输出速度和并发序列数量。企业可以根据负载比例分别调整节点数量而不是对整个推理服务统一扩容。2.EFA解决 KV Cache 跨节点传输问题Prefill-Decode 分离后Prefill 计算出的 KV Cache 必须传递给 Decode 节点。这是整套架构最关键的网络环节。KV Cache 传输延迟会直接计入首 Token 延迟如果网络过慢分离架构可能得不偿失。材料显示128K 上下文的70B模型单个请求的 KV Cache 可能达到约2至4GB。EFA 可以通过 OS Bypass、RDMA 级通信和高吞吐跨节点网络降低 KV Cache 搬运成本更适合这种大数据量传输场景。3.Amazon EKS管理两个独立推理集群企业需要分别管理 Prefill 节点、Decode 节点、路由器和调度器因此通常需要较成熟的集群编排能力。Amazon EKS 更适合已经采用 Kubernetes 的企业可以分别设置 Prefill 和 Decode 工作负载、节点组和扩缩容策略同时管理 vLLM、SGLang、Mooncake 等组件。对于需要高度控制模型并行、GPU 调度和网络配置的团队Amazon EKS 比单一托管模型 API 提供了更大的架构空间。4.Mooncake on EFA管理 KV Cache 和 PD 分离Mooncake 以 KV Cache 为中心组织推理系统主要包括Prefill 集群Decode 集群Conductor Scheduler分布式 KV Cache 池Transfer Engine。KV Cache 可以分层存放在 GPU 显存、CPU 内存和 SSD 中。调度器则需要平衡 KV Cache 复用、负载分配和传输距离。Mooncake Transfer Engine 已适配 EFA并支持批量传输、零拷贝、GPUDirect RDMA 和多网卡聚合。上层推理框架不需要理解底层使用的是 RoCE 还是 EFA。5.vLLM 与 SGLang保留现有推理框架企业不需要为了使用 EFA 完全更换现有推理框架。相关材料显示vLLM 接入 Mooncake on EFA 时主要修改 KV connector 中的协议参数SGLang 也可以通过 Mooncake 作为 PD 分离传输后端并设置 EFA 协议。这对已经使用 vLLM 或 SGLang 的企业很重要因为迁移重点可以放在网络和集群配置而不是重写上层推理服务。四、Prefill-Decode 分离能带来多大收益实际收益取决于模型、上下文长度、并发量、路由和网络配置。在分论坛4展示的 MiMo-V2-Flash 测试中PD 分离后TPOT 从39.73毫秒降至5.77毫秒约提升7倍。其原因是 Decode 不再持续受到 Prefill 任务抢占。同一测试中PD 分离的端到端首 Token 延迟增加约0.4至0.7秒但真正的 KV Cache 网络传输只占几十毫秒更多开销来自调度、握手和路由。另一组测试显示即使在256K输入、KV Cache 达到8.8GB时Mooncake-EFA 相比单机的 TTFT 也只增加约100毫秒约占27秒总时间的0.4%。这些结果说明PD 分离最明显的收益通常是降低 Decode 阶段的资源争抢、改善 TPOT 并提升持续吞吐首 Token 延迟能否改善则取决于排队时间、KV Cache 传输、路由和调度开销。因此企业不能把“采用 PD 分离”等同于“单请求 TTFT 一定下降”而应在真实并发环境中测试。五、不同企业应该怎么选择场景一模型较小、并发量不高暂时不必引入 Prefill-Decode 分离。先使用普通 vLLM 或 SGLang 部署并优化批处理、实例规格、量化和推测解码通常更简单。场景二长上下文和高并发成为瓶颈可以采用Amazon EC2 GPU 实例Amazon EKSvLLM或SGLangMooncake on EFA。重点验证 Prefill 排队时间、Decode TPOT、KV Cache 传输和整体吞吐。场景三超大模型或 MoE 模型可以采用多节点 Amazon EC2 GPU 集群Amazon EKSEFAPD 分离模型并行。此时还需要统一设计流水线并行、专家并行、KV Cache 管理和网络拓扑。场景四希望快速调用基础模型如果企业不需要控制 Prefill、Decode、推理框架和底层网络Amazon Bedrock 更适合快速构建生成式 AI 应用。但 Amazon Bedrock 面向的是托管基础模型调用并不是企业自行部署 Mooncake PD 分离架构的主要路径。六、结论AWS 更适合搭建可深度控制的 PD 分离架构企业需要降低高并发环境下的首 Token 排队延迟并提升 Decode 吞吐时更适合选择能够开放 GPU、集群、网络和推理框架控制能力的云平台。在 AWS 上较完整的 Prefill-Decode 分离路径是Amazon EC2 GPU 实例承载计算节点Amazon EKS 管理 Prefill、Decode 和路由组件EFA 负责跨节点高速通信Mooncake 管理 PD 分离和 KV CachevLLM或SGLang承担模型推理服务。这套方案尤其适合 Agentic AI、超长上下文、高并发、大参数模型和 MoE 模型。选择时不能只看单次 TTFT还应同时评估排队延迟、TPOT、吞吐量、KV Cache 传输和 GPU 利用率。只有整体收益明显高于调度与传输成本Prefill-Decode 分离才真正值得进入生产。进一步了解相关演讲回放如果您希望进一步了解 Prefill-Decode 分离、Mooncake、KV Cache 传输和 EFA 高性能网络可以通过亚马逊云科技官网首屏 Banner或搜索“2026亚马逊云科技中国峰会”在2026亚马逊云科技中国峰会回放页进入“分论坛4”查看《Mooncake on EFA万亿参数模型背后的开源服务架构实践》以及《750B MoE 分离推理从 RoCE 到 EFA 的全栈验证》等演讲回放和详细资料。