Amdahl与Gustafson定律：装修队的加速智慧

可视化演示

Amdahl定律和Gustafson定律从不同角度分析并行计算的加速比上限，指导并行系统设计。本文讲解Amda... 切换模式查看不同维度。

1. 阿姆达尔（Amdahl）定律：串行瓶颈锁死加速比

装修队接下了60平米小公寓的活儿。面积是客户定死的，活就这么多：拆改、贴砖、刷墙、等漆干、验收。贴砖刷墙可以分成八个区域让八个工人同时干，但“等漆干”这三天不行——你请一百个工人来，也得等三天。更扎心的是，“等审批”“等干透”这类工序，不管工期多紧都省不掉。于是你会发现一个残酷的事实：工人从1个加到10个，工期从30天降到8天；从10个加到100个，工期只降到6天半——越加人，提速越不明显。

这就是Amdahl定律的视角：问题规模固定，串行部分的比例s决定了加速比的天花板。所谓加速比，就是“单人工期 ÷ N人工期”，代表提升了多少倍。设串行比例s=0.2（20%的时间在等），可并行比例1-s=0.8，请N个工人后：

再让N无限增大，看看极限：

所以公寓装修的老板很快明白：与其盲目加人，不如去缩短“等漆干”的时间——比如换成快干漆，把s从0.3压到0.1，天花板立刻从3.3倍抬到10倍。Amdahl定律的工程启示就在这儿：先砍串行，再加核。

2. 古斯塔夫森（Gustafson）定律：扩大规模突破天花板

装修队老板沮丧了一阵子，突然接到一个电话：客户要把房子从60平扩建成300平的大别墅！老板眼睛一亮——活变多了，但可并行的工序（贴砖、刷墙、走线）也跟着变多了，而且占比越来越大！原来“等漆干”占工期的20%，现在房子大了、漆要刷的面积多了，但等干的时间并没按比例涨那么多，串行占比反而被“稀释”了。更重要的是，别墅的活可以分成几十个区域让几十个工人同时干，每个工人干的量不变，人越多干的区域越多，总工期反而能稳住。

这就是Gustafson定律的视角：问题规模随处理器数量扩展。在扩展规模后的世界里，串行占比s和并行占比1-s是扩展后的比例，但那些并行工作若只交给一个核来做，需要N倍的时间。于是加速比变成：

代入数字感受一下：s=0.1，N=32时，S=0.1+32×0.9=28.9，几乎是线性提速！对比Amdahl在同样s下只能到7.8——同一个串行比例，两种问题规模设定，结论天差地别。Gustafson定律的工程启示是：在可扩展的工作负载（科学模拟、海量数据）面前，加核是真的能带飞。

3. 两定律对比：假设定结论

同样是这支装修队，为什么两把尺子量出来的结论会“打架”？因为老板问的问题根本不是同一个。Amdahl问的是：“这套公寓就60平、活就这么多，我加人，最快多久干完？”Gustafson问的是：“我打算把房子加盖到300平，人越多活越多，单位时间能干多少？”一个固定工作量看极限，一个扩展工作量看增长——前提不同，答案自然不同。

把两个定律的底层假设摊开：Amdahl假设问题规模（总工作量W）固定，分析“固定负载加速比”；Gustafson假设并行执行时间固定，分析“扩展负载加速比”。无论哪个世界，N核总时间都可以拆成两段：

在现实生活中，串行比例s扮演的角色也完全不同：Amdahl里s是“天花板刻度尺”，s越小上限越高；Gustafson里s是“斜率折扣”，s越大线性加速的斜率损失越多。适用场景也因此分工明确——实时渲染、固定数据集批处理这类工作量恒定的任务，用Amdahl分析；气候模拟、基因测序、大模型训练这类规模可无限扩大的任务，用Gustafson分析。两定律不是敌人，而是同一个工地上的两把互补的尺子：一把量“能不能更快”，一把量“能不能更大”。

4. 加速比与效率：别只看提速就上头

别墅项目开工了，老板请了32个工人，工期从单人的30天压到3天——提速10倍！但老板心里咯噔一下：32个人只提速10倍？平均每个人贡献的提速只有10÷32≈0.31，也就是说每个工人的产出效率只有三成。工钱可是按人头算的，32份工钱换10倍提速，这买卖划算吗？如果加到64人只提速11倍，那新增的32人几乎在“摸鱼”——他们不是偷懒，而是工地太小、工序有前后依赖，人多了反而互相递料、让路，产生内耗。

这就是“效率”的含义。效率E定义为单位处理器贡献的加速比：

为什么N增大后效率一定下滑？因为工人之间要沟通、要递料、要等别人干完才能接手下一道工序——这些“协作开销”（通信、同步、资源竞争）随着人数增加而增长。于是存在一个边际收益递减点：从1核到2核，提速接近2倍；从32核到64核，可能只提速20%。精明的老板会算总账：如果目标是“最短工期”，那就多请人、接受低效率；如果目标是“性价比最高”，就停在效率过半的拐点。并行系统设计也是如此——超算中心的算力规划，本质就是权衡S和E。

5. 强扩展与弱扩展：装修队的两门生意

经历了别墅项目之后，装修队老板总结出两种生意模式。第一种叫“固定单”：客户给定面积，工期越短越好，这是强扩展（Strong Scaling）——问题规模不变，处理器越来越多，每个工人分到的活越来越少，效率注定下滑，Amdahl定律是它的判决书。第二种叫“包干单”：客户按人头给活，每人每天的工作量恒定，加人就加面积，整体工期不变，这是弱扩展（Weak Scaling）——问题规模随处理器数同步增长，每人工作量不变，效率可以保持稳定，Gustafson定律是它的理论靠山。

如何科学地判断一个并行系统“扩展性好不好”？看效率能否保持。定义扩展后的效率相对基准的比值：

实操中的判断标准很简单：固定规模下不断加核，当效率跌破某个阈值（比如50%）时，那个核数就是扩展临界点——继续加核纯属浪费钱。而在弱扩展场景下，只要实测效率曲线基本水平，说明系统可以“无限加盖”。大模型训练集群的搭建思路就属于后者：数据量随着GPU卡数线性切分，每个GPU的处理量不变，目标就是让效率曲线别掉下来。

6. Kumar尺度分析：工地上的三把尺子

老练的装修队老板出门带三把尺子：量面积、量工期、量分工。同样一个工地，用不同尺子去量，得出的“该不该加人”结论就不同。1994年，Kumar等人在《并行计算导论》里也提出了三把“尺子”——三种并行算法的尺度分析视角，把Amdahl和Gustafson统一到了同一个框架下：

• 固定存储尺度（固定规模）：问题规模W不变，分析加速比如何随处理器N变化——这就是Amdahl定律的世界。

• 扩展时间尺度（固定时间）：允许问题规模随N增大，让并行总时间保持稳定——这就是Gustafson定律的世界。

• 固定粒度尺度（固定单核负载）：每个处理器承担的工作量不变，规模随N等比增长——弱扩展分析的世界。

三种尺子的统一公式，是把总工作量W拆成“理想分工”和“协作开销”两块：

这三把尺子的价值在于：它告诉我们Amdahl与Gustafson并不矛盾，只是“固定W”与“让W随N变大”两个假设的产物。工程师真正要做的，是先确定自己的场景该用哪把尺子，再判断并行粒度合不合理。

7. 多核与集群设计指导：装修队的排兵布阵

接了大别墅项目，老板开始排兵布阵：派多少工人？哪些工序并行？哪些必须等？这里的核心问题是——给定目标提速倍数，反推需要多少核。比如客户要求提速10倍，串行比例s=0.1，从Amdahl公式反解N：

代入S_target=10、s=0.1，得到N=0.9÷(0.1-0.1)——分母是0，说明s=0.1时天花板就是10，目标10倍需要无穷多核！这提醒设计者：先降s，再谈核数。实际工程中的三条设计准则随之而来：

• 多核芯片规划：核数不盲目堆，根据目标应用的可并行度选择合适的核数与缓存架构，单核能效与并行收益要平衡。

• 集群节点预算：用反推公式算出理论核数，再留出通信开销的余量，决定采购多少节点。

• 负载均衡优化：像装修队避免“有人忙死、有人闲死”一样，调度器要把任务均匀分配到各核，减少同步等待——同步等待就是一种隐藏的串行段。

8. 加速比测量实践：工地验收的真相

房子装完了，客户问：“到底提速了几倍？”老板拍胸脯说“10倍”——但客户要看施工日志。测量加速比没有捷径，必须老老实实做对比实验：用最优的串行方案跑一遍，记录单核时间T_1；再用N个核并行跑同一方案，记录时间T_N，两者一比：

测量时要跑两组基线：固定输入基线（问题规模不变，N从1加到64，对应Amdahl场景）和扩展输入基线（问题规模随N等比增长，对应Gustafson场景）。如果实测加速比明显低于理论预测，别急着怪定律——先排查三件事：数据没喂饱（内存带宽瓶颈）、同步太多（工人互相等）、负载不均（有人闲着有人累死）。就像装修验收时发现实际工期比预估长，队长要拿着日志一个工序一个工序地找“卡脖子”的地方，定位到瓶颈之后，收益往往比简单加核大得多。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-import math  def amdahl_speedup(s, n):    # 固定问题规模, 串行比例 s, 处理器数 n    return 1.0 / (s + (1.0 - s) / n)  def gustafson_speedup(s, n):    # 扩展问题规模, 串行比例 s, 处理器数 n    return s + n * (1.0 - s)  def efficiency(speedup, n):    # 效率 = 加速比 / 处理器数    return speedup / n  def print_table(s):    header = "{:>6} {:>10} {:>12} {:>10} {:>12}".format(        "N", "AmdahlS", "GustafsonS", "AmdahlE", "GustafsonE")    print(header)    print("-" * len(header))    for n in [1, 2, 4, 8, 16, 32, 64]:        sa = amdahl_speedup(s, n)        sg = gustafson_speedup(s, n)        print("{:>6} {:>10.2f} {:>12.2f} {:>10.3f} {:>12.3f}".format(            n, sa, sg, efficiency(sa, n), efficiency(sg, n)))  def plot_curves(s, outfile="speedup.png"):    # 尝试用 matplotlib 画对比曲线, 无库时静默跳过    try:        import matplotlib        matplotlib.use("Agg")        import matplotlib.pyplot as plt    except ImportError:        return    ns = list(range(1, 65))    amps = [amdahl_speedup(s, n) for n in ns]    gusts = [gustafson_speedup(s, n) for n in ns]    plt.figure(figsize=(7, 4))    plt.plot(ns, amps, label="Amdahl (fixed size)", color="#F43F5E")    plt.plot(ns, gusts, label="Gustafson (scaled size)", color="#10B981")    plt.axhline(1.0 / s, color="#818CF8", linestyle="--", label="Amdahl ceiling")    plt.xlabel("Processors N")    plt.ylabel("Speedup S")    plt.legend()    plt.tight_layout()    plt.savefig(outfile, dpi=100)  def main():    s = float(input("请输入串行比例 s (0 到 1, 默认 0.1): ") or 0.1)    s = max(0.0, min(1.0, s))    print("串行比例 s = {:.2f}".format(s))    print_table(s)    plot_curves(s)    print("对比图已保存为 speedup.png (如已安装 matplotlib)")  if __name__ == "__main__":    main()

1. def amdahl_speedup(s, n): return 1.0 / (s + (1.0 - s) / n)固定规模加速比，串行时间原样保留，并行时间除以核数。
2. def gustafson_speedup(s, n): return s + n * (1.0 - s)扩展规模加速比，被N个核分担的并行工作量若单核来做要N倍时间。
3. def efficiency(speedup, n): return speedup / n每个核平均贡献的提速，越高越划算。
4. sa = amdahl_speedup(s, n)计算当前核数下Amdahl的加速比，用于和Gustafson对照。
5. sg = gustafson_speedup(s, n)计算当前核数下Gustafson的加速比，两条曲线的差距一目了然。
6. plt.axhline(1.0 / s, color="#818CF8", linestyle="--", label="Amdahl ceiling")画出Amdahl的极限天花板，提醒你串行比例不降、加核白搭。
7. s = float(input("请输入串行比例 s (0 到 1, 默认 0.1): ") or 0.1)交互式输入串行比例，方便对比不同“等漆干”时长的影响。
8. s = max(0.0, min(1.0, s))把s夹在0到1之间，防止输入越界导致公式无意义。

常见误区

面试题