简介这份PPT资料面向人工智能初学者、算法入门者及技术管理者系统梳理AI大模型的核心知识框架帮助读者快速建立对基础模型的整体认知。内容围绕参数规模、算力需求、模型精度与发展脉络展开涵盖Transformer、BERT、GPT-3、ViT、CLIP、DALL·E等代表性模型并延伸至FLAN的模型压缩思路与国内盘古、悟道、ERNIE等大模型进展兼顾自然语言处理、视觉与多模态方向。资源包内含1个PPT文件压缩包约2.51MB以图文并茂的幻灯片形式呈现便于直接用于学习汇报或内部培训。目前已有3481人学习下载适合希望用较短时间掌握大模型关键概念、主流模型对比及发展趋势的读者参考。1. 大模型参数、算力、精度到底在讲什么一次把 PPT 里最容易讲糊的三件事说清如果你最近被拉去做一份「AI 大模型介绍」的 PPT大概率会遇到这种场面第一页写「参数量 175B」第二页写「训练算力 3.14e24 FLOPs」第三页写「FP16 精度」台下有人问「所以这模型到底强在哪」你发现自己只能把数字再念一遍。问题不在数字而在这三个量之间没有建立起可解释的链条。参数规模决定模型能装下多少知识算力决定这些知识要花多少代价灌进去精度决定灌进去之后还剩多少有效信息——三者是乘法关系不是并列关系。这篇笔记面向需要把大模型讲清楚、并且想自己动手算一遍的工程师从概念到可复现的估算脚本把 PPT 里最容易讲糊的部分拆开。2. 参数规模从 7B 到 70B多出来的参数到底存在哪2.1 参数量不是「知识条数」而是矩阵形状的总和很多人第一次看到「70B 参数」会下意识理解成 700 亿条知识这是最常见的误解。参数量本质上是模型里所有可训练权重张量的元素个数之和。以标准 Transformer 解码器为例主要参数集中在四处词嵌入矩阵、每层的注意力投影矩阵Q/K/V/O、每层的前馈网络矩阵gate/up/down 或 fc1/fc2、以及最后的输出投影通常与词嵌入共享权重。一个粗略但够用的估算公式是参数量 ≈ 词表大小 × 隐藏维度 × 2输入嵌入 输出投影共享时算一次 层数 ×4 × 隐藏维度² 2 × 隐藏维度 × 前馈中间维度。这里的 4 对应 Q/K/V/O 四个投影2 对应前馈的两个大矩阵。把这个公式写成代码你就能在 PPT 里现场验证任何一个公开配置。def estimate_params(vocab_size, hidden_dim, num_layers, ffn_dim, tie_embeddingTrue): # 词嵌入 输出投影tie_embedding 为 True 时只算一份 embed vocab_size * hidden_dim output_proj 0 if tie_embedding else vocab_size * hidden_dim # 每层注意力Q/K/V/O 四个 hidden_dim x hidden_dim 矩阵 attn_per_layer 4 * hidden_dim * hidden_dim # 每层前馈两个 hidden_dim x ffn_dim 矩阵门控结构则为三个 ffn_per_layer 2 * hidden_dim * ffn_dim total embed output_proj num_layers * (attn_per_layer ffn_per_layer) return total # 一个 7B 量级的典型配置 p estimate_params(vocab_size32000, hidden_dim4096, num_layers32, ffn_dim11008) print(f估算参数量: {p/1e9:.2f} B)这段代码里hidden_dim和ffn_dim是最敏感的两个参数。前馈中间维度通常是隐藏维度的 2.7 到 4 倍取 2.7 倍左右是近年为了压缩推理显存常见的做法。tie_embedding在中小模型里常为 True能省下词表 × 隐藏维度这一大块。跑一遍你会发现前馈网络占了总参数的六成以上这解释了为什么量化时前馈层是重点照顾对象。2.2 为什么 PPT 上要同时写「总参数」和「激活参数」如果你讲的是混合专家MoE结构只写一个总参数会误导听众。MoE 把前馈层拆成多个专家每个 token 只激活其中少数几个。总参数可能上百 B但单次前向实际参与计算的激活参数只有十几 B。PPT 上正确的写法是「总参数 XX B / 激活参数 YY B」并注明专家总数与每 token 激活专家数。def moe_params(vocab_size, hidden_dim, num_layers, ffn_dim, num_experts, active_experts, tie_embeddingTrue): embed vocab_size * hidden_dim output_proj 0 if tie_embedding else vocab_size * hidden_dim attn_per_layer 4 * hidden_dim * hidden_dim # 每个专家是一个独立前馈总参数量按全部专家算 ffn_total num_experts * 2 * hidden_dim * ffn_dim # 激活参数量只算被选中的专家 ffn_active active_experts * 2 * hidden_dim * ffn_dim total embed output_proj num_layers * (attn_per_layer ffn_total) active embed output_proj num_layers * (attn_per_layer ffn_active) return total, active total, active moe_params(32000, 4096, 32, 14336, num_experts8, active_experts2) print(f总参数 {total/1e9:.1f} B, 激活参数 {active/1e9:.1f} B)参数说明num_experts是专家总数active_experts是每个 token 路由到的专家数。这两个数字直接决定推理成本和显存占用。讲 PPT 时如果只报总参数听众会误判部署门槛只报激活参数又会低估显存需求——因为所有专家的权重都得加载进显存只是不全部参与计算。2.3 把参数量换算成显存一张表让听众有体感光说数字没有体感PPT 里最实用的一页是把参数量换算成不同精度下的权重显存。换算关系很简单显存 ≈ 参数量 × 每参数字节数。FP32 是 4 字节FP16/BF16 是 2 字节INT8 是 1 字节INT4 是 0.5 字节。参数量FP32FP16/BF16INT8INT47B28 GB14 GB7 GB3.5 GB13B52 GB26 GB13 GB6.5 GB70B280 GB140 GB70 GB35 GB这张表要配一句提醒这只是权重显存实际推理还要加上 KV Cache 和中间激活。KV Cache 随上下文长度线性增长长上下文场景下它可能超过权重本身。讲到这里听众才会明白为什么「70B 模型 INT4 只要 35 GB」听起来能塞进单卡实际部署却依然吃力。3. 算力估算把「训练花了多少卡」翻译成可验证的数字3.1 训练算力的经验公式与它的适用边界训练一个大模型需要多少算力业界常用的估算方式是总计算量 ≈ 6 × 参数量 × 训练 token 数。这个 6 来自前向 2 次乘加、反向 4 次乘加的粗略统计。它是个量级估算不区分注意力里的二次项也不考虑重计算和通信开销所以适合做 PPT 里的数量级说明不适合拿来做精确预算。def training_flops(params, tokens): # 6 是前向反向的乘加系数经验值 return 6 * params * tokens def gpu_days(flops, gpu_peak_flops, utilization0.4): # gpu_peak_flops 为该卡峰值算力utilization 为实际利用率 effective gpu_peak_flops * utilization seconds flops / effective return seconds / 86400 flops training_flops(params7e9, tokens2e12) days_per_gpu gpu_days(flops, gpu_peak_flops3.12e14, utilization0.4) print(f总计算量 {flops:.2e} FLOPs, 单卡约 {days_per_gpu:.0f} 天)参数说明utilization是最容易被忽略也最影响结论的量。大集群里因为通信、气泡、故障重启实际利用率常在 0.3 到 0.5 之间。PPT 上如果按峰值算会得出一个乐观到不真实的卡数按 0.4 算才是能落地的估算。gpu_peak_flops要区分是哪种精度下的峰值BF16 和 FP8 的峰值差一倍混用会直接算错。3.2 推理算力为什么它和训练算力不是一回事训练算力是一次性投入推理算力是持续成本两者在 PPT 里必须分开讲。单次推理的计算量约为 2 × 参数量 × 生成 token 数只看激活参数。但真实服务里瓶颈往往不在算力而在显存带宽——自回归生成是逐 token 的每生成一个 token 都要把权重读一遍带宽决定了吞吐上限。def inference_flops(active_params, output_tokens): # 推理前向只有乘加系数为 2 return 2 * active_params * output_tokens def memory_bound_tokens_per_sec(weight_bytes, bandwidth_gbps): # 权重字节数除以带宽得到理论上限 token/s return bandwidth_gbps * 1e9 / weight_bytes flops inference_flops(active_params7e9, output_tokens512) tps memory_bound_tokens_per_sec(weight_bytes7e9*2, bandwidth_gbps2000) print(f单次推理 {flops:.2e} FLOPs, 带宽上限约 {tps:.0f} token/s)这段代码想说明一个反直觉结论推理速度很多时候不是算力不够而是带宽不够。把权重从 FP16 量化到 INT4字节数减半带宽上限直接翻倍。这也是为什么量化在推理侧收益远大于训练侧。PPT 里放这组对比比单纯罗列卡数更有说服力。3.3 把算力、参数量、token 数放进同一张对照表讲 PPT 时最怕三个数字各说各的。下面这张表把常见规模档位串起来让听众一眼看到「参数涨十倍算力涨多少」。参数量训练 token训练算力约FP16 权重显存1.5B300B2.7e21 FLOPs3 GB7B2T8.4e22 FLOPs14 GB13B2T1.6e23 FLOPs26 GB70B2T8.4e23 FLOPs140 GB表格里的算力按 6 × 参数量 × token 数估算。可以看到参数量从 7B 到 70B 涨十倍算力也涨十倍但显存涨十倍意味着单卡放不下必须切分——这就是并行策略要解决的问题也是下一章精度话题的引子。4. 精度选择FP32、FP16、BF16、INT8 到底怎么选4.1 精度不是「越高越好」而是「动态范围够不够」精度这个词在 PPT 里经常被简化成「位数越高越准」但实际选型看的是动态范围。FP16 有 10 位尾数、5 位指数精度高但范围窄训练时梯度容易溢出BF16 有 7 位尾数、8 位指数范围和 FP32 一致精度略低但训练稳定。这就是为什么现在训练默认 BF16 而不是 FP16——不是因为它更准而是因为它不容易炸。import numpy as np def check_range(dtype, values): # 检查一组数值在目标精度下是否溢出 info np.finfo(dtype) overflow np.any(np.abs(values) info.max) underflow np.any((values ! 0) (np.abs(values) info.tiny)) return overflow, underflow, info.max, info.tiny vals np.array([1e-8, 1.0, 1e5, 1e38], dtypenp.float64) for dt in [np.float16, np.float32]: o, u, mx, tn check_range(dt, vals) print(f{dt.__name__}: 溢出{o}, 下溢{u}, 最大{mx:.2e}, 最小{tn:.2e})跑这段代码你会看到FP16 的最大值约 6.5e41e5 和 1e38 都会溢出FP32 则能容纳。这解释了为什么混合精度训练里要做 loss scaling——把梯度放大再缩回来避免小梯度在 FP16 下变成 0。PPT 里讲这一页比单纯说「我们用 BF16」有信息量得多。4.2 量化精度的实际收益与代价推理侧从 FP16 降到 INT8 或 INT4显存和带宽收益是线性的但精度损失不是线性的。常见做法是只量化权重、保留激活为 FP16或者对敏感层如第一层和最后一层跳过量化。def quantize_symmetric(weight, bits8): # 对称量化以最大绝对值为 scale qmax 2 ** (bits - 1) - 1 scale np.max(np.abs(weight)) / qmax q np.round(weight / scale).astype(np.int32) q np.clip(q, -qmax - 1, qmax) return q, scale def dequantize(q, scale): return q * scale w np.random.randn(1024, 1024).astype(np.float32) q, s quantize_symmetric(w, bits8) w_hat dequantize(q, s) err np.mean((w - w_hat) ** 2) print(fINT8 量化均方误差: {err:.6f})参数说明bits取 8 或 4qmax是对称量化的上限。这段代码演示的是最朴素的对称量化实际工程里会用分组量化每 128 个元素一组 scale来降低误差。你可以把bits改成 4 再跑一遍会看到误差明显上升——这就是 INT4 需要更精细量化策略的原因。PPT 里放这组对比能直观说明「量化不是免费的」。4.3 精度、算力、显存三者的联动关系选精度从来不是孤立决策。降精度省显存、提带宽但可能掉点要补回精度就得多花算力做微调或蒸馏。这三者的联动可以用一句话概括精度换显存显存换算力算力换效果。PPT 里如果能把这条链讲通听众就不会再问「为什么不直接用 FP32」。5. 避坑与排查讲大模型参数时最容易翻车的五个点5.1 把「参数量」和「显存需求」直接划等号现象PPT 上写「70B 模型140 GB 显存」听众问「那两张 80G 卡不就够了」现场卡住。原因140 GB 只是 FP16 权重实际还要加 KV Cache、激活、框架开销通常要预留 20% 到 30% 余量。解决显存估算写成「权重 KV Cache 余量」三段KV Cache 按 2 × 层数 × 头数 × 头维度 × 序列长度 × 批大小 × 字节数估算讲清楚它随上下文线性增长。5.2 用峰值算力算训练时间得出不真实的卡数现象按峰值算出一张卡几天就能训完实际跑起来慢一个数量级。原因忽略了利用率、通信开销和故障重启。解决估算时显式写出利用率假设常用 0.3 到 0.5并在 PPT 里注明这是经验值而非理论值。如果听众追问就说明这个系数受集群规模、并行策略、网络带宽共同影响。5.3 混淆「总参数」和「激活参数」现象MoE 模型报总参数被误认为推理成本极高或只报激活参数被误认为显存需求很低。原因两个数字回答的是不同问题。解决PPT 上固定写成「总参数 / 激活参数」双数字格式并配一句「显存看总参数算力看激活参数」。5.4 精度标注不写具体格式现象只写「半精度」听众不知道是 FP16 还是 BF16讨论训练稳定性时各说各话。原因两者动态范围差异大训练行为不同。解决所有精度标注写全称训练场景注明是否配合 loss scaling推理场景注明是权重量化还是激活量化。5.5 算力单位混用导致数量级错误现象FLOPs 和 FLOPS 混写前者是总量后者是速率差一个时间维度。原因中文里都叫「算力」英文缩写只差一个字母。解决总量统一写 FLOPs注意小写 s速率统一写 FLOPS 或 TFLOPS并在表格表头注明单位含义。6. 进阶技巧用一套脚本把 PPT 里的数字全部自洽验证讲到最后最实用的习惯是PPT 里每一个数字都能被一段脚本复算出来。我一般会准备一个estimate.py把参数量、训练算力、推理算力、显存四块估算函数放在一起改几个配置就能生成整页数据。这样做的价值不在于算得多准而在于当有人质疑某个数字时你能当场改参数重算而不是翻回上一版 PPT 找来源。def full_report(vocab_size, hidden_dim, num_layers, ffn_dim, tokens, seq_len, batch, bytes_per_param2): params estimate_params(vocab_size, hidden_dim, num_layers, ffn_dim) train training_flops(params, tokens) # KV Cache: 2(K和V) * 层数 * 序列长 * 批大小 * 隐藏维度 * 字节 kv_cache 2 * num_layers * seq_len * batch * hidden_dim * bytes_per_param weight_mem params * bytes_per_param print(f参数量: {params/1e9:.2f} B) print(f训练算力: {train:.2e} FLOPs) print(f权重显存: {weight_mem/1e9:.1f} GB) print(fKV Cache: {kv_cache/1e9:.2f} GB) print(f合计显存: {(weight_memkv_cache)/1e9:.1f} GB) full_report(32000, 4096, 32, 11008, tokens2e12, seq_len8192, batch16)这段脚本把前面几章的函数串起来输出一份自洽的报告。参数说明seq_len和batch直接决定 KV Cache长上下文场景下它会迅速逼近甚至超过权重显存bytes_per_param改成 1 就是 INT8改成 0.5 就是 INT4可以现场演示量化收益。跑完之后你会得到一个重要习惯任何 PPT 数字先过一遍脚本对不上就查配置而不是凭印象填。我自己的血泪经验是早期做介绍时把「70B 模型两张卡能跑」写进 PPT结果被追问 KV Cache 时当场翻车。后来改成所有数字都从脚本出虽然多花半小时但再没被问倒过。希望帮到你。本文还有配套的精品资源点击获取
