【云原生 AI 实战（二）】大模型训练的“深水区”：从 Pod 成功拉起到 GPU 性能监控与模型导出

标签AWSEKSPyTorch性能调优SageMaker HyperPod大家好我是 [锅巴王子]。在上一篇文章中我们通过编写极其硬核的PyTorchJobYAML配合 EFA 极速网卡成功在 EKS 上拉起了 2 台包含 16 张 A100 显卡的物理节点并且 Pod 状态已经绿油油地显示为Running。很多新手看到Running就以为大功告成了准备开香槟。但其实大模型训练的“深水区”才刚刚开始。今天我们就来实战解析Pod 拉起之后里面到底在发生什么我们如何监控这 16 张卡的真实效率以及最关键的训练完的模型权重怎么拿出来阶段一打破黑盒查看真实的“炼丹”进度Pod 显示Running仅仅意味着 Kubernetes 成功把容器拉起来了。但里面的 PyTorch 代码有没有死锁有没有报错退出1. 见证“统帅”与“士兵”的握手 (Rendezvous)在分布式训练中Worker 节点启动后第一件事就是去寻找 Master 节点“对暗号”。 我们直接抓取 Master 节点的日志kubectl logs -f llama-3-finetune-master-0在浩如烟海的系统日志中如果你能看到类似下面的输出说明多机通信彻底打通了[INFO] torch.distributed.run: Master node is 10.0.12.34, port 29500 [INFO] torch.distributed.run: Worker 1 connected from 10.0.15.67 [INFO] Initializing process group with backend: nccl [INFO] Process group initialized successfully. World size: 16(注World size: 16意味着 PyTorch 成功识别到了 2 台机器上总共 16 张 GPU。)2. 确认 Loss 正常下降紧接着你应该能看到算法工程师写的训练脚本train.py开始吐出业务日志了Epoch [1/10], Step [100/5000], Loss: 3.4512, lr: 0.0001 Epoch [1/10], Step [200/5000], Loss: 3.1205, lr: 0.0001 ...只要 Loss 在下降说明模型确实在学习阶段二拒绝“显卡空转”启用 HyperPod 硬件级可观测性我们按每小时几十美金的价格租了 A100最怕的就是“一顿操作猛如虎显卡利用率百分之五”。普通的 Kubernetes 只能看到 CPU 和内存。这时候我们需要用到上一期提到的第二个神器Amazon SageMaker HyperPod 可观测性插件 (Observability)。1. 登录预置的 Grafana 大盘当你在 EKS 安装了这个插件后它会自动在后台收集 NVIDIA DCGM数据中心 GPU 管理器指标并输出到 Amazon Managed Grafana。打开你的 Grafana进入GPU Performance大盘。2. 【避坑指南】如何揪出性能瓶颈如果你在面板上看到GPU UtilizationGPU 利用率只有 30%请立刻停止训练不要白烧钱这通常是以下两个原因导致的病因 ACPU 喂不饱 GPU (Data Loading Bottleneck)现象GPU 利用率呈锯齿状一会 100%一会 0%。解法去改你的train.py把 PyTorch DataLoader 的num_workers调大比如从 4 调到 16让更多的 CPU 进程去读取数据喂给显卡。病因 BEFA 网络没用满 (Communication Bottleneck)现象GPU 利用率很低但在 Grafana 的EFA Network TX/RX网卡吞吐量监控上带宽跑满了。解法说明你的模型参数太大了跨机器同步梯度的压力超过了网络极限。你需要引入 DeepSpeed 或者 ZeRO-3 这类更高级的并行策略。阶段三落袋为安模型的持久化保存容器Pod的生命周期是短暂的。一旦训练结束 Pod 被销毁如果你把动辄几百 GB 的模型权重Checkpoint存在了容器的本地硬盘里那可真是“人间惨剧”。在大规模 AI 集群中我们绝对不用普通的 EBS 云盘存模型而是必须挂载高性能共享文件系统如 Amazon FSx for Lustre或直接流式写入 Amazon S3。实战解法在 PyTorchJob 中挂载 S3 / FSx通常我们会在 EKS 中配置好 CSI Driver然后在llama-train-job.yaml中新增持久化存储卷PVC# 在 YAML 的 volumes 部分增加 volumes: - name: dshm emptyDir: medium: Memory # 【核心】挂载 S3 或 FSx 用来存模型 - name: model-checkpoints persistentVolumeClaim: claimName: fsx-lustre-pvc # 在 container 的 volumeMounts 增加 volumeMounts: - name: model-checkpoints mountPath: /opt/checkpoints这样算法工程师在train.py里只需要写torch.save(model.state_dict(), /opt/checkpoints/llama3_epoch1.pt)模型就会安全地、以 GB/s 的极高吞吐量持久化到外部存储中。阶段四优雅落幕生命周期终结与资源释放当train.py执行完最后一行代码并正常退出Exit Code 0时Training Operator会接管剩下的工作它会将llama-3-finetune-master-0和所有 worker 的状态从Running变更为Completed。它会判定整个PyTorchJob为Succeeded成功。最爽的一点由于任务结束Pod 变更为 Completed 状态EKS 集群的自动缩容组件如 Karpenter会发现这几台昂贵的 p4d 机器闲置了。等待配置的缩容冷却时间如 5 分钟后AWS 会自动帮你关掉Terminate这些 EC2 实例立刻停止计费至此一次完美的云原生大模型训练周期就彻底闭环了。1. 揭秘插件底层它到底在输出什么安装 HyperPod Observability 插件后它其实是在你的 GPU 节点上部署了几个开源的 Exporter数据暴露组件DCGM ExporterNVIDIA 官方的工具负责读取 GPU 温度、利用率、显存。EFA ExporterAWS 写的工具负责读取网卡吞吐量。Node Exporter读取常规的 CPU 和内存。这三个组件都在用最标准的Prometheus/metrics接口向外吐数据。所以只要你的自建系统支持 Prometheus 协议就能完美对接。2. 对接自建 Grafana 的两种实战架构根据你们团队的运维习惯有两条路可以走方案 A混合模式极其推荐省心且灵活这是目前很多大厂最喜欢的做法。数据存储让插件依然把数据推送到 AWS 全托管的Amazon Managed Prometheus (AMP)里。AMP 帮你解决海量监控数据的存储和高可用问题。数据展示使用你们自建的 Grafana。怎么对接你只需要在自建 Grafana 里添加一个数据源Data Source类型选 Prometheus填入 AMP 的 URL。因为 AMP 需要 AWS IAM 权限验证你只需在 Grafana 里开启AWS SigV4 认证Grafana 原生支持就能直接读取 AMP 里的数据。方案 B纯自建模式完全脱离 AWS 监控体系如果你们有极其严格的合规要求连数据都不想存在 AWS 的 AMP 里且你们自己维护了一个庞大的 Prometheus 集群。怎么对接你不需要配置插件的远端写入。你只需要修改你们自建 Prometheus 的scrape_configs抓取配置。具体操作利用 Kubernetes 的服务发现机制kubernetes_sd_configs让你的 Prometheus 直接去 EKS 集群里“拉取Scrape”那些 Exporter 的端口比如 DCGM 默认的 9400 端口。然后你的自建 Grafana 连接自建的 Prometheus形成完美闭环。3. 【避坑预警】自建 Grafana 会失去什么虽然完全支持对接但我必须提醒你一个自建会面临的“小麻烦”如果你用 AWS 官方的 Managed Grafana它里面是预置好Out-of-the-box了一整套极其炫酷且专业的 SageMaker HyperPod 大盘模板的。从 EFA 拓扑图到单张显卡的热力图应有尽有。如果你用自建 Grafana你需要自己去画这些图表或者去开源社区Grafana Dashboards找别人写好的JSON模板导进去。比如你需要自己导入 NVIDIA 官方提供的 DCGM Dashboard (ID: 12239) 才能看到漂亮的 GPU 仪表盘。总结来说数据底座完全是开放的你可以自由传给自建的 Grafana。无非是 AWS 全托管版帮你做好了“精装修”而自建版需要你多花半天时间去“贴壁纸调优大盘 UI”而已。声明。3. 训练完 Pod 会消失吗Node 会缩容到 0 吗这是一个关于“省钱”的核心逻辑。我们分两步看Pod 会消失吗当你的train.py跑完了Pod 的状态会从Running变成Completed。它们不会立刻消失除非你配置了自动清理插件。它们会一直挂在那里方便你进去看日志kubectl logs。关键点状态为Completed的 Pod不再占用 CPU 和 GPU 资源。Node 会缩容吗重点看minSize2既然 Pod 已经Completed了物理机就空出来了。此时 EKS 的缩容组件如 Karpenter会跳出来干活判定闲置它发现那 2 台价值连城的 A100 机器现在上面只有几个“死掉”的 Pod没人用了。执行缩容它会把这几台机器关掉。底线minSize2因为你在 NodeGroup 里设置了minSize2所以它最多只会关掉超出的部分。如果你刚才因为训练任务临时扩容到了 4 台它会关掉 2 台。剩下的 2 台会永远开着。 架构师的实战建议既然你已经意识到了minSize2的存在如果你的集群不是 7x24 小时都在训练请把minSize设置为0。这样在没任务时昂贵的 GPU 机器会全部释放账单归零。为什么要设为 2通常是因为这 2 台机器上还跑着一些“常驻服务”比如监控、网关、或者一些小型的测试任务不希望每次训练都要等 15 分钟开机。总结一下Pod 变完成状态 - 资源释放 - 触发缩容 - 回到minSize设定的保底台数。