简介这份PPT资料系统梳理了AI大模型的核心知识框架面向人工智能初学者、算法入门者及需要快速建立认知的技术从业者帮助解决大模型概念零散、发展脉络不清的问题。内容围绕参数规模、算力需求、模型精度与演进历程展开涵盖Transformer、BERT、GPT-3、ViT、CLIP、DALL·E等代表性模型并延伸至FLAN的模型压缩思路与国内盘古、悟道、ERNIE等大模型布局兼顾自然语言处理、视觉与多模态三条技术路线。资源包内含1个PPT文件压缩包约2.51MB以图文并茂的幻灯片形式呈现便于课堂讲解、组会分享或个人自学时快速查阅。目前已有3481人学习下载适合作为大模型入门科普、技术汇报素材或课程教学参考帮助读者在较短时间内建立从基础概念到产业格局的整体认知。1. 大模型参数、算力、精度到底在讲什么一次把三个词拉回同一张表很多人第一次接触大模型是从一份 PPT 开始的。那份 PPT 上通常有三组数字参数量多少亿、训练用了多少张卡、精度是 FP16 还是 BF16。看完之后感觉懂了但真到自己要选模型、估成本、写部署方案时又发现这三个词根本对不上号——参数大不等于效果好卡多不等于训得快精度高不等于推理便宜。这篇笔记就围绕「大模型的参数规模、算力、精度以及发展」这条线把一份 PPT 里最容易讲糊的三件事拆开参数规模决定什么、算力怎么换算、精度怎么选。目标很具体——让你看完能自己拉一张表把手上要做的模型方案填进去知道每一格该写什么数、这个数从哪来、写错了会在哪里翻车。适合正在做模型选型、训练预算评估、推理部署方案的人也适合需要把技术方案讲给非技术同事听的人。2. 参数规模从 7B 到 70B多出来的参数到底花在哪2.1 参数量不是「知识量」先分清三层结构一份讲大模型的 PPT 里参数量通常写在第一页。但参数量本身不说明任何事得先知道这些参数分布在哪。主流 Transformer 结构里参数主要落在三块嵌入层embedding、注意力层attention、前馈层FFN。以常见的 decoder-only 结构为例FFN 往往占掉总参数的六成以上注意力层占两到三成嵌入层在小模型里占比高、在大模型里被摊薄。这意味着两件事。第一同样标 7B 的两个模型如果词表大小不同、层数不同实际能力分布可能差很远。第二参数量增长不是线性的能力增长而是和训练 token 数、数据质量绑在一起看的。常见做法是参考 Chinchilla 那类缩放结论给定算力预算参数量和训练 token 数要按比例配参数翻倍、token 也要跟着涨否则就是「大模型欠训练」表现反而不如小一号但喂饱的模型。我一般会建议在方案表里把参数量拆成三列写总参数、非嵌入参数、激活参数如果是 MoE。只写总参数后面算显存和算力时一定会对不上。2.2 用一段脚本把参数量算清楚而不是抄别人给的数与其信 PPT 上的数字不如自己按结构算一遍。下面这段脚本按 decoder-only 结构估算参数量输入是层数、隐藏维度、FFN 中间维度、词表大小和序列长度。# 估算 decoder-only Transformer 的参数量不含 bias量级估算够用 def estimate_params(n_layers, d_model, d_ff, vocab_size, n_headsNone): # 每层注意力QKV 投影 输出投影约 4 * d_model^2 attn 4 * d_model * d_model # 每层 FFN常见是两层线性d_model - d_ff - d_model ffn 2 * d_model * d_ff per_layer attn ffn # 嵌入层输入 embedding若权重共享则输出层不额外计 embed vocab_size * d_model total n_layers * per_layer embed return { per_layer: per_layer, embed: embed, total: total, total_billion: round(total / 1e9, 2), } # 一组常见量级的配置仅用于演示计算方式 print(estimate_params(n_layers32, d_model4096, d_ff11008, vocab_size32000))这段代码的逻辑很直白把每层拆成注意力和 FFN 两块乘层数再加嵌入层。参数说明上d_ff取 11008 这类非 4 倍d_model的值是因为不少开源结构用了门控 FFN中间维度不是整数倍关系。算出来的数和你看到的标称值有 5% 到 10% 的偏差是正常的因为 bias、归一化层、位置编码这些没算进去。它的价值不是精确复现而是让你在改层数、改维度时立刻看到参数量往哪走。提示如果模型用了 MoE总参数和激活参数要分开算。总参数决定显存占用激活参数决定单次前向的算力两者混在一起写后面预算一定错。2.3 参数规模和显存、并行的对应关系参数量一旦确定下一步就是它要占多少显存。训练时显存不只是权重还有梯度、优化器状态、激活值。用 Adam 这类优化器混合精度下每个参数大约要 16 到 20 字节权重 2 字节、梯度 2 字节、优化器一阶二阶各 4 字节、再加一份 FP32 主权重 4 字节。一个 7B 模型光这部分就接近 112GB 到 140GB单卡放不下必须上并行。常见做法是70B 以下优先张量并行加流水并行70B 以上再叠数据并行和 ZeRO 这类分片策略。这里不展开每种并行的通信代价只记一个判断顺序——先看单层能不能放进单卡放不下就切张量并行层数多、单卡放得下但整体放不下就切流水并行再不够才用数据并行加优化器分片。顺序反了通信开销会把省下来的显存又吃回去。3. 算力把「多少张卡跑多少天」换算成能对比的数3.1 算力单位先统一别在 PFLOPS 和卡天数之间来回跳PPT 上常见的两种写法一种是「用了 2000 张卡训练 30 天」另一种是「总计算量约 3e23 FLOPs」。这两种写法不能直接比得先统一。换算的核心公式是总 FLOPs ≈ 6 × 参数量 × 训练 token 数。这个 6 是前向 2 次加反向 4 次的粗略系数量级估算够用。有了总 FLOPs再除以硬件有效算力和利用率就能得到卡天数。有效算力不是标称峰值要乘一个利用率系数训练大模型时这个系数常见在 0.3 到 0.5 之间取决于并行策略、通信、数据加载是否打满。把利用率当成 1 去估预算会差一倍以上这是血泪经验。3.2 一段换算脚本从 token 数推到卡天数# 从参数量、token 数推算训练所需卡天数 def training_budget(params_billion, tokens_billion, gpu_peak_tflops, utilization0.4, n_gpus1024): # 总计算量6 * N * D单位 FLOPs total_flops 6 * params_billion * 1e9 * tokens_billion * 1e9 # 单卡有效算力TFLOPS 转 FLOPs/s effective gpu_peak_tflops * 1e12 * utilization total_seconds total_flops / (effective * n_gpus) days total_seconds / 86400 return { total_flops: f{total_flops:.2e}, days: round(days, 1), gpu_days: round(days * n_gpus, 0), } # 演示70B 模型、2T token、单卡峰值按常见训练卡量级填 print(training_budget(params_billion70, tokens_billion2000, gpu_peak_tflops990, utilization0.4, n_gpus2048))逻辑说明先算总 FLOPs再算集群每秒有效算力相除得到秒数。参数上utilization是最需要按实际情况调的小集群、通信差、数据管道弱可能只有 0.25调优好的大集群能到 0.5。gpu_peak_tflops要填对应精度的峰值FP16 和 FP8 差一倍填错精度结果直接错一倍。这个脚本的用途是快速对比不同方案不是精确排期。3.3 推理算力和训练算力是两笔账训练算力是一次性投入推理算力是持续支出两者算法完全不同。推理的单次计算量约等于 2 × 参数量 × 生成 token 数但真正卡住成本的是显存带宽和并发。一个 70B 模型在 FP16 下权重就要 140GB单卡放不下要么多卡要么量化。我一般会按「每千 token 成本」来横向比方案先测单请求延迟再测不同并发下的吞吐最后用吞吐反推每千 token 的卡时。只看单请求延迟会高估成本因为推理可以批处理批大小上去之后吞吐提升很明显。这一步没有捷径得实测。4. 精度FP32、FP16、BF16、FP8 怎么选选错会怎样4.1 精度不是越高越好是「够用且稳」精度这件事新手容易走两个极端要么全用 FP32 求稳要么直接上 FP8 求快。实际选型看三件事数值范围、训练稳定性、硬件支持。FP16 动态范围窄训练时容易溢出需要 loss scalingBF16 范围和 FP32 接近训练更稳是现在训练的主流FP8 在支持它的硬件上能进一步省显存和提吞吐但对校准和缩放要求高不是所有任务都能直接换。推理侧的选择更宽松。很多场景 FP16 和 BF16 效果几乎无差INT8 量化在多数生成任务上掉点可控INT4 就要看任务对细节的敏感度。常见做法是先跑 BF16 基线再试 INT8掉点超过阈值再退回。4.2 混合精度训练的关键参数和常见配置# 混合精度训练的关键配置示意以常见训练框架的参数命名为例 mixed_precision_config { compute_dtype: bf16, # 前向反向计算精度 master_weight_dtype: fp32, # 主权重保持 FP32更新更稳 loss_scale: dynamic, # FP16 训练时开BF16 一般不需要 initial_scale: 2**16, # 动态 loss scale 初值 min_scale: 1.0, scale_window: 2000, # 多少步没溢出就尝试放大 }逻辑说明compute_dtype决定算得快不快master_weight_dtype决定更新稳不稳这两个分开是混合精度的核心。loss_scale只在 FP16 下必须BF16 因为范围够大通常可以关掉。scale_window调小会让缩放更激进溢出风险上升调大则更保守训练前期可能偏慢。这几个参数没有万能值得看任务和硬件。4.3 精度对显存和吞吐的实际影响把精度从 FP32 换到 BF16权重和激活显存大约减半吞吐通常提升 1.5 到 2 倍。再换到 FP8显存还能再降吞吐再提但前提是硬件原生支持且校准做得好。这里有个容易忽略的点精度降低后通信量也跟着降分布式训练里通信往往是瓶颈所以精度带来的实际加速可能比纸面算的还多。注意量化到 INT4 时一定要在目标任务上做评测不要只看困惑度。生成任务里困惑度变化不大但事实性、格式遵循可能明显变差这类掉点在通用指标上看不出来。5. 避坑与排查参数、算力、精度对不上时的五个典型现场5.1 显存估算够了一跑就 OOM现象按参数量算显存明明够启动训练立刻 OOM。原因只算了权重没算激活值和临时缓冲区序列长度一长激活值能超过权重占用。解决把序列长度、批大小、激活重计算策略一起纳入估算先从小序列跑通再往上加。5.2 卡天数估出来很漂亮实际跑了两倍时间现象预算表上写 30 天实际跑了 60 天还没完。原因利用率按 0.5 估实际只有 0.25通信和数据加载没打满。解决先跑 100 步测实际吞吐用实测值反推别用理论峰值。5.3 换了 BF16 之后 loss 出现尖刺现象FP32 训练平稳换 BF16 后偶发 loss 尖刺。原因某些算子对数值范围敏感或梯度累积与缩放配置不匹配。解决先定位是哪个算子必要时对该部分保留 FP32或调整梯度裁剪阈值。5.4 量化后模型「看起来正常」评测掉点现象INT8 量化后人工试几个问题都正常跑评测集发现掉点明显。原因量化误差在长尾输入上被放大人工试的样本太集中。解决用覆盖目标任务分布的评测集别用几个随手问题下结论。5.5 参数量对不上方案评审被问住现象PPT 写 70B自己按结构算出来 68B 或 72B被追问。原因嵌入层是否共享、bias 是否计入、MoE 是否算激活参数口径不一致。解决在方案里明确写清口径总参数、非嵌入参数、激活参数分列避免歧义。6. 把三个词收进一张可复用的方案表前面拆了参数、算力、精度三块最后落到一个具体技巧做一张能复用的方案表把这三个词放进同一行任何模型方案都按这张表填。表里至少要有这些列模型名、总参数、激活参数、训练 token 数、总 FLOPs、目标精度、训练卡数、预估卡天数、推理精度、单卡显存需求、每千 token 成本。填不满的格子就是方案里还没想清楚的地方。字段含义常见取值来源总参数全部权重数量结构计算或官方标称激活参数单次前向参与计算的参数MoE 模型必填训练 token 数训练数据规模数据管道统计总 FLOPs6 × 参数 × token脚本估算目标精度训练计算精度BF16 为主流训练卡数集群规模资源排期预估卡天数总 FLOPs / 有效算力实测利用率反推推理精度部署精度FP16 / INT8 / INT4单卡显存需求权重加激活加缓存实测或估算每千 token 成本推理经济性实测吞吐反推这张表的价值在于它逼你把「参数大」和「算力够」和「精度省」放在一起看。单独看任何一个数都能讲得很漂亮放一起才会暴露矛盾参数大、精度高、卡又少这三件事不可能同时成立。我自己的习惯是任何模型方案先填这张表填的过程中发现哪一列填不出来就先别往下写 PPT。验证方法也很直接拿一个你已经跑过的小模型把真实数据填进去看预估卡天数和实际差多少。差得离谱说明利用率或精度口径有问题先修表再修方案。这个习惯帮我省过很多次返工——有一次方案评审前夜就是靠这张表发现推理精度和显存需求对不上连夜改了部署方案不然上线当天就得回滚。希望帮到你。本文还有配套的精品资源点击获取