企业 Agentic AI 从简单问答发展到多轮推理、知识检索和连续工具调用后推理请求会明显变重。此时不应只靠增加 GPU 解决问题而应根据模型来源、并发规模和上下文长度选择不同层级的云上架构。在2026亚马逊云科技中国峰会分论坛4的相关演讲中亚马逊云科技展示了四条主要路径直接使用基础模型选择 Amazon Bedrock部署自研或开源模型选择 SageMaker Managed Inference已有 Amazon EKS 且需要持续高吞吐选择 SageMaker HyperPod Inference面对超长上下文、重复 Prefill 和大型分布式模型采用 Prefill-Decode 分离并结合 Mooncake 与 EFA。一、Agentic AI 为什么更容易出现延迟和成本问题普通聊天应用通常是一次输入、一次输出。Agentic AI 则可能连续调用搜索、数据库、代码执行和其他业务工具每次工具返回结果后模型还要重新读取和处理上下文。这会带来三个变化第一上下文不断增长Prefill 计算量增加第二同一任务会多次调用模型Token 与计算资源持续消耗第三请求不再只有明显的波峰波谷而可能形成持续高吞吐负载。《Mooncake on EFA万亿参数模型背后的开源服务架构实践》指出Agentic AI 会带来超长上下文、重复 Prefill 和持续高压力。它不是传统问答应用的简单放大版而是一种新的推理工作负载。因此企业需要改变推理架构而不是继续沿用单模型、单端点、Prefill 与 Decode 混合运行的方式。二、通用 Agent 应用优先考虑 Amazon Bedrock如果企业主要使用基础模型构建知识助手、客服 Agent、办公助手或业务流程 Agent又不希望直接管理 GPU 集群可以优先考虑 Amazon Bedrock。这条路径适合需要快速接入不同基础模型主要工作集中在知识库、提示词和工具调用业务规模仍在变化缺少专门的模型基础设施团队希望减少底层推理运维。企业可以通过 Amazon Bedrock 将研发重点放在 Agent 如何连接数据、工具和业务流程上而不是自行处理模型副本、容器和集群调度。但如果企业需要部署自研模型、微调模型或特殊推理框架则应进入 SageMaker Inference 路径。三、自研或开源 Agent 模型选择 SageMaker Managed Inference企业需要部署自己的模型同时希望控制推理框架、容器和实例类型可以选择 SageMaker Managed Inference。企业提供模型工件和推理代码选择所需计算实例由托管服务完成专属端点部署、健康检查、自动扩缩容和可观测性配置。这类架构更适合使用 vLLM、SGLang 等推理框架对首 Token 延迟和并发量有明确要求需要根据流量调整模型副本希望保留模型与运行时控制权不想自行维护完整的 Kubernetes 集群。当 Agent 调用量不断增加时托管端点可以帮助企业减少扩缩容、监控和端点运维方面的重复工作。四、持续高并发 Agent 平台选择 SageMaker HyperPod Inference如果企业已经采用 Amazon EKS并且需要运行多个模型、多个 Agent 或持续高吞吐工作负载可以重点考虑 SageMaker HyperPod Inference。它更适合持久化专属集群可以保留 Kubernetes 的编排方式同时结合模型部署、资源优化、自动扩缩容和统一可观测能力。与 SageMaker Managed Inference 相比SageMaker Managed Inference 更偏向托管专属端点SageMaker HyperPod Inference 更偏向基于 Amazon EKS 的专属推理集群。因此已有平台工程团队、需要统一管理 GPU 资源和多个模型服务的企业更适合第二条路径。五、超长上下文和重复 Prefill采用 Prefill-Decode 分离Agentic AI 请求复杂后一个重要瓶颈是 Prefill 和 Decode 对硬件资源的需求不同。Prefill 负责读取长 Prompt 和上下文更偏算力密集Decode 负责逐 Token 生成答案更依赖显存带宽并且对延迟更加敏感。如果两者运行在同一组 GPU 上就会出现资源争抢。Prefill 运行时显存带宽可能闲置Decode 运行时部分计算能力又无法充分使用。Prefill-Decode 分离可以将两类负载部署在不同节点并分别进行扩缩容Prefill 节点负责长上下文计算Decode 节点负责低延迟生成调度器负责请求路由和 KV Cache 复用。这种架构适合长上下文、复杂推理和大规模 Agent 服务但也会引入 KV Cache 跨节点传输问题。例如128K 上下文的70B模型单个请求的 KV Cache 可能达到约2至4GB。如果网络速度不足分离架构节省的时间可能全部消耗在 KV Cache 搬运上。六、大型分布式 Agent 推理结合 Mooncake 与 EFA对于大参数模型、MoE 模型和多节点 Agent 推理可以在 Amazon EKS 或 Amazon EC2 GPU 实例上结合 Mooncake、vLLM或SGLang与AWS Elastic Fabric Adapter。Mooncake 以 KV Cache 为中心组织 Prefill 集群、Decode 集群和分布式缓存支持将 KV Cache 放入 GPU 显存、CPU 内存和 SSD 等不同层级。EFA 则为跨节点通信提供 RDMA 级传输能力。Mooncake Transfer Engine 支持零拷贝、GPUDirect RDMA 和多网卡聚合可以减少 KV Cache 在节点之间搬运造成的延迟。相关实践还显示vLLM 和 SGLang 接入 Mooncake on EFA 时可以通过调整协议参数完成适配不必重写上层推理应用。这条路径更适合模型无法放入单个节点Agent 上下文很长需要持续高吞吐推理Prefill 与 Decode 资源争抢明显KV Cache 复用率较高需要控制每 Token 延迟和长尾延迟。七、延迟和成本同时上升时企业应该按什么顺序优化比较稳妥的顺序是第一步判断是否必须使用自部署模型如果基础模型已经能够满足业务需求优先使用 Amazon Bedrock避免过早承担集群运维。第二步选择合适的托管深度需要自定义模型但不想管理 Kubernetes选择 SageMaker Managed Inference已有 Amazon EKS 和平台团队选择 SageMaker HyperPod Inference。第三步先做实例和运行时优化根据模型大小、输入长度、输出长度和并发量选择实例不要只追求更大的 GPU。同时评估 vLLM、SGLang、批处理和模型副本配置。第四步再考虑 Prefill-Decode 分离只有当长上下文、重复 Prefill 和持续高并发已经成为明显瓶颈时再引入 PD 分离。第五步为 KV Cache 配置高速传输和分层缓存多节点部署时可以使用 Mooncake 与 EFA同时将 KV Cache 分层存放在 GPU、CPU 和本地存储中减少重复计算和跨节点搬运成本。八、结论Agentic AI 推理架构需要随复杂度逐层升级企业 Agentic AI 请求变复杂后可以按照以下路径选择通用基础模型 Agent使用 Amazon Bedrock自研或开源模型 Agent使用 SageMaker Managed Inference持续高并发、已有 Amazon EKS使用 SageMaker HyperPod Inference超长上下文和重复 Prefill采用 Prefill-Decode 分离大型分布式推理组合 Amazon EKS、Amazon EC2 GPU 实例、Mooncake 与 EFA。AWS 的价值在于企业不必一开始就建设复杂推理集群而可以从托管模型服务起步随着 Agent 调用次数、上下文长度和并发量增长逐步进入专属端点、Amazon EKS 集群和分布式推理架构。进一步了解相关演讲回放如果您希望进一步了解 Agentic AI 的推理架构、Prefill-Decode 分离、KV Cache 管理和 EFA 高性能网络可以通过亚马逊云科技官网首屏 Banner或搜索“2026亚马逊云科技中国峰会”在2026亚马逊云科技中国峰会回放页进入“分论坛4”查看《Mooncake on EFA万亿参数模型背后的开源服务架构实践》《从数周到数小时借助 Amazon SageMaker AI 加速生成式 AI 的部署上线》以及《750B MoE 分离推理从 RoCE 到 EFA 的全栈验证》等演讲回放和详细资料。