Amdahl 定律——从哪来、为什么、有什么用

钩子：你花大价钱把训练从 1 张卡扩到 8 张，满心期待快 8 倍，结果只快了 3 倍；给服务加了 16 个线程，吞吐量却卡在 4 倍上不去。问题往往不在你并行得不好，而在那段"怎么也并行不掉"的串行代码，给整体加速焊死了一个天花板。 这条天花板，就是 Amdahl 定律。

0. 一个反直觉的事实

先抛个问题：一段程序，90% 能并行、10% 必须串行。给你无限多的核，它最快能快多少倍？

直觉可能是"无限倍"——毕竟 90% 都能并行嘛。但答案冷冰冰：最多 10 倍。因为那 10% 的串行部分，无论你堆多少核，它都得一个人慢慢走，而总耗时里永远含着这一段。串行占比，就是加速比的天花板。

1. 它从哪来：1967 年，一场对"并行狂热"的泼冷水

1967 年，IBM 的计算机架构师 Gene Amdahl 在 AFIPS 会议上提出这条定律（原称 Amdahl's Argument），本意是给当时方兴未艾的并行机热潮"降降温"。那时候业界流行一种乐观：核越多，程序就越快。Amdahl 用一个极简模型指出——只要程序里还有必须串行的部分，加速比就有硬上限，堆硬件的收益会快速饱和。

他的模型假设：问题规模固定，其中比例 p 可并行、比例 1-p 必须串行；并行部分用 n 个处理器后加速 n 倍（理想情况）。于是总加速比：

1

S(n) = 1 / ( (1 - p) + p / n )

当 n → ∞，分母里的 p/n → 0，加速比逼近 1 / (1 - p)。这就是那条天花板。

2. 为什么需要它：没有它，就会在"伪瓶颈"上砸错钱

没有 Amdahl 定律这把尺子，团队很容易犯两类错：

• 盲目堆硬件：以为加卡、加核、加机器是线性加速，结果钱花了大半，性能只动了一点，因为真正的瓶颈是那 10% 串行代码。
• 优化错地方：花大力气把本来只占 5% 的可并行部分优化到极致，对整体加速几乎无感；反而是那 30% 的串行热点，才是该动刀的地方。

Amdahl 定律的价值，是逼你在动手前先问一句："这段里，到底有多少是本质上必须串行的？" 答案决定了你所有并行投入的上限。

3. 本质一句话

Amdahl 定律的本质是：一个系统的整体加速比，由其中"无法并行的最大部分"决定；可并行部分决定你能多快接近天花板，串行部分决定天花板本身有多高。

4. 它有什么用：从多核到分布式，处处是它

Amdahl 不是教科书公式，它写进了每一处"加资源换速度"的工程决策里。

① 多核编译：make -j 为什么不是越快越好

1
2

make -j4    # 4 路并行编译
make -j16   # 16 路并行

并行度从 4 提到 16，耗时并不会降到 1/4——链接、依赖解析、单线程的收尾阶段是串行的。-j 的甜区通常在核数附近，再往上收益骤减，正是 Amdahl 在说话。

② 分布式训练：数据并行加速比的硬约束

用 n 张卡做数据并行，每张卡算 1/n 的前向反向，但梯度同步（all-reduce）是跨卡串行的全局屏障。卡数越多，同步占比越高，p/n 里的通信项吃掉收益。工程上常看到 8 卡接近线性、64 卡只剩二三十倍，就是天花板在生效。

③ 数据库分库分表：读写放大的串行锚点

把一个大表按 user_id 分 16 片，点查能并行 16 倍；但跨片聚合（如 SELECT SUM(amount) 不带分片键）必须汇总 16 片结果——这一步天然串行。分片再细，这类查询的加速也被"汇总"这段焊死。

④ 一个更通用的判断：先估串行占比，再决定投不投

任何"加机器/加线程"的提案，先用 Amdahl 算一遍天花板。若目标加速 10 倍，则串行占比必须压到 10% 以内——这立刻告诉你：该去重构那块串行热点，而不是去买第 17 台服务器。

5. 反例与边界：它什么时候会"骗"你

Amdahl 定律很强，但有三个常被忽视的边界：

• 它假设问题规模固定（强缩放）。现实中很多任务会随资源变多而"变大"——比如你有了 64 卡，就会去训更大的模型、更大的数据集。此时适用的是 Gustafson 定律（弱缩放）：总工作量随处理器数增长，并行部分也变大，加速比可以接近线性。所以"加核没用"只对"死守原问题规模"成立。
• 串行占比 p 往往不是常数。重构、缓存、异步化常常能把串行段本身并行掉或缩短，于是天花板被抬高——Amdahl 给的是某一刻的硬上限，不是永恒宿命。
• 它忽略了通信、同步、争用的隐性串行。公式里 p/n 假设并行段完美加速，真实系统里锁竞争、缓存一致性、I/O 会把有效 n 打折，实际曲线比公式更早就塌。

一句话：Amdahl 告诉你"现在"的天花板，而不是"优化后"的天花板；它管强缩放，不替弱缩放背书。

6. 对比表 + 🐾 小结

这条原则带走的几句话 🐾

• 加速比的上限，写在那段"怎么也并行不掉"的代码里，不在你买了多少核。
• 先估串行占比，再决定是去重构、还是去买第 17 台服务器——前者往往更划算。
• Amdahl 管"强缩放"（问题不变），问题跟着资源一起变大时，请换 Gustafson 上场。
• 它给的是此刻的天花板，不是宿命；把串行段并行掉或缩短，天花板就会升高。

相关阅读

• 《性能与 Amdahl 定律》（CS-Fundamentals 课程版，从体系化/课程视角展开）：/c61c0110/