同样一万张卡，怎么花出两倍效果
先给结论： 训练大模型最贵的东西不是"卡好不好"，而是每一块钱买到了多少有效计算。DeepSeek 在这件事上做了两件事——把"每美元的效率"当成仪表盘来管，把一次旗舰训练的账逐项列出来。后者比前者更罕见：整个行业几乎没人公布成本明细。
一、先讲一个反直觉的事实：他们用的是更便宜的卡
大模型集群通常用"卡间直连"的顶级方案（运算卡之间用专用高速通道互联）。而 DeepSeek 2021 年建的集群用了 10,000 张 PCIe 版本的 A100——也就是走普通主板通道、不是顶级互联的版本。
为什么选便宜方案？因为 2021 年做这个决定时，主要任务还不是大语言模型，而是推荐系统、视觉、语音这类计算。这些任务对"卡间通信"的要求没那么变态。省下的钱和更稳的机房，在当时是划算的。
后来大语言模型来了，这个选择就变成了负债：语言模型训练时，卡与卡之间要频繁交换梯度，通信一慢，卡就闲置——买的算力在排队。
他们的应对不是推倒重来，而是在同一个物理集群上把软件重做一遍。 这才是"系统与成本"这条线的主题。
二、CPERF：把"每美元买到多少计算"当仪表盘
论文提出一个记账指标，大意是：同样的钱，你能拿到多少真实算力。它的算法是把"计算效率"除以"成本占比"（都以一台参考机器的规格为基准）。
论文给出 1.38 这个数字（用表格里四舍五入后的输入复算，得到 1.3833）。翻译成大白话：在相同预算下，这套方案能买到约 1.38 倍的有效计算。
这里有一个很重要的口径细节：这个比值高度依赖当时的显卡价格。 论文自己也说，结论绑定 2021 年的硬件行情。换个年份、换张卡价，这个数字就不成立了。
这就是本系列反复强调的：任何"我们便宜 X%“都自带一个时间戳和价格前提。看到具体数字，先问"哪一年、什么价”。
三、通信库：为什么自己写一个
集群里最费时的操作叫 allreduce——把一万张卡各自算出的梯度汇总起来，让所有卡更新到同一个模型。
通用的做法（业界标准库）假设卡之间有高速直连通道。但在 PCIe 集群上，这个假设不成立，它会绕远路、消耗大量带宽。DeepSeek 自己写了一个方案，核心思路是：让 CPU 异步地去搬运这些数据，而不是让昂贵的运算卡停下来等通信。
他们把这一层和上层的并行策略（怎么切模型、怎么切数据、怎么排队错峰）成套重做。论文声称的结果是三条，要分开看：
| 论文的说法 | 具体数字 | 口径 |
|---|---|---|
| 算力表现约为对手的八成 | 83.0% | 两项矩阵运算性能的合并比值 |
| 成本约为一半 | 整机含网络 50.4%（单机 59.2%） | 采购价格比，非运行成本 |
| 省约四成能耗 | 每节点功耗 59.5% | 峰值功耗比 |
注意这三条不是同一件事：不是"只有 80% 的速度"，而是"用一半的钱拿到约八成的性能分"——这是一笔性价比账。而且这些比值绑死 2021 年的硬件价格，换个年份就不成立。
四、训练一次旗舰到底花多少钱：一张能逐项相加的账
这是全系列里我最推荐高中生看的一段，因为它展示了科研论文可以诚实到什么程度。
DeepSeek-V3 的论文直接给了一张成本表：
| 阶段 | H800 卡时 | 金额 |
|---|---|---|
| 预训练 | 2,664K | $5.328M |
| 上下文延长（把窗口从 4K 拉到 128K） | 119K | $0.238M |
| 后训练（对齐阶段） | 5K | $0.01M |
| 合计 | 2,788K | $5.576M |
这张表可以自己验算：2,664K + 119K + 5K = 2,788K ✓；三个金额相加也是 557.6 万美元 ✓；而 2,788K × $2（论文假设的每卡时租金）= 557.6 万美元，同样吻合 ✓。
“卡时"就是"一张卡跑一小时”，是最朴素的计费单位。整个预训练用了 2048 张卡、54.2 天。
五、这 557.6 万美元不包含什么（最重要的一段）
论文明确说明：这只是"正式训练"的直接租金。
不包含的至少有这么几类：
- 前期研究和大量失败的实验（探索阶段往往比正式训练更烧钱）
- 算法消融实验（“这么改到底有没有用"的对照实验）
- 人员工资
- 机房、电力、网络等基础设施的摊销
所以"557.6 万美元训出 V3"是一个被截断了口径的说法。 媒体常把它当作"全部成本"来报道，这是典型的口径截断——数字是真的，但少说了它只是总账里的一格。
一个行业的对照：别的公司几乎从不公布这类明细。公布出来会被拿去比较、会被质疑，但比较的前提正是透明。这也是这个系列想说的一点：最值得信任的论文，是那种肯把账摊开让你算的论文。
六、为什么一定要把"通信"藏起来
流水线重叠让通信不再浪费时间；成本表可逐项相加，但口径仅限正式训练
要理解这笔账为什么能这么算，得先知道训练时最大的浪费在哪里。
第七篇讲过 MoE：每次处理一个词，模型只叫醒少数几个"专家”。但这里有个系统的麻烦——专家分布在不同机器上。于是每处理一步，就要把词元通过机器间的网络送到对应专家那里，算完再送回来。这一来一回叫全对全通信。
问题在于：通信的时候，运算卡是闲着的。
如果通信占 30% 的时间，就等于每买 10 张卡，有 3 张在干等——钱在空气里烧。所以训练系统的核心 KPI 不是"卡跑多快"，而是**“卡有多少时间真的在算”**。
DeepSeek 的做法叫双向流水线：把一整套训练流程切成很多小段，让不同的机器同时处理不同的小段——当 A 组在通信时，B 组正在计算。这样通信的时间就被计算的时间盖住了。
打个比方：一个人洗菜、一个人切菜、一个人炒菜，如果每个人都必须等前一个人完全做完才动手，锅就得空着。流水线就是让所有人在同一时刻都有活干。
但这里有个前提：如果专家被分配得不均衡（某个专家被叫醒太多次，另一台机器闲着），流水线就会在某一段卡住，重叠失效。所以"均衡"不只是模型质量问题，还是系统效率问题——这也正是第七篇"无辅助损失均衡"存在的原因。模型设计和系统设计，从来不是两件事。
七、最常坏的零件，不是算力卡
集群运维论文里有一份按故障类型统计的表格（过去一年共 12,970 条故障记录）。结果是：
- NVLink 桥接器错误占 42.57%（这是卡间高速互联部件，反而最常坏）
- 另一类错误占 33.48%
- 内存纠错（ECC）相关只占 2.14%
结论很朴素但很实用：万卡集群里最脆弱的环节是连接，不是计算。 这也解释了为什么他们的运维重点是"每周巡检 + 提前更换"——坏掉一个连接部件会连累一整组卡。
这里也有一个论文自己的修辞问题：文中说这类故障"比其他硬件故障高好几个数量级"，但按自家表格复算，相对 ECC 是 22.5 倍，够不上"数量级"（那是十倍以上）的说法。这是一处值得记录的措辞夸大。
八、论文自己算错的地方，也值得记下来
这个系列的第十二篇讲过"看数字的六道检查"。这一篇里就有两个真实样本：
- 并行效率的算术不一致：论文声称某配置达到 91% 的并行效率，但用它自己给的每步耗时复算，得到约 82.5%。同一个公式在另外两组配置上却精确吻合——说明这不是口径问题，而是这一处数字本身有问题。
- 存储容量的单位含糊：论文说存储系统"超过 20 PiB"，但严格按二进制口径（PiB，1 PiB = 2⁵⁰ 字节）核算，镜像后是 19.65 PiB。PiB 和 PB 混着用，就能让一个数字看起来更大一点。
我特意写这两条，不是因为它们重要，而是因为它们证明了：再严谨的论文也需要读者自己动手核。 这个习惯，比记住任何数字都值钱。
九、这条线还没到头
集群和训练成本讲完了，但还有一个问题没答：模型训练好之后，用户问它一句话，它为什么回得那么慢？
而且 V3 的论文里埋了一个很有意思的模块——MTP（多词元预测），它训练时的目标是"一次猜不止一个词"。这个当初为了"提高数据效率"设计的模块，后来被拿到了推理服务上，变成了让回答变快的核心武器。
这就是第十五篇的主题：让模型说话更快。而第十四篇，我们先看一个更奇特的想法——让模型把知识"查出来"，而不是"算出来"。
一句话总结： 系统与成本这条线的核心不是堆硬件，而是把"每块钱买到多少有效计算"当仪表盘，并且愿意把一次训练的账逐项公开让读者相加验证。
记住这个数字： 2,788K H800 卡时 ≈ 557.6 万美元——而它只包含正式训练，不含研究、消融、工资和机房。
下一篇： 让模型"查表"记住知识：Engram 记忆——把一部分记忆从"算出来"改成"查出来"。