EKS 上的 GPU 工作负载：节点、网络与高性能存储的架构实践
内容提要
本文介绍EKS上GPU工作负载的架构实践，涵盖计算节点、网络邻近性和高性能存储三层。重点包括：EFA多网卡配置（含p6-b300特殊拓扑）、四种定价模式、基于AWS原生拓扑标签的调度、FSx for Lustre与S3 Express One Zone存储选型，以及Terraform模块实现，旨在提升分布式训练性能。
延伸解读
EFA 多网卡配置的实例差异
文章强调 EFA 多网卡配置并非一刀切，不同实例类型的网卡拓扑差异显著。例如 p6-b300.48xlarge 的 NIC 0 仅支持 ENA，不能直接套用通用模式，否则实例启动失败。Terraform 模块通过维护实例类型到网卡布局的映射表来应对，新增机型需在 efa_layout 中登记。这提醒读者在部署新实例类型前，务必核对官方 EFA 配置文档，避免因拓扑假设错误导致启动错误。
安全组自引用：跨节点 EFA 的隐性要求
EFA 跨节点通信依赖安全组自引用规则，即安全组必须允许来自自身的所有入站和出站流量。这一要求容易被忽略，因为单节点测试（如 fi_pingpong）不会暴露问题，只有跨节点 NCCL 通信时才会失败或回退到 TCP。企业环境若收紧默认出站规则，更易触发此问题。建议在创建 GPU 安全组时显式添加自引用规则，并作为生产就绪检查项。
存储选型：按访问模式而非工作负载类型
文章提出高性能存储选型应基于访问模式，而非简单按训练或推理划分。FSx for Lustre 适合高聚合吞吐的顺序读，S3 Express One Zone 适合高 TPS 小对象随机读和低延迟写，而常驻推理服务的模型加载用 Standard S3 即可。此外，S3 Express 是单 AZ 存储，需权衡容灾需求；其 ARN 格式与 Standard 不同，配置时需注意。
拓扑感知调度：Placement Group 的局限
文章指出，在 p5 实例上，cluster Placement Group 并不保证实例共享同一 bottom-layer 网络节点，对 allreduce 性能提升有限，且可能加剧容量不足问题。因此推荐直接使用 AWS 原生拓扑标签（如 topology.k8s.aws/network-node-layer-N）进行调度，工作负载通过 nodeAffinity 绑定到具体网络层。这种方式更精确，且无需额外 IAM 权限。
Q&A
在EKS上为GPU工作负载配置EFA多网卡时，需要注意哪些关键点？
配置EFA多网卡时，需要为每个ENI指定NetworkCardIndex、DeviceIndex和InterfaceType。通常主网卡（NCI=0）使用InterfaceType=efa，附加网卡（NCI≥1）使用efa-only。对于p6-b300实例，其NIC 0仅支持ENA，因此需要特殊处理：主网卡用interface，其余16张网卡用efa-only。此外，必须确保安全组包含自引用规则以允许EFA流量。
EKS GPU节点组支持哪四种定价模式？它们之间有什么区别？
四种定价模式为：On-Demand（按需）、Spot（竞价）、ODCR（On-Demand Capacity Reservation）和Capacity Block（容量块）。On-Demand和Spot由EKS节点组的capacity-type控制；ODCR和Capacity Block需要在Launch Template中指定capacity reservation ID，其中Capacity Block还需设置MarketType=capacity-block。ODCR适合长期稳定训练，Capacity Block适合短期大规模训练。
如何利用AWS原生拓扑标签实现GPU工作负载的节点邻近性调度？
AWS cloud-controller-manager会为每个GPU节点注入topology.k8s.aws/network-node-layer-N标签，表示网络层级。工作负载可以通过nodeAffinity指定bottom-layer标签（如network-node-layer-3或4）来调度到同一网络节点，从而减少allreduce延迟。相比Placement Group，直接使用拓扑标签更精确且避免容量问题。
在EKS上，FSx for Lustre和S3 Express One Zone分别适用于哪些存储访问模式？
FSx for Lustre（PERSISTENT_2）适用于高聚合吞吐、并行读写的训练数据，如大文件顺序读。S3 Express One Zone适用于高TPS小对象随机读、低延迟写、跨Pod并发拉取同一对象等场景。大文件一次性顺序读且能容忍延迟时，Standard S3即可。
为什么GPU节点的安全组需要自引用规则？
EFA流量使用RDMA over EFA，不基于标准TCP/UDP端口，常规安全组规则无法覆盖。自引用规则允许同安全组内的节点间EFA流量通过，否则跨节点NCCL通信会失败或回退到TCP。单节点测试正常但跨节点失败时，应检查安全组自引用规则。
在EKS上部署GPU工作负载时，如何验证EFA和NCCL的跨节点通信是否正常？
可以使用仓库提供的option_verify_gpu_efa.sh脚本，通过--multi N参数进行跨节点验证。脚本会创建多个Pod运行NCCL all_reduce_perf，并检查NCCL_DEBUG输出是否包含NET/AWS Libfabric，确认走EFA而非TCP fallback。同时可设置带宽阈值进行性能验证。
在EKS上使用S3 Express One Zone时，ARN格式与Standard S3有何不同？
S3 Express One Zone的ARN格式为arn:aws:s3express:{region}:{account}:bucket/{name}--{zone-id}--x-s3，而Standard S3为arn:aws:s3:::bucket-name。两者在IAM策略和CSI Driver配置中不能混用，否则会导致Pod Identity配置失败。
