Amdahl 定律 vs Gustafson 定律 — 完整教程、推导、应用场景及 Python 绘图

Amdahl 定律 vs Gustafson 定律：完整教程、推导、应用场景及 Python 绘图 理解并行加速：通过代码讲解 Amdahl 定律和 Gustafson 定律 并行计算基础：Amdahl 定律、Gustafson 定律及加速建模 并行加速原理：Amdahl 和 Gustafson 定律完整指南 并行扩展解析：推导并比较 Amdahl 和 Gustafson 定律 Amdahl vs Gustafson：并行加速完整指南（含 Python 代码） 并行性能建模：Amdahl 定律、Gustafson 定律及实际应用 学习并行加速：数学、直觉、应用场景及 Python 可视化 并行计算：必须掌握的两条定律（Amdahl & Gustafson） 工程师的并行加速：Amdahl 定律、Gustafson 定律及 Python 实现 从理论到代码：用 Amdahl 和 Gustafson 建模并行加速 实用并行加速指南：Amdahl 定律、Gustafson 定律及可视化 为什么并行不是无限的：简单解释 Amdahl vs Gustafson 并行加速真相：Amdahl 限制 vs Gustafson 扩展 并行计算神话与现实：Amdahl 和 Gustafson 的教训

引言

并行计算在现代计算中至关重要：多核 CPU、GPU、分布式集群、云工作负载、LLM 训练以及 HPC 模拟。 为了分析程序在更多处理器下能加速多少，主要有两种数学模型：

• Amdahl 定律 — 固定规模工作负载的性能
• Gustafson 定律 — 可扩展规模工作负载的性能

这两条定律并不矛盾，它们回答的是 不同的问题。 本教程涵盖推导、直觉、比较、实际应用场景，以及展示两条定律的 Python 绘图脚本。

1. 什么是加速比？

加速比衡量程序在 N 个处理器上运行速度提升多少： [math]S(N) = \frac{T_1}{T_N}[/math] 如果程序在一个处理器上运行 10 秒，两处理器运行 5 秒，则加速比为： [math]S(2) = \frac{10}{5} = 2[/math] 完美线性加速为： [math]S(N) = N[/math] 但实际系统存在串行瓶颈，这正是 Amdahl 定律和 Gustafson 定律描述的内容。

2. Amdahl 定律（固定工作量）

2.1 直觉

Amdahl 假设：

• 总工作量保持 不变
• 部分工作是串行的，无法并行化

设：

• f = 串行比例
• 1 - f = 可并行比例

2.2 推导

一个处理器的运行时间： [math]T_1 = T_s + T_p[/math] 定义： [math]f = \frac{T_s}{T_1}[/math] 因此： [math]T_s = fT_1[/math] [math]T_p = (1 - f)T_1[/math] N 个处理器的运行时间： [math]T_N = fT_1 + \frac{(1 - f)T_1}{N}[/math] 加速比： [math] S(N) = \frac{T_1}{T_N} = \frac{1}{f + \frac{1 - f}{N}} [/math] 其中 f 是串行工作比例，[math] 1-f [/math] 是可并行工作。Amdahl 公式也可以写成： [math] S(N) = \frac{T_1}{T_N} = \frac{1}{(1-p) + \frac{p}{N}} [/math] 其中 [math] p=1-f [/math]，[math] f=1-p [/math]

2.3 当 N → ∞ 时的极限

[math]S(\infty) = \frac{1}{f}[/math] 如果串行比例为 10%（f = 0.1）： [math]S_\infty = 10[/math] 即使处理器无限，也无法超过该值。

2.4 Amdahl 定律的实际应用场景

Amdahl 适合优化固定任务的 延迟：

• GPU 内核优化固定张量大小
• 单次请求推理延迟降低
• 视频编码、压缩、排序
• 加速固定批量作业
• 数据库查询加速

---

3. Gustafson 定律（可扩展工作量）

3.1 直觉

Gustafson 反过来问： “增加处理器，我能在相同时间内解决多大的问题？” 这反映了真实 HPC 工作负载：更多 CPU → 更高分辨率 → 更大模拟。

3.2 推导

假设程序在 N 个处理器上运行 1 个时间单位。 设：

• f = 串行比例（按规模测量）

可并行部分随处理器数量扩展，因此其运行时间保持与 N 成比例。 一个处理器的时间： [math]T_1 = f + N(1 - f)[/math] 加速比： [math]S(N) = f + N(1 - f)[/math] Gustafson 公式的 “N 减” 形式： [math]S(N) = N - (N - 1)f[/math] 或者，如果定义并行比例 [math]p = 1 - f[/math]，公式也可写为： [math]S(N) = f + N(1-f) = f + Np [/math] “N 减” 形式用 p 表示： [math] S(N) = N-(N-1)f = N - (N-1)(1-p) [/math]

3.3 解释

随着 N 增加，加速比趋近于： [math]S(N) \approx N(1 - f)[/math] 对于小串行比例，几乎呈线性增长。

3.4 Gustafson 定律的实际应用场景

Gustafson 适用于 吞吐量扩展 或可增加问题规模的工作负载：

• 天气和气候模拟
• 粒子模拟、CFD、有限元分析
• LLM 训练：更多 GPU → 更长序列或更大模型
• 大数据分析（Spark, Dask, Flink）
• 蒙特卡洛模拟

---

4. Amdahl 定律 vs Gustafson 定律（比较表）

项目	Amdahl	Gustafson
工作负载	固定	随 N 扩展
目标	降低延迟	增加吞吐量
加速比上限	有界: [math]1/f[/math]	近似线性: [math]N(1-f)[/math]
悲观/乐观	悲观	乐观
应用场景	优化现有任务	扩展大规模工作量

---

5. 实际应用场景（综合视角）

Amdahl（延迟优化）

• 减少单次 LLM 查询推理时间
• 加速数据库 join 操作
• 固定张量 GPU 内核优化
• 视频编码（相同视频）

Gustafson（吞吐量 / 扩展）

• LLM 训练（扩展至更多 GPU）
• 高分辨率天气模型模拟
• 大数据 ETL 扩展
• 科学 HPC 工作负载

6. Python 绘图脚本（显示两条定律）

下面代码生成 Amdahl 与 Gustafson 加速比曲线图。 可以调整 f（串行比例）和处理器数量 N。 脚本绘制两条曲线在同一张图上。 包括部分 [math]f[/math] 的值，例如串行部分： import numpy as np import matplotlib.pyplot as plt def amdahl_speedup(N, s): return 1.0 / (s + (1 - s) / N) def gustafson_speedup(N, s): return s + (1 - s) * N # Number of processors N = np.arange(1, 65) # Serial fractions to consider Serial = [0.05, 0.1, 0.2, 0.3, 0.5, 0.8, 0.9, 1.0] plt.figure(figsize=(10, 6)) for f in Serial: plt.plot(N, amdahl_speedup(N, f), linestyle='-', label=f"Amdahl Serial={f}") plt.plot(N, gustafson_speedup(N, f), linestyle='--', label=f"Gustafson Serial={f}") plt.title("Amdahl's Law") plt.xlabel("Number of Processors (N)") plt.ylabel("Speedup") plt.legend() plt.grid(True) plt.tight_layout() plt.savefig("parallel-speedup-amdahl-vs-gustafson.png") ## plt.show() 下面是 Amdahl 与 Gustafson 曲线图示。 [caption id="attachment_70445" align="alignnone" width="1000"] Amdahl 定律加速曲线[/caption] [caption id="attachment_70446" align="alignnone" width="1000"] Amdahl vs Gustafson 加速曲线[/caption] [caption id="attachment_70447" align="alignnone" width="1000"] Gustafson 定律加速曲线[/caption]

图示解读

• Amdahl 曲线迅速趋于平缓——受串行部分限制。
• Gustafson 曲线几乎线性上升——适用于可扩展工作负载。
• 串行比例 f 越高，两种模型差距越大。

结论

Amdahl 定律展示了固定工作负载下的并行 上限，适合延迟优化。Gustafson 定律展示了随工作负载扩展的并行 潜力。

• Amdahl 定律 → 固定规模工作负载 → 收益递减
• Gustafson 定律 → 可扩展工作负载 → 近似线性加速
• 结合使用理解硬件极限与算法特性
• Python 工具使可视化直观易懂

它们共同构成现代并行系统性能分析基础，从 HPC 到 LLM 训练，再到 GPU 计算。 英文：The Truth About Parallel Speedup: Amdahl’s Limits vs Gustafson’s Scaling

这事儿，得从上次写那个「互动小说生成器」说起。哦，抱歉，估计大家每天都会被迫看几条AI相关的文章，这篇多少又和它有关。上次那个互动小说生成器就是 AI 驱动的嘛。说实话，虽然我当时只是把它嫁接在 mastodon 上面，作为一个社交平台机器人，接收网友的互动指令来生成故事内容，但是我对比了一些市面上专为写小说而设计的工具，其实设计思路上，我自己感觉，那个简单的机器人已经是第一流的水平了：它有世界状态快照，记录故事中出现过哪些人物、物品、线索，「第一幕中有把枪挂在墙上，那么在第二幕或者第三幕中这把枪必须发射」；它有因果链，记录每一个事件的前因后果，避免情节出现矛盾；它还有节奏器，负责控制不同章节的节奏快慢，以及实现我个人趣味方面的章节间字数多少的某种韵律感……好了，不说了，虽然我自认为设计的很不错，不过我也必须承认，AI 搞创作，还是不行。对文字有足够的敏感度，就总会觉察到，处处别扭。所以再是耗费心力写出来的代码，也毫不吝惜地删了。

不过能不心疼吗？我都没存到 github 上就那么给删了。所以，后来又想着，也不真用它写小说，就玩儿呗，再写一个更周详的工具吧。于是就有了现在这个还在弄的游戏。刚才也提到了世界快照，生产故事已经用到了「世界」这个概念，那么继续把这个世界充实起来，就也顺理成章。其实我读小说时经常会想，曾经和主角擦肩而过的那些无名的角色，他们的日常是怎样的呢？难道他们的生活就没有被书写价值吗？所以一开始，这个游戏是想呈现出一部全景小说。玩家随便选择一个角色，就能观看聚焦在这个角色周围的故事。因为一开始的想法是游戏里的每个 NPC 都由 AI 驱动，所以很自然想到了《西部世界》，所以我给项目文件夹命名「东部世界」，但是想也知道那不太现实，先不说 AI 太贵，就算不差钱，如果 NPC 每个行为都要几十秒运算，那也卡得不像样了。还是得老老实实像传统游戏一样写代码，给 NPC 设定日常流程，饿了该吃饭、渴了要喝水，这些不能是 AI，而是 if else。不过还是得感谢 AI，慢慢程序有了个雏形，我弄得很慢，因为 AI 写出来的东西我要求自己不看明白咱就不继续往下走，边看边学吧。这也是我没打算把这个东西开源的原因，小玩意不值得拿出来现眼是一方面，主要是高手云集，诸位写得快，我学得慢，还不一下子就成了我看都看不懂的东西了？那可不行，别剥夺我的快乐。总之吧，游戏渐渐也跑起来了，让我想到《楚门的世界》，因为我就像是在对着镜头窥视这些一无所知的 NPC 生活。所以我又给游戏取名字叫《甄仁岛的故事》。楚门对甄仁，还不错。

我跟朋友聊起这个游戏，他说，啊？就是看文字？哈哈，好像「看文字」现在成了很奇怪的事，这倒又给了我一些想法。我觉得游戏叫《甄仁岛的来信》吧，不光是纯文字的游戏，索性，连原计划实时查看世界正在发生的故事的「信息看板」都砍掉，游戏世界就是个黑盒子，我们不知道里面在发生什么。倒也符合游戏世界的设定：那是一个被奇特场域包围，导致人类无法进入或离开的一个小岛，有大约几十个岛民居住其上，每天只有一班无人驾驶的轮渡进出岛屿，补给物资，同时也运送信件。玩家唯一可用的交互方式就是，特定时间段，在游戏的网站上投递信件，回信第二天才能跟随轮渡回到码头，寄送到玩家手上——也就是注册时填写的电子邮箱里。

如果当作小说来看，AI 的创作的确不行，但是当作游戏来玩，那种略有些别扭的文风，恰好带来一种复古游戏体验。第一个阶段的游戏目标是，通过文字交流，画出甄仁岛的大致地图。我还在想奖品是什么。毕竟这还挺难的，奖品也得够有吸引力才行。为了实现这个探索地图的功能，我已经实现了 NPC 在地图上自由行走，并且会记录下从 a 点到 b 点用了多少时间，但是，行走速度和身高和年龄有关——又是 if else 算出来的数值。而且岛的面积可不小，要想确定地图内容，得和不止一个 NPC 对话，互相参照和补充着分析才行。他们现在也已经可以主动规划去走一遍 a 到 b 的旅程，但是经我测试，怎么劝他下定决心，放弃当天的工资，去专程走这么几趟，是需要一些笼络人心的话才行的。

然而。我支线开得太多，性格又拖泥带水，总感觉离「现在就上线吧」还差那么一点：应该有真实的经济系统；应该有最初设想的故事性……而且一边写，一边学，有时候恍然大悟，哇哦原来可以这样实现？那岂不是之前那个功能可以写得更优雅些？于是，版本才到 0.001，却已经重构三次了。哦，我还忘了提，李飞飞工作室出的那个简单提示词生成一整个图形化可交互世界的 AI 产品，简直是和我这个小小小游戏完全两极的东西。总之就到这里吧，今天就不看代码了，梳理一下思绪，记上这一笔。希望早日完工，但也可能完不了工。

fin.