前五课把 Transformer 拆到零件级：注意力、位置编码、归一化、分词、逐层参数。这一篇把镜头拉远，从「一个 7B 模型」扩展到「整个 LLM 家族」——参数量级、训练三阶段、推理两阶段、开源与闭源的分岔，以及这一代模型真正做不到的事。内容来自我做的一套 34 课大模型课程的第 6 课。
- 本课在线阅读（免登录、手机可看）：https://learn.taleverse.cn/lesson-6.html
- 全部 34 课：https://learn.taleverse.cn/
- 源码（MIT 许可）：https://github.com/zhuangzhaoyeye/llm_course
问题 1：同样是 Transformer，参数量为什么能从 1 亿跨到 2.78 万亿？
因为「大小」有两个口径，混着用就会算错显存。
- 总参数：模型里一共有多少个权重，决定显存门槛
- 激活参数：每个 token 实际参与计算的权重数，决定单 token 算力
稠密（dense）模型两者相等；MoE（Mixture-of-Experts，混合专家）把 FFN 拆成很多「专家」，每个 token 只路由到其中少数几个，于是两个数被解耦。
| 模型 | 架构 | 总参数 | 每 token 激活 | 激活占比 |
|---|---|---|---|---|
| Llama 2 7B | Dense | 6.74B | 6.74B | 100% |
| Llama 3.1 70B | Dense | 70B | 70B | 100% |
| Llama 3.1 405B | Dense | 405B | 405B | 100% |
| DeepSeek-R1 | MoE | 671B | 37B | 5.5% |
| Kimi K3 | MoE | 2.78T | ≈104B | 3.7% |
为什么 MoE 能「用 3.7% 的参数干活」？因为它只稀疏化 FFN，Attention 和归一化仍是稠密的——而 FFN 恰恰是参数大头（上一课算过，占每层约 67%）。
算一笔：671B 稠密模型单 token 前向约 2 × 671e9 = 1.34 TFLOPs；DeepSeek-R1 只激活 37B，约 2 × 37e9 = 74 GFLOPs，差 18 倍。
但显存省不了：
| 模型 | fp16 权重 | 4-bit 量化 | 单卡可跑？ |
|---|---|---|---|
| 7B | ≈14 GB | ≈4.0 GB | 能（8 GB 起） |
| 70B | ≈140 GB | ≈42 GB | 不能（需 2×24 GB） |
| 671B (MoE) | ≈1.34 TB | ≈403 GB | 不能（约 8×H100-80GB） |
一句话：显存看总参数，算力看激活参数。「MoE 让大模型变便宜」只说对了一半——便宜的是推理算力，不是显存。
问题 2：一个只会「预测下一个词」的基座，为什么必须再训一遍？
因为「会预测下一个词」和「会听指令」不是同一件事。预训练目标里根本没有「回答用户」这一项。
Llama 3 的训练分两大阶段，外加一次长上下文扩展：
| 阶段 | 目标 | 数据量 | 算力占比 | 产出 |
|---|---|---|---|---|
| ① 预训练 | 学语言结构与世界知识 | ≈15.6T token | ≈99% | 基座模型 Base |
| ② 后训练 | 学会听指令、对齐偏好 | 百万级指令样本 | <1% | 对话模型 Instruct |
| ③ 长上下文扩展 | 窗口 8K → 128K | 长文档语料 | <1% | 长上下文模型 |
预训练那 99% 是可以自己复算的。用经验公式 C ≈ 6ND（N = 参数量，D = token 数；系数 6 = 前向 2 + 反向 4）：
6 × 405e9 × 15.6e12 ≈ 3.79 × 10²⁵ FLOPs
和 Llama 3 公布的 3.8 × 10²⁵ 对得上。
后训练虽然不到 1% 算力，却是「好不好用」的分水岭。最经典的反例来自 InstructGPT：1.3B 的模型经后训练后，回答被人类偏好的比例超过了 175B 的 GPT-3 基座——参数量差 100 倍以上，赢的是「听得懂指令」。
Llama 3 的后训练用 SFT + 拒绝采样 + DPO，而不是 PPO 类 RLHF，理由是训练更稳、更易复现——这是工程取舍，不是能力取舍。
问题 3：为什么同一个模型，首字要等两秒、后面却越吐越快？
因为推理被拆成两个阶段，落在 GPU 性能曲线的两侧。
| 阶段 | 一次处理多少 token | 瓶颈 | 决定 |
|---|---|---|---|
| Prefill | 整段提示（如 2048 个） | 计算（Tensor Core 打满） | 首字延迟 TTFT |
| Decode | 1 个（每步） | 显存带宽（HBM 打满） | 每 token 延迟 TPOT |
判据是算术强度 = FLOPs ÷ 访问字节数，和硬件的 ridge point 比。以 H100 SXM 为例：
ridge point ≈ 989 TFLOPS ÷ 3.35 TB/s ≈ 295 FLOP/byte
- Prefill 一次处理 S 个 token，每读一次权重能算 S 次，强度 ≈ S（S=2048 → 2048），远高于 295 → 计算受限
- Decode 每步只出 1 个 token，强度 ≈ 1，远低于 295 → 带宽受限
两者可以差三个数量级。这就解释了为什么 decode 阶段 Tensor Core 利用率常常只有个位数百分比，显存带宽却已打满。
还有一个反直觉的事实：首字延迟的大头往往不是算得慢。TTFT 的组成里，排队等待常是首要项，PD 分离（把 prefill 和 decode 放到不同机器）时 KV Cache 传输也可能居首，而 prefill 计算本身只占一小块。所以优化 TTFT 的第一手段是调度与架构（前缀缓存、PD 分离），不是换更快的卡。
问题 4：开源权重和闭源 API，到底差在哪、该怎么选？
先比硬约束，再比性价比。
| 维度 | 闭源 API | 开源权重自托管 |
|---|---|---|
| 数据合规 | 数据需出域 | 数据不出内网 |
| 成本结构 | 按 token 计费，随量线性增长 | 前期 GPU + 运维，边际成本低 |
| 能力上限 | 通常最强（复杂推理、多模态） | 接近但一般略低，可微调补齐垂直场景 |
| 迭代速度 | 厂商升级，你自动受益 | 自己决定何时升、升到哪版 |
| 运维门槛 | 几乎为零 | 需要 GPU 运维与推理优化 |
自托管的门槛是显存（4-bit 权重 + 再留 20%~40% 余量）：
| 规模 | 4-bit 权重 | 最低硬件 |
|---|---|---|
| 7B~8B | ≈4.0~4.8 GB | 单张 8 GB 消费卡 |
| 32B | ≈20 GB | 单张 24 GB（3090/4090） |
| 70B | ≈43 GB | 2×24 GB 或 A6000 |
| 671B (MoE) | ≈404 GB | 约 8×H100-80GB |
决策规则按约束排序：
| 你的约束 | 优先选择 |
|---|---|
| 数据不能出域 / 强合规 | 开源自托管（API 直接不满足） |
| 调用量小、快速验证 | 闭源 API（零运维、零前期） |
| 长期高并发、成本敏感 | 开源自托管（边际成本低） |
| 需要最强复杂推理 / 多模态 | 闭源 API |
| 需要深度定制（垂直微调） | 开源自托管（得拿到权重） |
关键认知：如果数据不能出域，那么「闭源 API 分数更高」这个论据根本不成立。
问题 5：模型「看起来很懂」，为什么还会一本正经地胡说？
因为它的训练目标是「生成最像正确答案的文本」，不是「查证事实」。而且评测长期奖励「猜」，不奖励「承认不知道」。
八条结构性限制，没有一条能靠换提示词解决：
| # | 限制 | 根因 | 工程对策 |
|---|---|---|---|
| 1 | 知识截止 | 训练数据有时间边界 | 检索（RAG）注入最新信息 |
| 2 | 幻觉 | 目标是生成最像的文本 | 强制引用来源 + 输出校验 |
| 3 | 多步推理衰减 | 误差逐步累积 | 思维链 + 代码执行 |
| 4 | 上下文窗口上限 | 注意力成本随长度增长 | 分块 + 摘要 + 检索 |
| 5 | 无持久记忆 | 推理是无状态的 | 应用层存状态并注入 |
| 6 | 无法作用于现实 | 只能输出文本 | 工具调用 |
| 7 | 训练数据偏见 | 语料本身有偏 | 领域上下文 + 人工审核 |
| 8 | 无法自校验 | 没有真值访问权 | 独立验证层 / 第二模型复核 |
关于「不知道时会不会编造」，2026 年有一些第三方基准数据在流传，但同一指标被挂到了不同代际的模型上、准确率也对不上，没有一手来源，我在文章里不给具体百分比——只能说定性趋势成立：模型「知道很多」和「不知道时几乎不承认」可以并存，所以分数高不等于可信。
还有一个更容易被忽略的点：标称上下文不等于有效上下文。宣传的 100 万 token 窗口，按 1 token ≈ 3~4 字符换算约 300 万~400 万字符；而开发者实测中，模型往往在远小于该规模时就失去连贯性。这个差距在工程上必须按实测有效范围设计分块与检索，而不是把 100 万 token 全塞进去。
问题 6：有哪些事是这一代模型真的做不到？
不是提示词没写好，也不是没喂数据，而是由输入形式、注意力机制、训练数据边界共同决定的。
| # | 做不到 | 可复现现象 | 根因 | 后面哪课解决 |
|---|---|---|---|---|
| 1 | 字符级计数与精确算术 | 数 strawberry 里有几个 r 会出错 | 模型看到的是 token，不是字符 | 工具调用（外包给代码执行） |
| 2 | 长上下文「中间遗忘」 | 关键信息放中段，回答质量下降 | 注意力对首尾有偏好 | 记忆与 RAG 工程化 |
| 3 | 知识停在训练截止日 | 不知道训练之后的事，也不知道你的私域文档 | 知识冻结在权重里 | 记忆与 RAG 工程化 |
| 4 | 多步推理累积误差 | 单步 95% 对，十步之后常常做不完 | 误差乘性累积，且不会自我纠正 | 推理模型与 RLVR、Agent |
| 5 | 不能自己动手 | 不会真的发邮件、查库、下单 | 只输出文本，动作靠外部执行 | 工具调用 |
第 4 条可以直接算出来。综合正确率 ≈ 单步正确率^步数：
| 步数 | 单步 95% | 单步 99% |
|---|---|---|
| 1 | 0.950 | 0.990 |
| 5 | 0.774 | 0.951 |
| 10 | 0.599 | 0.904 |
| 20 | 0.358 | 0.818 |
0.95¹⁰ ≈ 0.599——十步全对的概率不到六成。这就是「每一步都差不多对，整条链却常常错」的数学原因。让模型自己检查也救不了，因为检查本身也是一步，也会出错。
第 2 条有论文支撑：Lost in the Middle（Liu 等，2023）用受控实验把答案所在的文档从开头挪到中间，准确率随之变化，画出一条两头高、中间低的 U 形曲线。具体百分点随模型与文档数而变，这里只作定性描述。
小结
| 问题 | 结论 | 一个数字 |
|---|---|---|
| 参数为什么差 2 万倍 | 总参数与激活参数解耦 | Kimi K3：2.78T 总 / ≈104B 激活（3.7%） |
| 为什么要再训一遍 | 预测下一个词 ≠ 听指令 | 1.3B 微调后胜 175B 基座 |
| 为什么首字慢、后面快 | prefill 计算受限，decode 带宽受限 | ridge point ≈ 295 FLOP/byte |
| 开源还是闭源 | 先看硬约束，再看性价比 | 70B 4-bit ≈ 43 GB |
| 为什么会胡说 | 目标是「最像」，不是「正确」 | 八条结构性限制 |
| 什么是真做不到 | 单位、长度、知识、步数、动手 | 0.95¹⁰ ≈ 0.599 |
参考与说明
- Llama 3 训练规模（15.6T token、3.8×10²⁵ FLOPs、16K H100）：Meta, The Llama 3 Herd of Models, 2024，https://arxiv.org/abs/2407.21783
- InstructGPT 的 1.3B 胜过 175B 基座：Ouyang 等, 2022，https://arxiv.org/abs/2203.02155
- DeepSeek-R1（671B 总参数 / 37B 激活）：https://arxiv.org/abs/2501.12948
- Kimi K3（2.78T 总参数 / ≈104B 激活 / 100 万 token 窗口）：Moonshot AI, 技术报告，https://github.com/MoonshotAI/Kimi-K3
- 中间遗忘的 U 形曲线：Liu 等, Lost in the Middle, 2023，https://arxiv.org/abs/2307.03172
数字说明：算力（2×671e9、2×37e9、6×405e9×15.6e12）、显存（参数量×字节数）、算术强度（989/3.35≈295）、多步衰减（0.95ⁿ、0.99ⁿ）我都用 Python 独立复算过。文中没有给出幻觉率的具体百分比——那份数据只有二手来源且口径互相冲突，不适合写进公开文章。
说明：这套课程由 AI 在我设计的规则下生成，再经过脚本检查和独立审查；审查发现过不少问题，都写在仓库 README 里。如果你发现错误，欢迎在仓库提 Issue，写清位置，我会逐条核实。
继续学
上一篇是第 5 课「逐层解剖一个模型」，把 Llama 2 7B 的参数一块块算出来。这一课之后是第 7 课「Scaling Laws 与算力预算」。每张卡片后面还有 AI 助教，可以接着追问（每人每天有次数限制）。
- 课程：https://learn.taleverse.cn/
- 源码：https://github.com/zhuangzhaoyeye/llm_course ，觉得有帮助的话欢迎点个 Star
