Bowen Blog

Appearance

2026-09-29
1850
6.7m

训练平台设计 ​

"设计一个支持 1000 卡规模的训练平台，核心组件有哪些？"——这类题没有标准答案，但有标准的答题结构：分层列出组件、说明每个组件的设计矛盾、给出量化指标。本篇就是那份参考答案。

答题框架：五层组件 ​

┌─────────────────────────────────────────────┐
│  用户界面层：提交 / 实验跟踪 / 配额自助        │
├─────────────────────────────────────────────┤
│  作业管理层：调度 / 队列 / 抢占 / 成本核算     │
├─────────────────────────────────────────────┤
│  运行时层：容器镜像 / 分布式启动 / 容错恢复    │
├─────────────────────────────────────────────┤
│  数据与存储层：数据集管理 / checkpoint / 缓存  │
├─────────────────────────────────────────────┤
│  物理层：GPU / 网络 / 机房 / 拓扑             │
└─────────────────────────────────────────────┘

每层选一个组件展开它的设计矛盾，比平铺直叙更能体现深度。

作业层：调度与 SLA ​

调度器设计（题库 217/231）：gang scheduling + 优先级队列 + 回填是基线（见集群调度篇）；平台层要加的是 SLA 分级——生产训练（预留资源、恢复优先）、实验作业（可抢占）、调参作业（spot 填空）。SLA 的可量化形式：排队时间 P90、抢占率、恢复时间。三档 SLA 对应三种价格，让用户自己权衡——配额与定价是平台调控需求的唯一温和手段。

HPO 基础设施（题库 224）是作业层的特殊住户：超参搜索要起大量短命作业，天然适合抢占档资源。设计要点：试验间共享 tokenized 数据与缓存（省去重复预处理）、早停（ASHA 类）把坏试验的卡时省下来、以及试验亲和调度（同组试验打到缓存热的节点）。

运行时层：镜像与容错 ​

镜像管理（题库 219）：训练镜像 = CUDA/NCCL 基座 + 框架 + 业务代码。矛盾是体积 vs 变更频率——基座（10+ GB）月级变更、框架周级、代码分钟级。标准解法：分层镜像 + 基座预烘到节点（P2P 分发慢则本地缓存），业务代码走挂载而非打包，实现"改代码不重建镜像"。镜像仓库要管多架构（x86/ARM）与多 CUDA 版本（新旧卡并存）。

容错与自动恢复（题库 221）：检测（NCCL 超时/心跳丢失/SM error 事件）→ 诊断归因（硬件故障 vs 软件 hang，见容错篇）→ 恢复动作（重启进程 → 换节点 → 缩容降级）。平台层的目标是无人干预的自动恢复率——人工介入的门槛应设在"同类故障连续 N 次"而不是单次故障。数据隐私与合规（题库 232）在这个层落地：数据访问审计、租户间网络隔离、训练数据的脱敏与血缘记录。

数据与存储层 ​

数据集管理（题库 218/222/223）：数据集版本化（指纹 + 变更日志）是可复现性的根——实验跟踪（题库 160）里的"数据版本"字段就来自这里；global shuffle、分片与缓存见数据管道篇；模型仓库（题库 223）管理 checkpoint 的版本与元数据（训练配置、评估分数、血缘），与Checkpoint 存储篇的三级存储拓扑对接。

模型 CI/CD（题库 234）：训练平台的流水线不是代码 CI 而是评估门禁——checkpoint 产出后自动触发标准评测（PPL/基准任务/安全评测），分数写回模型仓库，只有过线的版本才允许发布到推理平台。与推理平台的接口（模型格式、量化版本）在这里约定。

可观测性与成本 ​

**Observability（题库 235）**的三层仪表盘：

  1. 集群层：利用率（按卡时）、故障率、碎片率、队列深度——回答"平台健康吗"。
  2. 作业层：MFU、吞吐、checkpoint 间隔、恢复次数——回答"这个训练跑得好吗"（口径见性能指标篇）。
  3. 实验层：loss 曲线、梯度范数、数据配比——回答"模型学得好吗"。

Cost model（题库 229）：平台的核心报表是卡时单价——总成本（折旧/电力/网络/运维）÷ 有效卡时（利用率修正后）。它能回答三个问题：新作业报价、实验 vs 生产的资源配比、以及"把 MFU 从 45% 提到 50% 等于多少钱"——把 Infra 优化翻译成预算语言，是平台团队的沟通货币。dry-run/profiling 模式（题库 227）：作业提交时可选 10 分钟试跑，自动产出预估 MFU 与显存曲线——把"跑炸了才知道"变成"提交前就知道"，是对 GPU 时最便宜的保险。

异构计算支持（题库 230）的答题要点

分层回答：物理层——异构卡分池管理，网络拓扑按卡型分区（不同卡的 NVLink 域不同）；运行时层——镜像多架构、NCCL/通信库按卡型选择（甚至异构间通信降级到 IB）；作业层——调度按卡型过滤 + 声明式匹配；框架层——并行配置随卡型重算（[集群调度]篇思考题 3）。加分点：指出"异构训练单个作业"（如不同卡跑不同 stage）目前只有特殊场景可行（prefill/decode 分卡型），常规做法是异构分池而非混部。

小结 ​

  • 答题框架五层：界面、作业、运行时、数据存储、物理——每层挑一个组件讲透设计矛盾。
  • SLA 分级 + 定价是平台调控资源的手；HPO 是抢占资源的天然住户。
  • 镜像分层与代码挂载解"体积 vs 频率"矛盾；容错的 KPI 是无人干预恢复率。
  • 可观测三层仪表盘 + 卡时单价报表，让平台从"管机器"升级为"经营算力"。

思考题 ​

  1. 1000 卡平台的 checkpoint 间隔设 15 分钟，一次全集群断电的期望损失是多少？和恢复机制怎么联动？
  2. 为什么"业务代码走挂载不走镜像"在千卡规模几乎是必须的？估算差异。
  3. dry-run 模式测得的 MFU 与真实训练会有什么系统性偏差？
参考答案
  1. 期望损失 ≈ 平均故障间隔内的预期未保存进度 = E[loss]≈ 平均 tck/2=7.5 分钟 × 1000 卡（[容错]篇公式）+ 全集群恢复时间（重启+加载，数十分钟量级）；联动：断电属于"全灭"型故障，恢复顺序要按拓扑批量拉起（避免 NCCL 建链风暴），并把恢复时间计入 SLA 承诺。
  2. 镜像构建 + 分发到 125 台机：即使 P2P 分发，GB 级层的冷分发是分钟级且占满网络；挂载（分布式 FS/对象存储）让代码变更秒级生效、且所有节点版本一致——千卡规模下"一半节点跑旧代码"的排障成本远超挂载的工程成本。
  3. dry-run 是短时长：CUDA Graph/JIT 未完成预热、数据缓存未热、checkpoint 写入未发生、长周期波动（DDP 长尾、host 侧 GC）未出现——通常高估 MFU 几个百分点；对策是试跑时长覆盖至少数百 step 并在真实作业早期再校准。

参考资料 ​

  • KubeCon 系：Volcano 与 Run:AI/Google 的 AI 调度实践分享
  • Li et al., MegaScale（生产级训练平台的组件与诊断）
  • Meta AI, Llama 3 Herd of Models（容错与平台工程章节）
最近更新