企业 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 的全栈验证》等演讲回放和详细资料。
