750B MoE 大模型上云推理，不能只选择"显存足够大的 GPU"。模型权重、Prefill-Decode 分离、KV Cache 传输、流水线并行和专家并行会同时产生跨节点通信，因此更需要把 GPU、网络和调度架构作为一个整体设计。
在2026亚马逊云科技中国峰会分论坛4展示的实际迁移案例中，一套可参考的 AWS 路径是：
Amazon EC2 P5en GPU 实例＋AWS Elastic Fabric Adapter（EFA）＋Amazon EKS＋2P2D 分离推理＋Mooncake／NIXL＋NCCL＋UCCL-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组，使用 EP=16 的专家并行。专家路由会产生小数据量、高频率、对延迟敏感的 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或NIXL；
NCCL与UCCL-EP；
EFA网卡；
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模型；
2P＋2D架构；
4台 p5en.48xlarge；
KV Cache通过 Mooncake over EFA传输；
MoE all-to-all使用 UCCL-EP。
在与客户本地同款 GPU＋InfiniBand 集群的对比中，AWS EFA方案在3K和60K输入下的平均 TTFT 分别改善约36%和31%，120K输入下基本持平并略优。TPOT仍有进一步优化空间，材料将差异指向 UCCL-EP和推测解码接受率，而不是 KV Cache传输本身。
这说明，大模型上云不只是"云上能否跑起来"。通过合适的GPU、EFA网络和并行架构，750B MoE模型也可以获得与本地高性能集群相当，甚至部分指标更好的表现。
七、750B MoE 上云的推荐组合
综合来看，企业可以采用以下路径：
GPU：4台或更多 Amazon EC2 p5en.48xlarge，使用 H200 GPU和NVSwitch；
网络：TCP网络负责模型加载与常规访问，EFA负责RDMA级推理通信；
推理架构：2P2D Prefill-Decode分离；
KV Cache：Mooncake或NIXL over EFA；
Prefill并行：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：万亿参数模型背后的开源服务架构实践》等演讲回放和详细资料。