先给结论：预训练基础设施规划应先定义模型规模和训练负载，再筛选集群架构，但两者要尽早交叉验证。只看参数量，可能低估长序列带来的显存压力；先定集群，也可能发现目标模型无法高效运行。可执行的顺序是“定负载—估资源—选架构—做基准测试—调整计划”。
先把“模型规模”说完整
参数量是起点，不是完整需求。至少要确定模型类型、参数规模、上下文长度、精度、训练 token 目标、期望训练周期，以及是否采用全参数训练。序列长度会影响激活值占用和计算量；优化器、重计算和分片方式，则会改变单卡内存需求。
可用数量级检查排除明显不合适的方案。例如，7B 参数模型用 BF16 存储权重，权重本身约需 14GB；这不等于训练只需 14GB。混合精度 Adam 训练时，参数相关状态的内存占用可能约为每参数 12—20 字节，具体取决于实现和分片方式，且尚未计入激活值、临时缓冲和运行开销。70B 模型的参数相关状态合计可能达到约 0.84—1.4TB，需分布到多张加速卡上。
这些估算是容量筛查，不是采购清单。预训练基础设施规划还要写明训练数据规模和数据管线要求，例如数据是否已完成去重、如何分片读取，以及能否持续供给训练进程。
架构不要凭峰值算力拍板
单机多卡适合先验证代码、并行策略和数据流程，部署与排错相对直接，但扩展上限受单机资源约束。多机集群能够扩大总算力和内存容量，却增加节点间通信、故障恢复和作业调度的复杂度。两种方案都要比较实际吞吐，而不是只比较标称算力。
结合模型选择并行方式
数据并行让不同设备处理不同批次，通常易于理解，但每步需要同步梯度；张量并行把单层计算拆到多设备，对设备间通信更敏感；流水线并行把模型分层放置，可容纳更深的模型，但微批次安排不当会出现设备空闲。实际训练可以组合使用，优先从团队熟悉、框架支持成熟的路径开始。比如在 PyTorch 中评估 FSDP，或在 JAX 中使用设备网格组织分片；是否合适仍取决于模型结构和目标硬件。
用短测把规划落到实处
- 固定代表性负载：选定目标模型的主要层型、序列长度、精度和批次配置，不要用过小模型替代。
- 估算并排除：计算权重及训练状态的总量，再给激活值、通信和运行缓冲留余量；内存不够时，评估分片、重计算或缩短序列等选项。
- 搭建候选拓扑：比较单机与多机方案，并核对设备间互联、节点网络、存储读取和软件栈兼容性。网络规格再高，如果数据读取或算子支持成为瓶颈，也无法换来相应训练吞吐。
- 跑端到端基准：用目标数据管线完成预热后的连续训练，记录每秒 token、设备利用率、显存余量、通信等待和故障恢复表现。结果需注明软硬件版本及测试配置，避免把一次短测当成长期效率保证。
- 按结果调整规模：根据实测吞吐估算完整训练周期，并计入评估、检查点保存和作业中断后的重跑时间，再决定增加设备、缩小模型或调整训练目标。
检查点（checkpoint）间隔也应纳入计划：保存太频繁会占用存储和训练时间，间隔太长则故障后可能损失更多进度。应通过实际保存耗时和恢复测试确定间隔，而非只按固定经验值设置。
判断顺序：模型先定边界，架构再做验证
所以，预训练基础设施规划不是“先选模型”或“先买集群”的单选题。先冻结足以估算的负载边界，再用候选架构的基准结果修正模型规模、并行策略和训练周期。如果团队尚未确定最终模型，可先按上下限设计，例如分别评估一个较小基线和目标规模；但必须把两者的序列长度、训练精度等假设写清楚。
常见问题
只有参数量，能估出需要多少设备吗？
不能。还需知道精度、优化器、序列长度、并行方式和单设备内存，并用目标配置验证。
先买设备再适配模型，可以吗？
适合需求尚未明确的实验环境，但正式训练前应确认算子兼容、互联效率和数据读取能力；否则容易出现设备闲置。
小模型测出来的吞吐能直接外推吗？
不宜直接外推。模型层数、隐藏维度、序列长度及通信占比变化后，吞吐可能改变，应使用接近目标负载的配置复测。
什么情况下应重新做预训练基础设施规划？
模型结构、上下文长度、训练周期或硬件拓扑发生明显变化时，应重新估算并基准测试；原有结论未必仍适用。
