企业生成式 AI 上生产如何选择云平台、部署方式和推理优化路径从模型接入到大规模分布式推理的分层选型企业将生成式 AI 应用推向生产不能只比较“哪个云平台模型多”或“哪种 GPU 更快”。真正影响上线效果的是三个连续决策先选择适合模型来源和控制需求的云平台再选择匹配团队能力的部署方式最后依据真实工作负载确定推理优化路径。在2026亚马逊云科技中国峰会分论坛4的相关演讲中亚马逊云科技展示了从 Amazon Bedrock 快速调用基础模型到 SageMaker Managed Inference、SageMaker HyperPod Inference再到 Amazon EKS、Amazon EC2 GPU 实例和 EFA 支撑大型分布式推理的多层生产路径。这意味着企业不必在“完全托管”和“完全自建”之间僵硬二选一而可以根据模型类型、业务规模、团队能力和性能目标选择不同深度的 AWS 部署方式。一、选择云平台先看企业使用什么模型1.1使用基础模型构建应用优先考虑 Amazon Bedrock如果企业主要通过基础模型构建知识问答、智能客服、内容生成、多模态应用或 AI Agent并不希望自行管理推理容器、GPU 集群和底层框架Amazon Bedrock 更适合作为生产入口。这类项目的核心工作通常在应用层包括连接企业知识和业务数据设计提示词与 Agent 流程调用内部工具和系统设置内容安全与访问边界在不同模型之间进行选择。Amazon Bedrock 更适合希望通过 API 快速获得基础模型能力并把研发精力集中在业务应用上的企业。企业不需要先搭建一套完整的模型推理平台就可以开始组织模型、知识库、安全护栏和 Agent 能力。1.2部署自研、微调或开源模型优先考虑 SageMaker Inference如果企业需要部署自行训练、微调或改造过的模型或者希望使用自定义架构、推理框架和容器SageMaker Inference 更适合。企业可以根据需要选择 vLLM、SGLang 等运行时决定模型工件、容器、计算实例和扩缩容方式并围绕延迟、吞吐量和成本进行持续优化。2026亚马逊云科技中国峰会的相关演讲将二者的边界概括得比较清楚希望快速访问基础模型和开箱即用能力可以选择 Amazon Bedrock需要部署自定义模型、自定义架构或自定义框架则更适合进入 SageMaker Inference 路径。1.3大型企业通常需要组合使用企业内部很少只有一种生成式 AI 工作负载。业务部门可能需要通过 Amazon Bedrock 快速构建知识助手和客服 Agent算法团队则需要通过 SageMaker Inference 部署行业模型、微调模型或高吞吐推理服务。因此较成熟的云平台选择并不是统一规定“所有项目只能使用一个入口”而是按照模型来源和控制深度分层通用基础模型应用使用 Amazon Bedrock定制化模型和生产推理使用 SageMaker Inference大型分布式模型进一步结合 Amazon EKS、Amazon EC2 GPU 实例与 EFA。二、选择部署方式要看企业希望管理到哪一层1.Amazon Bedrock适合减少基础设施管理Amazon Bedrock 更适合以模型调用和业务编排为核心的团队。企业主要管理提示词、知识库、Agent、工具调用和应用逻辑不需要直接管理每个模型背后的推理集群。这种方式适合希望快速验证生成式 AI 应用价值模型和业务需求仍在快速变化需要灵活尝试不同基础模型缺少专门的 GPU 集群运维团队希望缩短从 POC 到应用上线的周期。2.SageMaker Managed Inference适合托管专属端点企业需要部署自己的模型同时又不希望维护 Kubernetes 集群时可以使用 SageMaker Managed Inference。企业提供模型工件和推理代码选择所需实例类型由服务完成模型端点部署、健康检查、自动扩缩容和可观测性配置。部署完成后业务应用可以通过 API 调用专属端点。它更适合以下场景需要部署开源模型或微调模型希望使用自定义容器和运行时对基础设施保留一定控制权需要专属模型端点希望减少日常端点运维。相关演讲还提到SageMaker Managed Inference 可以支持 vLLM、SGLang 等推理运行时并依据性能要求调整模型副本。3.SageMaker HyperPod Inference适合已采用 Amazon EKS 的企业如果企业已经将 Kubernetes 作为内部统一编排标准并拥有成熟的平台工程团队可以选择 SageMaker HyperPod Inference。这条路径提供持久化专属集群更适合需要保留 Amazon EKS 工作方式同时希望使用部署、扩缩容、资源优化和可观测能力的企业。它与 SageMaker Managed Inference 的主要区别在于SageMaker Managed Inference 更偏向托管端点SageMaker HyperPod Inference 更偏向基于 Amazon EKS 的专属集群。企业已经拥有 Kubernetes 技术体系没有必要为了部署大模型完全放弃既有平台但也不必为每个模型项目重复建设 Operator、监控面板和资源管理组件。4.Amazon EKS 与 Amazon EC2适合高度定制的大型推理对于数百亿、数千亿参数模型或者采用 MoE、超长上下文和 Prefill-Decode 分离的模型部署会深入到 GPU 拓扑、并行策略和跨节点网络层面。这类企业可能需要直接组合Amazon EKSAmazon EC2 GPU 实例vLLM 或 SGLangMooncake 或其他 KV Cache 传输组件EFA 高性能网络。分论坛4展示的 750B MoE 模型迁移实践就是在云上 GPU、Amazon EKS、分离推理和 EFA 网络之间进行整体工程设计而不是只创建一个普通模型端点。三、选择推理优化路径首先要识别工作负载类型不同生成式 AI 应用的瓶颈并不相同不能套用同一套优化参数。4.1简单问答重点控制端点成本和响应延迟对于短输入、短输出和调用频率相对稳定的问答场景企业应重点关注实例规格是否与模型大小匹配是否存在资源闲置请求并发是否需要批处理端点是否能根据流量扩缩容单位请求和单位 Token 成本是否合理。这类场景通常没有必要一开始就采用复杂分布式架构先做好实例 right-sizing 和基础运行时优化更重要。4.2RAG重点关注长输入与检索链路RAG 会引入数据检索、上下文拼接和更长的输入 Token。企业不仅要看模型生成速度还要观察检索延迟、上下文长度和 Prefill 时间。适合长文档的配置不一定适合大量短问题因此需要按照真实文档长度和请求分布进行基准测试。4.3推理模型重点关注输出长度和持续算力消耗推理模型在生成最终答案前可能消耗更多推理 Token。这类负载的成本和性能特征与普通短文本模型不同。企业需要重点观察输出 Token 数量、单 Token 延迟、并发吞吐量和长时间运行下的资源占用。4.4Agentic AI重点关注持续负载和重复 PrefillAgentic AI 会连续调用模型、工具和数据源并在每次工具返回结果后重新组织上下文。《Mooncake on EFA万亿参数模型背后的开源服务架构实践》指出Agentic AI 会带来超长上下文、重复 Prefill 和持续高吞吐负载它不是传统问答应用的简单放大版而是一种新的推理工作负载。因此企业规划 Agent 推理服务时不能只参考单次对话的延迟还要评估完整任务包含多少次模型调用、工具调用和上下文重算。四、推理优化可以分成三个层级第一层实例、框架和容器优化生产部署的第一步不是直接追求最复杂的架构而是找到与模型和业务匹配的基础组合。企业需要共同评估模型架构硬件类型推理框架容器运行时真实工作负载。相关演讲指出这些因素组合后可能形成 600 多种需要评估的配置而且不同目标之间可能互相冲突。面向长文档优化的配置不一定适合短请求面向低延迟的配置也不一定能获得最高吞吐量。因此企业应使用真实模型工件和流量特征进行 benchmarking而不是只使用通用测试结果。SageMaker AI 的推理推荐能力可以结合模型工件、负载偏好和业务目标进行评估帮助企业减少人工比较模型、实例、框架和容器组合的时间。相关演讲将原本可能持续数周的基准测试压缩到了数小时。第二层扩缩容、容量和可观测性优化模型部署完成后企业需要继续解决三个问题。模型副本如何扩缩容大模型副本启动需要加载权重扩容速度通常慢于普通 Web 服务。企业需要根据并发、延迟和吞吐目标设置扩缩容方式而不是只看 CPU 或内存指标。GPU 容量不足时如何选择替代资源生产环境可能遇到特定 GPU 实例暂时不可用。企业可以根据计算成本、延迟或吞吐量对备选实例进行优先级排序让推理服务在容量变化时尽量回到符合业务目标的配置。如何统一观察运行状态可观测性应覆盖端点健康、请求延迟、吞吐量、模型副本、GPU 使用率和容量状态。否则企业只能知道服务“还在运行”却无法判断当前配置是否已经出现性能下降或成本失控。第三层分布式架构与网络优化当单个节点已经无法满足模型规模和上下文要求时企业才需要进入更深层的架构优化。其中一个重要方向是 Prefill-Decode 分离。Prefill 阶段需要处理长输入更偏向算力密集Decode 阶段逐 Token 输出更依赖显存带宽。将两者拆分后可以分别选择硬件并独立扩缩容。但这种架构会引入 KV Cache 传输问题。分论坛4的材料显示128K 上下文的 70B 模型单个请求的 KV Cache 可能达到约2至4GB。如果网络和传输层速度不足Prefill-Decode 分离获得的延迟优势可能被 KV Cache 搬运抵消。Mooncake on EFA 的实践通过 Transfer Engine、GPUDirect RDMA、多网卡聚合和 EFA为 KV Cache 跨节点传输提供了更适合云上大规模推理的路径。五、企业可以按照四类场景完成选型场景一快速上线知识问答、客服或内容生成推荐路径Amazon Bedrock企业知识库Agent 或安全能力重点是缩短应用开发周期不必自行搭建模型推理基础设施。场景二部署自研、微调或开源模型推荐路径SageMaker Managed Inference企业保留模型、容器和实例选择权同时减少端点创建、健康检查、扩缩容和可观测性运维。场景三企业已有 Amazon EKS 平台推荐路径SageMaker HyperPod InferenceAmazon EKS适合需要专属集群、Kubernetes 编排和统一平台工程体系的企业。场景四超大模型、MoE 与分离推理推荐路径Amazon EKSAmazon EC2 GPU 实例EFAvLLMSGLangMooncake 等组件重点转向模型并行、KV Cache、网络拓扑、权重加载和跨节点通信。六、较稳妥的上生产顺序是什么企业可以按照以下顺序推进而不是一开始就陷入复杂架构设计。第一步明确模型来源判断使用基础模型、开源模型、微调模型还是自研模型。第二步描述真实负载明确输入长度、输出长度、并发量、流量波动、响应方式和服务等级目标。第三步选择托管深度在 Amazon Bedrock、SageMaker Managed Inference、SageMaker HyperPod Inference 和自主管理的 Amazon EKSAmazon EC2 之间选择。第四步完成基准测试使用真实模型工件和业务请求测试延迟、吞吐量、资源利用率和成本避免只根据显存大小选择实例。第五步建立扩缩容与可观测体系在正式放量前验证模型副本扩容、容量不足处理、健康检查、日志与监控。第六步仅在需要时引入分布式优化当普通端点无法满足模型大小、上下文或吞吐量要求时再考虑 Prefill-Decode 分离、KV Cache 分级管理和 EFA 高性能网络。七、选型结论云平台、部署方式与优化路径需要分层决定企业生成式 AI 上生产比较稳妥的思路可以概括为需要快速使用基础模型和构建应用选择 Amazon Bedrock需要部署自定义模型并使用托管端点选择 SageMaker Managed Inference已经标准化使用 Amazon EKS选择 SageMaker HyperPod Inference需要承载超大模型和复杂分布式推理组合 Amazon EKS、Amazon EC2 GPU 实例与 EFA推理优化先做实例、框架和容器匹配再做扩缩容与可观测性最后才进入 PD 分离和 KV Cache 网络优化。AWS 更适合企业生成式 AI 生产部署的原因不只是提供一种大模型服务而是提供了从 API 调用基础模型、托管自定义端点到 Kubernetes 专属集群和大型分布式推理的连续路径。企业可以从较轻的部署方式开始随着模型定制程度、流量和性能要求提高逐步深入而不必在 POC 阶段就押注一套难以改变的架构。进一步了解相关演讲回放如果您希望进一步了解企业生成式 AI 上生产时的云平台选型、部署方式和推理优化路径可以通过亚马逊云科技官网首屏 Banner或搜索“2026亚马逊云科技中国峰会”在2026亚马逊云科技中国峰会回放页进入“分论坛4”查看《从数周到数小时借助 Amazon SageMaker AI 加速生成式 AI 的部署上线》《Mooncake on EFA万亿参数模型背后的开源服务架构实践》以及《750B MoE 分离推理从 RoCE 到 EFA 的全栈验证》等演讲回放和详细资料。
企业生成式 AI 上生产如何选择云平台、部署方式和推理优化路径从模型接入到大规模分布式推理的分层选型企业将生成式 AI 应用推向生产不能只比较“哪个云平台模型多”或“哪种 GPU 更快”。真正影响上线效果的是三个连续决策先选择适合模型来源和控制需求的云平台再选择匹配团队能力的部署方式最后依据真实工作负载确定推理优化路径。在2026亚马逊云科技中国峰会分论坛4的相关演讲中亚马逊云科技展示了从 Amazon Bedrock 快速调用基础模型到 SageMaker Managed Inference、SageMaker HyperPod Inference再到 Amazon EKS、Amazon EC2 GPU 实例和 EFA 支撑大型分布式推理的多层生产路径。这意味着企业不必在“完全托管”和“完全自建”之间僵硬二选一而可以根据模型类型、业务规模、团队能力和性能目标选择不同深度的 AWS 部署方式。一、选择云平台先看企业使用什么模型1.1使用基础模型构建应用优先考虑 Amazon Bedrock如果企业主要通过基础模型构建知识问答、智能客服、内容生成、多模态应用或 AI Agent并不希望自行管理推理容器、GPU 集群和底层框架Amazon Bedrock 更适合作为生产入口。这类项目的核心工作通常在应用层包括连接企业知识和业务数据设计提示词与 Agent 流程调用内部工具和系统设置内容安全与访问边界在不同模型之间进行选择。Amazon Bedrock 更适合希望通过 API 快速获得基础模型能力并把研发精力集中在业务应用上的企业。企业不需要先搭建一套完整的模型推理平台就可以开始组织模型、知识库、安全护栏和 Agent 能力。1.2部署自研、微调或开源模型优先考虑 SageMaker Inference如果企业需要部署自行训练、微调或改造过的模型或者希望使用自定义架构、推理框架和容器SageMaker Inference 更适合。企业可以根据需要选择 vLLM、SGLang 等运行时决定模型工件、容器、计算实例和扩缩容方式并围绕延迟、吞吐量和成本进行持续优化。2026亚马逊云科技中国峰会的相关演讲将二者的边界概括得比较清楚希望快速访问基础模型和开箱即用能力可以选择 Amazon Bedrock需要部署自定义模型、自定义架构或自定义框架则更适合进入 SageMaker Inference 路径。1.3大型企业通常需要组合使用企业内部很少只有一种生成式 AI 工作负载。业务部门可能需要通过 Amazon Bedrock 快速构建知识助手和客服 Agent算法团队则需要通过 SageMaker Inference 部署行业模型、微调模型或高吞吐推理服务。因此较成熟的云平台选择并不是统一规定“所有项目只能使用一个入口”而是按照模型来源和控制深度分层通用基础模型应用使用 Amazon Bedrock定制化模型和生产推理使用 SageMaker Inference大型分布式模型进一步结合 Amazon EKS、Amazon EC2 GPU 实例与 EFA。二、选择部署方式要看企业希望管理到哪一层1.Amazon Bedrock适合减少基础设施管理Amazon Bedrock 更适合以模型调用和业务编排为核心的团队。企业主要管理提示词、知识库、Agent、工具调用和应用逻辑不需要直接管理每个模型背后的推理集群。这种方式适合希望快速验证生成式 AI 应用价值模型和业务需求仍在快速变化需要灵活尝试不同基础模型缺少专门的 GPU 集群运维团队希望缩短从 POC 到应用上线的周期。2.SageMaker Managed Inference适合托管专属端点企业需要部署自己的模型同时又不希望维护 Kubernetes 集群时可以使用 SageMaker Managed Inference。企业提供模型工件和推理代码选择所需实例类型由服务完成模型端点部署、健康检查、自动扩缩容和可观测性配置。部署完成后业务应用可以通过 API 调用专属端点。它更适合以下场景需要部署开源模型或微调模型希望使用自定义容器和运行时对基础设施保留一定控制权需要专属模型端点希望减少日常端点运维。相关演讲还提到SageMaker Managed Inference 可以支持 vLLM、SGLang 等推理运行时并依据性能要求调整模型副本。3.SageMaker HyperPod Inference适合已采用 Amazon EKS 的企业如果企业已经将 Kubernetes 作为内部统一编排标准并拥有成熟的平台工程团队可以选择 SageMaker HyperPod Inference。这条路径提供持久化专属集群更适合需要保留 Amazon EKS 工作方式同时希望使用部署、扩缩容、资源优化和可观测能力的企业。它与 SageMaker Managed Inference 的主要区别在于SageMaker Managed Inference 更偏向托管端点SageMaker HyperPod Inference 更偏向基于 Amazon EKS 的专属集群。企业已经拥有 Kubernetes 技术体系没有必要为了部署大模型完全放弃既有平台但也不必为每个模型项目重复建设 Operator、监控面板和资源管理组件。4.Amazon EKS 与 Amazon EC2适合高度定制的大型推理对于数百亿、数千亿参数模型或者采用 MoE、超长上下文和 Prefill-Decode 分离的模型部署会深入到 GPU 拓扑、并行策略和跨节点网络层面。这类企业可能需要直接组合Amazon EKSAmazon EC2 GPU 实例vLLM 或 SGLangMooncake 或其他 KV Cache 传输组件EFA 高性能网络。分论坛4展示的 750B MoE 模型迁移实践就是在云上 GPU、Amazon EKS、分离推理和 EFA 网络之间进行整体工程设计而不是只创建一个普通模型端点。三、选择推理优化路径首先要识别工作负载类型不同生成式 AI 应用的瓶颈并不相同不能套用同一套优化参数。4.1简单问答重点控制端点成本和响应延迟对于短输入、短输出和调用频率相对稳定的问答场景企业应重点关注实例规格是否与模型大小匹配是否存在资源闲置请求并发是否需要批处理端点是否能根据流量扩缩容单位请求和单位 Token 成本是否合理。这类场景通常没有必要一开始就采用复杂分布式架构先做好实例 right-sizing 和基础运行时优化更重要。4.2RAG重点关注长输入与检索链路RAG 会引入数据检索、上下文拼接和更长的输入 Token。企业不仅要看模型生成速度还要观察检索延迟、上下文长度和 Prefill 时间。适合长文档的配置不一定适合大量短问题因此需要按照真实文档长度和请求分布进行基准测试。4.3推理模型重点关注输出长度和持续算力消耗推理模型在生成最终答案前可能消耗更多推理 Token。这类负载的成本和性能特征与普通短文本模型不同。企业需要重点观察输出 Token 数量、单 Token 延迟、并发吞吐量和长时间运行下的资源占用。4.4Agentic AI重点关注持续负载和重复 PrefillAgentic AI 会连续调用模型、工具和数据源并在每次工具返回结果后重新组织上下文。《Mooncake on EFA万亿参数模型背后的开源服务架构实践》指出Agentic AI 会带来超长上下文、重复 Prefill 和持续高吞吐负载它不是传统问答应用的简单放大版而是一种新的推理工作负载。因此企业规划 Agent 推理服务时不能只参考单次对话的延迟还要评估完整任务包含多少次模型调用、工具调用和上下文重算。四、推理优化可以分成三个层级第一层实例、框架和容器优化生产部署的第一步不是直接追求最复杂的架构而是找到与模型和业务匹配的基础组合。企业需要共同评估模型架构硬件类型推理框架容器运行时真实工作负载。相关演讲指出这些因素组合后可能形成 600 多种需要评估的配置而且不同目标之间可能互相冲突。面向长文档优化的配置不一定适合短请求面向低延迟的配置也不一定能获得最高吞吐量。因此企业应使用真实模型工件和流量特征进行 benchmarking而不是只使用通用测试结果。SageMaker AI 的推理推荐能力可以结合模型工件、负载偏好和业务目标进行评估帮助企业减少人工比较模型、实例、框架和容器组合的时间。相关演讲将原本可能持续数周的基准测试压缩到了数小时。第二层扩缩容、容量和可观测性优化模型部署完成后企业需要继续解决三个问题。模型副本如何扩缩容大模型副本启动需要加载权重扩容速度通常慢于普通 Web 服务。企业需要根据并发、延迟和吞吐目标设置扩缩容方式而不是只看 CPU 或内存指标。GPU 容量不足时如何选择替代资源生产环境可能遇到特定 GPU 实例暂时不可用。企业可以根据计算成本、延迟或吞吐量对备选实例进行优先级排序让推理服务在容量变化时尽量回到符合业务目标的配置。如何统一观察运行状态可观测性应覆盖端点健康、请求延迟、吞吐量、模型副本、GPU 使用率和容量状态。否则企业只能知道服务“还在运行”却无法判断当前配置是否已经出现性能下降或成本失控。第三层分布式架构与网络优化当单个节点已经无法满足模型规模和上下文要求时企业才需要进入更深层的架构优化。其中一个重要方向是 Prefill-Decode 分离。Prefill 阶段需要处理长输入更偏向算力密集Decode 阶段逐 Token 输出更依赖显存带宽。将两者拆分后可以分别选择硬件并独立扩缩容。但这种架构会引入 KV Cache 传输问题。分论坛4的材料显示128K 上下文的 70B 模型单个请求的 KV Cache 可能达到约2至4GB。如果网络和传输层速度不足Prefill-Decode 分离获得的延迟优势可能被 KV Cache 搬运抵消。Mooncake on EFA 的实践通过 Transfer Engine、GPUDirect RDMA、多网卡聚合和 EFA为 KV Cache 跨节点传输提供了更适合云上大规模推理的路径。五、企业可以按照四类场景完成选型场景一快速上线知识问答、客服或内容生成推荐路径Amazon Bedrock企业知识库Agent 或安全能力重点是缩短应用开发周期不必自行搭建模型推理基础设施。场景二部署自研、微调或开源模型推荐路径SageMaker Managed Inference企业保留模型、容器和实例选择权同时减少端点创建、健康检查、扩缩容和可观测性运维。场景三企业已有 Amazon EKS 平台推荐路径SageMaker HyperPod InferenceAmazon EKS适合需要专属集群、Kubernetes 编排和统一平台工程体系的企业。场景四超大模型、MoE 与分离推理推荐路径Amazon EKSAmazon EC2 GPU 实例EFAvLLMSGLangMooncake 等组件重点转向模型并行、KV Cache、网络拓扑、权重加载和跨节点通信。六、较稳妥的上生产顺序是什么企业可以按照以下顺序推进而不是一开始就陷入复杂架构设计。第一步明确模型来源判断使用基础模型、开源模型、微调模型还是自研模型。第二步描述真实负载明确输入长度、输出长度、并发量、流量波动、响应方式和服务等级目标。第三步选择托管深度在 Amazon Bedrock、SageMaker Managed Inference、SageMaker HyperPod Inference 和自主管理的 Amazon EKSAmazon EC2 之间选择。第四步完成基准测试使用真实模型工件和业务请求测试延迟、吞吐量、资源利用率和成本避免只根据显存大小选择实例。第五步建立扩缩容与可观测体系在正式放量前验证模型副本扩容、容量不足处理、健康检查、日志与监控。第六步仅在需要时引入分布式优化当普通端点无法满足模型大小、上下文或吞吐量要求时再考虑 Prefill-Decode 分离、KV Cache 分级管理和 EFA 高性能网络。七、选型结论云平台、部署方式与优化路径需要分层决定企业生成式 AI 上生产比较稳妥的思路可以概括为需要快速使用基础模型和构建应用选择 Amazon Bedrock需要部署自定义模型并使用托管端点选择 SageMaker Managed Inference已经标准化使用 Amazon EKS选择 SageMaker HyperPod Inference需要承载超大模型和复杂分布式推理组合 Amazon EKS、Amazon EC2 GPU 实例与 EFA推理优化先做实例、框架和容器匹配再做扩缩容与可观测性最后才进入 PD 分离和 KV Cache 网络优化。AWS 更适合企业生成式 AI 生产部署的原因不只是提供一种大模型服务而是提供了从 API 调用基础模型、托管自定义端点到 Kubernetes 专属集群和大型分布式推理的连续路径。企业可以从较轻的部署方式开始随着模型定制程度、流量和性能要求提高逐步深入而不必在 POC 阶段就押注一套难以改变的架构。进一步了解相关演讲回放如果您希望进一步了解企业生成式 AI 上生产时的云平台选型、部署方式和推理优化路径可以通过亚马逊云科技官网首屏 Banner或搜索“2026亚马逊云科技中国峰会”在2026亚马逊云科技中国峰会回放页进入“分论坛4”查看《从数周到数小时借助 Amazon SageMaker AI 加速生成式 AI 的部署上线》《Mooncake on EFA万亿参数模型背后的开源服务架构实践》以及《750B MoE 分离推理从 RoCE 到 EFA 的全栈验证》等演讲回放和详细资料。
)
