为什么 AI 离不开 GPU —— 八位教授打不过四千个小学生
先抛一个真实的决策问题：你手里这台工作站 CPU 32 核、主频 3GHz，单核频率比很多 GPU 还高——为什么跑一个 14B 模型连 1 token/s 都困难，而插一块 GPU 就能几十 token/s？买不买卡、买哪种卡，第一个要搞懂的就是这个。
答案一句话：大模型干的活几乎全部是矩阵乘法——一层网络约等于「一个大矩阵 × 一个向量」，而 Qwen2.5-14B 有 48 层，每生成一个 token 都要把这 48 层串着过一遍。串行的层数没法减少，但每一层内部的海量乘加彼此独立，可以同时算——GPU 吃的正是后半句。
用后厨打个比方（本手册的统一比喻，点到即止）：CPU 是 8 位教授级大厨，一道菜又快又漂亮，但一次只能盯几口锅；GPU 是后厨里 4000 个只会一道工序的小工，你喊一声「切！」，全后厨同时动手。矩阵乘法恰好是「同一道工序打几百万份数据」——教授再快也切不过人海。
| CPU | GPU | |
|---|---|---|
| 核心 | 几个 ~ 几十个强核心 | 数千 ~ 上万个精简核心 |
| 优化目标 | 延迟导向：分支预测、乱序执行、大缓存 | 吞吐导向：同一指令打多份数据（SIMT） |
| 擅长 | 逻辑复杂、步骤互相依赖的任务 | 海量同构计算（矩阵乘法天生如此） |
| 跑 14B | 逐格串行乘加，慢几个数量级 | 数千线程把输出矩阵一次铺满 |
CPU · 单核 0 拍
GPU · 数千线程 —
Tensor Core：矩阵乘法专用机床
GPU 核心里还有一层分工：普通 CUDA Core 一拍做一个乘加；Tensor Core 一条指令直接吃掉一小块矩阵的「乘加」（比如 4×4 的块），是为矩阵运算专设的电路。同等芯片面积下，它是这几年的 AI 算力暴增的关键——H100 官方口径 BF16 dense 算力约 989 TFLOPS（官方 datasheet · 查证 2026-09）。
展开参考答案 · 先大白话，再专业版
矩阵乘法为什么天生适合 GPU 并行：算结果里的每个格子，步骤一模一样，而且格子之间互不等谁——相当于几百万份同一道工序。GPU 后厨有几千个小工，一声令下一人领一份同时干；CPU 那几位大厨再快，也只能挨个做。
Tensor Core 比 CUDA Core 快在哪：CUDA Core 是一次只算一个「a×b 再加 c」的小工；Tensor Core 是一台专用小炒机，一口吞进一小块矩阵、整块一起出——一条顶一串。而 AI 的活几乎全是这种整块乘加，正对它的胃口。
矩阵乘法每个输出元素 C[i][j] 只依赖 A 的一行与 B 的一列，元素之间零数据依赖、无分支跳转，天然映射到 GPU 的 SIMT 执行模型：一个线程负责一个格子，数千线程一次铺满，算术强度高、占用率高。
Tensor Core 是专用矩阵乘加（MMA）硬件单元：一条指令完成一小块矩阵（如 16×8×16）的乘加，并把结果累加进 FP32 累加器。单条指令的工作量从「1 次乘加」变成「一小块的乘加」，再叠加专用单元的数量优势，同精度等效吞吐比 CUDA Core 逐个乘加高出约一个数量级——这正是上面 A1 动画里「指令数骤减」的出处。
看懂一张 GPU 的参数表 —— 先看台面，再看油管，最后看马力
决策问题：预算两万块，购物页写着 24GB、1TB/s、165 TFLOPS、支持 NVLink——先看哪个？顺序错了就可能买回来一张「跑不动自己模型」的贵卡。
| 参数 | 买车比喻 | 它决定什么 | 看的顺序 |
|---|---|---|---|
| 显存容量 | 油箱 + 台面大小 | 模型能不能装下：权重 + KV Cache + 开销都要住进去 | ① 一票否决 |
| 显存带宽 | 油管粗细 | 生成速度：decode 每出一个字都要把权重完整读一遍（第 7 章细讲） | ② 决定快慢 |
| 算力 TFLOPS | 马力 | 首字延迟（prefill）、训练与批量吞吐 | ③ 看口径 |
| 互连 PCIe / NVLink | 车间之间的传送带 | 多卡协作效率：NVLink 比 PCIe 快一个数量级以上；单卡用户可以无视 | ④ 多卡才看 |
| TDP 功耗 | 油耗 | 电源、散热、机箱、机房与电费 | ⑤ 部署环境 |
SM 是什么：GPU 厂房里的一间间标准车间
参数表上还有个高频词：SM（Streaming Multiprocessor，流式多处理器）。听着唬人，用大白话说：整块 GPU 是一座厂房，SM 就是厂房里一间间标准化的独立车间——芯片并不是把几万个核心散装铺成一片，而是先把核心组装成几十间配置一模一样的车间，每间都能自己领活、自己开工。
每间 SM 车间里，标配三样东西：
- 通用工位 · CUDA Core（约 128 个/车间）：什么数值活都能干的万能工位，一拍做一个乘加；
- 矩阵专用机床 · Tensor Core（约 4 台/车间）：只干「整块矩阵乘加」这一种活，但一口顶几十口（上一节刚认识）；
- 车间小料架 · 共享内存 / L1 缓存：车间边上的一小块快速取料区，全车间共用——免得每领一个数据都跑一趟大仓库（显存）。
所以「CUDA Core 数」「Tensor Core 数」不是两类孤立的电路：总核心数 = 车间数 × 每车间工位数。例如 H100 就是 132 间车间 × 每间 128 个通用工位 ≈ 16864 个 CUDA Core（官方 datasheet · 查证 2026-09）。买卡时真正该看的是车间数量和每车间的机床配置，而不是被「几万核心」的总数晃花眼——下面把其中一间车间放大看看。
深挖 · 游戏卡 vs 数据中心卡：TFLOPS 看着差不多，实际差在哪
参数表上消费卡的「AI 算力」常用稀疏 / 低精度口径印，数字看起来能直追数据中心卡。但实际跑模型，差的是另外四件事：
- 显存容量：24GB vs 80GB——决定你能装什么模型，这一条就一票否决（第 3 章）。
- 带宽：约 1.0 vs 2.0~3.35TB/s——decode 速度直接被砍半再砍半（第 7 章）。
- 互连：消费卡无 NVLink，多卡协作只能走 PCIe，训练切分策略受限（C 页）。
- 特性与稳定：ECC 显存、FP8/FP4 支持、驱动认证、7×24 长期运行的稳定性，都是数据中心卡的溢价所在。
结论：个人跑模型，游戏卡性价比极高；要开服务、要训练，再考虑数据中心卡或云（D 页）。
显存里的住户 —— 权重只是最大的那一个
决策问题：14B 模型量化后权重只要 7.4GB，为什么塞进 8GB 显存的卡还是直接 OOM？——因为显存这间公寓里，权重只是住户之一。
把显存想成一张台面（后厨比喻最后用一次）：台面放不下的东西，厨师再快也做不了。推理时台面上常住着这些住户：
- 权重——模型本体，常驻最大头，开着就占住，关不掉。
- 激活值——每步计算的临时工作区，跟 batch 和上下文走，用完就腾但一直要地方。
- KV Cache——「边做边记的草稿纸」，随对话变长、人数变多而膨胀（第 5 章专门讲）。
- CUDA 上下文 / 运行时——驱动与框架的底数开销，约 0.5~1GB，看不见但真实吃掉。
- 碎片——显存分配器留下的空洞，这就是「明明剩 3GB 却分配不出 2GB」的原因。
- （空置门牌）梯度 + 优化器——训练住户，推理时不出现；一旦开训账单是权重的 8 倍以上，C 页再搬进来。
「14B」不是 14GB —— 参数量 × 字节数的换算
决策问题：模型名字里的 7B / 14B / 70B 到底是什么？老板问「这模型多大」，你答「14B」——它占多少显存？答案取决于第二个变量：精度。
一个参数（权重）就是一个数字。模型名里的 B = Billion（十亿个参数）。存一个数字要花字节，所以换算只有一个公式：
权重显存 ≈ 参数量(B) × 每参数字节数
精度是什么：记一个数，你愿意花多少位
模型里的一个参数，就是 0.7231… 这样一个带小数的数。所谓「精度」，就是存这个数时你愿意花多少个二进制位——位数越少，显存越省，但数记得越糙。用尺子打比方：
- FP32 是游标卡尺：刻度细、量程大，一个数要花 4 字节——准，但贵；
- BF16 是换了量程的家用卷尺：刻度糙了，但量程和 FP32 一样宽——记神经网络绰绰有余，连训练都用它；
- INT4 是只有 16 个刻度的短尺：糙到离谱？配一个「缩放系数」重新标定刻度后，网络居然基本能忍——这是本地部署的标配。
拆开看，浮点数的位分三段：符号 + 指数 + 尾数。指数管量程（能表示多大、多小的数），尾数管刻度细度（小数点后几位）。AI 有个关键性质：参数的值域很宽，但对每个值糙一点意外不敏感——所以砍位宽时优先保指数（别爆表）、牺牲尾数（糙一点没事）。BF16 就是这个思路的产物：FP32 的 23 位尾数砍到只剩 7 位，指数原样保留。位宽 ÷ 8，就是上面公式里的「每参数字节数」：
| 精度 | 位的组成（符号+指数+尾数） | 一个数多大 | 一句话画像 |
|---|---|---|---|
FP32 | 1 + 8 + 23 | 4 字节 | 游标卡尺：训练时的主权重、优化器状态用 |
FP16 | 1 + 5 + 10 | 2 字节 | 刻度细但量程窄，数值一大就溢出，训练已少用 |
BF16 | 1 + 8 + 7 | 2 字节 | FP32 的量程 + 糊刻度：训练、推理的主力精度 |
FP8 | 1 + 4~5 + 2~3 | 1 字节 | 更短的尺：数据中心推理新贵（H 系卡起） |
INT4 | 无指数，16 个整档 + 缩放系数 | 0.5 字节 | 短尺+标定：本地部署、QLoRA 存放的标配 |
精度速查表（按名义参数量口算；实际 config 里 Qwen2.5-14B 是 14.8B，BF16 约 29.6GB——量级一致）：
| 精度 | 每参数字节 | 7B 权重 | 14B 权重 | 70B 权重 |
|---|
「装得下」三档判定
- ✅ 装下还有余量：总需求 ≤ 可用显存的 85%——日常放心跑。
- ⚠️ 勉强：85%~100%——只能短上下文、低并发，塞满就 OOM。
- ❌ 装不下：超过可用显存——连权重都放不进去，一切免谈；出路是量化、换卡或多卡。
KV Cache —— 会越聊越贵的草稿纸
决策问题：同一个模型，为什么刚聊时又快又稳，聊到几万字之后开始变慢、甚至直接 OOM？多变的从来不是权重——权重是死的。
推理时模型每读一个 token，都要把它的 K / V 两张「卡」存下来，因为后面的每个新 token 做注意力时都要回看全部历史。这些卡就是 KV Cache——后厨里那张「这道菜做到第几步」的草稿纸，越写越长，而且每桌客人一张。
教学公式
每 token KV 字节 = 2（K 和 V）× 层数 × kvDim × 每元素字节
其中 kvDim = KV 头数 × head_dim。现代模型普遍用 GQA（分组查询注意力）省钱：40 个查询头共享 8 组 KV，草稿纸直接省到 1/5，质量几乎不掉。用 Qwen2.5-14B 的真实 config（48 层、8 个 KV 头 × head_dim 128 → kvDim 1024）实算，BF16 下：
2 × 48 × 1024 × 2B = – ≈ 0.19 MB / token
换成直觉（单请求，同一模型）：
| 上下文 | 1 路并发的 KV | 8 路并发的 KV |
|---|
显存估算器 —— 这张卡到底能不能跑
决策问题：下周要给组里 8 个人部署 14B 代码助手，手里的卡是 24GB——不用装任何工具，先在这里把账算一遍。前五章的公式，现在拼成一台判定机。
- 权重
- KV Cache
- 开销CUDA 上下文 0.6GB 底数 + 激活工作区（按权重的 15%）——第 3 章的「看不见的住户」
- 可用
深挖 · 为什么第一个字慢、后面快 —— 带宽瓶颈预告
决策问题：向本地模型提一个长问题，第一个字卡了 2 秒才出来，之后却每秒蹦几十个字——同一个模型，为什么两副面孔？这决定了你该怎么优化「体验」。
先把两个术语引出来——模型生成一次回答，其实是两步走：
- 第一步「读题」· Prefill（预填充）：把你输入的全部 token 一次性并行算完。你贴了 2000 字的代码，它就一口气处理完这 2000 个 token；
- 第二步「逐字写」· Decode（解码）：自回归地一个字一个字往外蹦——每写一个字，都要把全部权重从显存完整读一遍。
| 第一幕 · Prefill 读题 | 第二幕 · Decode 逐字写 | |
|---|---|---|
| 怎么干 | 一摞 token 并行一起算 | 一次只生成一个 token |
| 吃哪个瓶颈 | 算力（compute-bound） | 带宽（memory-bound） |
| 决定什么 | 第一个字多久出来（TTFT，首字延迟） | 后面每个字多快（tokens/s） |
两幕的细节与优化是 B 页开篇，这里先记住 Decode 的粗算式：
tokens/s ≈ 显存带宽 ÷ 权重量（GB）
物理图像很直白：decode 时算力大量闲置，GPU 大部分时间在等数据从显存搬过来；每秒能把权重读几遍，就能出几个字。三个粗算例子（数字由本手册共享公式实时算出）：
| 卡 | 模型精度 | 权重 | 带宽 | 理论上限 | 实际（打 5~7 折） |
|---|
终极测验 · 5 题验收
5 题验收。答对 4 题以上，才算把「这张卡能不能跑」真正带走。
参考资料 · References
本页所有硬件数字与模型配置的出处。硬件规格与价格会随时间变化，请以官方页面为准。
硬件规格（官方 datasheet / 规格页）
- NVIDIA · GeForce RTX 5090 官方规格页（32GB GDDR7 / 1792GB/s，页内对照 RTX 4090 的 1008GB/s）· nvidia.com/geforce/rtx-5090 · 查证 2026-09
- NVIDIA · H100 官方页（80GB HBM3 / 3.35TB/s；BF16 dense 989 TFLOPS 与 FP8/稀疏口径）· nvidia.com/data-center/h100 · 查证 2026-09
- NVIDIA · H200 官方页（141GB HBM3e / 4.8TB/s，容量 +76%、带宽 +43% vs H100）· nvidia.com/data-center/h200 · 查证 2026-09
- NVIDIA · Blackwell 架构页（B200：192GB HBM3e / 约 8TB/s，原生 FP4/FP8）· nvidia.com/data-center/blackwell · 查证 2026-09（部分 B200 数字以生态汇总为准，官方细节见 datasheet PDF）
- Apple · M4 Pro / M4 Max 发布稿（M4 Max 满血版 546GB/s、最高 128GB 统一内存；32 核 GPU 低配版为 410GB/s）· apple.com/newsroom · 查证 2026-09
- Apple · Metal 文档 · recommendedMaxWorkingSetSize（macOS 给 GPU 的统一内存默认上限：大内存机型约 75%、小内存机型约 66%）· developer.apple.com · 查证 2026-09
模型配置与精度口径
- Qwen2.5-14B 模型卡与 config.json（48 层 / hidden 5120 / 40 查询头 / 8 KV 头 / head_dim 128，GQA）· huggingface.co/Qwen/Qwen2.5-14B-Instruct · 查证 2026-09
- Qwen2.5 Technical Report（架构与配置数字总源）· arxiv.org/abs/2412.15115
- Mixed Precision Training（Micikevicius et al., 2017）—— FP16/BF16/FP32 精度与字节口径的经典出处 · arxiv.org/abs/1710.03740
- NVIDIA · Ampere 架构页（Tensor Core 官方介绍：一条指令完成一小块矩阵乘加）· nvidia.com/data-center/ampere-architecture · 查证 2026-09
本页全部显存 / 速度计算统一调用共享公式库 gpu-and-deployment/calc.js（window.GPU_CALC），四页数字同源，不会互相打架。