← 返回书架人工智能 · 交互式 Wiki

训练系统与性能入门专题讲解学习主线 6 / 6

SYSTEMS / TRAINING ENGINEERING

训练工程：从数据读取到参数更新

从数据 shard 到一次 optimizer step，需要跟踪每步处理的 token 数、显存占用、多卡同步的张量，以及 checkpoint 的评估结果。本页对照预训练、对比学习、SFT 和 DPO 的运行流程。

一次训练 step 的执行流程

先选训练范式，再逐站看 data、GPU 和网络各做什么。各环节列出输入、输出、资源消耗和失败征兆。

CAUSAL PRETRAINING

从 token shard 形成可训练的序列

01 / 08

从经过清洗、去重和 tokenizer 处理的二进制 shard 中读取 token。真实系统会并行预取下一批数据，避免 GPU 等磁盘；数据顺序与 shard 本身都是实验版本的一部分。

INPUTtoken shard

ACTIONshuffle + read

OUTPUTtoken arrays

数据 / CPU解压、索引、预取

加速器此时通常空闲或算上一步

网络读共享存储 / 节点传输

for shard in shuffled(train_shards):
    for batch in read_sequences(shard):
        train_step(batch)

工程检查

shard 是否与 tokenizer 版本匹配；dataloader 是否真的没有等 GPU。

典型失败

GPU 利用率周期性掉到零；训练日志里 step time 抖动，但 kernel 本身没有变慢。

一次 optimizer step 处理多少 token？

“batch size”常被混着说。这里分开 microbatch、gradient accumulation 和全局 optimizer step。

数据并行副本数 DP 8 每个 DP 副本 microbatch 4 序列长度 T 2048 梯度累积 microsteps 8

输入 tokens / update = DP × B_micro × T × accum

这里假设等长、满填充样本。TP/PP/CP 卡协作处理同一份样本，不能把 GPU 总数当 DP 数。有效监督 token 还要扣除 padding 与不计 loss 的位置；对比学习的梯度累积也不会自动扩大每个 microbatch 的负例池。

一次参数更新处理 524.3K tokens / optimizer step

每卡一次 forward8.2Ktokens

全局 microstep65.5Ktokens / forward round

样本等价数256microbatch × DP × accum

固定 microbatch 和消费样本总数时，增大 accumulation 会减少 optimizer 更新次数；每次更新要累积更多轮 forward/backward。通信不会自动减少：标准 DDP 默认在每轮反向同步，需在前 A−1 个 microstep 用 no_sync 覆盖 forward 和 backward，最后一轮再同步。显存与吞吐收益取决于保存激活、通信和调度方式。

训练显存：权重、梯度与优化器状态

这里只算“静态训练状态”，不含 activations 和临时 workspace；它仍然足以看出大模型为何必须分片。

模型参数量优化器状态数据并行 GPU 数

假设 BF16 权重/梯度、FP32 master 与优化器状态；不计 activation、通信 buffer、碎片与临时 workspace。

STATIC TRAINING STATE

7B · AdamW · 8 GPU · DP

每卡静态状态112.0 GB

集群总静态状态896.0 GB

相比 DP 降低0%

普通数据并行中，每张卡都保留完整参数、梯度和优化器状态。模型本身放不下一张卡时，不能靠增加 accumulation 解决。

多卡训练的几种分工方式

不同并行方式切的是不同维度；大规模训练通常组合 DP、TP、PP 和序列并行。

DATA PARALLEL

复制模型，切 batch

每卡处理不同样本，反向同步梯度。实现简单、吞吐高，但每卡必须放得下完整训练状态。

all-reduce gradients

ZeRO / FSDP

切参数、梯度、优化器状态

训练状态分片保存，计算所需的参数在使用前重聚。省显存，代价是更多 all-gather / reduce-scatter。

shard → gather → compute → reshard

TENSOR PARALLEL

切单层矩阵计算

把 attention / MLP 的权重和计算按维度拆到多卡，层内需要高频通信。适合单卡装不下单层或需要更多 compute 并行。

layer-level sharding

PIPELINE PARALLEL

切模型层，流水线送 batch

不同 GPU 负责不同层；需要 micro-batch 填充流水线，并处理 bubble、激活缓存和跨阶段通信。

stage 1 → stage 2 → …

显存、吞吐和收敛是三个指标。分片可能让你“跑得起来”，但通信会压低吞吐；增大全局 batch 可能提高并行效率，却改变学习率、训练 token 预算与泛化行为。配置选择应同时比较内存、速度和训练效果。

继续追踪具体的计算与执行

前向数值、局部导数和有限差分。

行列分片、局部梯度和集合通信。

保存与重算的峰值和计算次数。

有限精度、稳定归一化与误差检查。

每张卡读到哪些样本词表分片的 loss 流水线执行顺序多请求与物理 KV 块综合理解检查

从代码到可信 checkpoint 的操作顺序

从小规模验证开始，再逐步扩大计算量和并行规模。

单 batch 过拟合

用极小数据确认 tokenizer、loss、mask、反传与 checkpoint 能闭环；loss 应能明显下降。

代表性数据小跑

测真实长度分布、吞吐和显存峰值。记录 tokens/s、step time、grad norm、dataloader wait。

扩大并行与 batch

逐级增加 GPU/accum；先确认数值等价或可解释差异，再追求吞吐。检查通信和 checkpoint 写入瓶颈。

定期评估与放行

目标指标 + 邻近任务 + 生成样例 + 失败集。只有证据通过，才让新 checkpoint 进入下游或重建索引。

训练事故的排查顺序

下面按症状列出观测信号和排查步骤，结合数据、梯度、运行状态与评估结果定位。

GPU 利用率周期性掉到 0

先看 dataloader wait、共享存储吞吐、worker 数与 shard 大小。常见原因是 CPU tokenization 在训练时才做、每步去读小文件、batch 预处理不同步。把清洗和 tokenization 离线化、预取 shard、固定长度/bucket 往往比换 GPU kernel 更有效。

loss 突然尖峰或变成 NaN

同时看 raw loss、grad_norm、学习率、被跳过的 optimizer step、混合精度溢出。检查数据 shard 是否损坏、长度是否异常、attention mask 是否正确、是否需要 bf16/fp16 loss scaling、梯度裁剪与 warmup。先定位发生在哪个 step 和哪条数据，再谈修模型。

OOM 发生在第 3 个 microbatch

activation 会额外占用显存。看峰值是否随 T、microbatch 或图像/文档长度增长；尝试 activation checkpointing、序列 bucket、减少 microbatch、增加 accumulation，或换 ZeRO/FSDP。先用 profiler 区分参数、activation 和碎片。

单卡 loss 正常，多卡反而变差

比较全局 batch、学习率、warmup、gradient accumulation 与数据分片。检查 all-reduce 是否在正确时机发生、样本是否被重复或漏读、随机种子是否在同一 rank 重复。扩大 batch 往往要重新调学习率和训练预算。

SFT 生成效果差，但 token loss 下降

token CE 衡量“在参考答案前文下预测下一个 token”，不等于端到端生成质量。检查 chat template、EOS、assistant mask、推理 stopping、packing 泄漏和是否对长答案过度加权；加 heldout 生成评测与人工样例。

后训练后检索指标下降

先确认你拿的是同一个 embedding 接口：pooling、projection、normalize、instruction prefix 是否变。再检查 SFT 数据是否改变了表示、后训练目标是否与检索一致、索引是否用新模型重建。查询向量和文档索引应采用兼容的模型与编码协议。