真实面经题目 · 原创解析
这道题考察能否把 LLM 训练时间从经验判断转成可计算的工程估算。核心公式是总训练 FLOPs 除以集群有效算力：dense decoder-only 模型可用约 6 × 参数量 × token 数估算前向加反向训练 FLOPs，再除以 GPU 数、单卡峰值 FLOPs 和硬件利用率或 MFU。好的回答还要说明单位换算、序列长度和 attention 开销、MoE active 参数、数据并行扩展效率、checkpoint/eval/restart 等 wall-clock 修正因素。
估算 LLM 训练时间可以按三步走。第一步估总计算量，如果题目已经给 total FLOPs 就直接使用；如果只给 dense 模型参数量 N 和训练 token 数 T，常用粗略估算是训练 FLOPs ≈ 6NT，6 来自前向和反向中参数相关矩阵乘的主要成本。长上下文、特殊 attention、embedding、logits、MoE 或多模态模块要额外修正，MoE 应看每个 token 激活的 active parameters 而不是总参数。第二步估有效算力：有效 FLOPs/s = GPU 数量 × 单卡峰值 FLOPs × 利用率，利用率最好用 MFU 或实测 achieved TFLOPs，而不是只看显卡标称峰值。第三步相除得到纯计算时间，再加上数据加载、通信、pipeline bubble、checkpoint、评测、故障恢复和集群排队等 wall-clock overhead。例如 7B dense 模型训练 1T tokens，总量约 42e21 FLOPs；若 1024 张 312 TFLOPS GPU、MFU 40%，有效算力约 1.28e17 FLOPs/s，纯计算约 3.8 天，实际项目可能因 overhead 增加到 4 到 6 天或更久。
先明确 N 是模型参数量，T 是训练 token 数，F 是总训练 FLOPs，G 是 GPU 数，P 是单卡峰值 FLOPs/s，u 是硬件利用率或 MFU。若题目给的是每秒 tokens、step time 或 batch size，也可以反推吞吐再估时间，但最稳的表达是从计算量除以有效算力。
对 dense decoder-only Transformer，训练主计算通常近似为 6NT，其中前向约 2NT，反向对激活和权重梯度再带来约 4NT。这个公式忽略了一些 attention 二次项和非矩阵乘开销，但作为早期容量规划很常用。
当 sequence length 很长时，attention 的 O(L^2) 成本不能完全忽略；词表很大时 lm head 也可能明显；MoE 模型要用每 token 激活专家对应的 active 参数，而不是总专家参数；如果有多模态 encoder、额外 loss 或重复计算，也要加入额外 FLOPs。
集群有效算力不是 G × P 的理论值，而是 G × P × u。u 可以来自历史训练的 MFU、HFU 或 profiler 统计。通信、kernel 效率、batch size、activation checkpointing、并行策略和网络拓扑都会影响 u，因此新模型估算最好给出乐观、正常、保守三档。
纯计算时间 = total_FLOPs / effective_FLOPs_per_second。结果要做单位换算：TFLOPS 是 1e12 FLOPs/s，PFLOPS 是 1e15 FLOPs/s，一天是 86400 秒。很多错误估算来自把 token 数、参数量的 B/T 单位和 FLOPs 的指数写错。
另一个校验口径是 tokens/s。若已知全局 batch tokens 和 step time，则训练时间 = T / tokens_per_second。它和 FLOPs 口径应该大致一致；如果差距很大，说明 MFU 估错、batch 配置不稳定，或者计算量公式漏掉了长序列、MoE、重算等成本。
真实训练时间要在纯计算时间上加 overhead，包括 checkpoint 写入、周期评测、数据管道阻塞、worker 重启、坏卡替换、弹性训练恢复、日志与监控开销、pipeline bubble、gradient accumulation 尾步和集群调度等待。大规模训练中这些开销可以从几个百分点到几十个百分点不等。
专业回答不应只给单点数字，而应说明假设。例如在 MFU 35%、40%、45% 下分别是多少天；checkpoint 和评测按 10% overhead 后是多少；如果 GPU 数减半，时间近似翻倍但通信效率可能变化。这样估算才适合容量规划和风险沟通。
推理每生成一个 token 主要做一次前向矩阵乘，参数相关计算大致是 2N；训练还要保存或重算激活，并计算激活梯度和权重梯度，反向成本通常约为前向两倍，所以合计常用 6NT 作为粗估。
MFU 衡量模型实际完成的有效 FLOPs 相对硬件峰值的比例，更贴近训练计算效率。nvidia-smi utilization 只是 GPU 是否忙的采样比例，通信等待、低效 kernel 或内存搬运也会显示忙，因此不能代表有效矩阵计算吞吐。
MoE 每个 token 只路由到少数专家，实际参与前向和反向的参数是 active parameters，而不是全部专家参数。总参数决定存储、通信和加载压力，但计算量应按激活专家数、路由策略和负载均衡情况修正。
不一定。MLP 和大部分投影计算大致随 token 数线性增长，但标准 attention 的 score 和加权部分含有 O(L^2) 项；长上下文下二次项、显存压力和重算策略会让时间增长超过线性。
activation checkpointing 不保存全部中间激活，而是在反向传播时重新计算部分前向结果，因此显存下降的代价是额外计算。它可能允许更大 batch 或更长序列，但单 step 计算时间通常会上升。
先用试跑得到稳定 tokens/s、step time 分解和 MFU，再按目标 token 数估算纯训练时间；随后修正 GPU 数扩展效率、通信拓扑、checkpoint 和评测频率。最好用两三个规模点拟合，而不是假设线性扩展。
