怎样核算训练成本：token、计算量、耗时与峰值显存

token 先分清分母#

在 SFT 中，模型读取提示和回答，通常只对选定的回答位置计算损失。因此至少记录输入 token、目标 token和填充位置。

假设两个样本各有 800 个提示 token、200 个回答 token。它们共有 2000 个非填充输入位置，400 个监督目标。若每条都补到 1024 长度，批张量中有 2048 个位置，另有 48 个填充位置。

如果处理这批用了 0.5 秒，可以报告每秒 4000 个非填充 token、800 个目标 token，或 4096 个张量位置。三个吞吐量都能算，但不能混着比较。

目标位置没有计损失，不意味着其余输入免费。后续回答仍要以提示为条件，通常需要处理提示的前向计算和相关梯度路径。具体内核是否跳过填充或采用变长处理，要检查实现，不能仅凭掩码假定节省了对应算力。

同一批数据重复三个 epoch，若无丢弃或截断，模型会读取三遍。原始语料的唯一 token 数与训练累计读取量不同；训练成本通常更关心后者，同时保留重复比例以解释数据利用。

6ND 是什么样的近似#

对某些稠密 Transformer 的全参数训练，可以用参数量 N、累计处理 token 数 D 估算主要矩阵计算量：

直觉是，矩阵乘法中的一次乘加按两个运算计，前向主要参数计算约为 2N 每 token，反向再贡献大约两倍前向，合起来约 6N。Kaplan 等人的计算口径与忽略项见 Scaling Laws 第 2.1 节。

这里不能把 N、D 随便替换。引用这类估算时要说明参数是否排除嵌入、是否忽略注意力随序列长度增长的部分，以及 token 是否包含实际计算的填充。它不是对所有模型与训练方式都精确成立的定律。

若取 N=1 亿、D=1000 万，则得到：

FLOPs 在这里表示运算总量，不是每秒速度。用这个数除以硬件标称峰值，只能得到非常理想化的时间下界式估算；真实任务还有利用率、内存访问、通信、数据读取和运行时开销。

LoRA 冻结了大部分权重，也仍需经过基础模型的前向和部分反向路径。因此不能把 6ND 中的 N 直接换成可训练适配器参数量，就宣称获得相同比例的计算节省。节省的优化器状态与实际算量需要分别核算。

相同 token 数，不同长度仍可能不同成本#

考虑标准稠密注意力中与长度平方有关的部分。两条长度 1024 的序列，其平方和是 2×1024²；一条长度 2048 的序列，则为 2048²，后者是前者的两倍。

总 token 数都是 2048，但这部分计算不同。这并不表示整个训练成本必然翻倍：线性层、注意力实现、批量效率和是否存在跨样本屏蔽都影响总成本。

打包也要区分目的。减少填充可以提高有效位置比例，但拼接不同样本时要确认边界与注意力规则。若为了省填充而让一个样本看到另一个样本不应提供的信息，改变的就不只是效率。

所以吞吐报告除了 token/s，还应保留序列长度分布、批大小、打包与掩码方式。平均长度相同，也可能有不同的长尾和峰值显存。

权重文件大小不是训练显存#

训练通常还需要梯度、优化器状态、保存的激活和临时缓冲。Transformers 的训练内存说明按这些组成解释了为什么训练占用远大于权重本身。固定版本文档

我们明确指定一个教学账本：每参数低精度权重 2 字节、低精度梯度 2 字节、FP32 主权重 4 字节、两个 FP32 Adam 状态各 4 字节。合计为 16 字节每参数。

1 亿参数对应 16 亿字节，约 1.49 GiB。这只覆盖这份假设账本中的参数相关状态，还没有计入激活、临时空间、通信缓冲或运行时占用。

不同实现可能不用主权重，或用 FP32 梯度、分片状态、量化优化器与卸载；不能把“16 字节”当成固定常数。文档中的另一种混合精度账本也可能给出不同总数，关键是逐项列出假设。

分布式分片可以减少每张卡保存的某些状态，但不能简单把所有占用都除以卡数。激活、临时聚合和通信空间可能有不同的分布方式。最终需要测量每个设备的峰值，而不是只看总文件大小。

峰值、常驻和缓存占用要分开#

一个任务平时只占较少内存，某次长样本或保存检查点时却超出容量，仍然无法稳定运行。记录峰值时，要说明测量覆盖哪些阶段，是否包括优化器第一次创建状态、评测生成和检查点保存。

框架统计的已分配张量内存、分配器保留内存和系统工具看到的进程占用，也不是同一个口径。不要把不同工具的数字放在一起，直接解释成内存泄漏。

激活重计算可以用额外计算换取更低的保存激活需求；卸载可以用主机内存与传输换取设备空间。这些改动可能让任务从无法运行变为可运行，却未必提高每秒速度。容量约束与吞吐目标应分别报告。

训练更快，不代表整个实验同样快#

构造一个总耗时 100 分钟的实验：训练计算 70 分钟，其他环节 30 分钟。如果某项优化把训练部分加速两倍，整体时间为 35+30=65 分钟，整体加速约为：

不是两倍。若数据处理、验证与保存占比很高，只优化训练内核的收益会受限制。

测量也要有边界。预热、编译、数据缓存、异步设备执行是否被正确计入，会影响结果。测稳定吞吐可以单独报告预热后区间；报告完整作业时间则应从声明的起点统计到结束。只测主机提交操作的时间，不等于设备已经完成计算。

同一设备、相同精度与工作负载下的重复测量，比跨设备猜测更能说明优化效果。还应记录其他任务是否争用资源，而不是把某次机器空闲带来的优势当成算法收益。

后训练还要计算生成与反馈#

强化学习中的采样、工具执行、奖励计算和参数更新都消耗资源。若每个问题生成多条长轨迹，再做多轮打分，更新本身可能只占总成本的一部分。

偏好学习可能需要收集成对回答；模型评审需要额外推理；人工复核需要时间。数据清洗、去重、存储、下载与版本管理也不是零成本。

建议把端到端账本分为数据准备、候选生成、反馈与筛选、训练、验证、失败重跑。即使暂时不能换算成金额，也可以记录 CPU/GPU 小时、token、存储与人工工时，避免只展示最便宜的一段。

研究总账不能只保留最后一跑#

假设十次配置探索各花 2 小时，最终选中的运行用了 2 小时。可以报告最终训练成本 2 小时，但整个探索已花 20 小时。如果还有失败任务、数据生成与评测，应继续累加，不能把它们从研究成本里消失。

两张卡运行一小时是两 GPU 小时，但不保证与一张卡运行两小时等效；不同设备和互连也不能按小时直接互换。金额需要当时实际计费、资源类型和时间记录，本文不使用任何未核对的云价格。

比较方法时最好同时看效果和成本。一个方案在相同效果下更省，或相同成本下更好，才是较清楚的优势。若一个更快、另一个更准，报告权衡而不是强行给出单一赢家。

把估算和测量留在不同列#

一份成本报告至少应标出：配置与长度分布、累计输入与目标 token、计算量估算假设、完整耗时与稳定吞吐、各设备峰值内存、失败和额外反馈成本。

本文脚本只核对 token 分母、6ND 算例、长度平方项、假设内存账本与局部加速的总时间，没有测量硬件性能。实际实施时先用小规模运行校准估算，再扩大规模，同时保留估算误差。这样成本数据才既能帮助安排资源，也能约束研究结论。