本文为原文的中文翻译，原文链接：https://dev.to/lovestaco/cpu-gpu-tpu-npu-dpu-qpu-six-chips-one-question-438b。
翻开你笔记本的规格表，你会看到一个 CPU、一个 GPU，如果机器够新，还会看到一个 NPU。
打开云实例页面，摆在你面前的是 GPU、TPU，还有一块网卡，仔细一看，那其实是一整台电脑披着风衣。
在某个实验室里，一台比深空还冷的冰箱正在运行一台 QPU。
六个缩写，全都以 PU 结尾，全都在做"计算"。
那个显而易见、我躲了很多年的问题是：为什么不干脆造一款足够好的处理器，然后就到此为止？
简短的回答是，“计算"并不是一件事。更长的回答才是有趣的部分。
CPU 是那个对什么都点头的朋友
CPU 是 central processing unit（中央处理器）的缩写，它是通才。
它运行你的 OS、你的 API 处理程序、你的正则表达式、你的 if 语句、你的数据库、你的构建工具，还有那个无缘无故吃掉 4GB RAM 的 Slack 客户端。
CPU 天生擅长不可预测的工作。下一条指令取决于上一条结果的分支型代码。
指针追逐，也就是顺着一个地址找到下一个地址，再据此找下一个。漫长的依赖链，什么都并行不了，因为第 5 步确实需要第 4 步的输出。
为了做到这一点，现代 CPU 核心塞满了与数学无关的机械装置：分支预测器猜测你的 if 会往哪边走，乱序执行背着你重排指令，还有一整套缓存层级，想尽办法掩盖 RAM 远得令人尴尬的事实。
所有这些聪明劲儿都要花晶体管和功耗。所以你得到的是一小撮非常聪明的核心，而不是几千个。
这很棒，直到工作负载的形状变了为止。
然后有人丢给你一百万个一模一样的加法
假设你要对几百万个值做同样的运算。同一条指令，不同的数据，没有分支，谁也不用等谁。
CPU 能做这件事。它甚至会在多个核心和 SIMD 单元上并行地做。
只是它做不好，因为你花钱买来的那堆分支预测硬件，正在预测一个根本不存在的分支。
于是 GPU（graphics processing unit，图形处理器）登场。
GPU 源自渲染，而渲染正是这类问题最纯粹的形式。
一个 4K 画面大约有 830 万个像素，按 60fps 算，你每秒要对所有这些像素着色 60 次，每一个都套用同样的光照计算。
于是 GPU 设计师做出了与 CPU 设计师相反的取舍。放弃花哨的每核智能，把晶体管花在算术单元上，让数千个线程整齐划一地运行。
这种模式有个名字：SIMT，单指令多线程。
没人预先料到的笑点在于：神经网络原来和图形是同一种形状。
一次 transformer 的前向传播，大部分是巨大的矩阵乘法，也就是数百万次互相独立的乘加运算。这正是 GPU 的母语。
显卡意外地成了整个 AI 产业的底座，这大概是硬件史上最赚钱的一次意外。
同样的硅片预算，两种截然不同的花法。左边是四个核心，其中大部分面积并不做算术。
右边是一整片算术单元，它们完全不会自己思考。
如果数学运算永远一样，那就造一块只做这种运算的芯片
一旦矩阵乘法成为一个产业的主要成本，下一步就不可避免。
那就是 TPU（tensor processing unit，张量处理单元），Google 的机器学习加速器。
GPU 仍然是一台通用的并行计算机。它有调度器、寄存器堆，以及一套设计来处理你扔给它的任何东西的内存模型。
TPU 则把目标收窄：专门围绕张量和矩阵运算来构建硅片，并按照这些运算实际的流动方式来设计数据搬运。
如果你喜欢这类东西，Google 的第一篇 TPU 论文值得一读，因为它对这笔取舍坦率得令人耳目一新。
这块芯片并不聪明。
它是一大块脉动阵列，也就是让数据依次流过一整排乘加单元的结构，控制逻辑被剥掉了；它在每瓦性能上取胜，恰恰是因为它拒绝灵活。
这一句话就是专用硬件的全部论点：假设越窄，假设成立时回报越大。
而假设不成立时，摔得越惨。
把 TPU 对准你的 JSON 解析器，然后看着什么好事都不发生。
这笔取舍值得展开讲讲，因为正是这一个想法解释了整个动物园。
这是一根绳子，一端是灵活性，另一端是每瓦吞吐量，每一块经典芯片都站在这根绳子上的某个位置：
但并不是所有 AI 都住在数据中心
你的手机用人脸解锁，在通话时虚化你的背景，把语音备忘转录成文字，还能修好你在暗光下拍的照片。
这些都不应该需要往 GPU 集群跑一个来回。那样会很慢，会在射频上耗电池，还意味着为了这点便利把你的脸送到别人的服务器上。
这就是 NPU（neural processing unit，神经处理单元）：一个小型 AI 加速器，就坐在设备本地，与 CPU 和 GPU 同处一块芯片之上。
Apple 把自己的叫作 Neural Engine，并通过 Core ML 暴露出来；Qualcomm 和 Intel 各有自家的产品；而笔记本上每一张"AI PC"贴纸，其实都是关于 NPU 的贴纸。
TPU 和 NPU 都是 AI 加速器，所以这个区别值得说清楚。它其实不在于数学，而在于它们各自为哪种环境而造：
TPU：数据中心。插在墙上供电。训练并服务巨型模型。为每机架吞吐量优化。
NPU：你的口袋。靠电池运行。持续执行小模型。为每瓦操作数优化，也为不让你的牛仔裤着火而优化。
同样的方程，天差地别的约束。这足以证明两块不同的芯片是合理的。
那块根本不负责计算的芯片
这是我第一次深挖时最吃惊的部分。
想象一台运行着几十个 VM 的云主机。在你的应用代码跑起来第一行之前，这台机器必须先：终结网络数据包、运行虚拟交换机、执行安全组策略、加密流量、把实际位于远端的存储呈现为虚拟磁盘，还要处理这栋楼里的每一个 I/O 中断。
传统上，这些全由宿主 CPU 来做。也就是说，你买了一台 64 核服务器，其中相当一部分核从来没碰过客户的工作负载。
业界客气地称之为"数据中心税”。
DPU（data processing unit，数据处理单元）把这笔税转移到自己的芯片上。
它是一块卡，有自己的 CPU 核心、自己的 NIC，还有用于网络、存储和加密的硬件引擎；它接管基础设施类工作，好让宿主 CPU 回去跑应用。
AWS Nitro 是著名的例子，也正是 AWS 能交付给你一台几乎保留宿主全部核心的裸金属实例的原因。
NVIDIA BlueField 是同一思路的商用版本。
所以 DPU 并不是在通用性阶梯上走得更远。
它站在一条完全不同的轴上，因为它的工作负载是搬运数据，而不是消化数据。
然后还有那个根本不在玩同一局游戏的
到目前为止，每一个处理器都是经典的。CPU、GPU、TPU、NPU、DPU，全都在搬运比特，而比特不是 0 就是 1。
QPU（quantum processing unit，量子处理单元）用的是量子比特。
一个量子比特可以处于叠加态，量子比特之间可以纠缠，量子算法利用这些特性，以经典算法在结构上无法做到的方式探索问题空间。
有两件事人们老是搞错，这里我多啰嗦两句：
QPU 不是一块更快的 CPU。它是一种不同的计算模型。不存在哪个世界里你把 Web 服务器移植过去就能提速。大多数问题根本得不到任何量子优势。
“在所有事情上都指数级更快"是营销话术。真正有前景的方向窄而具体：模拟量子系统（化学、材料）、某些优化问题，以及密码学，正是 Shor 算法让人们今天而不是 2040 年就开始关心后量子密码。如果你想上手真硬件而不是凭感觉，IBM Quantum 可以让你免费跑一个量子线路。
今天的机器噪声大、规模小，纠错是所有人都在攻的那堵墙。这确实是令人兴奋的研究。但它不是一次数据中心升级。
那你到底该怎么选？
别从缩写开始。从工作的形状开始。
把它当作一组问题来读，而不是一个层级结构：
这份工作是分支多、变化多的吗？CPU。大多数软件都是这样，这没什么不好。
是同一套运算作用于海量数据吗？GPU。
这个运算恰好是张量数学，而且是数据中心规模的吗？TPU。
是电池上跑的张量数学吗？NPU。
瓶颈是搬运数据，而不是对数据做运算吗？DPU。
这个问题上有已知的量子算法优势吗？QPU，终究会，大概不是今天。
有一点值得内化：这不是一场竞赛。这些芯片是同事，不是对手。
从你的手机发往某个 AI 功能的一次请求，可能就会碰到其中四种。手机的 NPU 先决定它能否在本地处理这个请求。
如果不能，CPU 负责构造请求，数据中心的 DPU 终结连接并完成存储和加密工作，服务器 CPU 运行你的应用逻辑，最后由 GPU 或 TPU 做真正的推理。
在真实代码里咬你的那部分
懂分类学是好事。
但实际陷阱不在这里：加速器只对它在真正执行的那部分工作有帮助。
阿姆达尔定律对此毫不浪漫。如果运行时间里有 20% 没被加速，那么把另外 80% 加速到无限快，你的上限仍然只有 5 倍。
实际上，那没被加速的 20% 是数据加载、预处理，以及在 PCIe 总线上拷贝张量。
这就是为什么"我们买了 GPU，结果只快了 1.3 倍"的故事那么多。GPU 没问题。是 GPU 在挨饿。
大概十行代码就能看到它发生：
import time, torch
x = torch.randn(8192, 8192)
t = time.perf_counter()
x @ x
print(f"cpu: {time.perf_counter() - t:.3f}s")
g = x.cuda()
torch.cuda.synchronize()
t = time.perf_counter()
g @ g
torch.cuda.synchronize() # kernels are async, so measure honestly
print(f"gpu (resident): {time.perf_counter() - t:.3f}s")
t = time.perf_counter()
(x.cuda() @ x.cuda()).cpu() # the version people accidentally write
torch.cuda.synchronize()
print(f"gpu (+copies): {time.perf_counter() - t:.3f}s")
中间那个数字，是出现在营销材料里的数字。
最下面那个数字，才是你每次调用都跨总线搬数据时会得到的数字。
在大矩阵乘法上，传输的成本可能超过运算本身，而解决办法永远一样：让数据常驻在设备上，并批量化你的工作，让这一趟跑得值。
同样的教训也出现在 NPU 上：最快的路径就是让张量从不离开加速器可见的共享内存；DPU 也一样，它的全部意义就在于数据包不再在宿主内存里来回蹦。
如果你想知道自己的机器都载着什么：
lscpu | grep -E 'Model name|^CPU\(s\)|Flags' | cut -c1-120 # cores + SIMD support
nvidia-smi --query-gpu=name,memory.total --format=csv # discrete GPU
ls /dev/accel* /dev/dri/render* 2>/dev/null # accelerators + render nodes
在现代笔记本上，最后一行安静地有意思，因为里面的硅通常比你预想的多。
心智模型，一个代码块说清
如果这整篇文章你只记住一件事，记住这个问题，而不是那些缩写词。
以下是我会粘贴到自己笔记里的版本：
我们最终没有六种处理器，并不是因为计算变得不必要地复杂。
我们最终有六种，是因为"让它通用"和"让它快"这两股力量方向相反，而不同的问题处于这根绳子的不同位置上。
CPU 对一切都点头，因此在所有事情上都表现平平。
TPU 几乎对什么都不点头，但对它接受的那一点点事情表现得极其出色。
其他一切都介于两者之间，各自做着特定的工作。
你团队的注意力是有限的，而 AI 生成代码的洪流让在不拖慢速度的前提下保持生产环境的安全和可靠变得更加困难。
我正在构建 LiveReview，一个爆炸半径感知的 AI 代码审查工具，为你的业务关键系统而生。
LiveReview 不会对每个 diff 一视同仁地呈现，而是按爆炸半径给每个变更打分，也就是它的影响通过调用图能传播多远，这样你就能把注意力集中在真正重要的地方。
把代码审查的精力花在业务风险最高的地方，而不是均匀地分散在每个 diff 上。
⭐ 在 GitHub 上 Star：
参考项目：HexmosTech