ByteDance Pretraining 10T Parameter Model 这个关键词组合最近在技术社区里流传度很高。第一眼看到时很多人会把“10T Parameter”直接读成“10 万亿参数的模型”。如果这是指模型参数量那在当前的硬件和算法水平下几乎不可能成立如果是指预训练数据量也就是 10T10 万亿tokens那这正好踩在大规模语言模型预训练工程的核心位置上。含义不同后续讨论的技术问题完全不同。这篇文章不从新闻角度评判任何公司或数字口径而是从预训练工程的视角把 10T 级别的 pre-train 拆成几个可以独立理解和排查的部分数据管线、并行训练、稳定性控制、过程评测、生产发布。读完你会得到一张完整的技术地图知道 10T 这个量级背后真正难在哪里也能把其中的经验映射到自己的小规模训练任务上。1. 先搞清楚 10T 到底指什么tokens、参数还是显存1.1 “10T Parameter” 很可能是对数据规模的表达在大语言模型领域Parameter 和 Token 是两个经常被混用的概念但它们的工程含义完全不同。术语含义常见量级举例与可训练性的关系Parameter模型权重参数总量7B、13B、70B、数百 B参数越多单卡显存和并行难度越大Token训练数据切分后的最小文本单位1T、2T、10T tokenstoken 总量决定训练步数和总算力消耗Batch一次迭代输入模型的样本集合4096 到数百万 tokens影响收敛稳定性和吞吐Context Length单条样本的最大长度2048、8192、32K、128K影响显存和注意力计算复杂度一个 7B 参数的模型用 1T 到 2T tokens 做预训练在今天已经不算罕见。到了 10T 这个量级模型参数量不一定会成倍增长但训练数据量、GPU 集群规模、训练天数和稳定性要求会明显上升。外界讨论“ByteDance Pretraining 10T Parameter Model”时比较合理的理解是这家公司把一组模型放在至少 10T tokens 级别的数据上进行预训练参数规模可能在几十 B 到数百 B 之间。10T 这样的数字作为营销口径很容易被传播但作为工程指标它真正描述的是数据规模而不是模型规模。1.2 10T tokens 预训练项目包含哪些核心模块把预训练理解为“把数据喂给模型跑几万亿 tokens”会低估它的复杂度。一个 10T tokens 级别的预训练项目至少包含这样几条流水线数据生产线采集、清洗、去重、语言过滤、质量过滤、安全过滤、配比采样。Tokenizer 与词表词表大小、分词算法、是否加入特殊 token、词表版本锁定。模型结构transformer 层数、隐藏维度、注意力头数、激活函数、注意力实现方式。并行训练策略数据并行、张量并行、流水并行、显存切分、序列并行。优化器与学习率调度AdamW、global batch、warmup、cosine 衰减、最小学习率。日志、监控与检查点loss、grad norm、吞吐、tokens seen、定时保存、断点回滚。过程评测与安全过滤固定评测集、阶段性评测、内容安全规则、发布前审计。这些模块不是先后顺序关系而是同时运行、相互影响的关系。数据配比变了loss 曲线会变并行策略错了显存直接爆掉检查点策略不完善一次硬件故障就可能损失几天算力。10T 预训练看起来是一个训练任务实际上是一套复杂的工程系统。1.3 学习环境与生产环境差异很大普通开发者在自己电脑、单机多卡服务器上跑模型与在万卡集群上跑 10T tokens差的不是“模型更大”而是“故障处理方式完全不同”。维度学习/研究环境生产预训练环境数据规模几 GB 到几百 GB10T tokens 级别PB 级文本设备数量1 到 8 卡数百到数万卡检查点可选断掉重跑即可必须且需要分钟级回滚能力监控本地日志全链路指标、告警、自动剔除坏卡数据更新静态数据集动态数据流持续清洗和采样发布要求能跑通就算成功需要评测、安全、合规、可回溯理解这些差异之后再看 10T 预训练的技术难点就不会只盯着“尺寸”两个字。2. 数据管线决定模型上限训练只是把上限兑现出来2.1 数据清洗的目标不是“干净”而是“均衡”很多人在小规模训练时对数据不敏感因为数据量少随便清洗就能训练。到了 10T tokens 级别数据清洗目标会从“去掉脏数据”变成“控制分布”。清洗通常包括这些操作文本去重去掉重复网页、重复段落避免模型背数据。质量过滤去掉乱码、纯广告、无意义文本。语言过滤按目标语言控制语种比例。安全过滤过滤色情、暴力、仇恨言论、隐私信息等违规内容。领域配比网页、代码、书籍、数学、多语言文本按比例混合。这里容易被误解的是“越干净越好”。在实际项目中数据质量需要与数据多样性做平衡。如果只保留质量极高的百科类文本模型会缺少代码、对话、口语化表达等能力。更好的做法是给每条样本打上来源、语言、领域、质量分等标签然后按规则采样。示例 JSONL 格式{text: 这是从技术社区抓取的一段文本内容……, source: web, lang: zh, category: tech, quality_score: 0.92} {text: def hello_world():\n print(hello), source: code, lang: code, category: python, quality_score: 0.87}这些字段的价值在训练时体现采样器可以根据source、category、quality_score动态调整配比而不需要重新生成数据集。数据配比不是一次定死的而是通过小规模实验不断调整。2.2 Tokenizer 词表大小直接影响成本和训练效果Tokenizer 决定文本被切成什么 token也间接决定模型的输入输出维度。常见词表大小有 32K、64K、128K 等。词表越大单 token 表示的信息越充分但嵌入层参数也会变大。嵌入层参数量的简化计算公式embedding 参数量 ≈ vocab_size * hidden_size * 2这里乘以 2是因为嵌入层和输出层通常共享权重。以vocab_size 128000、hidden_size 8192为例128000 * 8192 * 2 ≈ 2.1B 参数这个数字说明仅词表和 embedding 就可能占据模型参数的很大比例。如果模型整体是 70B2.1B 还可以接受如果是一个 7B 的小模型2.1B 就明显偏重了。实际项目中的做法是先在小规模语料上训练和对比 tokenizer关注平均 token 长度、稀有 token 占比、OOV 情况再决定词表大小。Tokenizer 一旦训练完成并进入预训练阶段就不能随意更换因为模型参数分布已经和词表绑定。2.3 采样配置与 Batch 设计要一起看数据配比和 batch 设计不是两个独立环节。采样器按权重从不同数据域抽取样本然后组成 batch。一个偏代码偏少的配比和一个偏代码偏多的配比会影响模型最终能力曲线。示意配置data: max_seq_len: 4096 global_batch_size_tokens: 4000000 micro_batch_size: 2 gradient_accumulation_steps: 8 sampling: - dataset: web_zh weight: 0.45 - dataset: code weight: 0.25 - dataset: book weight: 0.15 - dataset: math weight: 0.15这里的max_seq_len决定模型能处理多长的上下文global_batch_size_tokens表示一个优化步看到的 token 总数micro_batch_size和gradient_accumulation_steps共同决定显存占用。常见误区是只看 batch 数量不看 token 数。对于大模型预训练业界更习惯用 global batch tokens 来描述 batch。同一批数据上下文长度越长能装进去的样本越少但每个样本的信息量更大。这个参数需要结合学习率和训练动态调整不是一个可以随便拍板的数字。3. 并行训练策略DP、TP、PP、FSDP 怎么配合3.1 四类并行方式的分工单个 GPU 无法装下大模型参数、梯度、优化器状态所以需要把模型切到多张卡上。常见的并行方式有四种。并行方式切分对象主要通信类型典型适用场景DP / DDP数据样本每步同步梯度小模型多机多卡代码简单FSDP / ZeRO优化器状态、梯度、参数分片 all-gather / reduce-scatter中大规模训练显存受限时TP张量并行单层内的参数切分每层内 all-reduce超大模型跨多卡计算单层PP流水并行按层切分到不同设备前后向微批通信多机多卡超大模型数据并行最简单但它只解决“数据多”的问题不解决“单卡放不下模型”的问题。FSDP 通过把优化器状态分片能让更多参数跑起来但通信开销不能忽略。TP 把一层参数切成多份适合单机内部高速互联。PP 按层切分适合跨机场景但需要处理流水线气泡和微批调度。3.2 一个 10T tokens 规模训练任务的并行配置示例不同框架的配置参数名不同下面用伪配置文件说明思路。# 仅用于说明并行配置思路实际参数名以所用框架版本为准 train_config { model: { hidden_size: 8192, num_layers: 80, num_attention_heads: 64, seq_len: 4096, vocab_size: 128000, }, parallelism: { tensor_model_parallel_size: 8, pipeline_model_parallel_size: 8, data_parallel_size: 512, use_flash_attention: True, }, optimizer: { type: AdamW, lr: 3e-4, min_lr: 3e-5, weight_decay: 0.1, beta1: 0.9, beta2: 0.95, lr_decay_style: cosine, warmup_frac: 0.001, }, activation_recomputation: True, bf16: True, }tensor_model_parallel_size 8表示一个 transformer 层被切成 8 份通常要求单机内至少有 8 张卡通信走 NVLink 或 IB。pipeline_model_parallel_size 8表示模型按层切成 8 段跨机分片。data_parallel_size 512表示整体数据并行规模很大是吞吐量扩展的主力。hidden_size、num_layers、num_attention_heads需要满足一些整除约束。常见约束包括hidden_size / num_attention_heads必须能整除hidden_size / tp_size必须能整除num_layers / pp_size必须能整除。这些约束一旦不满足框架会在启动时报错。3.3 激活重计算、梯度累积和 bf16 不是可选项对于 10T tokens 级别的训练下面三个配置直接影响能不能在有限显存里完成训练。激活重计算Activation Recomputation用“重新计算”代替“保存激活值”显著降低显存占用代价是增加了计算量。实际项目中可以只对部分 transformer 层开启全重算减少重算带来的吞吐损失。这个开关属于典型的“用时间换显存”。梯度累积Gradient Accumulation让微批先计算梯度但不更新累积到指定步数后再统一更新参数。它解决的是 global batch 与单卡显存的矛盾。global_batch_size_tokens / (micro_batch_size * seq_len * dp_size)就是梯度累积步数。累积步数越大global batch 越大但与学习率之间的配比也必须重新考虑。bf16 混合精度在训练中很常用。模型前向和反向用 bf16 计算优化器状态用 fp32 保存既节省显存又比 fp16 更容易避免溢出。但开启 bf16 后loss scaling 策略、梯度裁剪阈值、日志里观察到的 loss 精度都会变化不能照搬 fp32 训练的经验。4. 稳定性控制Loss Spike 是预训练第一大敌人4.1 Loss Spike 的常见原因与处理Loss spike 指训练过程中 loss 突然跳高可能很快恢复也可能持续恶化。在小规模训练里遇到 spike 重跑一遍成本不高在 10T tokens 级别重跑代价极大所以必须在训练设计阶段就准备好排查手段。现象可能原因检查方式处理建议loss 单点跳高后快速恢复数据里混入异常样本检查 spike 前后 batch 的数据分布过滤问题样本对照日志重试该步loss 阶梯式上升且不回落学习率过大或数据配比突然变化查看 lr、grad_norm、数据采样权重降低学习率或从健康 checkpoint 恢复训练过程中出现 nan / infbf16 溢出、优化器状态异常检查 loss scale、grad_norm、耗时日志从最后一个健康 checkpoint 恢复检查数据数值范围训练 hang 住或吞吐骤降单卡掉线、通信超时、硬件故障查看硬件日志、通信日志、节点状态剔除坏卡从 checkpoint 恢复loss 长期不降数据信号不足、任务太难或学习率过低对比小规模消融实验的 loss 曲线调整数据配比、batch、学习率排查 loss spike 时最重要的一点是保留足够的上下文。否则即使发现 loss 异常了也无法定位它出现在哪个数据范围、哪一步、哪张卡。4.2 训练日志、检查点和回滚机制生产预训练的训练日志至少应该包含这些字段step12345 loss1.234 lr2.5e-4 grad_norm1.23 tokens_seen512000000000 throughput45000_tokens/s gpu_count4096 ...tokens_seen比step更重要因为它能反映真实数据消耗量。throughput用于判断集群利用率是否正常。grad_norm用于判断训练稳定性梯度范数异常增大往往是 loss spike 的前兆。检查点不能只保存模型权重还要保存optimizer 状态当前 step数据采样指针随机数生成器状态学习率调度器状态回滚时如果只恢复模型权重而没恢复数据指针训练会重复或漏掉一段数据如果没恢复优化器状态学习率和动量会错乱。生产环境建议每隔一定步数保存一次检查点并演练从故障检查点恢复到继续训练的全流程。这些演练在训练开始前就要做不能真正故障了才开始试。4.3 一条可复用的排查链路遇到训练异常时按下面的顺序排查不要一开始就怀疑模型结构。先确认硬件和通信状态查看节点健康状态、GPU 温度、有无掉卡、通信日志是否报错。再确认训练是否真的停了看tokens_seen是否还在增长loss 日志是否更新。然后定位数据问题调出异常 step 前后的数据样本检查是否出现乱码、超长文本、空文本或配比跳变。最后才怀疑参数和数值问题检查 lr 是否正常、grad_norm 是否异常、loss scale 是否被更新。这个顺序的核心逻辑是先排除环境问题再检查输入再检查优化过程。倒过来排查容易在模型结构上浪费时间。5. 训练中如何评估不是跑完 10T 才看效果5.1 用小规模消融实验先跑通方案10T tokens 的训练不可能等到全部跑完再验证效果。合理做法是先用小模型、小数据跑出可信的实验结果再把配比、超参、模型结构迁移到大任务。消融实验的规模可以这样设计实验维度小规模值生产规模值模型参数0.5B 到 3B数十 B 到数百 B数据量10B 到 100B tokens10T tokens 级别GPU 数量8 到 64 卡数千卡训练目的验证数据配比、超参、稳定性产出最终模型小规模实验虽然不能完美预测大规模训练的最优超参但可以快速暴露数据管线问题、并行配置问题和稳定性问题。数据配比如果在小批量实验里明显失衡放到 10T 规模只会更严重。5.2 用固定评测集做过程评测预训练过程中需要周期性评测不能只看训练 loss。训练 loss 下降不能保证下游任务表现好因此要准备一个固定版本、可重复的评测集。一个典型过程评测集包含语言建模评测困惑度PPL看模型对文本的拟合能力。常识推理如 BoolQ、PIQA、HellaSwag 等。代码能力用代码补全或代码题集。数学能力用数学题集评估推理能力。多语言能力按部署地区准备对应语种评测。评测集一旦确定训练期间就不要随意增删题目否则不同阶段之间的对比就失去了意义。评测结果要写入日志或数据库中方便追踪“某个数据配比调整后哪个能力下降了”。5.3 一个最小评测脚本示例下面是一个最简化的过程评测逻辑用于说明评测脚本的结构。# 最小过程评测脚本实际项目中需要加入分布式采样、tokenizer 对齐等逻辑 def evaluate(model, tokenizer, eval_samples): total_loss 0.0 count 0 model.eval() for batch in eval_samples: inputs tokenizer( batch[text], paddingTrue, truncationTrue, return_tensorspt, max_length2048, ) with torch.no_grad(): outputs model( input_idsinputs[input_ids], labelsinputs[input_ids], ) total_loss outputs[loss].item() count 1 return total_loss / count这个脚本的核心是固定评测数据、固定 tokenizer、固定 max_length。评测时不要启用 dropout不要更新参数不要混入随机噪声。如果评测结果和训练 loss 趋势矛盾优先检查 tokenizer 版本和评测数据是否被污染。6. 从研究实验到生产预训练的落地差异6.1 三种环境的配置差异很多开发者能跑通单机训练但没接触过生产级预训练。下面从配置维度对比三者的差异。维度学习环境研究/开发环境生产预训练环境数据规模几 MB 到几 GB几十 GB 到几 TBPB 级10T tokens并行规模单卡单机 8 卡或小规模多机数千卡以上检查点不必要定时保存分钟级回滚能力监控看终端日志loss、吞吐指标全链路监控、告警、自动容错数据安全低要求基础权限数据权限、内容安全、合规审计发布流程直接运行代码评审评测、安全、审批、灰度学习环境的关键目标是“跑通”研究环境的关键目标是“可复现”生产环境的关键目标是“可控”。同一个训练脚本在这三种环境下的配置差异很大。6.2 发布前检查清单无论是发布一个预训练模型还是发布一条数据管线都应该有可执行的检查清单。这里给出一个预训练发布前清单。数据配比和过滤规则有文档记录且版本可回溯。Tokenizer 版本已锁定和训练数据一致。并行配置与硬件拓扑匹配整除约束全部满足。检查点周期设置合理并完成过回滚演练。loss spike 告警阈值已配置梯度范数监控已启用。过程评测集固定版本评测逻辑可重复执行。内容安全过滤规则已跑过全量数据抽样验证。模型权重、Tokenizer、配置文件的哈希校验已完成。日志字段完整tokens_seen、throughput、loss等指标可回溯。发布口径与技术报告中的参数规模和训练数据规模一致。这个清单不一定覆盖所有业务场景但它能避免一些低级发布事故。6.3 普通开发者的下一步扩展方向如果读者不在大厂预训练团队仍然可以从这篇文章里提炼出几个可操作的练习方向。第一个方向是跑通一个 1B 到 3B 模型的完整预训练流程用 5B 到 10B tokens 的数据验证数据管线、训练配置、日志、检查点、过程评测这条链路。第二个方向是强化排错能力主动在训练中制造问题比如加入脏数据、调大学习率、模拟掉卡然后练习从日志和指标中定位原因。第三个方向是理解下游链条预训练只是第一步后面还有继续预训练、SFT、RLHF、模型压缩和部署这些环节对模型的影响同样值得深入。最后说一个判断10T 级别的预训练真正难的不是参数规模这个数字而是数据分布的可控性和万卡集群的稳定性。模型结构、并行策略、优化器配置都可以靠现成框架解决但数据配比是否均衡、检查点是否能回滚、loss spike 能不能快速定位这些工程能力决定了训练能否长期稳定推进。对大多数开发者而言最有价值的练习不是盲目追求跑更大的模型而是把一个小规模训练任务跑稳能读懂 loss 曲线能设计固定评测集能在训练异常时从日志里找到原因。具备这套能力之后再看 10T、百 B 这类数字你关注的不再是新闻热度而是它背后的数据、算力和工程系统。
预训练10T tokens：数据、并行与稳定性的工程全景
ByteDance Pretraining 10T Parameter Model 这个关键词组合最近在技术社区里流传度很高。第一眼看到时很多人会把“10T Parameter”直接读成“10 万亿参数的模型”。如果这是指模型参数量那在当前的硬件和算法水平下几乎不可能成立如果是指预训练数据量也就是 10T10 万亿tokens那这正好踩在大规模语言模型预训练工程的核心位置上。含义不同后续讨论的技术问题完全不同。这篇文章不从新闻角度评判任何公司或数字口径而是从预训练工程的视角把 10T 级别的 pre-train 拆成几个可以独立理解和排查的部分数据管线、并行训练、稳定性控制、过程评测、生产发布。读完你会得到一张完整的技术地图知道 10T 这个量级背后真正难在哪里也能把其中的经验映射到自己的小规模训练任务上。1. 先搞清楚 10T 到底指什么tokens、参数还是显存1.1 “10T Parameter” 很可能是对数据规模的表达在大语言模型领域Parameter 和 Token 是两个经常被混用的概念但它们的工程含义完全不同。术语含义常见量级举例与可训练性的关系Parameter模型权重参数总量7B、13B、70B、数百 B参数越多单卡显存和并行难度越大Token训练数据切分后的最小文本单位1T、2T、10T tokenstoken 总量决定训练步数和总算力消耗Batch一次迭代输入模型的样本集合4096 到数百万 tokens影响收敛稳定性和吞吐Context Length单条样本的最大长度2048、8192、32K、128K影响显存和注意力计算复杂度一个 7B 参数的模型用 1T 到 2T tokens 做预训练在今天已经不算罕见。到了 10T 这个量级模型参数量不一定会成倍增长但训练数据量、GPU 集群规模、训练天数和稳定性要求会明显上升。外界讨论“ByteDance Pretraining 10T Parameter Model”时比较合理的理解是这家公司把一组模型放在至少 10T tokens 级别的数据上进行预训练参数规模可能在几十 B 到数百 B 之间。10T 这样的数字作为营销口径很容易被传播但作为工程指标它真正描述的是数据规模而不是模型规模。1.2 10T tokens 预训练项目包含哪些核心模块把预训练理解为“把数据喂给模型跑几万亿 tokens”会低估它的复杂度。一个 10T tokens 级别的预训练项目至少包含这样几条流水线数据生产线采集、清洗、去重、语言过滤、质量过滤、安全过滤、配比采样。Tokenizer 与词表词表大小、分词算法、是否加入特殊 token、词表版本锁定。模型结构transformer 层数、隐藏维度、注意力头数、激活函数、注意力实现方式。并行训练策略数据并行、张量并行、流水并行、显存切分、序列并行。优化器与学习率调度AdamW、global batch、warmup、cosine 衰减、最小学习率。日志、监控与检查点loss、grad norm、吞吐、tokens seen、定时保存、断点回滚。过程评测与安全过滤固定评测集、阶段性评测、内容安全规则、发布前审计。这些模块不是先后顺序关系而是同时运行、相互影响的关系。数据配比变了loss 曲线会变并行策略错了显存直接爆掉检查点策略不完善一次硬件故障就可能损失几天算力。10T 预训练看起来是一个训练任务实际上是一套复杂的工程系统。1.3 学习环境与生产环境差异很大普通开发者在自己电脑、单机多卡服务器上跑模型与在万卡集群上跑 10T tokens差的不是“模型更大”而是“故障处理方式完全不同”。维度学习/研究环境生产预训练环境数据规模几 GB 到几百 GB10T tokens 级别PB 级文本设备数量1 到 8 卡数百到数万卡检查点可选断掉重跑即可必须且需要分钟级回滚能力监控本地日志全链路指标、告警、自动剔除坏卡数据更新静态数据集动态数据流持续清洗和采样发布要求能跑通就算成功需要评测、安全、合规、可回溯理解这些差异之后再看 10T 预训练的技术难点就不会只盯着“尺寸”两个字。2. 数据管线决定模型上限训练只是把上限兑现出来2.1 数据清洗的目标不是“干净”而是“均衡”很多人在小规模训练时对数据不敏感因为数据量少随便清洗就能训练。到了 10T tokens 级别数据清洗目标会从“去掉脏数据”变成“控制分布”。清洗通常包括这些操作文本去重去掉重复网页、重复段落避免模型背数据。质量过滤去掉乱码、纯广告、无意义文本。语言过滤按目标语言控制语种比例。安全过滤过滤色情、暴力、仇恨言论、隐私信息等违规内容。领域配比网页、代码、书籍、数学、多语言文本按比例混合。这里容易被误解的是“越干净越好”。在实际项目中数据质量需要与数据多样性做平衡。如果只保留质量极高的百科类文本模型会缺少代码、对话、口语化表达等能力。更好的做法是给每条样本打上来源、语言、领域、质量分等标签然后按规则采样。示例 JSONL 格式{text: 这是从技术社区抓取的一段文本内容……, source: web, lang: zh, category: tech, quality_score: 0.92} {text: def hello_world():\n print(hello), source: code, lang: code, category: python, quality_score: 0.87}这些字段的价值在训练时体现采样器可以根据source、category、quality_score动态调整配比而不需要重新生成数据集。数据配比不是一次定死的而是通过小规模实验不断调整。2.2 Tokenizer 词表大小直接影响成本和训练效果Tokenizer 决定文本被切成什么 token也间接决定模型的输入输出维度。常见词表大小有 32K、64K、128K 等。词表越大单 token 表示的信息越充分但嵌入层参数也会变大。嵌入层参数量的简化计算公式embedding 参数量 ≈ vocab_size * hidden_size * 2这里乘以 2是因为嵌入层和输出层通常共享权重。以vocab_size 128000、hidden_size 8192为例128000 * 8192 * 2 ≈ 2.1B 参数这个数字说明仅词表和 embedding 就可能占据模型参数的很大比例。如果模型整体是 70B2.1B 还可以接受如果是一个 7B 的小模型2.1B 就明显偏重了。实际项目中的做法是先在小规模语料上训练和对比 tokenizer关注平均 token 长度、稀有 token 占比、OOV 情况再决定词表大小。Tokenizer 一旦训练完成并进入预训练阶段就不能随意更换因为模型参数分布已经和词表绑定。2.3 采样配置与 Batch 设计要一起看数据配比和 batch 设计不是两个独立环节。采样器按权重从不同数据域抽取样本然后组成 batch。一个偏代码偏少的配比和一个偏代码偏多的配比会影响模型最终能力曲线。示意配置data: max_seq_len: 4096 global_batch_size_tokens: 4000000 micro_batch_size: 2 gradient_accumulation_steps: 8 sampling: - dataset: web_zh weight: 0.45 - dataset: code weight: 0.25 - dataset: book weight: 0.15 - dataset: math weight: 0.15这里的max_seq_len决定模型能处理多长的上下文global_batch_size_tokens表示一个优化步看到的 token 总数micro_batch_size和gradient_accumulation_steps共同决定显存占用。常见误区是只看 batch 数量不看 token 数。对于大模型预训练业界更习惯用 global batch tokens 来描述 batch。同一批数据上下文长度越长能装进去的样本越少但每个样本的信息量更大。这个参数需要结合学习率和训练动态调整不是一个可以随便拍板的数字。3. 并行训练策略DP、TP、PP、FSDP 怎么配合3.1 四类并行方式的分工单个 GPU 无法装下大模型参数、梯度、优化器状态所以需要把模型切到多张卡上。常见的并行方式有四种。并行方式切分对象主要通信类型典型适用场景DP / DDP数据样本每步同步梯度小模型多机多卡代码简单FSDP / ZeRO优化器状态、梯度、参数分片 all-gather / reduce-scatter中大规模训练显存受限时TP张量并行单层内的参数切分每层内 all-reduce超大模型跨多卡计算单层PP流水并行按层切分到不同设备前后向微批通信多机多卡超大模型数据并行最简单但它只解决“数据多”的问题不解决“单卡放不下模型”的问题。FSDP 通过把优化器状态分片能让更多参数跑起来但通信开销不能忽略。TP 把一层参数切成多份适合单机内部高速互联。PP 按层切分适合跨机场景但需要处理流水线气泡和微批调度。3.2 一个 10T tokens 规模训练任务的并行配置示例不同框架的配置参数名不同下面用伪配置文件说明思路。# 仅用于说明并行配置思路实际参数名以所用框架版本为准 train_config { model: { hidden_size: 8192, num_layers: 80, num_attention_heads: 64, seq_len: 4096, vocab_size: 128000, }, parallelism: { tensor_model_parallel_size: 8, pipeline_model_parallel_size: 8, data_parallel_size: 512, use_flash_attention: True, }, optimizer: { type: AdamW, lr: 3e-4, min_lr: 3e-5, weight_decay: 0.1, beta1: 0.9, beta2: 0.95, lr_decay_style: cosine, warmup_frac: 0.001, }, activation_recomputation: True, bf16: True, }tensor_model_parallel_size 8表示一个 transformer 层被切成 8 份通常要求单机内至少有 8 张卡通信走 NVLink 或 IB。pipeline_model_parallel_size 8表示模型按层切成 8 段跨机分片。data_parallel_size 512表示整体数据并行规模很大是吞吐量扩展的主力。hidden_size、num_layers、num_attention_heads需要满足一些整除约束。常见约束包括hidden_size / num_attention_heads必须能整除hidden_size / tp_size必须能整除num_layers / pp_size必须能整除。这些约束一旦不满足框架会在启动时报错。3.3 激活重计算、梯度累积和 bf16 不是可选项对于 10T tokens 级别的训练下面三个配置直接影响能不能在有限显存里完成训练。激活重计算Activation Recomputation用“重新计算”代替“保存激活值”显著降低显存占用代价是增加了计算量。实际项目中可以只对部分 transformer 层开启全重算减少重算带来的吞吐损失。这个开关属于典型的“用时间换显存”。梯度累积Gradient Accumulation让微批先计算梯度但不更新累积到指定步数后再统一更新参数。它解决的是 global batch 与单卡显存的矛盾。global_batch_size_tokens / (micro_batch_size * seq_len * dp_size)就是梯度累积步数。累积步数越大global batch 越大但与学习率之间的配比也必须重新考虑。bf16 混合精度在训练中很常用。模型前向和反向用 bf16 计算优化器状态用 fp32 保存既节省显存又比 fp16 更容易避免溢出。但开启 bf16 后loss scaling 策略、梯度裁剪阈值、日志里观察到的 loss 精度都会变化不能照搬 fp32 训练的经验。4. 稳定性控制Loss Spike 是预训练第一大敌人4.1 Loss Spike 的常见原因与处理Loss spike 指训练过程中 loss 突然跳高可能很快恢复也可能持续恶化。在小规模训练里遇到 spike 重跑一遍成本不高在 10T tokens 级别重跑代价极大所以必须在训练设计阶段就准备好排查手段。现象可能原因检查方式处理建议loss 单点跳高后快速恢复数据里混入异常样本检查 spike 前后 batch 的数据分布过滤问题样本对照日志重试该步loss 阶梯式上升且不回落学习率过大或数据配比突然变化查看 lr、grad_norm、数据采样权重降低学习率或从健康 checkpoint 恢复训练过程中出现 nan / infbf16 溢出、优化器状态异常检查 loss scale、grad_norm、耗时日志从最后一个健康 checkpoint 恢复检查数据数值范围训练 hang 住或吞吐骤降单卡掉线、通信超时、硬件故障查看硬件日志、通信日志、节点状态剔除坏卡从 checkpoint 恢复loss 长期不降数据信号不足、任务太难或学习率过低对比小规模消融实验的 loss 曲线调整数据配比、batch、学习率排查 loss spike 时最重要的一点是保留足够的上下文。否则即使发现 loss 异常了也无法定位它出现在哪个数据范围、哪一步、哪张卡。4.2 训练日志、检查点和回滚机制生产预训练的训练日志至少应该包含这些字段step12345 loss1.234 lr2.5e-4 grad_norm1.23 tokens_seen512000000000 throughput45000_tokens/s gpu_count4096 ...tokens_seen比step更重要因为它能反映真实数据消耗量。throughput用于判断集群利用率是否正常。grad_norm用于判断训练稳定性梯度范数异常增大往往是 loss spike 的前兆。检查点不能只保存模型权重还要保存optimizer 状态当前 step数据采样指针随机数生成器状态学习率调度器状态回滚时如果只恢复模型权重而没恢复数据指针训练会重复或漏掉一段数据如果没恢复优化器状态学习率和动量会错乱。生产环境建议每隔一定步数保存一次检查点并演练从故障检查点恢复到继续训练的全流程。这些演练在训练开始前就要做不能真正故障了才开始试。4.3 一条可复用的排查链路遇到训练异常时按下面的顺序排查不要一开始就怀疑模型结构。先确认硬件和通信状态查看节点健康状态、GPU 温度、有无掉卡、通信日志是否报错。再确认训练是否真的停了看tokens_seen是否还在增长loss 日志是否更新。然后定位数据问题调出异常 step 前后的数据样本检查是否出现乱码、超长文本、空文本或配比跳变。最后才怀疑参数和数值问题检查 lr 是否正常、grad_norm 是否异常、loss scale 是否被更新。这个顺序的核心逻辑是先排除环境问题再检查输入再检查优化过程。倒过来排查容易在模型结构上浪费时间。5. 训练中如何评估不是跑完 10T 才看效果5.1 用小规模消融实验先跑通方案10T tokens 的训练不可能等到全部跑完再验证效果。合理做法是先用小模型、小数据跑出可信的实验结果再把配比、超参、模型结构迁移到大任务。消融实验的规模可以这样设计实验维度小规模值生产规模值模型参数0.5B 到 3B数十 B 到数百 B数据量10B 到 100B tokens10T tokens 级别GPU 数量8 到 64 卡数千卡训练目的验证数据配比、超参、稳定性产出最终模型小规模实验虽然不能完美预测大规模训练的最优超参但可以快速暴露数据管线问题、并行配置问题和稳定性问题。数据配比如果在小批量实验里明显失衡放到 10T 规模只会更严重。5.2 用固定评测集做过程评测预训练过程中需要周期性评测不能只看训练 loss。训练 loss 下降不能保证下游任务表现好因此要准备一个固定版本、可重复的评测集。一个典型过程评测集包含语言建模评测困惑度PPL看模型对文本的拟合能力。常识推理如 BoolQ、PIQA、HellaSwag 等。代码能力用代码补全或代码题集。数学能力用数学题集评估推理能力。多语言能力按部署地区准备对应语种评测。评测集一旦确定训练期间就不要随意增删题目否则不同阶段之间的对比就失去了意义。评测结果要写入日志或数据库中方便追踪“某个数据配比调整后哪个能力下降了”。5.3 一个最小评测脚本示例下面是一个最简化的过程评测逻辑用于说明评测脚本的结构。# 最小过程评测脚本实际项目中需要加入分布式采样、tokenizer 对齐等逻辑 def evaluate(model, tokenizer, eval_samples): total_loss 0.0 count 0 model.eval() for batch in eval_samples: inputs tokenizer( batch[text], paddingTrue, truncationTrue, return_tensorspt, max_length2048, ) with torch.no_grad(): outputs model( input_idsinputs[input_ids], labelsinputs[input_ids], ) total_loss outputs[loss].item() count 1 return total_loss / count这个脚本的核心是固定评测数据、固定 tokenizer、固定 max_length。评测时不要启用 dropout不要更新参数不要混入随机噪声。如果评测结果和训练 loss 趋势矛盾优先检查 tokenizer 版本和评测数据是否被污染。6. 从研究实验到生产预训练的落地差异6.1 三种环境的配置差异很多开发者能跑通单机训练但没接触过生产级预训练。下面从配置维度对比三者的差异。维度学习环境研究/开发环境生产预训练环境数据规模几 MB 到几 GB几十 GB 到几 TBPB 级10T tokens并行规模单卡单机 8 卡或小规模多机数千卡以上检查点不必要定时保存分钟级回滚能力监控看终端日志loss、吞吐指标全链路监控、告警、自动容错数据安全低要求基础权限数据权限、内容安全、合规审计发布流程直接运行代码评审评测、安全、审批、灰度学习环境的关键目标是“跑通”研究环境的关键目标是“可复现”生产环境的关键目标是“可控”。同一个训练脚本在这三种环境下的配置差异很大。6.2 发布前检查清单无论是发布一个预训练模型还是发布一条数据管线都应该有可执行的检查清单。这里给出一个预训练发布前清单。数据配比和过滤规则有文档记录且版本可回溯。Tokenizer 版本已锁定和训练数据一致。并行配置与硬件拓扑匹配整除约束全部满足。检查点周期设置合理并完成过回滚演练。loss spike 告警阈值已配置梯度范数监控已启用。过程评测集固定版本评测逻辑可重复执行。内容安全过滤规则已跑过全量数据抽样验证。模型权重、Tokenizer、配置文件的哈希校验已完成。日志字段完整tokens_seen、throughput、loss等指标可回溯。发布口径与技术报告中的参数规模和训练数据规模一致。这个清单不一定覆盖所有业务场景但它能避免一些低级发布事故。6.3 普通开发者的下一步扩展方向如果读者不在大厂预训练团队仍然可以从这篇文章里提炼出几个可操作的练习方向。第一个方向是跑通一个 1B 到 3B 模型的完整预训练流程用 5B 到 10B tokens 的数据验证数据管线、训练配置、日志、检查点、过程评测这条链路。第二个方向是强化排错能力主动在训练中制造问题比如加入脏数据、调大学习率、模拟掉卡然后练习从日志和指标中定位原因。第三个方向是理解下游链条预训练只是第一步后面还有继续预训练、SFT、RLHF、模型压缩和部署这些环节对模型的影响同样值得深入。最后说一个判断10T 级别的预训练真正难的不是参数规模这个数字而是数据分布的可控性和万卡集群的稳定性。模型结构、并行策略、优化器配置都可以靠现成框架解决但数据配比是否均衡、检查点是否能回滚、loss spike 能不能快速定位这些工程能力决定了训练能否长期稳定推进。对大多数开发者而言最有价值的练习不是盲目追求跑更大的模型而是把一个小规模训练任务跑稳能读懂 loss 曲线能设计固定评测集能在训练异常时从日志里找到原因。具备这套能力之后再看 10T、百 B 这类数字你关注的不再是新闻热度而是它背后的数据、算力和工程系统。
