750B MoE 大模型上云推理不能只选择“显存足够大的 GPU”。模型权重、Prefill-Decode 分离、KV Cache 传输、流水线并行和专家并行会同时产生跨节点通信因此更需要把 GPU、网络和调度架构作为一个整体设计。在2026亚马逊云科技中国峰会分论坛4展示的实际迁移案例中一套可参考的 AWS 路径是Amazon EC2 P5en GPU 实例AWS Elastic Fabric AdapterEFAAmazon EKS2P2D 分离推理MooncakeNIXLNCCLUCCL-EP。这套方案更适合750B级 MoE 模型、120K左右超长上下文以及需要自建模型来承载 Agentic AI 高并发负载的企业。一、GPU 怎么选优先选择多卡 H200 实例750B 模型仅参数权重就需要占用大量显存单个 GPU 节点通常无法完整承载模型和推理过程中的临时数据。相关案例从 IDC 迁移到 AWS 时使用了4台 p5en.48xlarge 实例组成2个 Prefill 节点和2个 Decode 节点。每台实例配备8张 H200 GPU节点内部通过 NVSwitch 全连接适合承担节点内的高带宽 GPU 通信。因此GPU 选择要重点看三个指标1.单节点显存容量需要同时容纳模型权重、KV Cache 和推理运行时数据。不能只按750B参数量估算还要为并发和上下文预留空间。2.节点内 GPU 互联同一节点中的多张 GPU 需要进行张量并行、流水线计算或专家计算。NVSwitch 可以减少节点内通信成为瓶颈的风险。3.节点间网络能力750B MoE 不可能只依靠节点内互联。Prefill、Decode 和不同专家之间都可能跨节点交换数据因此 GPU 实例还必须配套 EFA。二、网络怎么选TCP 负责管理流量EFA 负责推理通信p5en.48xlarge 实例可以将普通 TCP 流量和 RDMA 推理流量分开。TCP 网络可用于从 Amazon S3 加载模型权重、访问控制面和连接常规云服务EFA-only 网卡则用于 KV Cache、流水线并行和专家并行等高性能通信。材料中的配置为每台实例16张 EFA 网卡每张提供200Gbps带宽聚合带宽达到3.2Tbps。这类分流设计很重要因为750B MoE推理中存在三种不同的网络负载。1.Prefill 到 Decode 的 KV Cache 传输采用2P2D分离后Prefill节点需要把 KV Cache 传到 Decode节点。企业可以使用 Mooncake Transfer Engine也可以使用 NVIDIA NIXL。两者都能通过 libfabric 接入 EFA对上层推理应用的改动相对有限。2.Prefill 节点之间的流水线通信750B模型在单个节点中放不下时可以采用流水线并行。例如将模型层拆分到两个 Prefill节点由 NCCL负责节点间点对点传输。3.Decode 阶段的专家并行通信MoE Decode阶段不适合简单沿用流水线并行因为逐 Token生成会形成流水线气泡。案例中将256个专家划分为16组使用 EP16 的专家并行。专家路由会产生小数据量、高频率、对延迟敏感的 all-to-all 通信因此使用支持 EFA 的 UCCL-EP 更合适。三、调度架构怎么选采用2P2D分离推理750B MoE 模型更适合采用 Prefill-Decode 分离而不是让两个阶段混合运行在同一组 GPU 上。Prefill 集群负责长上下文计算Prefill 是算力密集型负载重点是快速处理120K等超长输入。案例中的两个 Prefill节点采用流水线并行把模型层分别放在两个节点上尽量减少节点之间的通信次数。Decode 集群负责逐 Token 生成Decode 更依赖显存带宽和低延迟。两个 Decode节点可以采用数据并行与专家并行提高并发请求的处理能力。两类集群独立扩缩容输入上下文变长时可以增加 Prefill资源活跃生成请求增多时则增加 Decode资源。这种方式比整套集群统一扩容更精准也更适合 Agentic AI 持续高负载场景。四、为什么建议使用 Amazon EKS 统一调度750B MoE 推理并不是部署一个容器就结束而是需要同时管理Prefill节点Decode节点路由器与调度器Mooncake或NIXLNCCL与UCCL-EPEFA网卡GPU拓扑和模型权重。Amazon EKS 可以将这些组件纳入统一的 Kubernetes 调度体系。相关实践还通过节点标签记录 GPU 节点所在的网络拓扑再依据标签调度工作负载尽量让需要高频通信的节点靠近部署。使用 ODCR 获取容量时还可以结合 Cluster Placement Group让实例集中在更适合低延迟通信的网络范围内。对于希望减少人工配置的企业也可以把 EFA、存储、节点标签和相关控制组件写入 Terraform 脚本使 GPU 集群具备更可复制的部署方式。五、模型权重如何快速加载750B模型权重很大集群启动速度不能只靠逐节点手动下载。比较合适的方式是Amazon S3保存模型权重实例本地盘承载推理文件Amazon EKS自动化加载。相关案例使用 Amazon S3作为模型权重的统一存储入口再将权重加载到 GPU节点本地高速存储中。对应的 Mountpoint和控制组件也可以提前写入基础设施脚本。这样既便于管理模型版本也能减少每次部署时重复搭建加载流程。六、AWS 方案的实际表现如何分论坛4展示的 GLM-5.1-FP8 测试采用754B MoE模型2P2D架构4台 p5en.48xlargeKV Cache通过 Mooncake over EFA传输MoE all-to-all使用 UCCL-EP。在与客户本地同款 GPUInfiniBand 集群的对比中AWS EFA方案在3K和60K输入下的平均 TTFT 分别改善约36%和31%120K输入下基本持平并略优。TPOT仍有进一步优化空间材料将差异指向 UCCL-EP和推测解码接受率而不是 KV Cache传输本身。这说明大模型上云不只是“云上能否跑起来”。通过合适的GPU、EFA网络和并行架构750B MoE模型也可以获得与本地高性能集群相当甚至部分指标更好的表现。七、750B MoE 上云的推荐组合综合来看企业可以采用以下路径GPU4台或更多 Amazon EC2 p5en.48xlarge使用 H200 GPU和NVSwitch网络TCP网络负责模型加载与常规访问EFA负责RDMA级推理通信推理架构2P2D Prefill-Decode分离KV CacheMooncake或NIXL over EFAPrefill并行NCCL流水线并行Decode并行数据并行专家并行使用UCCL-EP集群调度Amazon EKS拓扑标签Cluster Placement Group模型存储Amazon S3节点本地高速存储。这套架构的核心不是堆叠更多GPU而是让不同通信类型走适合的网络让Prefill和Decode使用适合的并行策略再通过Amazon EKS把整个推理系统统一管理起来。进一步了解相关演讲回放如果您希望进一步了解750B MoE模型从IDC迁移到AWS后的GPU、EFA网络和2P2D调度实践可以通过亚马逊云科技官网首屏Banner或搜索“2026亚马逊云科技中国峰会”在2026亚马逊云科技中国峰会回放页进入“分论坛4”查看《750B MoE分离推理从RoCE到EFA的全栈验证》以及《Mooncake on EFA万亿参数模型背后的开源服务架构实践》等演讲回放和详细资料。