大模型训练平台设计¶

适配方向：AI Infra、训练平台、分布式训练、MLOps、训练调度、训练稳定性。

面试趋势：训练平台题不只看你知道哪些并行名词，而是看你能不能把 数据 -> 调度 -> 训练 runtime -> checkpoint -> 评测 -> 成本治理 讲成一套完整系统。

核验说明（2026-03-26）：本章以训练基础设施通用原理与当前主流工程实践为准，不维护容易过时的细碎产品数字。

一、面试官真正要看的能力¶

这类题表面上是在问训练平台，实际上是在看你能不能同时理解：

大规模分布式系统
GPU 集群调度
训练 runtime 和并行策略
数据与实验可复现
故障恢复与成本控制

如果候选人只会背：

DP / TP / PP / ZeRO
Megatron / DeepSpeed / FSDP
checkpoint / elastic training

但没法把这些东西放进一套完整平台里，面试官一般会认为还停留在“概念知道一点”的层级。

二、训练平台到底要解决什么¶

训练平台的目标，不是让一个训练任务能跑起来，而是让大量训练任务能够稳定、可复现、可恢复、可治理地跑在共享 GPU 集群上。

至少要解决这几类问题：

数据管理
任务提交与审批
GPU / 网络 / 存储调度
分布式训练执行
状态保存与恢复
评测与发布门禁
成本、效率与治理

三、推荐回答骨架¶

面试时建议先给出平台视角，而不是直接背并行策略。

Text Only

我会把训练平台拆成 6 层：

1. 数据层：
   - 原始数据接入、清洗、去重、切分、版本化

2. 控制层：
   - 任务提交、配额、优先级、资源审批、实验配置

3. 调度层：
   - GPU / 网络 / 存储资源分配
   - 拓扑感知调度
   - 抢占、排队、弹性扩缩

4. 训练执行层：
   - 分布式 launcher
   - runtime
   - 并行策略
   - 通信与容错

5. 状态与资产层：
   - checkpoint
   - model artifact
   - 日志、指标、trace

6. 评测与治理层：
   - 基础评测
   - 安全评测
   - 发布门禁
   - 成本监控

四、平台架构视角¶

图源：Google Cloud Architecture Center - MLOps using TensorFlow Extended, Vertex AI Pipelines, and Cloud Build，许可：CC BY 4.0。当前主图用于解释训练平台中的数据、流水线、训练、评测与部署闭环。

一个比较成熟的平台，通常会把系统拆成下面几块：

层级	关注点	典型能力
数据层	数据是否可追溯、可复现	清洗、版本化、采样、去重、权限
控制面	谁能跑、跑多少、优先级是什么	任务提交、审批、配额、租户隔离
调度面	资源怎么分、怎么放置	拓扑感知、抢占、排队、弹性伸缩
训练 runtime	任务如何真正跑起来	launcher、worker、并行策略、通信
状态层	任务中断后怎么恢复	checkpoint、artifact、元数据
评测层	训练结果能不能上线	指标、回归、安全、发布门禁

一个简单的链路¶

Text Only

控制层 -> 任务编排
        -> 资源申请与策略校验
调度层 -> GPU 调度 -> 拓扑感知放置
        -> 抢占 / 回收 / 弹性扩缩
执行层 -> launcher
        -> 容器 / 作业运行时 -> NCCL / RDMA / 分布式训练框架 -> 训练 runtime
状态层 -> checkpoint -> 恢复
数据层 -> 数据集版本 -> 流式读取
评测层 -> 日志 / trace / 指标 -> 门禁

五、训练平台离不开的核心设计¶

5.1 数据平台¶

训练平台最容易被低估的部分，其实是数据。

至少要回答这些问题：

数据怎么接入、清洗、去重、切分
数据版本怎么管理
训练数据和验证数据如何隔离
高吞吐读取怎么做
流式数据和离线数据怎么统一
有害样本、污染样本、重复样本怎么发现

5.2 为什么数据治理重要¶

很多训练平台题，真正拉开差距的不是“你会不会分布式训练”，而是你能不能把数据治理说清楚。

比如：

训练数据和验证数据不能泄漏
数据集版本变化要可追溯
tokenizer 变化要可记录
预处理规则变化要可回放
评测集不能被训练集污染

5.3 训练 runtime¶

训练 runtime 关注的是作业真正怎么跑：

launcher 如何启动多机多卡
节点间如何通信
如何处理进程故障
如何处理参数同步
如何处理多阶段训练流程

六、并行策略不是背名词¶

训练平台的关键不是“排个队”，而是高价值 GPU 如何被合理使用。

6.1 常见并行策略¶

策略	解决什么问题	典型限制
DP	单卡放不下，但样本可以分摊	同步开销大
TP	单层算子太大，需要切到多卡	高频通信，要求高速互联
PP	模型层数太深，需要跨节点切层	流水线 bubble
FSDP / ZeRO	显存不够，需要切分参数、梯度、优化器状态	额外通信与工程复杂度
MoE	模型容量很大，但每个 token 只激活部分专家	路由、负载均衡、通信都更复杂

6.2 调度器为什么要懂拓扑¶

TP 对带宽和延迟特别敏感，最好落在 NVLink / NVSwitch 域内。

PP 可以跨机，但要控制 stage 之间的通信。

DP / FSDP / ZeRO 的同步范围更大，更需要考虑网络拥塞和节点健康状态。

所以调度器不能只看“还有多少空卡”，还要看：

是否在同一机架
是否在同一网络平面
GPU 型号是否一致
节点健康状态
当前租户和优先级

6.3 资源放置¶

训练任务提交时，平台通常会要求：

GPU 型号
卡数
内存需求
任务优先级
是否允许抢占
是否允许弹性扩缩

调度器的职责不是只给你一个“可用”答案，而是给你一个“合理”的答案。

七、抢占与弹性¶

生产平台通常不会让所有任务都拥有同等地位。

常见分层如下：

核心预训练任务：最高优先级，资源锁定
重要微调任务：中高优先级，可排队
探索实验任务：可中断、可迁移、可回收

成熟的平台通常会支持：

checkpoint 预写
低优先级任务被抢占
被抢占任务稍后恢复
弹性扩卡 / 缩卡

如果你能主动提到“抢占前先做安全 checkpoint”，会很加分。

八、checkpoint 和恢复¶

训练平台最怕的不是“慢”，而是“贵且会断”。

8.1 常见 checkpoint 类型¶

Text Only

1. 频繁 checkpoint
   - 用于故障恢复

2. 里程碑 checkpoint
   - 用于评测、回滚、对比

3. 发布候选 checkpoint
   - 允许进入下游推理或发布流程

8.2 故障恢复不只是重启¶

一个好的回答方式是：

先判断是 GPU、网络、节点还是作业级故障
决定是否局部摘除，还是整体重启
从最近的 checkpoint 恢复
恢复后校验训练状态是否一致

8.3 什么是“静默错误”¶

静默错误是训练平台里很容易拉开差距的追问。

系统没挂，但结果已经不可信，例如：

梯度出现 NaN，却被吞掉
某段数据预处理错了，loss 还看不出来
某个 expert 长期不被激活
某个 rank 的数据重复了

成熟平台要能发现这些问题，而不是等模型训完才知道。

九、评测与发布门禁¶

训练平台不是“把 ckpt 产出来就结束”。

至少要接三类评测：

基础训练评测
loss 曲线
perplexity
各数据域表现
任务评测
code / math / reasoning / instruction follow
多模态任务指标
安全与回归评测
有害输出
拒答行为
关键能力回退

比较成熟的平台会把这些做成自动门禁：

达不到阈值，不允许进入下游
指标异常，自动阻断发布
结果必须可追溯、可回放

十、成本和效率¶

平台优化不只是让单个任务更快，而是让整个集群的 ROI 更高。

10.1 训练平台常看的效率指标¶

指标	含义
GPU 利用率	卡是否真正忙起来
MFU / HFU	模型或硬件 FLOPs 利用率
step 时间	训练吞吐最直接指标
通信时间占比	是否被 AllReduce / AllToAll 拖住
checkpoint 开销	存档是否影响主链路
token 成本	是否能长期承担

10.2 常见优化方向¶

提升 batch 和 micro-batch 配置
做拓扑感知放置
提升 job packing 和资源复用
把评测、训练、数据处理拆成不同资源池
让调度器支持优先级、抢占和弹性

一句话总结：

平台优化不只是“让单个任务更快”，而是让整个集群整体 ROI 更高。

十一、面试高频追问¶

11.1 如何选择 DP / TP / PP？¶

回答思路：

先看模型能不能放下
再看通信条件
再看目标是预训练、微调还是推理

常见判断：

模型太大、单卡放不下，先考虑 TP 或 PP
模型层很深、需要跨机切层，考虑 PP
想降低显存占用，考虑 FSDP / ZeRO
想扩到更大模型容量，考虑 MoE

11.2 为什么要做 experiment config 标准化？¶

因为平台最怕的是不可复现。

如果没有统一配置，就会出现：

同一个实验不同人写不同脚本
数据集版本不一致
并行配置不可复现
结果无法比较

11.3 checkpoint 周期怎么定？¶

答案不在公式，而在权衡：

训练越贵，越要重视 checkpoint
间隔太大，故障恢复代价高
间隔太小，会拖慢训练
要结合任务成本、故障概率和恢复时间综合判断

11.4 为什么有些任务能抢占，有些不能？¶

因为生产平台通常会把任务分层：

核心预训练任务：尽量不被打断
试验任务：允许中断和恢复
低优先级任务：可以被回收

这反映的是平台治理，而不是单纯的技术能力。

十二、面试答案模板¶

12.1 讲平台架构时¶

Text Only

我会把训练平台看成一个面向共享 GPU 集群的基础设施系统，
而不是单个训练脚本。

先从数据层开始，解决清洗、版本化和高吞吐读取；
然后在控制面定义任务 spec、配额和优先级；
执行层才是具体的分布式训练 runtime，
包括 FSDP、ZeRO、TP、PP、EP 等并行策略；
状态层负责 checkpoint、恢复和资产管理；
最后通过评测门禁、成本监控和可观测性把训练结果接到下游。

12.2 讲调度层时¶

Text Only

调度器不能只看还有多少空卡，
还要看 GPU 拓扑、网络平面、优先级和任务类型。

比如 TP 更适合放在高速互联域内，
PP 更关注 stage 间通信，
FSDP / ZeRO 则更关注同步开销和节点稳定性。

12.3 讲平台可治理时¶

Text Only

真正的训练平台不只是能跑任务，
还要能追溯数据、配置、评测和结果。

如果没有版本化、checkpoint 和门禁，
训练就很难从“能跑”升级到“可控、可恢复、可上线”。

十三、本章总结¶

Text Only

1. 训练平台题考的是系统思维，不只是并行名词。
2. 数据治理、调度、runtime、checkpoint、评测缺一不可。
3. 调度器必须懂拓扑、优先级和资源治理。
4. 并行策略要放在平台和 runtime 里统一管理。
5. checkpoint、恢复、评测门禁是生产级平台的必答题。
6. 成本、效率和 ROI 是 2026/2027 年训练平台岗位越来越重要的考点。

如果你能把这一页内容讲顺，训练平台题就不再只是“会几个名词”，而是能体现你已经站在 AI Infra 和大厂平台工程的视角思考问题。

参考资料¶

PyTorch Distributed Documentation
DeepSpeed Documentation
Hugging Face Accelerate / Transformers 文档
NVIDIA NCCL / CUDA 文档
MLOps 与训练平台相关工程实践资料

最后更新：2026-03-26