CHAPTER 04 ≈ 45 MIN READ

第二章：计算的大脑——CPU与GPU

【上章回顾】上一章我们搞清楚了文件住在哪里——硬盘是仓库，内存是工作台，缓存是调料架。但我们一直绕开了一个问题：是谁在使用这张工作台？谁在发号施令，让数据流动起来？

【本章目标】这一章我们要揭开两块最重要的芯片的面纱：

理解 CPU 为什么被叫做"中央处理器"，核心数和主频到底意味着什么

理解指令集是怎么回事，为什么 ARM 和 x86 的程序不能互通

理解 GPU 凭什么跑游戏、跑 AI——它和 CPU 的根本区别在哪

理解 CPU 和 GPU 的分工哲学，以及为什么现代 AI 全都押注在 GPU 上

预计阅读时间：40-50 分钟

2.1 CPU：真正的中央处理器

一个厨师的故事

想象一家高档餐厅。厨房里只有一位大厨——他技艺精湛，什么菜都会做：炒、炖、烤、蒸，甚至还会做甜点。但他一次只能专注于一件事：要么在颠勺，要么在盯着火候，要么在调味。他速度极快，切一根葱只需要零点几秒，但他永远是串行工作的——一道菜一道菜地来。

这位大厨，就是 CPU。

CPU（Central Processing Unit，中央处理器）是计算机的核心指挥官，也是真正执行所有计算的地方。你打开一个网页、运行一段代码、甚至移动一下鼠标，本质上都是 CPU 在一步一步地执行一条条指令。

它的特点是：通用、精确、串行（或轻度并行）、极快。

核心概念：核心、线程、主频

打开你电脑的任务管理器（Windows 按 Ctrl+Shift+Esc，macOS 用活动监视器），点到"性能-CPU"选项卡，你会看到一堆数字：

逻辑处理器数（如 16）
核心数（如 8）
主频（如 2.50 GHz，峰值 4.90 GHz）

这三个数字到底是什么意思？

主频：大厨的做菜速度

主频（Clock Speed），单位是 GHz（吉赫兹），表示 CPU 每秒钟执行多少次基本操作。1 GHz = 每秒 10 亿次时钟周期。

但这里要注意：一次时钟周期不等于执行一条指令。现代 CPU 通过各种优化，可以在一个时钟周期内并发处理多条指令（这叫流水线和超标量，我们不深入展开）。但粗略来说，主频越高，CPU 处理单个任务的速度越快。

一个 5 GHz 的 CPU，每秒执行 50 亿次操作。这是什么概念？如果你一秒钟能打 5 个字，那 CPU 一秒钟能"打" 50 亿个字。它等待你敲一下键盘的时间，足够它做几十亿次计算。

主频不是越高越好，因为：

提高主频会导致功耗和发热量急剧上升（大致与频率的三次方成正比）
单核性能的提升到了物理极限，靠堆主频的时代已经过去了

所以 CPU 厂商转向了另一个方向——多核心。

核心数：雇了更多大厨

核心（Core），可以理解为一个独立的计算单元。一个 8 核 CPU，相当于餐厅里有 8 位大厨，他们可以同时各自处理一道菜。

多核心对于多任务和可以并行化的程序非常有用：

你一边下载文件，一边看视频，一边写文档——这三件事可以分别跑在不同核心上
编译代码（把你写的程序翻译成机器能执行的二进制）是典型的可以并行化的任务，16 核编译比 4 核快得多

但也有个问题：不是所有任务都能并行。有些任务天生是串行的——第二步必须等第一步算完才能开始。在这类场景下，核心数再多也没用，反而是单核性能（主频和架构）更重要。

这也是为什么打游戏的时候，你会看到"单核性能"这个词被反复强调——很多游戏的主线程是串行的，多核帮不上太大忙。

线程：大厨的多任务能力

现代 CPU 普遍支持超线程技术（Hyper-Threading），让一个物理核心可以伪装成两个逻辑处理器。

怎么理解？还是大厨的比喻：一位大厨在等某道菜入锅之前，可以趁这个间隙去处理另一道菜的备料。虽然他本质上是一个人，但因为切换得很快、空闲时间被充分利用，对外表现得像两个人在同时工作。

所以你的 8 核 16 线程处理器，意味着：8 个物理核心，每个核心对操作系统呈现为 2 个逻辑处理器，合计 16 个逻辑处理器。

超线程能提升大约 15-30% 的多线程性能，但不能替代真正的物理核心。

现实参数对照

以 Intel 的 i7-13700H（2023年款，常见于中端笔记本）为例：

参数	数值
核心架构	6 性能核 + 8 能效核（共 14 核）
线程数	20 线程
基础频率	2.4 GHz
最大睿频	5.0 GHz
三级缓存	24 MB
TDP	45W

你注意到了吗——它有两种核心：性能核（P-Core） 和 能效核（E-Core）。这是 Intel 从 12 代开始引入的大小核架构（类似于手机 SoC 的设计思路）：

性能核：主频高、单核性能强，处理需要快速响应的任务（游戏主线程、前台应用）
能效核：主频较低、功耗小，处理后台任务（系统服务、下载、同步）

这样做的好处是：在性能需要的时候用大核全力冲，闲置时候能效核维持运行，整体功耗更合理。

CPU 是怎么执行指令的

CPU 的工作原理，用一句话概括就是：取指令 → 解码 → 执行 → 写回，循环往复。

取指（Fetch）：从内存（或缓存）里把下一条指令取过来
解码（Decode）：把这条指令翻译成 CPU 内部电路能理解的操作信号
执行（Execute）：调用 ALU（算术逻辑单元）或其他执行单元，完成计算
写回（Write Back）：把计算结果存回寄存器或内存

这个循环每个时钟周期都在发生，现代 CPU 还有流水线（把这四步重叠进行，类似工厂流水线）和乱序执行（预测后续指令，提前开始执行）等技术加速这个过程。

但这些优化的本质，都是为了让这个大厨每一秒都尽量不闲着。

流水线：让大厨永不空闲

上面那个「取指 → 解码 → 执行 → 写回」的四步循环，如果每条指令都必须等上一条完全走完四步才能开始，CPU 里大部分电路大部分时间都是空闲的。

工厂早就解决了这个问题——流水线（Pipeline）。

想象汽车装配线：第一辆车在装发动机的时候，第二辆车已经在装变速箱了，第三辆车在装车门，第四辆车在做最终检验。虽然每辆车装完仍然需要同样的时间，但整条线同时在处理多辆车，吞吐量大幅提升。

CPU 的流水线完全一样：

时钟周期:   1   2   3   4   5   6   7
指令 1:    取指 解码 执行 写回
指令 2:        取指 解码 执行 写回
指令 3:            取指 解码 执行 写回
指令 4:                取指 解码 执行 写回

四步流水线下，每个时钟周期结束时，理想情况就是完成一条指令（而不是四个时钟周期才完成一条）。现代 CPU 的流水线深度通常在 10-20 级，Intel 的某些设计甚至达到过 30 级。流水线越深，每一级做的事越少，理论上可以跑更高的主频——但也带来了更大的"分支惩罚"问题。

流水线的敌人：分支指令

流水线工作得很好，只要指令是顺序执行的。但程序里有大量的条件分支：

# 伪代码
if 用户账户余额 > 0:
    执行转账
else:
    提示余额不足

在取指阶段，CPU 还不知道判断结果——它要等「判断余额」这条指令执行完才知道下一步跳到哪。如果 CPU 什么都不做，就要把流水线后续的位置全部空着，等一个结果———这叫流水线停顿（Pipeline Stall）。

对于一个 15 级流水线的 CPU，每次分支预测失败，就要浪费最多 15 个时钟周期——在 5 GHz 的 CPU 上，这是 3 纳秒的损失。程序里平均每 5-7 条指令就有一条分支，这个代价不可忽视。

分支预测：大厨的直觉

解决方案是分支预测（Branch Prediction）：CPU 不等结果，直接预测跳转方向，提前把预测路径上的指令塞进流水线继续执行。

如果预测对了：一切正常，流水线未中断，性能无损失
如果预测错了：清空流水线中错误路径上的指令（流水线冲刷，Pipeline Flush），从正确路径重新开始——浪费了那么多周期

现代 CPU 的分支预测精度极高，通常在 95% 到 99% 之间。Intel 和 AMD 的分支预测器是非常复杂的硬件学习系统，能识别循环次数、历史跳转模式，甚至利用神经网络思路（感知机分支预测器）。

这件事有一个有趣的实际意义：你写的代码的数据分布，会影响CPU的性能。有一个著名的例子：对一个随机数组做判断，比对一个排好序的数组做同样的判断慢数倍——因为乱序数组的分支预测率更低。2012 年 Stack Overflow 有一个讨论这件事的回答，至今仍是该网站历史上点赞最多的答案之一，你可以搜索「Why is processing a sorted array faster than an unsorted array」找到它。

乱序执行：不按食谱的顺序来

除了流水线，现代 CPU 还有另一个优化：乱序执行（Out-of-Order Execution，OoOE）。

设想你在按食谱做菜：步骤 3 要等步骤 2 完成（比如等水烧开），但步骤 4 和步骤 2 没有依赖关系（比如切菜）。聪明的厨师不会傻等水开——他先去切菜。等水烧好，步骤 3 就可以立刻进行。

CPU 的乱序执行同理：如果下一条指令要等待某个数据（比如正在从缓存读取），CPU 会扫描后续的若干条指令，找出那些当前执行条件已经满足的指令，提前执行它们，等到数据到位后再完成原本的指令，最后按程序原本的顺序提交结果（重排序缓冲区，ROB，确保结果对程序员来说仍然是顺序的）。

乱序执行的窗口（一次能预先看多少条指令）在现代 CPU 上通常是 200-600 条指令。这意味着 CPU 是一个能超前"阅读"几百条指令、提前计划执行顺序的系统，而不是傻乎乎地一条条读。

【建议配图】流水线冲刷示意图：

正常流水线（预测正确）：
时钟:  1   2   3   4   5   6   7   8
指令A: F   D   E   W
指令B（预测）:  F   D   E   W

流水线冲刷（预测错误，分支在指令A）：
时钟:  1   2   3   4   5   6   7   8
指令A: F   D   E   W
指令B（错）:   F   D  [丢弃]
指令C（错）:       F  [丢弃]
正确指令B':            F   D   E   W
                    ↑ 冲刷，重新开始

投机执行与安全：一个意外的副作用

乱序执行和分支预测带来了性能提升，但 2018 年，研究人员发现这两种技术也带来了一个严重的安全漏洞——幽灵（Spectre） 和 熔断（Meltdown）。

简单来说：CPU 在投机执行期间，可能会访问不该访问的内存区域。虽然最终会丢弃结果，但访问的痕迹留在了缓存里，可以被恶意程序通过缓存时序侧信道检测到，从而偷取其他程序的数据。

这个漏洞影响了几乎所有现代 CPU（Intel、AMD、ARM），补丁方案导致性能下降了 5-30%（取决于任务类型）。这件事告诉我们：硬件优化不只是性能问题，也是安全问题，而且一旦写进硅片就很难修复。

你在科大学操作系统时，老师可能会提到 Meltdown 和 Spectre——它们已经是现代安全研究的经典案例。

❌ 常见误区澄清

❌ 核心数越多，电脑越快 ✅ 取决于任务类型。单线程性能强的 4 核 CPU，在游戏中可能比 16 核但频率低的 CPU 表现更好。"快"是相对于具体任务而言的。

❌ 主频 3.5 GHz 比 2.5 GHz 快 40% ✅ 不同架构之间主频没有可比性。Apple M3 的 4 GHz 和 Intel 的 4 GHz 是完全不同的东西——苹果的 IPC（每时钟周期执行的指令数）更高，实际性能远不止靠主频来定。

❌ 睿频就是正常运行频率 ✅ 睿频（Turbo Boost）是短时峰值频率，只在有散热余量时触发，且只持续几秒到几十秒。长时间负载下，CPU 会因温度限制降频到"长期功耗墙"对应的频率。这就是为什么某些笔记本标称 5 GHz，实测持续性能却很一般。

🔧 动手环节：观察你 CPU 的真实行为

Windows 用户：

按 Ctrl+Shift+Esc 打开任务管理器
点击"性能" → "CPU"
观察以下内容：
- 当前主频 vs 基础频率（是否在睿频中？）
- 逻辑处理器数量
- 右键图表，选"将逻辑处理器图形更改为" → "每个逻辑处理器"，可以看到每个核心各自的负载情况

然后打开一个网页或运行一个程序，观察各核心的负载如何变化——你会看到少数几个核心在工作，其余的几乎空闲。这就是"单线程任务只用单核"的直观体现。

macOS 用户：

打开"活动监视器"（Spotlight 搜索即可）
点击 CPU 标签
在底部可以看到 CPU 负载曲线

如果你用的是 M 系列芯片 Mac，可以在终端运行：

sudo powermetrics --samplers cpu_power -n 1

能看到性能核和能效核各自的频率与功耗（需要管理员权限）。

✓ 本节要点

✓ CPU 是计算机的大脑，负责执行所有指令，特点是通用、精确、串行
✓ 主频决定单核速度，核心数决定并行能力，二者服务于不同场景
✓ 超线程让一个核心对外表现为两个逻辑处理器，提升利用率
✓ 大小核架构（Intel 12代+）是性能与能效的平衡设计
✓ 睿频只是短时峰值，散热是决定实际性能的重要因素

2.2 指令集：CPU 的"方言"

你的程序在外星球跑不了

2020 年，苹果发布了 M1 芯片，宣布 Mac 电脑全面从 Intel 转向自研 ARM 架构。当时最大的担忧是：我之前买的那些 macOS 软件，还能用吗？

答案是：大部分可以，但需要"翻译"。苹果内置了一个叫 Rosetta 2 的兼容层，能把为 Intel x86 编译的程序实时翻译给 ARM 的 M1 执行。这个翻译做得相当好，以至于很多人感知不到性能损失。

但这件事背后揭示了一个根本性的问题：为 x86 编译的程序，不能直接在 ARM 上运行。反过来也一样。

为什么？因为它们说的是不同的"方言"——这就是指令集架构（ISA，Instruction Set Architecture）。

什么是指令集

CPU 本质上是一堆逻辑电路，它能直接理解的是机器码——一串二进制数，比如 10110000 01100001。这串二进制对 CPU 来说是一条具体的指令："把值 97 存入某个寄存器"。

指令集，就是 CPU 能理解的所有指令的完整集合，以及每条指令的编码格式、操作行为。它定义了：

有哪些指令（加法、比较、跳转、存取内存……）
每条指令的二进制表示是什么
寄存器怎么编号
内存地址怎么表达

你写的高级语言程序（Python、C、Java）最终都要被编译器翻译成这个 CPU 能直接执行的机器码。编译时，你得告诉编译器"我要编译给 x86-64"还是"编译给 ARM64"，因为这两套指令集的机器码完全不同。

x86 和 ARM：两条不同的路

现代桌面/服务器领域主要有两大指令集阵营：

x86（准确说是 x86-64）

起源于 1978 年 Intel 的 8086 处理器，经历几十年演化。为了向后兼容，它背负了大量历史包袱——一些 1980 年代的设计决策至今还保留着。

特点：

CISC（复杂指令集）：指令数量多，单条指令可以完成复杂操作
指令长度可变（1-15 字节不等），解码复杂
历史包袱重，但生态极其庞大
功耗相对较高

Intel 和 AMD 的桌面/笔记本 CPU，服务器 CPU，都是 x86。Windows 生态基本上是围绕 x86 建立的。

ARM

起源于 1985 年英国 Acorn 公司，设计哲学与 x86 截然不同。

特点：

RISC（精简指令集）：指令数量少，每条指令做的事情简单
指令长度固定（AArch64 模式下每条指令固定 4 字节），解码简单，功耗低
授权模式（ARM 公司卖 IP，其他公司设计芯片），生态碎片化但覆盖极广
功耗效率极高

手机芯片几乎全是 ARM（高通骁龙、联发科天玑、苹果 A 系列、华为麒麟）。苹果 M 系列是 ARM 架构的桌面/笔记本实现，证明了 ARM 在高性能端同样能打。

【建议配图】x86 vs ARM 对比示意图

x86-64 指令（变长，1-15字节）          ARM64 指令（固定4字节）
┌─────────────────────────────┐         ┌───────────┐
│  操作码  │  前缀  │  操作数...│         │  操作码  │  操作数  │
└─────────────────────────────┘         └───────────┘
      解码复杂，但功能丰富                   解码简单，功耗低

为什么不统一成一种指令集？

这问题问得好，答案是：技术上可以，但生态不允许。

x86 的生态是几十年积累的。全世界数十亿台电脑上跑的程序，游戏、办公软件、工具，大多数都是 x86 的二进制。如果明天所有 CPU 都换成 ARM，这些程序全部需要重新编译，甚至部分需要重写——这是不可能的迁移成本。

苹果能成功完成迁移（从 PowerPC 到 Intel，从 Intel 到 ARM），是因为他们掌控了整个软件生态，而且迁移是有几年过渡期的，最重要的是他们有 Rosetta 翻译层兜底。

对于 Windows 来说，Microsoft 也在推 Windows on ARM，但因为兼容性问题和软件生态的迁移难度，至今进展缓慢。

还有一个值得一提的指令集：RISC-V。它是一个完全开源、无专利费的指令集，诞生于 2010 年。目前主要在嵌入式、学术研究和部分服务器领域出现，中国有不少机构在大力投入。中科大自己也有相关的 RISC-V 研究——你在这里学微电子，未来说不定会设计自己的 RISC-V 芯片。

指令集、编译器与你写的代码：三层抽象

理解指令集的一个常见误区是：觉得指令集是程序员需要直接面对的东西。大多数时候并不是——编译器已经帮你处理了这一层。让我们把这三层抽象讲清楚。

你写的 Python 代码，长这样：

def add(a, b):
    return a + b

result = add(3, 4)

经过编译（或解释），最终在 x86-64 CPU 上执行的汇编代码，可能长这样：

; x86-64 汇编（AT&T 语法，GCC 生成，概念示意）
add:
    movl    %edi, %eax    ; 把第一个参数（edi寄存器）移到 eax
    addl    %esi, %eax    ; eax += 第二个参数（esi寄存器）
    ret                   ; 返回，结果在 eax 里

同一段逻辑，编译给 ARM64，变成：

; ARM64 汇编（AArch64 语法，概念示意）
add:
    add     w0, w0, w1    ; w0 = w0 + w1（w0、w1是ARM的寄存器）
    ret                   ; 返回

注意：寄存器名不同（x86 用 eax/esi，ARM 用 w0/w1），指令格式不同，但逻辑相同。这就是为什么同一份 C 或 Python 代码，编译给不同架构能产生不同的二进制——编译器承担了翻译工作。

三层抽象的关系是：

高级语言（C / Python / Java）
        ↓  编译器 / 解释器
汇编语言（人类可读的指令描述）
        ↓  汇编器
机器码（二进制，CPU 直接执行）
        ↓
   CPU 执行（x86 / ARM / RISC-V）

对于编译型语言（C、C++、Rust、Go），这个翻译在你运行程序之前完成，产生特定架构的二进制文件——这就是为什么你下载软件时有时需要选 x86_64 或 arm64。

对于解释型语言（Python、JavaScript），这个翻译在运行时由解释器完成，因此理论上可以在任何架构上运行（只要解释器本身有对应架构的版本）。但代价是额外的运行时开销。

Java 采用了中间路线：编译成字节码（Bytecode），在任意平台上由 JVM（Java Virtual Machine，Java 虚拟机）解释/JIT 编译执行。「Write Once, Run Anywhere」（一次编写，到处运行）的口号正是基于此——JVM 屏蔽了底层 ISA 的差异。

编译器有多复杂？

现代编译器（如 GCC、Clang/LLVM）是极其复杂的软件，它们不仅翻译语言，还做大量优化：

内联展开（Inlining）：把小函数的代码直接嵌入调用处，消除函数调用开销
循环展开（Loop Unrolling）：把循环体复制几次，减少循环控制的开销，方便流水线
向量化（Vectorization / SIMD）：把多个数据的相同操作合并成一条 SIMD 指令（如 AVX-512，一条指令处理 16 个 32 位浮点数），大幅提升数值计算性能
寄存器分配：把变量尽量放在寄存器里，减少内存访问

这里的 SIMD（Single Instruction Multiple Data，单指令多数据）值得多说一句。x86 的 AVX-512 指令集扩展允许一条指令同时操作 512 位数据——相当于 16 个 32 位浮点数同时做加法。这是一种在指令集层面的并行，介于 CPU 的串行和 GPU 的大规模并行之间。深度学习框架的 CPU 推理路径大量使用这类指令。

RISC-V：第三条路

RISC-V 的诞生背景值得多讲几句，因为它和中科大的关系比你想象的更近。

RISC-V 由 UC Berkeley 的 Krste Asanovic 教授团队于 2010 年提出，最初只是用于教学的开源指令集。但它的设计目标很清晰：完全开源、模块化、没有历史包袱。

「模块化」是 RISC-V 的独特之处：它有一个极简的基础指令集（RV32I，只有 47 条指令），然后通过扩展模块按需添加——比如 M 扩展（整数乘除法）、F 扩展（单精度浮点）、V 扩展（向量运算）。你可以只选你需要的。一个微控制器可能只需要 RV32IM，而一个高性能处理器可能需要 RVG（G = IMAFD）加上 V 扩展。

中科大有相关团队在研究基于 RISC-V 的处理器设计，中国科学院也有香山（XiangShan）高性能 RISC-V 处理器开源项目，性能已接近 ARM Cortex-A76 水平。如果你未来选择处理器架构或微电子方向，RISC-V 几乎可以确定会是你接触的主要平台之一。

从更宏观的视角看，RISC-V 代表了一种可能性：指令集可以不被商业公司垄断。就像 Linux 之于操作系统，RISC-V 之于处理器架构——开源生态有没有可能动摇 x86 和 ARM 的垄断地位？目前答案是「在某些细分市场已经发生了」，但全面动摇还有很长的路。

❌ 常见误区澄清

❌ ARM 指令集是苹果发明的 ✅ ARM 指令集由 ARM Holdings 公司（现属于软银）所有。苹果只是 ARM 的大客户之一，授权了 ARM 指令集设计自己的微架构（如 Firestorm、Everest 等核心）。就像你可以用汉语写出不同风格的文章，苹果用 ARM"语言"写出了自己独特的"文章"。

❌ 64 位比 32 位就是更快 ✅ 64 位主要意义是：能寻址更大的内存空间（32 位最多 4GB，64 位理论上可达 16EB）。对于计算速度本身，64 位不一定更快，甚至有些情况下 32 位程序因为数据量更小反而更快。关键是它打破了 4GB 内存上限的枷锁。

🔧 动手环节：看看你的 CPU 是什么架构

Windows：

# 在 PowerShell 或 CMD 中运行
wmic cpu get caption

输出类似 Intel64 Family 6 Model 154 Stepping 3 说明是 x86-64。如果看到 ARM64，你用的是 ARM Windows 设备（如 Surface Pro X）。

macOS：

uname -m
# 输出 x86_64 = Intel Mac
# 输出 arm64 = M系列芯片 Mac

还可以更进一步：在 macOS 上打开"系统报告"（关于本机 → 更多信息 → 系统报告），在"软件"→"应用程序"列表里，可以看到每个 App 的"种类"：Intel、Apple（原生 ARM）或 Universal（两者都有）。

✓ 本节要点

✓ 指令集是 CPU 能直接理解的"语言"，不同指令集的程序不能直接互换运行
✓ x86-64（CISC）是桌面/服务器的主流，ARM（RISC）统治移动端并正在进攻桌面端
✓ RISC 和 CISC 的核心区别是指令的复杂程度，现代实现中差距已经很小
✓ 苹果 M 系列是 ARM 授权 + 自研微架构，不等于"苹果架构"
✓ RISC-V 是开源指令集，代表了未来可能的第三条路

2.3 GPU：平行宇宙的计算方式

为什么显卡能跑游戏？

2023 年，一台搭载 RTX 4090 的电脑，运行《赛博朋克 2077》4K 全特效，画面流畅得像电影。同一时间，这台电脑的 CPU（i9-13900K）却只有 30% 左右的负载。

是 CPU 在偷懒吗？

不。是这件事本身就不需要 CPU 来做——它是 GPU 的主场。

要理解这件事，我们需要先搞清楚渲染一帧画面到底需要什么。

渲染一帧：GPU 的日常工作

你看到的游戏画面，是由数百万个像素组成的。以 4K 分辨率（3840×2160）为例，一帧有 8294400 个像素。游戏跑在 60 帧每秒，意味着每秒要计算 约 5 亿个像素的颜色值。

每个像素的颜色，取决于：光源方向、物体材质、阴影、反射、环境光遮蔽……一个像素的着色计算可能涉及几十到几百次浮点运算。

关键在于：这些像素的计算彼此之间完全独立。第 100 万号像素的颜色，和第 200 万号像素的颜色没有任何数据依赖关系——它们可以同时计算。

这就是 GPU 存在的根本原因：大规模并行计算。

GPU vs CPU：将军 vs 士兵

回到餐厅的比喻。如果说 CPU 是精通所有厨艺、能应对任何复杂订单的大厨，那 GPU 就是一支拥有数千名流水线工人的工厂——每个工人只会做一件简单的事（比如：计算一个像素的颜色），但他们可以同时出发。

具体来说：

对比维度	CPU	GPU
核心数	几个到几十个	几千到几万个
单核性能	极强（复杂逻辑、分支、预测）	较弱（适合简单重复运算）
擅长任务	串行任务、复杂逻辑控制	并行任务、大规模数值计算
缓存设计	大、多级、为单线程优化	小、为高并发吞吐量优化
内存带宽	较低（内存控制器共享）	极高（专用显存 GDDR/HBM）
功耗	中（笔记本 CPU 15-45W）	高（RTX 4090 TDP 450W）

以 NVIDIA RTX 4090 为例：它拥有 16384 个 CUDA 核心（NVIDIA 的并行计算单元），同时运行时这些核心可以同时处理数万个线程。

而 i9-13900K 只有 24 个核心、32 个线程——但每个核心的单独处理能力比 GPU 的一个核心强得多。

GPU 内部结构（概念层面）

GPU 内部是高度层次化的并行结构：

GPU
├── 多个 SM（流式多处理器，NVIDIA叫法）
│   ├── 多个 CUDA Core（基本浮点/整型运算单元）
│   ├── 张量核心（Tensor Core，专门加速矩阵乘法）
│   ├── 光追核心（RT Core，实时光线追踪）
│   └── 共享内存（比显存快得多的片上缓存）
└── 显存（GDDR6X 或 HBM，带宽极高）

以 RTX 4090 为例：

128 个 SM
每个 SM 里有 128 个 CUDA Core
合计 16384 个 CUDA Core
显存带宽：1008 GB/s（相比之下，DDR5 内存带宽约 50-100 GB/s）

这个带宽数字解释了为什么显存跑满比内存跑满更难察觉——GPU 和显存之间的数据高速公路比 CPU 和内存之间宽太多了。

GPU 不只是用来打游戏的

GPU 的"并行计算"能力，随着深度学习的崛起，变得比游戏渲染更重要。

神经网络的核心运算是什么？矩阵乘法。

训练一个大型语言模型，本质上是大量的矩阵相乘、求梯度、更新参数——这些都是高度可并行的数值计算。GPU 天生适合干这件事。

NVIDIA 在 2006 年推出了 CUDA（Compute Unified Device Architecture），允许程序员直接用 GPU 做通用计算（而不仅仅是渲染）。配合 PyTorch、TensorFlow 这样的框架，GPU 成了 AI 时代最重要的基础设施。

你在 Geek Center 写 PyTorch 代码时，model.cuda() 这一句，就是把模型的参数和计算搬到 GPU 上运行——这可能让训练速度提升 10-100 倍。

"为什么 AI 时代内存价格飞起"

开篇的问题在这里可以部分回答了：训练大模型需要 GPU，GPU 需要显存。但推理（让已经训练好的模型帮你干活）要部署在服务器上，服务器里需要大量 DRAM（就是普通内存，但服务器级别的）来缓存模型权重和 KV 缓存（一种推理加速机制）。全球大量部署 AI 推理服务器，内存需求急剧上升，价格自然水涨船高。

渲染管线：GPU 到底是怎样画出一帧的

这一节我们把「GPU 渲染游戏画面」这件事讲得更具体一些。理解渲染管线，你会对「为什么高画质更费显卡」和「光线追踪为什么那么重新」有更清晰的认识。

一帧画面是怎么从游戏引擎里的三维场景，变成你屏幕上的像素的？这个过程叫渲染管线（Rendering Pipeline），大体上分为几个阶段：

三维场景数据（顶点坐标、材质、光源）
        ↓
[顶点着色（Vertex Shading）]
把三维坐标投影到屏幕坐标系，处理每个顶点的位置变换
        ↓
[图元组装 + 裁剪]
把顶点连成三角形，剔除屏幕外的三角形
        ↓
[光栅化（Rasterization）]
把三角形转换成覆盖的像素集合
        ↓
[片段着色（Fragment Shading）]
对每个像素计算颜色（光照、纹理、阴影……）
        ↓
[深度测试 + 输出合并]
处理遮挡关系，写入帧缓冲
        ↓
显示到屏幕

这个管线里，顶点着色和片段着色（也叫像素着色）是计算最密集的两步，也是那些「着色器程序（Shader）」运行的地方。着色器是跑在 GPU 上的小程序，由游戏开发者用 HLSL（Direct3D）或 GLSL（OpenGL）编写。

一个 4K、60 帧的游戏里，每秒需要执行的片段着色器次数：

$3840 \times 2160 \times 60 \approx 5 \times 10^8 \text{ 次/秒}$

每次着色器调用可能涉及纹理采样、阴影计算、PBR（基于物理的渲染）光照模型……GPU 的数千个核心并行处理这些调用，才让实时渲染成为可能。

光线追踪：「欺骗」与「真实」

你可能听说过 RTX 显卡的光线追踪（Ray Tracing）功能。传统光栅化渲染是一种「聪明的欺骗」——它从摄像机处出发，把场景投影到屏幕上，然后用各种技巧（Shadow Map、Screen Space Reflection 等）模拟光影效果。效率极高，但本质上是近似。

光线追踪则从物理上更接近真实：模拟光线从光源发出，与场景中的物体相交、反射、折射，最终到达摄像机的过程。准确说，实时光追通常用「逆向追踪」——从摄像机出发，对每个像素发射光线，追踪它与场景的交点，计算该点的光照。

传统光栅化：
场景三角形 → 投影到像素 → 用技巧近似光影

光线追踪：
相机像素 → 发射光线 → 求与场景交点 → 递归追踪反射/折射 → 累积光照

光追的计算量远大于光栅化，原因在于：每个像素需要求光线与整个场景的交点（场景里可能有数百万个三角形），还需要递归追踪二次、三次反射。NVIDIA 从 Turing 架构（RTX 20 系列，2018年）开始在 GPU 上加入了专门的 RT Core（光线追踪专用单元），负责硬件加速 BVH（包围体层次结构，一种空间加速数据结构）的遍历，大幅降低了光线求交的开销。

即便如此，全分辨率的完整光追仍然开销极大，实际游戏里通常只对特定效果（反射、阴影、全局光照）开启光追，其余部分仍用传统光栅化——这叫混合渲染（Hybrid Rendering）。

为什么换更大显示器会更费显卡？

现在你可以从渲染管线角度理解这件事：分辨率翻倍，意味着像素数量翻倍，片段着色器的调用次数翻倍。从 1080P（2073600 像素）到 4K（8294400 像素），像素数量翻了 4 倍，对 GPU 的算力需求大约也翻 4 倍。这就是为什么某些能在 1080P 跑 144 帧的显卡，在 4K 下只能跑 30 帧。

从游戏显卡到科学计算加速器：GPU 的角色演变

GPU 的用途已经远超游戏。让我们看看 GPU 在不同领域是如何被使用的。

深度学习训练：为什么矩阵乘法和 GPU 是绝配

神经网络的计算，本质上可以表达为矩阵乘法。以一个简单的全连接层为例：

$Y = X \cdot W + b$

其中 $X$ 是输入矩阵（形状 [batch_size, input_dim]），$W$ 是权重矩阵（形状 [input_dim, output_dim]），$b$ 是偏置向量。

假设 $X$ 的形状是 $[256, 4096]$（批量大小 256，每个样本 4096 维），$W$ 的形状是 $[4096, 4096]$，则这一次矩阵乘法涉及：

$256 \times 4096 \times 4096 \approx 4.3 \times 10^9 \text{ 次乘加运算}$

这 43 亿次运算之间完全没有数据依赖——第 $(i, j)$ 个输出元素的计算，和第 $(i', j')$ 个输出元素的计算毫无关系，可以完全并行。GPU 的数千个核心，就是为这种任务而生的。

NVIDIA 的 Tensor Core（从 Volta 架构，也就是 V100 开始引入）是专门加速矩阵乘法的专用单元：一个 Tensor Core 在一个时钟周期内可以完成一个 $4 \times 4$ 矩阵乘法（相当于 64 次乘加运算）。RTX 4090 有 512 个第四代 Tensor Core，以 FP8 精度（低精度浮点，训练和推理常用）计算时，理论算力达到约 1320 TFLOPS（每秒 1320 万亿次浮点运算）。

科学计算：超算里的 GPU

GPU 不只在消费电子里。全球前十名超级计算机中，绝大多数使用 GPU 作为主要的计算加速单元。美国橡树岭国家实验室的 Frontier 超算（曾长期占据 TOP500 第一）使用了 AMD 的 Instinct MI250X GPU，峰值算力超过 1 ExaFLOPS（$10^{18}$ 次浮点运算每秒）。

科学计算用的 GPU 和游戏显卡的主要区别在于：

维度	游戏显卡（如 RTX 4090）	科学计算 GPU（如 H100）
双精度算力	约 97 TFLOPS（FP32），FP64 极低	约 67 TFLOPS（FP64，全精度）
显存容量	24 GB GDDR6X	80 GB HBM3
显存带宽	1008 GB/s	3350 GB/s
NVLink	无	支持多卡高速互联
价格（2024年）	约 12000-15000 元	约 200,000-300,000 元（一张）
主要用途	游戏渲染、入门 AI	大模型训练、科学仿真

注意双精度（FP64）算力的差距：游戏显卡为了节省芯片面积，把 FP64 性能砍得很低（往往只有 FP32 的 1/64 甚至更低）；而科学计算 GPU 需要维持高精度，FP64 算力必须有保障。

挖矿：GPU 算力的另一个用途

2020-2022 年，比特币和以太坊的挖矿热潮导致显卡价格翻了 2-3 倍，一张 RTX 3080 要卖到 1 万元以上，玩家苦不堪言。

挖矿（以以太坊的 Ethash 算法为例）本质上是反复计算哈希函数，需要密集的内存访问（Memory-Bound）——GPU 的高带宽显存非常适合。NVIDIA 后来专门针对以太坊挖矿限制了消费卡的哈希算力（LHR，Lite Hash Rate），防止显卡被扫货。

2022 年以太坊从 PoW（工作量证明，需要挖矿）转向 PoS（权益证明，不需要挖矿）后，大量矿卡流入二手市场，显卡价格才回归正常。

这件事说明：GPU 的算力本质上是一种通用资源，谁需要大规模并行计算，谁就会来争它——无论是游戏渲染、AI 训练还是挖矿。

❌ 常见误区澄清

❌ 显存越大，显卡越好 ✅ 显存大小只是一个维度。一张 16GB 的低端显卡，在渲染性能上远不如 8GB 的高端显卡。显存更像是"工厂的货架大小"，决定一次能放多少材料，但工人的速度（算力、带宽）才是核心。在 AI 推理场景下，显存大小反而更重要，因为模型权重需要全部装进显存——这个场景下"货架大小"是硬约束。

❌ 独立显卡总比集成显卡好 ✅ 集成显卡（核显）近年来进步很快。苹果 M3 的 GPU 部分，在功耗控制下能胜过不少入门级独显，且共享内存带宽更高（因为 CPU 和 GPU 在同一个芯片上，访问同一块内存）。对于不玩 3A 游戏、不跑深度学习的用户，M 系列的集成 GPU 完全够用。

❌ GPU 可以完全替代 CPU ✅ GPU 擅长大规模并行、计算规则简单的任务。操作系统调度、网络协议栈、数据库查询、大多数业务逻辑——这些充满条件分支、顺序依赖的任务，GPU 处理起来很吃力。CPU 和 GPU 是互补关系，不是替代关系。

🔧 动手环节：查看你的显卡信息

Windows：

打开任务管理器 → 性能 → GPU
观察以下数字：
- GPU 利用率（3D / Compute / Copy）
- 显存使用量（专用显存 vs 共享显存）
- GPU 频率

然后打开一个游戏或运行一段 PyTorch 代码（如果你有 NVIDIA 显卡），对比任务管理器里 GPU 和 CPU 的负载变化。

如果有 NVIDIA 显卡，还可以用：

# 安装了 CUDA 的情况下
nvidia-smi

输出会显示显卡型号、显存使用量、温度、功耗、GPU 利用率。

macOS（M 系列）：

M 系列芯片的 GPU 是集成的，可以在活动监视器的"GPU 历史记录"中查看利用率。也可以在终端使用：

sudo powermetrics --samplers gpu_power -n 1

✓ 本节要点

✓ GPU 的核心价值是大规模并行计算，擅长处理大量独立的简单运算
✓ 渲染画面、训练神经网络都是典型的并行计算任务，天然适合 GPU
✓ GPU 拥有数千到数万个简单核心，配合极高带宽的专用显存工作
✓ CUDA 让 GPU 从专用图形硬件变成了通用并行计算平台
✓ 显存大小 ≠ 显卡性能，但在 AI 推理部署中是关键约束

2.4 CPU 与 GPU 的分工哲学

两种思维方式

到这里，我们已经理解了 CPU 和 GPU 各自是什么。现在来说一个更有意思的问题：它们的设计理念为什么如此不同？

这背后是两种完全不同的计算哲学。

延迟优化 vs 吞吐量优化

这是理解 CPU 和 GPU 分工的最核心概念：

CPU 的设计目标：最小化延迟（Latency）

延迟，是从"发出请求"到"得到结果"的时间。CPU 的每个核心，都配备了大量用于预测、缓存、乱序执行的电路，目的只有一个：让这一个任务尽快完成。

想象一个高级客服：她有一个请求，立刻调用所有资源来解决它——查数据库、调系统、和后台沟通——总之以最快速度给你答复。她一次只服务一个人，但这个人的等待时间极短。

GPU 的设计目标：最大化吞吐量（Throughput）

吞吐量，是单位时间内处理多少任务的总量。GPU 不在乎某一个任务多快完成，它在乎的是所有任务在单位时间内完成多少。

想象一家银行的叫号大厅：有 1000 个窗口，每个窗口的柜员能力一般，但他们同时在服务 1000 个客户。虽然每个客户等待的时间不一定最短，但整个大厅的总处理速度（每小时服务多少人）远超一个超级客服。

这两种设计取向，决定了 CPU 和 GPU 的硬件结构：

CPU 核心面积分配（概念示意）：
┌──────────────────────────────────────────┐
│   控制逻辑（分支预测/乱序执行）  30%       │
│   缓存（L1/L2/L3）              40%       │
│   执行单元（ALU/FPU）           30%       │
└──────────────────────────────────────────┘
→ 大量面积用于"让单任务更快"的辅助电路

GPU 核心面积分配（概念示意）：
┌──────────────────────────────────────────┐
│   执行单元（大量 CUDA Core）     80%+      │
│   共享内存 / 寄存器文件          15%       │
│   控制逻辑（极简）               5%        │
└──────────────────────────────────────────┘
→ 绝大多数面积用于"执行计算"本身

（注：上面的百分比是概念性示意，实际芯片的面积分配更复杂。）

异构计算：让它们协同工作

现代计算机不是 CPU 干全部活，也不是 GPU 干全部活——而是异构协同：

一个典型游戏帧的执行流程：

1. CPU：处理游戏逻辑
   - 读取玩家输入
   - 更新所有 NPC 的 AI 状态
   - 计算物理碰撞（大量分支逻辑）
   - 决定这一帧需要渲染什么

2. CPU → GPU：提交渲染命令
   - CPU 把"这一帧要画什么、怎么画"打包成命令列表
   - 通过 PCIe 总线发送给 GPU

3. GPU：并行渲染
   - 顶点着色器：处理所有三角形顶点的坐标变换（可并行）
   - 光栅化：把三角形转成像素（可并行）
   - 片段着色器：计算每个像素的颜色（可并行）
   - 输出到帧缓冲

4. GPU → 显示器：
   - 渲染好的帧送到屏幕显示

在这个流程里，CPU 和 GPU 通常是流水线式并行的：当 GPU 在渲染第 N 帧时，CPU 已经在处理第 N+1 帧的游戏逻辑了。

AI 计算的分工方式

在深度学习里，分工略有不同：

训练阶段：

CPU：数据预处理（读文件、增强、打包成 Batch），把数据送给 GPU
GPU：执行前向传播（矩阵乘法、激活函数），反向传播（梯度计算），参数更新

推理阶段（模型上线服务）：

CPU：接收用户请求，管理并发，路由任务
GPU：批量执行模型前向传播，返回结果

这就是为什么大型 AI 服务器不只是堆 GPU——它们同样需要足够强大的 CPU 来"喂饱"GPU，否则 GPU 会因为等待数据而空转（这叫 I/O 瓶颈或 CPU 瓶颈）。

专用加速器的崛起：不只是 CPU 和 GPU

CPU 和 GPU 是通用的计算平台，但随着特定计算任务的规模急剧扩大，一类新型芯片开始大量出现：专用加速器（Domain-Specific Accelerator，DSA）。

NPU：手机里的 AI 大脑

你手机的处理器（SoC）里，除了 CPU 核心和 GPU 核心，通常还有一块叫 NPU（Neural Processing Unit，神经处理单元） 或 AI 加速器的东西。

高通骁龙 8 Gen 3 的 NPU 理论算力达到 98 TOPS（每秒万亿次运算，INT8 精度），苹果 A17 Pro 的 Neural Engine 达到 35 TOPS。

这些 NPU 是做什么用的？主要是：

实时人脸识别解锁（每秒处理摄像头帧）
相机的计算摄影（夜景融合、人像虚化的分割）
语音唤醒（在极低功耗下持续监听唤醒词）
手机端侧 AI 推理（如苹果的 Apple Intelligence）

NPU 的正确理解方式：它是一块硬连线的矩阵乘法机器，针对神经网络推理的数据流做了极致的面积和功耗优化，但几乎不能做别的事。这就是"专用"的含义：以通用性换取特定任务的极致效率。

TPU：Google 的自研加速器

2016 年，Google 内部开始大量使用自研的 TPU（Tensor Processing Unit，张量处理单元），并在 2017 年对外公布。

TPU 是专门为 TensorFlow（Google 的深度学习框架）设计的矩阵乘法加速器。它的设计思路和 GPU 有根本区别：

GPU 是通用并行处理器，同时支持渲染和 GPGPU（通用 GPU 计算）
TPU 完全不支持渲染，只为神经网络的矩阵运算优化，控制逻辑极简

这使得 TPU 在特定任务（训练、推理 TensorFlow 模型）上比同代 GPU 更高效（以每单位功耗的计算量衡量），但灵活性远不如 GPU。Google 在自己的数据中心（GCP）大量部署 TPU，外部开发者也可以通过 Google Colab 免费使用 TPU v2/v4。

TPU 的出现标志着一个趋势：超大规模计算公司开始自研芯片，以避免被单一的 CPU/GPU 供应商卡脖子，也为了更好地匹配自己的软件栈。亚马逊有 Trainium（训练）+ Inferentia（推理），微软有 Maia 100，Meta 有 MTIA，百度有昆仑，华为有昇腾 910B……这个领域在过去几年里是竞争最激烈的半导体赛道之一。

加速器的分工全景

以一个简化的视角看，不同芯片在「通用性」vs「效率」坐标轴上的位置：

通用性
  高
  |
  |   CPU（最通用，可以做任何事）
  |
  |        GPU（通用并行，GPGPU）
  |
  |                  NPU / TPU（专用，只做神经网络）
  |                                   ASIC（如比特币矿机芯片，只做一件事）
  低
  +-------------------------------------------------> 特定任务效率
  低                                              高

越往右下角，效率越高，但灵活性越差。一旦算法改变（比如从 CNN 换成 Transformer），专用加速器可能需要重新设计；而 GPU 只需要改代码。这是「通用」和「专用」之间永恒的权衡。

互联的问题：多卡训练

训练大模型需要大量显存。GPT-3 的参数量是 1750 亿，以 FP16（16 位浮点，每个参数 2 字节）存储需要 350 GB 显存，远超单张 H100 的 80 GB。解决方案是多卡并行训练，让模型分布在多张 GPU 上。

多卡训练需要 GPU 之间高速互联。NVIDIA 的解决方案是 NVLink，带宽远高于 PCIe：

互联方式	带宽（双向）	典型用途
PCIe 4.0 x16	64 GB/s	普通 GPU 与主板之间
NVLink 4.0	900 GB/s	H100 多卡互联
NVSwitch（全互联）	每个 GPU 与其他所有 GPU 900 GB/s	DGX H100 服务器（8卡全互联）

一台 DGX H100 服务器（8 张 H100，NVSwitch 全互联，2024 年售价约 30 万美元）是目前用于大模型训练的标准单节点配置。OpenAI 训练 GPT-4 用了数千张 A100，分布在数百到数千台服务器上，通过 InfiniBand 网络互联——这已经是数据中心级别的工程问题。

一个特殊情况：苹果的统一内存架构

苹果 M 系列芯片带来了一个有趣的变化：CPU 和 GPU 不再是两块独立的芯片，而是集成在同一块 SoC（System on Chip，片上系统）上，并且共享同一块内存（统一内存，Unified Memory）。

在传统架构里：

传统架构：
CPU ←─PCIe总线──→ GPU（有独立显存）
 ↓                   ↓
DDR5 内存          GDDR6X 显存
(~100 GB/s)       (~1000 GB/s)

数据需要在内存和显存之间复制，产生延迟和带宽瓶颈。

苹果 M 系列：

M 系列架构：
          ┌─────────────────────────────┐
          │           SoC               │
          │  CPU核心 ← → GPU核心        │
          │         ↕                   │
          │     统一内存                │
          │  (LPDDR5, ~200-800 GB/s)    │
          └─────────────────────────────┘
CPU 和 GPU 访问完全相同的一块内存，无需复制。

这个设计的好处是：

零拷贝：CPU 处理完的数据 GPU 可以直接用，反之亦然，无需跨总线复制
更高效的协同：适合 CPU 和 GPU 频繁交互的任务（比如机器学习推理、视频编辑）

代价是：

统一内存的带宽低于专用 GDDR6X 显存（M3 Max 约 400 GB/s vs RTX 4090 的 1008 GB/s）
内存容量上限受制于 SoC 设计（目前 M4 Max 最高 128GB）
对于极端并行的 GPU 任务（如大规模模型训练），这个带宽差距会成为瓶颈

苹果统一内存架构不是银弹，但在面向消费者的使用场景（视频剪辑、轻量 AI 推理、日常开发）里，它的表现非常出色，功耗远低于传统 CPU+独显方案。

【建议配图】CPU + GPU 协同工作示意图

用户点击"开始游戏"
         │
         ▼
    ┌────────────┐
    │    CPU     │   ← 处理游戏逻辑、物理、AI
    │ （大厨）   │      发出渲染指令
    └─────┬──────┘
          │  PCIe 总线 / 统一内存
          ▼
    ┌────────────┐
    │    GPU     │   ← 并行渲染所有像素
    │（工厂车间）│      处理着色器
    └─────┬──────┘
          │
          ▼
       显示器输出

边界在哪里：什么时候用 CPU，什么时候用 GPU

以下是一个粗略的判断规则：

适合 CPU 的任务：

操作系统调度、文件系统管理
数据库查询（大量条件判断、B树遍历）
网络协议处理
游戏的逻辑部分（AI、物理碰撞检测的离散阶段）
编译器、解释器
几乎所有"业务逻辑"代码

适合 GPU 的任务：

实时三维渲染
深度学习训练与推理（矩阵乘法密集）
密码学（暴力破解哈希，这也是挖矿用 GPU 的原因）
图像/视频批量处理
科学计算（流体模拟、分子动力学、气候模型）
信号处理（FFT 大规模并行化）

边界模糊的地方： 一些任务原本在 CPU 上跑，因为规模扩大，开始迁移到 GPU。比如数据库查询（GPU 数据库，如 RAPIDS），比如推荐系统的特征计算。这个边界还在移动，是个活跃的研究领域。

❌ 常见误区澄清

❌ 游戏的 FPS 越高，是 GPU 越好的功劳 ✅ 不完全对。在高分辨率（4K）下，渲染的压力主要在 GPU，此时 GPU 性能是瓶颈；但在低分辨率（1080P）+高帧率场景下，GPU 完成渲染很快，等待 CPU 提交下一帧的命令成了瓶颈——这叫 CPU 瓶颈。这也是为什么追求 240Hz 的电竞选手即使用了顶级显卡，也需要搭配强力 CPU。

❌ 跑 AI 模型只需要 GPU，CPU 无所谓 ✅ CPU 决定了数据预处理的速度和任务调度能力。一块顶级 GPU 配上羸弱的 CPU，会出现"GPU 空转等数据"的情况，整体训练速度反而比配置均衡的机器慢。

🔧 动手环节：观察 CPU 和 GPU 的分工

在你的电脑上做这个实验：

打开任务管理器（性能选项卡），让 CPU 和 GPU 的折线图同时可见
打开一个 3D 游戏（或者 YouTube 上的 4K 视频）
观察：CPU 和 GPU 的负载各是多少？谁更高？

然后： 4. 把游戏画质从最高调到最低（或把视频从 4K 换成 1080P） 5. 再次观察 CPU 和 GPU 负载

你应该能观察到：画质越低，GPU 负载越低，但 CPU 负载基本不变（甚至略升，因为帧率更高、CPU 需要更快地提交渲染命令）。这就是 CPU 瓶颈和 GPU 瓶颈的直观体现。

如果你有 NVIDIA 显卡，运行一段简单的 PyTorch 代码（需要安装 PyTorch + CUDA）：

import torch
import time

# 在 CPU 上做矩阵乘法
a = torch.randn(4096, 4096)
b = torch.randn(4096, 4096)

start = time.time()
for _ in range(100):
    c = a @ b
end = time.time()
print(f"CPU: {end - start:.2f}s")

# 在 GPU 上做同样的事
a_gpu = a.cuda()
b_gpu = b.cuda()

# 预热
torch.cuda.synchronize()
start = time.time()
for _ in range(100):
    c_gpu = a_gpu @ b_gpu
torch.cuda.synchronize()
end = time.time()
print(f"GPU: {end - start:.2f}s")

在一台配有 RTX 3060 的机器上，GPU 版本通常比 CPU 快 30-50 倍以上。这个数字会让你对"并行计算"有直观感受。

✓ 本节要点

✓ CPU 针对延迟优化（让单个任务尽快完成），GPU 针对吞吐量优化（让总量尽可能多）
✓ 现代计算机是异构系统，CPU 和 GPU 协同工作，各司其职
✓ CPU 瓶颈和 GPU 瓶颈是两种不同的性能限制，解决方案完全不同
✓ 苹果统一内存架构消除了 CPU-GPU 之间的数据复制开销，在特定场景下极具优势
✓ AI 计算让 GPU 的重要性从"游戏显卡"上升到"算力基础设施"

章节收尾

本章知识图谱

CPU                          GPU
├── 核心/线程/主频              ├── CUDA核心 / SM
├── 指令集 (x86, ARM, RISC-V)  ├── 显存 / 带宽
├── 大小核架构                  ├── 渲染管线
├── 延迟优化设计                └── 吞吐量优化设计
└── 执行指令的循环
      (取指→解码→执行→写回)

          CPU + GPU = 异构计算
          ┌────────────────────────────────┐
          │  逻辑控制 + 大规模并行计算      │
          │  = 现代电脑/服务器/AI算力       │
          └────────────────────────────────┘

与其他章节的联系

第一章里我们建立了存储金字塔：寄存器、缓存、内存、硬盘。这一章揭示了谁在使用这张金字塔——CPU 的寄存器和缓存是第一章概念的具体化，GPU 则有自己独立的显存体系，但本质上也遵循"离执行单元越近，速度越快、容量越小"的规律。

第三章操作系统，我们会看到 CPU 的多核能力如何被操作系统调度——进程和线程的概念，本质上是操作系统对 CPU 核心的虚拟化和时分复用。

第四章，我们会看到 CPU 和 GPU 如何通过主板（PCIe 总线）连接，以及苹果 SoC 如何打破了这个传统架构。

第五章选购时，你会发现这一章的知识正好能帮你看懂参数表上那些数字到底值不值得花钱。

一个值得思考的问题

CPU 越来越多核，GPU 也在往 CPU 的方向进化（加入更多复杂控制逻辑、更大缓存）。未来的芯片，是否会出现 CPU 和 GPU 真正融合为一种架构？

苹果 M 系列是一种回答：集成在同一块 SoC 上，统一内存。NVIDIA 的 Grace Hopper 超级芯片是另一种回答：把 ARM CPU 和 H100 GPU 直接封装在一起，用超高速互联连接。

"CPU 和 GPU 的边界会消失吗？"——这是一个在学术界和工业界都没有定论的开放问题。等你读到研究生，说不定这就是你的研究方向之一。

摩尔定律的终结与后摩尔时代的应对

在结束这一章之前，有必要讲一个贯穿整个计算机硬件发展史的重要概念：摩尔定律（Moore's Law），以及它正在走向终结这件事。

1965 年，Intel 联合创始人 Gordon Moore 提出了一个观察规律：集成电路上可容纳的晶体管数量，大约每两年翻一番，而成本保持不变。这个规律在此后五十多年里近似成立，是半导体行业的指路明灯：工程师可以预期，不需要改变软件，两年后的硬件会快一倍。

具体数字：

1971 年 Intel 4004：约 2300 个晶体管，10 微米制程
2000 年 Intel Pentium 4：约 4200 万个晶体管，180 纳米制程
2024 年 Apple M4：约 280 亿个晶体管，3 纳米制程

五十年里，晶体管数量翻了一千万倍。这是人类历史上任何其他技术都从未达到过的改进幅度。

但这个趋势正在放缓。问题在于物理极限：

量子隧穿效应：当晶体管尺寸缩小到几纳米时，电子会「穿越」本应绝缘的栅极，导致漏电。台积电的 3 纳米（N3E）制程里，晶体管的栅极长度约为 12 纳米，而单个硅原子的直径是 0.2 纳米——我们已经在原子尺度上工作了。
散热墙：晶体管密度越高，单位面积的功耗越大，散热越困难。CPU 的功耗密度（瓦/平方厘米）已经接近汽车发动机输出面的水平。
经济成本：先进制程的晶圆厂成本指数级上升。一座 3nm 晶圆厂耗资超过 200 亿美元，只有台积电、三星、Intel 能负担，并且极限制程的良率（合格品率）极低。

后摩尔时代的应对策略

行业正用多种方式来延续性能提升，即使不再像过去那样单纯依赖缩小晶体管：

更聪明的架构：与其让单个核心更快，不如让更多核心协同工作——Apple M 系列和 Intel 的大小核都是这个思路。

专用加速器：给矩阵运算设计 Tensor Core，给光线追踪设计 RT Core，给视频编解码设计专用固定功能单元——在有限的晶体管预算里，把面积给最需要的运算。

先进封装：把多个芯片封装到一起，通过极高密度的互联实现接近单片的性能。英特尔的 Foveros 3D 封装、AMD 的 3D V-Cache（在 CPU 上方堆叠缓存芯片）都是这类技术。台积电的 CoWoS 封装是 H100、MI300X 等 AI 芯片使用的关键技术，把 GPU 和 HBM 显存放在同一个封装基板上，实现超高带宽连接。

新材料：二维材料（如 MoS2）、碳纳米管晶体管、III-V 族半导体……研究人员在寻找硅之外的替代材料，以突破硅晶体管的物理极限。

光子计算与量子计算：更激进的方向是用光（光子）而不是电子传输信息，或者用量子叠加态做某些特定计算。这些仍在研究阶段，短期内不会取代传统计算机，但值得持续关注。

这章讲了很多硬件，但背后有一个朴素的逻辑：过去半个世纪，程序员的懒惰可以被摩尔定律救赎——今天写的烂代码，等两年买新电脑，不用改代码就自动快了一倍。但现在，这个"免费午餐"越来越少。理解硬件的工作原理，对软件工程师来说变得比任何时候都重要。你今天学的这些，不只是科普——它是你未来写出高性能代码的底层直觉。

【下章预告】

现在你知道了 CPU 和 GPU 是什么、各自怎么工作。但还有一个关键问题没有回答：谁来协调它们？ 当你双击一个图标，是谁决定把这个任务分配给哪个核心？是谁决定哪段代码能占用多少内存？

答案是：操作系统。

下一章，我们走进这个"看不见的管家"——理解进程、线程调度，以及任务管理器里那些数字真正意味着什么。

扩展资源

以下资源均真实存在，按难度标注：

视频：

《How a CPU Works》— In One Lesson（YouTube）⭐ 入门，13分钟，用直观动画演示 CPU 取指-执行循环
《But How Do Transistors Work?》— Lesics（YouTube）⭐ 入门，从物理层面理解 CPU 里的基本单元
《GPU Architecture》— NVIDIA Deep Learning Institute 公开课（YouTube）⭐⭐ 进阶，NVIDIA 官方出品，讲 CUDA 编程模型和 GPU 架构
《Inside the Apple M1》— Asahi Linux Blog（文章）⭐⭐⭐ 深入，逆向工程角度分析 M1 微架构，技术密度极高

文章：

Agner Fog《Instruction tables》⭐⭐⭐ 深入，统计各 x86 指令的延迟和吞吐量，用于底层性能分析（偏研究向）
Anandtech 的芯片评测文章（如《Apple M3 Review》）⭐⭐ 进阶，严谨的工程师视角，有大量测试数据和架构分析
Wikipedia：《Instruction set architecture》⭐⭐ 进阶，系统梳理 ISA 概念和各主流指令集

中文资源：

《深入理解计算机系统（CSAPP）》第三、五章 ⭐⭐⭐ 深入，中科大计算机系的必读书，这两章讲汇编和性能优化，是理解 CPU 指令集的经典材料
Bilibili 搜索"CPU是怎么工作的硬核科普"——有若干质量不错的中文视频 ⭐ 入门

本章完

主题

字号

2.1 CPU：真正的中央处理器

一个厨师的故事

核心概念：核心、线程、主频

主频：大厨的做菜速度

核心数：雇了更多大厨

线程：大厨的多任务能力

现实参数对照

CPU 是怎么执行指令的

流水线：让大厨永不空闲

流水线的敌人：分支指令

分支预测：大厨的直觉

乱序执行：不按食谱的顺序来

投机执行与安全：一个意外的副作用

❌ 常见误区澄清

🔧 动手环节：观察你 CPU 的真实行为

✓ 本节要点

2.2 指令集：CPU 的"方言"

你的程序在外星球跑不了

什么是指令集

x86 和 ARM：两条不同的路

x86（准确说是 x86-64）

ARM

【建议配图】x86 vs ARM 对比示意图

为什么不统一成一种指令集？

指令集、编译器与你写的代码：三层抽象

编译器有多复杂？

RISC-V：第三条路

❌ 常见误区澄清

🔧 动手环节：看看你的 CPU 是什么架构

✓ 本节要点

2.3 GPU：平行宇宙的计算方式

为什么显卡能跑游戏？

渲染一帧：GPU 的日常工作

GPU vs CPU：将军 vs 士兵

GPU 内部结构（概念层面）

GPU 不只是用来打游戏的

渲染管线：GPU 到底是怎样画出一帧的

光线追踪：「欺骗」与「真实」

为什么换更大显示器会更费显卡？

从游戏显卡到科学计算加速器：GPU 的角色演变

深度学习训练：为什么矩阵乘法和 GPU 是绝配

科学计算：超算里的 GPU

挖矿：GPU 算力的另一个用途

❌ 常见误区澄清

🔧 动手环节：查看你的显卡信息

✓ 本节要点

2.4 CPU 与 GPU 的分工哲学

两种思维方式

延迟优化 vs 吞吐量优化

异构计算：让它们协同工作

AI 计算的分工方式

专用加速器的崛起：不只是 CPU 和 GPU

NPU：手机里的 AI 大脑

TPU：Google 的自研加速器

加速器的分工全景

互联的问题：多卡训练

一个特殊情况：苹果的统一内存架构

【建议配图】CPU + GPU 协同工作示意图

边界在哪里：什么时候用 CPU，什么时候用 GPU

❌ 常见误区澄清

🔧 动手环节：观察 CPU 和 GPU 的分工

✓ 本节要点

章节收尾

本章知识图谱

与其他章节的联系

一个值得思考的问题

摩尔定律的终结与后摩尔时代的应对

后摩尔时代的应对策略

【下章预告】

扩展资源