做AI大模型的人基本绕不开同一个问题这个训练任务到底需要多少卡、多少数据、多少天我接触这行最磨人的不是调模型结构而是前期预算——参数量、显存、算力、token数这四个量只要有一个是拍脑袋猜的后面采购、排期、实验设计全都会跟着跑偏。这篇把我在实际项目里用过的估算方法完整梳理一遍目标就一个你拿到一个模型规模能快速回答“要多少数据、多少卡、多少天、多少显存”并且数据精度足够支撑你下单和排期。后面这些公式和结论都是我踩过不少坑之后的沉淀。比如第一次评估一个70B规模的预训练任务时我用“论文里的经验值”估显存结果被虚拟内存、中间激活、KV cache这些隐藏开销打得措手不及。所以这篇文章不是堆公式而是把每一笔开销的来源都拆开给你看同时告诉你哪些数字可以快速心算哪些必须实测。1. 参数规模估算从模型结构推导到快速心算1.1 一个标准Transformer层的参数量到底怎么算现在的LLM基本都跑在Transformer架构上所以从标准Transformer的参数量拆起最实用。设隐藏维度为H也就是每个token经过一层之后的特征向量维度。一个完整的自注意力子层加一个FFN子层参数主要由三块构成。第一块是注意力层里的四个投影矩阵Q、K、V和输出O。在标准实现里这几个矩阵的shape都是H×H所以这一块是4×H²。第二块是FFN常见的是先把H维映射到4H维再用一个线性层把4H维映回H维如果不考虑偏置参数是H×4H加上4H×H总共8H²。第三块是LayerNorm和偏置这类小参数每个LayerNorm大概2H一层有两个数量级很小。所以说一个标准的Transformer层在不计算激活函数的情况下参数量约等于12H²加一点点零头。写成公式就是单层参数 ≈ 12 × H²整个模型的参数还要加上词嵌入矩阵。如果词表大小是V嵌入维度是H那么嵌入参数是V×H。如果输出头与输入嵌入共享权重这部分只计一次如果不共享还要再多一个V×H。位置编码如果是可学习的固定方式通常是小头很多新模型直接用RoPE这类相对位置编码压根不增加参数。举个例子一个隐藏维度4096、32层的模型单层参数约12×4096²≈2.01亿32层就是64.4亿词表按32000算嵌入参数约1.31亿总参数约65.7亿这就是市面上“7B级别”模型的由来。你会注意到嵌入占比很小真正的大头是层数乘上隐藏维度的平方。1.2 三层快速估算不查表也能心里有数实际沟通里没人会拿着公式现场算我习惯直接记三层经验第一层单层参数约等于12 × H²。第二层总参数约等于层数L × 12 × H²加上词表嵌入V×H。第三层反向推理时如果你只知道层数和参数总量可以通过解一个简单的一元二次方程反推隐藏维度不必去翻模型卡片的详细配置。比如某人说“我要做一个约30B的dense模型大概48层”先用总参数减去嵌入估计值再除以48和12就能得到H²的量级。30B减掉嵌入大约1.5B到2B剩下约28B除以48再除以12约4860万开根号约6970。也就是说这种结构大概率用接近6~7K的隐藏维度。这个反推方法在选硬件、对比不同模型时非常好用。再给你一个常用规模速查模型规模典型层数典型隐藏维度参数量大致落在7B32409665~70亿13B405120130~140亿30B486144280~320亿70B808192660~710亿注意这是dense模型的经验值MoE模型完全不一样。MoE的总参数等于共享部分加上每个专家FFN参数的专家数量门控网络还要加一小笔。估算MoE时最容易把“总参数”和“激活参数”混在一起很多MoE号称几百亿甚至上千亿参数但单次推理只激活其中一小部分这种模型对算力的需求要按激活参数算对显存的压力才按总参数算。2. 显存开销估算权重、梯度、优化器与激活值2.1 权重与优化器状态训练显存的大头很多刚入行的人以为模型训练显存就是“参数量乘一个字节数”这是最典型的误区。纯推理阶段确实可以用这个逻辑FP16/BF16精度下每个参数2字节7B模型权重约14GB加上一点KV cache和激活值80G的单卡可以跑一跑。但从头训练完全不是这么回事因为优化器状态太吃显存了。以最常用的Adam类优化器为例。混合精度训练通常会把权重以半精度存储用于前向和反向计算但同时保留一份FP32的权重副本用于参数更新再加上一阶动量m和二阶动量v这两份也都是FP32。梯度的存储方式视框架而定半精度训练下梯度通常是FP16或BF16按2字节算如果按FP32保存则更多。把这几项加一起每参数大约是权重半精度2B 权重FP32副本4B 梯度2B 动量FP32 4B 二阶动量FP32 4B 16字节所以一个7B模型的训练光是权重、梯度、优化器状态这三件套就是7×10⁹×16≈112GB。这还没算任何激活值。这就是为什么单张80G显存卡几乎不可能放下7B模型的从头预训练必须靠ZeRO、FSDP这类策略把状态分片打散到多张卡上或者用CPU offload换显存。有些优化器可以减少状态比如Adafactor不保存完整二阶动量或者用8比特优化器把动量压到1字节或2字节但这些方案在大模型预训练里用得相对少。主流的稳定路线仍然是Adam类优化器加分片策略所以我在业务评估时一律先按16字节算后面再根据技术方案打折。2.2 激活值最容易被低估的一笔开销权重和优化器状态是“购买时就能算清”的显存激活值才是训练中真正的变量。它的规模取决于三个东西batch size、序列长度、层数和隐藏维度。而且它会在前向过程中动态产生峰值往往出现在某个大矩阵计算附近。一个简单的粗估思路是Transformer每一层都会保存若干份大小为“batch×seq×H”的中间张量比如注意力里的Q、K、V、注意力分数、输出以及FFN里的中间4H维激活。如果中间激活不重计算每层每个token存下的字节数可以达到隐藏维度的几十倍。用公式表示就是激活显存 ≈ L × B × S × H × bytes_per_element × 一个系数这个系数在不同框架和算子实现里差异很大常见范围在30到60之间。举例算一下更容易明白。假设7B模型、H4096、32层batch size8、seq长度4096、半精度2字节系数按40算就是32×8×4096×4096×2×40≈275GB。这意味着如果不做任何优化激活值轻松超过权重相关开销。这就是为什么现在训练长序列模型几乎必开FlashAttention和梯度检查点。FlashAttention的核心思路是不把完整的S×S注意力矩阵写回显存而是分块计算并即时softmax从而省掉那一大块与序列长度平方相关的显存。梯度检查点则更粗暴前向时不保存全部中间激活只存少量关键张量反向要算梯度时重新前向一遍以大约30%的额外计算量换回激活值显存的大幅下降。经验上说开了这两样之后同样的训练任务显存峰值能降到原来的四分之一甚至更低。2.3 用案例推演7B和70B分别要吃多少显存手工估算再详细也不如跑几个具体案例。我用最常见的两个规模来演示。第一个案例7B模型BF16混合精度Adam优化器训练batch size全局设为512序列长度4096。先看纯参数相关显存每参数16字节112GB如果不用任何分片策略一张卡必须能塞下这么多东西显然不行。实际工程会用ZeRO-3或FSDP把参数、梯度、优化器状态切成N份分到N张卡上。假设8卡那么每卡参数相关显存约14GB激活值因为数据并行也会被切到batch中的一部分如果全局batch512单卡batch通常是64算上检查点和FlashAttention激活值可能被压到每卡10~20GB。这样才能在8×80GB的机器里跑得比较从容。这是预训练7B的常见配置。第二个案例70B模型BF16精度纯推理。权重本身约140GB一张80G卡放不下两张又偏满KV cache一旦序列变长立刻爆显存。所以实际场景里要么用INT8/INT4量化把权重压到70GB甚至更低要么用张量并行把权重拆到多卡。至于训练70B模型参数相关显存70×10⁹×161120GB用80G卡要16张才刚好从账面上放下所有权重和优化器状态再算上激活值、通信预留、检查点临时缓冲实际工程至少用32张以上才比较稳。这就是为什么75B级别模型预训练动辄需要上百张甚至几百张卡。这里还有一笔经常被忽略的KV cache。推理阶段每条请求的KV cache大小大约是2×L×S×H×2字节。70B模型、80层、H8192、单条请求、序列长度2048、半精度算下来约5GB看着不大但并发32条请求就是160GB。所以在做线上推理服务显存规划时KV cache经常比模型权重更可怕长上下文和高并发下尤其如此。3. 算力与训练时间估算从FLOPs到卡时3.1 为什么每个参数每token大约要6次浮点运算训练时间估算的核心是浮点运算量。标准Transformer的每一层、每个参数在每个token上前向传播大约要2次浮点运算也就是一次乘加。反向传播要更多因为需要计算权重梯度和输入梯度近一步会叠加额外计算。把前向和反向都算在一起业界广泛采用的经验值是每个参数、每个token大约6次浮点运算。所以总训练浮点运算量的公式特别简单总FLOPs ≈ 6 × 参数量 × 训练token数注意这个公式已经把所有线性层、注意力、FFN、反向计算全部折进去了不包含softmax、LayerNorm这类占比很小的运算。如果你做对比实验这个公式的精度足够。算一个实际数字。7B模型训练1万亿token总FLOPs是6×7×10⁹×10¹²4.2×10²²。这个量级意味着什么如果一台机器能稳定跑出每秒10¹⁵次浮点运算也需要约1.16万小时所以要靠很多卡并行压缩时间。3.2 训练时间公式怎么用7B模型的一笔细账训练时间可以写成一个非常直接的计算式训练天数 总FLOPs ÷ (卡数 × 单卡峰值算力 × 算力利用率) ÷ 86400这里最关键的参数是算力利用率也就是常说的MFU。它衡量的是实际有效算力占硬件理论峰值的比例。真实预训练里MFU通常在40%到60%之间做得特别好的大规模集群能到50%以上但很难超过60%。不用峰值算力直接除就是因为有访存瓶颈、通信延迟、算子启动开销和同步等待在拖后腿。现在假设我们用单卡BF16峰值算力为200 TFLOPS的主流训练卡跑一个7B模型的预训练设定训练数据量1000亿tokenMFU取50%。总FLOPs等于6×7×10⁹×10¹¹4.2×10²¹单卡每秒有效浮点运算等于200×10¹²×0.510¹⁴也就是每秒10万亿次有效计算。卡数取64那么总有效算力是6.4×10¹⁵训练秒数等于4.2×10²¹÷6.4×10¹⁵≈65.6万秒除以86400约7.6天。这个数比较符合实际经验64张200T训练卡训一个7B模型1000亿token的规模一到两周内完成。我建议大家都记住这个算式的变形它不只是用来算日子还能在采购和实验设计时反向用。比如你有多少卡、多少天能反推最多能跑到多少总FLOPs再去匹配模型规模和token量。3.3 一张表快速看不同规模的算力预算为了让刚上手的人能直接不计算就看到结论我按常规参数做了一张速查表。以下都假设单卡BF16峰值约200 TFLOPSMFU50%。模型规模训练token数卡数估算训练天数7B1000亿3215.2天7B1000亿647.6天13B2000亿12814.1天70B1.4万亿512133天70B1.4万亿102466.5天这张表里最醒目的是70B模型1.4万亿token、512卡的训练时间超过4个月。这就是为什么很多团队在70B这个量级会改用MoE架构因为MoE虽然总参数量巨大但每个token实际激活的参数少得多单位token浮点运算量明显下降训练时间会更友好。你要是在初期沟通阶段听到“几十B模型几百卡一个月完成预训练”大概率是激活参数小于总参数的MoE。4. 数据量与Token数估算多少数据不算多4.1 Chinchilla法则20倍参数量的token数从哪来有了参数量另一个绕不开的问题是数据量。现在行业内最常引用的经验规则来自大规模扩展律实验在给定算力预算下模型参数量和训练token数应该同步增长近似关系是训练token数约等于参数量的20倍。这个结论被称为Chinchilla法则后来成了预训练阶段设定数据规模的重要参考。按这个法则来算7B模型大约配1400亿token70B模型大约配1.4万亿token。这跟我在前文算力表里用的数据量基本一致。不过要特别提醒20倍不是教条。如果你在意的是推理成本倾向于在同样预算下把模型做小、把数据喂多比如7B模型训2000亿token如果你的目标是探索模型能力的上限也可以让模型大一些、数据少一些。但在默认情况下20倍作为起点是最稳妥的。数据量还牵扯到重复epoch的问题。现在大规模预训练通常尽量只跑一个epoch最多两个。同一批高质量数据被反复训练会带来严重的过拟合和记忆问题。所以数据准备阶段应该把绝大部分有效数据一次性凑够不要指望把一个小数据池反复塞很多遍来强行凑token数。4.2 从语料库到token文本规模怎么换算当你去收集原始语料时面对的不是“token数”而是“多少GB的文本”。这两者之间的换算关系因语言和清洗程度而异。我这里给一个数量级参考足够日常估算用。英语自然语言经过清洗之后大约每GB文本能产出2.5亿到3亿token中文因为单字和词汇组合更密大约每GB产出3亿到4亿token代码文本视格式化程度约每GB产出2亿到3亿token。这里的“清洗后”非常重要意味着已经去重、去噪、去掉低质量页面。举例说你想训一个7B模型目标token是1400亿。按照英文语料约2.8亿token/GB来算需要准备大约500GB清洗后的英文文本。但原始爬取数据通常包含大量重复和垃圾页面一个常见经验是清洗后有效文本大约只有原始数据的20%到30%。所以真要自己从头攒语料可能要准备2到2.5TB的原始数据。如果你的语料是中文为主按3.5亿token/GB估400GB清洗后的中文文本就差不多了。4.3 反向预算手里的算力到底能喂饱多大的模型参数估算不只是“从模型出发要多少资源”更常见的是“从手里资源出发选择模型规模”。这个反过来的思路是排期谈判里最常用的工具。比如你现在有64张主流训练卡想在一个月内完成一个预训练任务。单卡200TFLOPS、MFU按50%算30天总有效浮点运算等于64×200×10¹²×0.5×30×86400算出来约1.66×10²²。再除以6得到“参数量×token数≈2.76×10²¹”。如果训练token数定在1400亿那模型参数量可以做到约19.7B如果坚持用70B模型同样的算力只能喂约394亿token离Chinchilla要求的1.4万亿差得远。所以别急着拍板“我们就要训一个70B”先看自己的卡时池子有多大。这类反向计算能帮你把一个模糊的念想变成可讨论的数字要么缩小模型要么减少数据要么增加卡数或拉长时间。我在实际项目中最后都是以这张算力预算表作为项目范围的基础。5. 常见问题与排查技巧实录5.1 OOM不一定是参数算错了训练过程中最常见的报错就是显存溢出也就是OOM。很多人第一反应是“我的参数估错了”其实多数时候不是静态权重的问题而是动态激活值或临时张量瞬间暴增。排查这类问题我通常分四步走。第一步先用极小batch size把模型跑起来确认静态的权重、梯度、优化器状态没有超出预算。第二步逐步增大batch size同时用工具记录显存峰值比如PyTorch里用torch.cuda.max_memory_allocated()看峰值是否随batch线性增长。第三步如果峰值涨得比预期快优先检查是不是序列长度相关的注意力矩阵太大或者KV cache累积太多。第四步再考虑开FlashAttention或梯度检查点同时把batch size降下来试试。另外有个很关键的点显存库通常带有缓存机制即使某块显存被释放了也不会立刻还给系统而是留在进程缓存里。所以偶尔看到进程占用的显存很高不一定代表模型当前真的需要这么多而是分配器在复用内存池。排查时以实际分配的模型张量大小为准别被进程监控值骗了。5.2 并行策略怎么改变你的估算结果同样一个模型使用不同并行策略显存和时间估算会有本质差别。这点必须单独拎出来说不然会做出完全错误的采购决策。数据并行是最容易理解的每张卡都复制一份完整的模型权重和优化器状态数据被切成多份。这种策略不降低单卡显存只降低每个batch的处理时间。带ZeRO优化器的数据并行就不同了参数、梯度、优化器状态被切成很多份分到各卡单卡显存约等于原来的一份除以卡数但通信量明显上升尤其是all-gather和reduce-scatter。FSDP也是类似思路。张量并行和张量并行则是把单个层切到多卡上通信更频繁对卡间带宽要求很高。所以通常只在单机内使用跨机张量并行容易通信成为瓶颈。流水并行按层数切分每卡只负责一部分层通信压力相对小但会出现流水线空档需要足够的微批次来掩盖。我给你的实操建议是小规模验证阶段先用数据并行加ZeRO-1或ZeRO-2把训练先跑起来模型大到单份状态放不进一张卡时再引入ZeRO-3或FSDP真正到100B以上级别再考虑流水线和张量并行混合。不要一开始就上最复杂的并行方案会让调试难度直线上升。5.3 一个顺手的小脚本把估算变成函数估算做多了之后我干脆写了个小函数把前文所有公式都塞进去每次谈需求时直接填参数。这里把核心逻辑列出来你可以直接复制改造成自己的工具。def estimate_training( param_num, # 激活参数量比如7e9 token_num, # 训练token数比如1e11 gpu_count, # 卡数 peak_flops200e12, # 单卡BF16峰值算力200 TFLOPS mfu0.5, # 算力利用率 bytes_per_param16, # Adam混合精度训练约16字节 gpu_memory80e9, # 单卡显存 ): total_flops 6 * param_num * token_num effective_flops gpu_count * peak_flops * mfu seconds total_flops / effective_flops days seconds / 86400 # 全参数状态不分片时的显存需求 full_state_bytes bytes_per_param * param_num # 单卡分片后用ZeRO-3时的参数相关显存 per_gpu_state full_state_bytes / gpu_count return { total_flops: total_flops, days: days, full_state_bytes: full_state_bytes, per_gpu_state_bytes: per_gpu_state, per_gpu_state_fit: per_gpu_state gpu_memory * 0.8, } result estimate_training(7e9, 1e11, 64) print(result)这段代码里我把显存计算简化成了参数相关状态真实工程还要再加上激活值。激活值需要单独用实测或更细的模型去估。我的习惯是先用这个函数把训练天数和基本显存算出来再给这个数字增加20%到30%的余量作为采购和排期的“心理安全垫”。5.4 关于MFU和余量的几点避坑心得技术估算做得再好还是要为现实留余量。我总结几条我反复踩过的坑希望你能直接跳过。第一个是MFU的假设别太乐观。等真正跑到大规模多机并行时通信和同步会让整体MFU掉下来。我在新集群上做可行性评估时会先用一个小规模的基准测试跑几天统计真实每秒处理的token数再外推整个训练任务。没有实测数据之前永远不要用50%以上的MFU去给客户画饼。第二个是显存和训练时间都要加余量。显存建议至少留20%给临时张量、框架缓存和显存碎片训练时间建议在公式结果上额外加15%到25%用来覆盖检查点保存、验证评估、数据预处理、容错重训这些不可避免的开销。一次预训练动辄几周甚至几个月只要中途发生一次节点异常损失的时间很容易超过你的安全边际。第三个是检查点存储别忘。训练时定期保存的模型文件大小大约是权重所占总字节数7B模型BF16权重是14GB一份70B模型是140GB一份。如果每半小时存一次再加上保留最近几份存储成本很快就会超过预期。这个成本不一定体现在GPU账单里但一定会出现在项目总预算里。第四个是算力和数据加载的速度要一起看。GPU算得再快如果数据流水线跟不上训练卡也会空转。我见过不少训练任务MFU上不去不是因为卡不行而是数据加载、tokenize、混洗全部挤在CPU侧GPU经常等数据。所以数据量估算不只是算够不够还要考虑能不能“喂得动”。最后所有估算都是为了一个目的在一个数字上达成共识然后继续往前走。没有哪个公式是绝对精确的但有一套稳定的参数体系比每次靠感觉和道听途说要可靠得多。我自己实际使用时的习惯是先把参数量和token数量级定住再用算力公式算出卡时用显存公式判断每卡放不放得下最后用20%余量把预算定死。这套流程跑通之后项目规划和外部沟通都会顺畅很多。希望这篇梳理能让你少走我走过的弯路。
