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

标签：AWS EKS PyTorch 性能调优 SageMaker HyperPod

大家好，我是 [锅巴王子]。在上一篇文章中，我们通过编写极其硬核的 PyTorchJob YAML，配合 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 Utilization（GPU 利用率）只有 30%，请立刻停止训练，不要白烧钱！这通常是以下两个原因导致的：

病因 A：CPU 喂不饱 GPU (Data Loading Bottleneck)
- 现象：GPU 利用率呈锯齿状，一会 100%，一会 0%。
- 解法：去改你的 train.py，把 PyTorch DataLoader 的 num_workers 调大（比如从 4 调到 16），让更多的 CPU 进程去读取数据喂给显卡。
病因 B：EFA 网络没用满 (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 Exporter：NVIDIA 官方的工具，负责读取 GPU 温度、利用率、显存。
EFA Exporter：AWS 写的工具，负责读取网卡吞吐量。
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 会缩容吗？（重点看 `minSize=2`）

既然 Pod 已经 Completed 了，物理机就空出来了。此时 EKS 的缩容组件（如 Karpenter）会跳出来干活：

判定闲置：它发现那 2 台价值连城的 A100 机器现在上面只有几个"死掉"的 Pod，没人用了。
执行缩容：它会把这几台机器关掉。
底线（minSize=2） ：因为你在 NodeGroup 里设置了 minSize=2，所以它最多只会关掉超出的部分。
- 如果你刚才因为训练任务临时扩容到了 4 台，它会关掉 2 台。
- 剩下的 2 台会永远开着。

💡 架构师的实战建议：

既然你已经意识到了 minSize=2 的存在：

如果你的集群不是 7x24 小时都在训练 ：请把 minSize 设置为 0。这样在没任务时，昂贵的 GPU 机器会全部释放，账单归零。
为什么要设为 2？：通常是因为这 2 台机器上还跑着一些"常驻服务"（比如监控、网关、或者一些小型的测试任务），不希望每次训练都要等 15 分钟开机。

总结一下：Pod 变完成状态 -> 资源释放 -> 触发缩容 -> 回到 minSize 设定的保底台数。

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

阶段一：打破黑盒，查看真实的"炼丹"进度

1. 见证"统帅"与"士兵"的握手 (Rendezvous)

2. 确认 Loss 正常下降

阶段二：拒绝"显卡空转"，启用 HyperPod 硬件级可观测性

1. 登录预置的 Grafana 大盘

2. 【避坑指南】如何揪出性能瓶颈？

阶段三：落袋为安，模型的持久化保存

实战解法：在 PyTorchJob 中挂载 S3 / FSx

阶段四：优雅落幕（生命周期终结与资源释放）

1. 揭秘插件底层：它到底在输出什么？

2. 对接自建 Grafana 的两种实战架构

方案 A：混合模式（极其推荐，省心且灵活）

方案 B：纯自建模式（完全脱离 AWS 监控体系）

3. 【避坑预警】自建 Grafana 会失去什么？

3. 训练完 Pod 会消失吗？Node 会缩容到 0 吗？

Pod 会消失吗？

Node 会缩容吗？（重点看 minSize=2）

💡 架构师的实战建议：

Node 会缩容吗？（重点看 `minSize=2`）