CPU 和 GPU 谁更强？

本文结合chatgpt生成

CPU 和 GPU 谁更快？为什么有些任务 CPU 反而更有优势？

我们经常听到一种说法：CPU 擅长处理复杂任务，而 GPU 擅长并行计算。

但这就带来了一个问题：

GPU 有成千上万个计算单元，计算能力远超 CPU，为什么我们不把所有任务都交给 GPU 呢？

事实上，CPU 和 GPU 的设计目标并不相同。GPU 虽然拥有更强的大规模并行计算能力，却不意味着它在所有任务中都更快。

下面，我们通过一个贯穿全文的例子，理解两者的区别。

一、先看一个例子：电商平台计算订单价格

假设我们正在开发一个电商平台，每位用户下单时，系统需要根据商品价格、会员等级和优惠券计算最终支付金额。

计算规则如下：

def calculate_price(price, level, coupon):
    discount = [1.0, 0.95, 0.9, 0.8]

    rate = discount[level]
    final_price = price * rate - coupon

    return max(0, final_price)

例如，一个黄金会员购买了价值 200 元的商品，享受九折优惠，并使用一张 20 元的优惠券：

[
200\times 0.9-20=160
]

最终支付 160 元。

现在假设我们需要计算不同数量的订单：

• 场景 A：只有 10 笔订单。
• 场景 B：有 100 万笔订单。
• 场景 C：有 100 万笔订单，但每笔订单的优惠规则都不一样。

这三种情况，究竟应该使用 CPU 还是 GPU？

二、CPU 和 GPU 的核心区别

我们可以把 CPU 和 GPU 想象成两种不同的工作团队。

CPU 像一个由少量全能员工组成的团队。

每个员工能力都很强，既能计算，也能进行复杂判断，还能灵活处理各种突发情况。

GPU 则像一个拥有大量员工的流水线工厂。

每个员工执行的操作相对简单，但可以让大量员工同时工作。

这就决定了两者不同的优化方向：

对比	CPU	GPU
计算核心	相对较少，但功能强大	大量并行计算资源
单线程性能	通常较强	通常较弱
复杂分支	擅长	可能影响效率
大规模并行	能够并行，但规模有限	非常擅长
主要优势	低延迟、复杂控制	高吞吐量、大规模计算

这里需要区分两个概念：

• Latency（延迟）：完成一次任务需要多长时间。
• Throughput（吞吐量）：单位时间内能够完成多少任务。

CPU 往往更注重单个任务的执行效率，而 GPU 更注重大量相似任务同时执行时的总体效率。

三、场景 A：只有 10 笔订单，CPU 可能更快

回到我们的电商平台。

假设现在只有 10 笔订单需要计算。

对于 CPU 来说，这只是几十次简单的算术运算，可能很快就能完成。

但如果使用独立 GPU，整个过程可能包括：

1. CPU 向 GPU 提交计算任务。
2. 必要时，将订单数据复制到 GPU 显存。
3. 启动 GPU Kernel（运行在 GPU 上的计算程序）。
4. GPU 计算并返回结果。

虽然 GPU 真正执行计算可能非常快，但启动 Kernel 和传输数据都需要时间。

为了理解这个问题，我们假设：

耗时	CPU	GPU
实际计算	4 μs	1 μs
启动及其他开销	—	8 μs
总耗时	4 μs	9 μs

以上是假设数据，仅用于说明原理。

GPU 的计算速度虽然快四倍，但总耗时反而更长。

这就像你只需要搬一本书，从楼上走到楼下就可以了，没必要专门找一辆货车。

因此，对于规模很小的任务，GPU 的额外开销可能超过并行计算带来的收益。

这也解释了 GPU 优化中一个常见技术：Kernel Fusion（算子融合）。

它会将多个小计算合并成一个 Kernel，以减少重复的启动和中间数据处理开销。

四、场景 B：100 万笔订单，GPU 开始发挥优势

现在，电商平台迎来了一场大型促销活动，需要同时计算 100 万笔订单。

注意，这些订单之间没有依赖关系。

第一笔订单计算得到 160 元，并不会影响第二笔订单的计算。

因此，我们完全可以同时计算不同订单。

对于 CPU，虽然也可以使用多线程处理，但能够同时执行的线程数量相对有限。

GPU 则可以启动大量线程，将订单分配给不同的线程处理。

例如：

# 逻辑示意：每笔订单可以独立计算
for i in parallel_range(1_000_000):
    result[i] = calculate_price(
        prices[i],
        levels[i],
        coupons[i]
    )

这里的 parallel_range 只是表示并行计算，并非实际的 Python GPU API。

当数据量足够大时，GPU 的并行计算能力能够充分发挥，启动开销在总耗时中的占比也会变小。

这就引出了一个重要概念：

TLP（Thread-Level Parallelism，线程级并行）。

GPU 主要通过大量线程同时执行任务，并在部分线程等待数据时调度其他线程，来提高吞吐量、隐藏访存延迟。

CPU 则具有更复杂的单核执行机制，例如：

• 分支预测（Branch Prediction）：预测程序接下来要执行的分支。
• 乱序执行（Out-of-Order Execution）：在不违反数据依赖的前提下，优先执行已经准备好的指令。
• 多级缓存（Cache）：减少访问较慢内存的次数。

这些机制能够提高单个线程的执行效率。

所以，我们可以初步总结：

CPU 擅长把少量任务尽快完成，而 GPU 擅长同时完成大量任务。

不过，任务数量多不代表 GPU 一定更快，我们还需要考虑任务本身是否适合并行。

五、场景 C：100 万笔订单，但优惠规则非常复杂

假设现在的优惠规则升级了。

普通会员按照原价计算，白银会员打九五折，黄金会员需要根据商品类别判断折扣，钻石会员还可能叠加限时优惠。

于是代码变成：

if level == 0:
    final_price = price

elif level == 1:
    final_price = price * 0.95

elif level == 2:
    if category == "electronics":
        final_price = price * 0.9
    else:
        final_price = price * 0.85

else:
    final_price = special_discount(price)

此时，每笔订单可能进入不同的计算分支。

这会给 GPU 带来一个问题：线程束分歧（Warp Divergence）。

以 NVIDIA GPU 为例，GPU 通常将 32 个线程组织成一个 Warp（线程束）。

如果一个 Warp 中，有些线程执行普通会员逻辑，另一些线程执行黄金会员逻辑，那么 GPU 可能需要分别执行不同的分支路径。

在执行某一分支时，不属于该分支的线程可能暂时无法参与有效计算。

这会降低 GPU 的资源利用率。

CPU 则有复杂的分支预测和独立的核心控制机制，更适合处理多变的控制逻辑。

不过，这并不意味着出现 if 就应该使用 CPU。

如果 100 万笔订单中，大多数订单执行相同的优惠规则，那么 GPU 仍然能够高效执行。

即使分支不同，只要并行规模足够大，GPU 依然可能更快。

真正影响 GPU 效率的，是大量并行线程之间的执行路径是否存在明显差异。

六、再增加一个条件：后一笔订单依赖前一笔

现在，我们给电商平台增加一个积分账户。

假设同一用户有 100 元余额，连续提交多笔订单：

balance = 100

for order in orders:
    if balance >= order.price:
        balance -= order.price
        order.success = True
    else:
        order.success = False

这里就出现了新的问题：

第二笔订单能否成功，取决于第一笔订单处理后剩余多少余额。

第三笔订单又取决于第二笔订单。

因此，这几笔订单必须遵守前后顺序。

这叫做 数据依赖（Data Dependency）。

对于这样的严格依赖链，即使 GPU 拥有数千个计算单元，也无法简单地让所有步骤同时执行。

CPU 的高单线程性能，通常更适合处理这类低并行度的工作。

但如果我们需要处理的是 100 万个不同用户的余额，每个用户之间互不影响，那么仍然可以将不同用户的计算并行处理。

由此可见：

决定 GPU 能否发挥优势的关键，不是计算量大不大，而是存在多少可以独立执行的计算。

七、还有一个重要因素：数据访问方式

回到最初的优惠计算。

假设我们需要根据用户 ID，从一个巨大的用户数据库中查找会员等级。

如果每笔订单都要随机查询不同位置的数据，那么计算性能就不再只取决于算术运算速度。

它还取决于内存访问效率。

CPU 拥有多级缓存、硬件预取和乱序执行等机制，适合处理许多延迟敏感、访问不规则的任务。

GPU 则拥有较高的内存带宽，可以通过大量并发线程隐藏部分访存延迟。

因此：

• 如果只有少量随机查询，而且查询之间存在依赖，CPU 可能更合适。
• 如果有海量相互独立的查询，GPU 仍然可能更快。

这里涉及两个非常重要的概念：

Compute-bound（计算受限）：程序主要受到计算能力限制。

Memory-bound（访存受限）：程序主要受到数据读取或写入速度限制。

例如，我们最开始的订单计算：

\(\text{FinalPrice}=\text{Price}\times\text{Discount}-\text{Coupon}\)

每笔订单只需要少量算术运算，却必须读取价格、折扣和优惠券等数据。

如果处理海量订单，它就很容易受到内存带宽的影响。

但需要强调：

访存受限不意味着 CPU 更快。 GPU 通常拥有更高的内存带宽，所以即使是访存受限的任务，也可能在 GPU 上执行得更快。

八、为什么 GPU 算力很强，整个程序却不一定快？

假设电商平台一次处理 100 万笔订单，总耗时由三部分组成：

阶段	耗时
CPU 准备订单数据	20 ms
GPU 计算订单金额	10 ms
整理并返回结果	20 ms
总计	50 ms

现在，我们对 GPU 计算进行优化，将计算时间从 10 ms 缩短为 1 ms。

整个程序的耗时就变成：

\(20+1+20=41\text{ ms}\)

虽然 GPU 计算快了 10 倍，但整个程序的性能只提升了约 22%。

因为真正占据大量时间的，是 CPU 端的数据准备和结果处理。

这种现象可以用 阿姆达尔定律（Amdahl's Law） 解释：

程序整体的加速效果，会受到未被优化部分的限制。

这也是为什么现代 AI 推理系统通常需要 CPU 和 GPU 协同工作。

CPU 负责请求调度、数据准备、运行时控制等工作；GPU 负责大规模矩阵计算和其他并行运算。

如果 GPU 已经很快，而 CPU 调度成了瓶颈，那么继续优化 GPU 不一定能显著提升整体性能。

九、总结：什么时候选择 CPU，什么时候选择 GPU？

通过电商订单计算这个例子，我们可以得到一个比较清晰的判断框架。

任务特点	通常更适合
只有少量订单，计算很简单	CPU
数百万笔独立订单，规则相似	GPU
优惠规则复杂、分支高度不一致	CPU 更有机会
订单之间有严格的前后依赖	CPU 更有机会
大量独立的数据查询	GPU 可能更有优势
数据主要在 CPU 内存中，计算量很小	CPU
大规模矩阵乘法	GPU

当然，这些只是经验判断，最终仍需通过实际性能测试确认。

遇到新的计算任务时，我们可以依次问自己五个问题：

1. 任务规模有多大？
2. 有多少计算可以同时进行？
3. 不同线程的执行逻辑是否相似？
4. 数据存储在哪里，需要多少数据传输？
5. 我们更关注单次延迟，还是整体吞吐量？

能够回答这些问题，就能够初步判断一个任务更适合 CPU 还是 GPU。

CPU 擅长让少量复杂的事情尽快完成，GPU 擅长让大量相似的事情高效完成。