大模型训练用了多少TB数据

刷到某模型训练数据几百 TB、上万亿 token 之类的说法，回头一看各家口径都不一样，根本没法拿来比较。这篇帮你把「训练用了多少数据」拆成几个可核对的维度：原始文本量和清洗后留存量的差别、token 与 TB 怎么换算、多轮和多模态数据算不算重复计数，最后给一套自己去站内查当时数字的路径。

刷到「某模型训练数据几百 TB」「语料上万亿 token」之类的说法，回头一对，发现各家口径完全不一样，根本没法拿来比较。问题通常不在数字本身，而在于报出来的是哪一层数据：是原始抓取量，还是清洗去重之后真正能用的量，还是实际过了一遍的训练消耗量。

这篇不讲结论式排名，只给你一套可核对的拆解方法：原始量和留存量的差别怎么问、TB 和 token 怎么对齐、多轮和多模态算不算重复计数，以及想去引用某个数字时该到站内哪个页面看当时的记录。

同一件事，为什么各家报的数字差那么多

最容易被忽略的是口径分层。原始抓取量可以非常大，但经过质量过滤、去重、敏感内容剔除之后，能进入训练的实际留存往往小一大截。如果两家一个报抓取量、一个报留存后可用量，表面差出一个量级是正常的，不代表谁的数据更差。

• 先问一句话：这个数说的是语料池大小，还是训练实际消耗量，重复轮次有没有被乘进去
• 再问清洗链路：去重强度、质量过滤门槛不同，留存比例差别很大，不能只看抓取侧
• 最后问语言构成：同样字节数折成 token 数，中文、英文、代码之间差得远，跨语言直接比 TB 没意义

TB 和 token 不是一回事，怎么对齐

TB 是存储体积，token 是模型实际处理的单元，两者之间靠「每 token 平均字节数」这个桥梁换算。问题在于这个均值浮动很大：中文密度高、英文稀疏、代码里符号多，混进去还会再变。所以任何换算都只能当区间看，别当精确值用。

1. 第一步：确认体积口径问清是压缩前还是压缩后的体积。压缩包和解压后的明文差得很明显，直接把压缩包体积当训练数据量是最常见的坑。
2. 第二步：确认编码形式确认是不是 UTF-8 明文存储。同样一段内容在不同编码下占的字节数不同，不确认这一点就没法做换算。
3. 第三步：确认多模态是否混入图片、音频按各自编码方式占体积，不能简单折成文本 token 混进总数。如果对方报的总量里含多模态样本，要先拆出来再比。
4. 第四步：反推区间而不是点值按每 token 平均字节数反推时给一个区间，并标注这个区间只适用于哪类语料，避免被下游当成硬数字引用。

多轮训练还有个容易混的地方：同一批语料跑多个 epoch，语料池没变大，但训练消耗量会成倍上去。如果一方报语料池、一方报消耗量，看起来差好几倍，其实说的不是同一件事。

想引用当时的数字，去哪查

口径会随技术报告更新，所以任何具体数字都别从记忆里抄，直接去站内看当时记录的那一版。站内收录时一般会标注这个数是哪一层口径，比转述二手说法可靠。

模型资料与规格

先到 /models 和 /training 看，站内收录的是当次核对过的口径说明

算力与训练开销

去 /compute/training-cost 看，那一页讲的是消耗侧，不是语料侧

跨来源对比

优先看 /benchmarks/registry 和 /about 的检测口径说明，确认两个数是不是同一个定义

这些数字什么时候别当真

训练数据量最常被误用的地方，是拿来推断模型能力强弱。语料多不等于质量高，去重强度、配比设计、清洗门槛对最终效果的影响往往比总量更大，单看一个 TB 数很容易得出反直觉的结论。

• 别把训练数据量当能力指标：规模只是原料侧的一个维度，配比和清洗质量没写出来就说明不了问题
• 别把预训练数据量套到自家微调预算上：微调用的数据量和预训练完全不是一个量级，混着算会严重高估成本
• 别在没确认编码和压缩口径前做换算：压缩包体积、UTF-8 明文、token 数三者不能直接互换
• 不适用场景：想估算自己的训练成本，看数据 TB 数没用，要按参数规模和算力口径算，去 /compute/training-cost 核对

训练数据量是原料清单，不是能力证明；先问清口径，再决定这个数能不能用。