AI Infra 为什么重要
AI Infra 是支撑训练和推理的基础设施，包括计算设备、存储、互联，以及组织这些资源的软件。训练用样本调整参数；推理用训练好的参数，把输入变成输出。
1.1.1 编程抽象上移：从操作系统到模型上下文
传统应用用代码表达行为，编译器把代码变成指令，操作系统管资源。模型驱动的应用多了一个入口：选模型、组织上下文、提供工具。上下文就是本次模型调用能用的全部输入：任务指令、参考材料、此前的交互结果。参数不变，换指令、示例或材料，模型就在做另一件事。
图 1-1 · 两种应用的表达方式与执行路径
实线：向下的执行依赖 · 虚线：工具仍靠操作系统Agent 循环：模型选下一步，宿主程序动手
以代码检查为例：代码、测试要求和可用工具一起交给模型，模型提出修改或发起工具调用；应用执行测试，把结果加进下一次调用的上下文。完成一次任务可能要多次模型调用和工具执行。
同一个模型给不同应用服务，用的是同一组参数，所以可以把多条请求合成一批，共用一次读入的权重。每批请求数叫 batch size。但长文档、长回答、多轮工具调用又会改变计算量、状态占用和等待时间：同一模型、同一套加速器，换个任务，性能可能差很远。
模型影响硬件要做的事
压缩保存的状态、改变注意力机制、只用部分参数（专家），都会改变硬件的工作量。
硬件影响该选哪种模型
存储容量、传输速度、设备连接方式，决定哪些模型结构和执行方法更合适。适合一个应用的方案，换个应用要重新评估。
各层可以围绕同一个完整的执行过程一起设计：模型结构给出计算和数据依赖，运行时知道状态何时产生、何时使用，硬件承担运算和传输。用这些信息重排执行，就能消掉通用实现里的一部分开销。上层可编程性的变化，为跨层联合优化打开了空间。
1.1.2 从任务到硬件的六层分工
廖恒博士用“十八层宝塔”描述从应用到芯片、工艺、物理的层层依赖，并指出多数人只懂其中一两层，因而错过了跨层优化的机会。本书借这个方法分成六层，点击查看每层负责什么。
图 1-2 · 从应用到硬件的六层分工
点击层级贯穿多层的能力
资源调度、运行环境、观测和计费要结合多层信息；工艺、封装、供电、散热决定设备如何制造和部署；网络也不只在最底层，跨设备协作的模型、算子和服务都要经过具体互联。
层与层之间的接口就是联合优化的切入点。
模型 × 系统
模型改变状态表示 → 改变存储和通信需求。
编译器 × 存储
相邻算子融合 → 改变中间结果放在哪里。
运行时 × 主机
加速器之间直接交接 → 减少主机参与次数。
1.1.3 一次生成请求的处理过程
推理实例是能独立完成模型请求的一组执行资源，可以是一张或多张加速器。路由器选实例，实例内部再安排加速器。先分清谁负责执行，才知道权重该放哪、中间结果该交给谁。
图 1-3 / 1-4 · 一次请求从进入到流式返回
路由策略、分词器放在哪里、prefill 与 decode 是否分到不同实例，都属于部署选择。KV 条的长度和 token 数为示意。
同一份数据经历两种频率完全不同的搬移：加载把模型送到加速器（启动时一次），执行则每一步都把所需权重和状态送到计算单元。外部请求可能只有一小段文字，内部搬的却是大得多的权重、KV 状态和中间张量。
练习 1-1 的账本 · 回答变长、实例复制，哪些量会变
70B · 8 比特权重 73.73 GB · 每 token KV 320 KiB每 token 320 KiB 由书中“8192 token 的 BF16 KV = 2.5 GiB”线性换算；每步权重读取按例题 1-1 的“每参数一字节、约 70 GB”。输入 2048 token 是示意值。把实例复制成两份，权重就要存两份，路由器多了一个可选的去处。
软件对应的硬件
超节点是一组通过高带宽互联紧密协作的加速器，可以分布在多台服务器或计算托盘里。超节点内部的互联叫 scale-up，目标是一组加速器低开销地共同计算；超节点之间经网卡和交换网络相连，叫 scale-out，用来扩大集群。GB200 NVL72 把 36 个 Grace CPU 和 72 个 Blackwell GPU 装进一个机柜，72 个 GPU 经 NVLink 组成同一个互联域：紧密协作的范围从单机扩到了机柜。
图 1-5 · 物理连接的两层视图：三种流量
| 流量 | 走哪条路 | 什么时候发生 | 时间要求 |
|---|---|---|---|
| ■ 请求 | 服务入口 → 数据中心网络 → 主机 | 每个请求进出 | 数据量小，可能只是一小段文字 |
| ■ 模型文件 | 共享存储 → 网络 → 主存 → 显存 | 实例启动或模型切换 | 量大，但可以提前加载 |
| ■ 中间结果 | GPU ↔ GPU（超节点内部互联，或经网卡跨超节点） | 每层计算之间 | 必须及时到达，下一层才能继续 |
CPU 连主存，负责主机程序和执行控制；GPU 连各自的显存（常用 HBM，宽接口持续供数）；CPU 与 GPU 可经 PCIe 相连，GPU 之间可走独立高速互联。支持直接内存访问时，数据由传输硬件直接写入目标内存，CPU 只发起和管理（第 7 章）。设备数量为示意。
物理连接直接影响模型的执行时间。单卡的算力和带宽决定本地计算与读写的耗时，多卡协作再加上数据交换和等待。本章先估单卡，后续章节把同样的方法用到超节点和网络。
贯穿全书的两条线索
decoder-only 与因果编码器—解码器（CED）
DeepSeek V4 → V4.1 FlashV4 已经用上下文压缩与稀疏访问改变存储和读取需求；V4.1 Flash 进一步重划模型内部职责：编码器形成上下文表示，解码器从中取全局信息，大量输入 token 不必经过解码器主体；生成新 token 时仍依次经过编码器与解码器。Agent 负载“输入多、输出少”，计算投入可以按此重新安排。开源的 Qwen3 用作基础算例。第 2 章讲 CED 的结构与状态，第 3 章分解负载，第 4–7 章追踪数据路径，第 8、9 章讲缓存与分配。
练习 1-1〔延伸〕· 一次请求中的权重读取、状态增长与数据传递
沿图 1-3 至 1-5，补画 KV 状态随输出增加的过程，分别标出模型文件加载、一步权重读取、KV 追加和卡间结果传递。回答从 100 增到 1000 个 token，哪些数据只加载一次、哪些访问会增加？把一个实例复制成两个，权重容量与请求路由怎样改变？（可用上面的账本对照。）
系统设计的关键数字
1.2.1 用数量级判断方案
Jeff Dean 在 2009 年的演讲里列了一张“Numbers Everyone Should Know”：写程序、搭系统之前，先估主要操作要花多少时间。这是 2009 年的设备环境，看的是数量级关系。点两行比一比。
原幻灯片 12 项操作 · 对数刻度（图 1-6 扩展）
点击任意两行比较1 μs = 1000 ns，1 ms = 1000 μs；1 byte = 8 bit。KB/MB/GB/TB 是 10³/10⁶/10⁹/10¹² 字节，KiB/MiB/GiB 是 2¹⁰/2²⁰/2³⁰。Zippy 是 Google 当时的压缩库。颜色：绿 = 计算，灰 = 同步，橙 = 存储，蓝 = 网络。
串行等待会累加：20 次寻道 vs 1 ms 计算
每次寻道 10 ms某部分在原总时间中占比越大，缩短它对整体的改善就越大。若比例 f 的部分加速 s 倍，其余不变：
Speedup = 1 / ((1 − f) + f / s) 上限 1 / (1 − f)
Amdahl 定律 · 同样的 AI 编程工具，为什么团队收益不同
原来 100 小时、编码 20 小时：编码缩到 4 小时，其余 80 小时不变，总共 84 小时（1.19×）。编码占 80% 时：20 + 80/5 = 36 小时（2.78×）。想继续缩短交付，就得改沟通、评审和审批。局部提速，最终要放回完整任务里衡量。
1.2.2 分析 AI 系统需要哪些关键数字
某任务要保存 M 字节、做 F 次浮点运算、经某个存储接口读写 R 字节；加速器提供容量 Mcap、计算吞吐 Π、接口带宽 β。三类需求分别比较：
M ≤ Mcap Tcompute = F / Π Tmemory = R / β
按峰值 Π、β 算出的时间是硬件的物理极限，软件怎么组织都不会更快。下界与实测耗时 T 之比就是利用率：MFU = F/(ΠT)，MBU = R/(βT)，都不超过 1。它们回答同一个问题：离物理极限还有多远。M 与 R 要分开算，因为一份数据可以存一次、读很多次。
容量 · byte
能同时放下多少：权重、上下文状态、运行时工作区。
计算吞吐 · FLOP/s
一次乘加计 2 FLOP。峰值对应特定输入精度、累加精度和稠密/稀疏条件。
带宽 · byte/s
单位时间搬多少。估哪一段传输，就用哪一段接口的带宽。
延迟 · s
发起后要等多久。大块传输看数据量 ÷ 带宽；小请求逐次等待时，启动与往返可能占大头。
GPU 资源速查表
BF16 输入 · FP32 累加 · 稠密峰值 · 十进制 GB/TB| 资源或操作 | RTX 4090 | A100 80GB SXM | H100 SXM |
|---|---|---|---|
| 架构 | Ada | Ampere | Hopper |
| 显存容量（GB） | 24 | 80 | 80 |
| 显存带宽（TB/s） | 1.008 | 2.039 | 3.35 |
| BF16 矩阵峰值（TFLOP/s） | 165.2 | 312 | 989.4 |
| 按带宽峰值读取 1 GB（ms） | 0.99 | 0.49 | 0.30 |
读写量不变而带宽翻倍，R/β 减半；计算量不变而算力翻倍，F/Π 减半。条形按各列最大值归一。
1.2.3 参数存储量与链路带宽的换算
先把参数换成字节，看放不放得下；再用字节除以带宽，看搬一次要多久。DeepSeek-R1-Distill-Llama-70B 是稠密模型，公开权重约 705.54 亿参数（70,553,706,496），BF16 每个 2 字节：
MW = N · bW = 70,553,706,496 × 2 B ≈ 141.11 GB ≈ 131.42 GiB
容量检查要写全：MW + Mstate + Mwork ≤ Mcap，多卡逐卡核算。141.11 GB 放不进一张 80 GB 的 H100：要么均分到两张卡（每张 70.55 GB），要么做 8 比特分组量化（每 128 个权重共享一个 2 字节 scale，部分参数保留 BF16），合计 73.73 GB 放进一张。
图 1-7 · 显存预算计算器
8192 token 的 BF16 KV 为 2.5 GiB ≈ 2.68 GB，工作区预留 2 GiB ≈ 2.15 GB：一张 H100 上 73.73 + 2.68 + 2.15 = 78.56 GB，刚好放下。多卡时权重与 KV 均分、每卡各留一份工作区，这是本页为演示设的分配方式（示意）。容量用厂商名义 GB。
链路换算 · bit/s 先除以 8
ConnectX-7 · 400 Gbit/s这是理想时间。每次传输还有启动时间，协议开销和共用链路的其他流量也会压低应用实际拿到的带宽；沿路径把这些计进去，估算才更细。
练习 1-2〔核心〕· 不同权重精度下的显存需求与多卡分配
BF16 权重 141.11 GB，8 比特 73.73 GB，H100 SXM 每卡 80 GB。每卡预留 5 GB 状态与工作区，分别判断单卡和两卡均分能否容纳。再换成一张 48 GB 的 RTX A6000 加一张 80 GB 的 H100 SXM，判断两种精度能否部署，给出可行方案的一种权重分配。最后把 400 Gbit/s 换成 GB/s，求传 1 GB 的理想时间。
用几个数字估算一次模型执行
1.3.1 生成一个 token，先检查什么
例题 1-1：一张 H100 SXM，能否让 70B 模型在 10 ms 内生成一个新 token？为便于手算，取 N = 70×10⁹，每参数 1 字节存储、读入后转成 BF16 计算；单请求每步处理一个新 token，每步从显存把权重完整读一遍；读取与计算充分重叠。容量上一节已经查过（73.73 GB 放得下）。
驻留量
MW = bWN
存一份，70 GB
每步读取量
RW = bWN
每步再读一遍，70 GB
每步运算量
F ≈ 2BN
每个权重对每个 token 一乘一加；B=1 时 140 GFLOPs
前两式此刻相等，只因为权重存一份、读一遍。下一步生成时，驻留量还是 MW，读取却又多了一次 RW。B 增大只增加运算量：同一份权重要和更多请求的当前 token 向量做乘加。
1.3.2 计算与读取分别需要多久
Tstep ≥ max(F / Π, RW / β) 70 GB ÷ 3350 GB/s ≈ 20.90 ms 140 GFLOPs ÷ 989,400 GFLOP/s ≈ 0.1415 ms
每读一个权重只做一次乘加，计算单元很快算完已读入的数据，然后等下一批数据。提高算力只缩短乘加，不能加快显存读取。数据分块到达时，算当前块的同时可以读下一块，稳定后由较慢的一项决定速度。
单步生成计算器 · 例题 1-1 / 图 1-9 ~ 1-12 / 练习 1-3
N = 70×10⁹ · 目标 10 ms/步左：时间下界随 B 变化（图 1-11），蓝线权重读取每批 70 GB 不变，绿线计算按 2BN 增长，黑虚线是两者最大值。右：理想输出吞吐 B / T（图 1-12）。竖虚线是转折点 B* = bWΠ / (2β)，对应算术强度 I = 2B/bW 追上 Π/β，即第 4 章 Roofline 的出发点。
图 1-10 · 分块读取与计算重叠：一次读取，服务一整批
权重分 8 块依次到达（分块数为示意），每到一块就对批内所有请求做乘加。B 小时绿块细得几乎看不见，计算单元大部分时间在等数据；把上面的 B 拖过 B* 后，绿块连成一片，计算反过来成为瓶颈。“每输出 token 分摊”是整批耗时 ÷ 输出数，用来换算吞吐，不是单个请求的响应延迟。
批内复用增加的是吞吐，不是单请求速度。8 个请求共享一次读取：整批仍是 20.90 ms，每个输出分摊 2.61 ms，吞吐从 47.9 提到 383 token/s，但每个请求仍要等整批跑完。B* ≈ 148 也只比较了矩阵运算与权重读取：一张 H100 放下 73.73 GB 权重后只剩约 6.27 GB，远装不下 148 条请求的 KV。
练习 1-3〔核心〕· 带宽与 batch size 如何影响单步生成时限
用例题 1-1 的模型与加速器，有效带宽取标称 70%、有效算力取峰值 50%。分别取 B = 1、16、64，求整批时间下界、每输出 token 分摊时间和理想吞吐。目标每请求每步 ≤ 10 ms，哪些 B 仅凭下界就可判定不行？再把权重读取量减半、运算量不变，重新判断。求 B*，并解释为什么每输出分摊时间减少，不等于单步延迟缩短。（上面的计算器可以直接拨到这些条件。）
1.3.3 用实测检验估算
Qwen3-8B，BF16 权重，跑在 RTX PRO 6000 Blackwell Workstation Edition（96 GB、1.792 TB/s、503.8 TFLOP/s）上，vLLM 0.23 eager 模式（按程序顺序逐项提交工作）。每请求输入 2048、生成 256 个 token，每档测三次。吞吐 = 整批输出数 ÷ 总时间（含输入处理）；TPOT = 每请求首末输出间隔 ÷ 255，取中位数。
图 1-13 / 1-14 · 同时请求数从 1 到 64
实测理想吞吐 = 单请求吞吐 × B（练习 1-4 的假设）。TPOT 下界按 Tstep ≈ max(B·F1/Π, (RW + B·Rstate,1)/β) 估：F1 = 16.34 GFLOPs，RW = 15.14 GB，Rstate,1 = 0.302 GB（按 2048 token 上下文）。
从 1 到 64 个请求，吞吐约涨 31 倍，单请求输出间隔从 26.5 ms 涨到 40.5 ms。权重被所有请求共用，所以吞吐上去了；但每个请求各有自己的上下文状态，注意力计算和上下文访问也随请求数增长，每一步就慢了。吞吐与响应时间要同时报告。
练习 1-4〔核心〕· 用实测吞吐与输出间隔检验批处理模型
根据图 1-13、1-14 的四档测量值，算各档相对单请求的吞吐之比和 TPOT 增长比例。假设增加并发后只受共享权重读取限制，吞吐应怎样变化？对照实际结果提出两个可通过测量区分的解释，设计一次只改变上下文长度的测量来判断，并指出测量前要保持不变的模型、输出长度与计时起止点。
1.3.4 实测为何达不到极限：模型漏项还是系统开销
“新算子比旧的快三成”说明不了问题：不知道极限在哪，就不知道这三成是快到头了，还是离上限还差一个数量级。正确起点是先按第一性原理算出硬件允许的上限，再看实测差多远。
从 26.5 ms 到 8.62 ms 下界：差距去哪了
Qwen3-8B · batch 1 · RTX PRO 6000① 理论模型漏了项
只算了权重和 KV 的读取，没算注意力以外的向量运算和采样。补上后下界上移，差距缩小。改的是模型，不是系统。
② 实现本身的开销
eager 模式逐个提交 kernel，每次都经过主机上的 Python、驱动和 PCIe，加速器在两次 kernel 之间空转；客户端逐步记日志也占主机时间。这些与硬件无关，可以去掉。
补测同时关闭了前缀缓存并重新构造了输入，逐步日志的影响无法与这些条件完全分开；加速器事件只覆盖模型执行，不含采样与输出。
eager 模式下，GPU 在等 CPU 提交
实测与下界不符时，按顺序查：先问模型有没有漏项，再问实现有没有开销。每次只改变一个条件，才能分清两种来源。本例三倍的差距，大部分是主机一侧的系统开销。
需求如何推动架构设计
前面把硬件当成给定条件；反过来，这些硬件本身也是为具体需求设计的。三个案例，三种不同的瓶颈。
1.4.1 TPU：使用量到了规模，专用芯片更合算
Google 早就讨论过用 GPU、FPGA 或专用芯片，但早期空闲资源已够用。2013 年一项预测改变了讨论：如果每位用户每天用三分钟语音搜索，数据中心规模可能要翻倍。TPU v1 于 2015 年进入数据中心，论文 2017 年发表。
每日总需求 = 请求量 Q × 每请求计算量 F1。Q 增大，空闲能力终会用尽：可以加通用服务器，也可以做专用处理器。后者有前期开发成本，但可能降低每请求的设备时间和能耗。
服务规模越大，累计节省越容易抵偿前期投入。
规模与总成本
示意：无刻度图 1-15 · 围绕反复出现的矩阵运算组织计算阵列和缓冲
第 4 章展开1.4.2 SmartNIC：把包处理放到数据经过的位置
2015 年 Azure 设计 40 Gbit/s 云服务器时，网络带宽提高，虚拟网络策略也越来越复杂。多台虚拟机共用物理网络，平台要识别数据归属、查转发规则、封装、维持隔离，而这些占的正是本该给租户的 CPU 核。2015 年末起，新服务器装上基于 FPGA 的 SmartNIC，2016 年对客户提供 Accelerated Networking。
包处理要占几个 CPU 核
最小帧每帧占 84 字节线时ncore = λpacket / μcore
图 1-16：主机软件管理复杂策略，适合重复执行的包处理规则交给 FPGA；FPGA 可重新配置，网络处理能随策略更新而改。网卡若还要读主机内存，就得经 PCIe，此时返回延迟和可同时发出的请求数决定读取速度（第 7 章 KV-Direct）。
设计的关键是兼顾软件的更新能力与硬件的处理速度。
1.4.3 Unified Bus：让设备直接访问其他设备的内存
单卡放不下模型和状态，最直接的办法是加卡。但“总容量够了”和“任务能高效执行”之间，还隔着工作划分、数据交换和同步：一步计算依赖另一张卡的结果，就要等交接。华为面向昇腾等异构设备推进的 UB，相关研究在 GPT-3（2020）发布前已开始；GPT-3 之后多设备协同的需求被广泛认识，投入随之扩大。
图 1-17 · 一次远程访问要穿过几层
数据一旦跨过主机边界，软件就要改用消息传递接口、重排缓冲区，再经网卡驱动和协议栈，每多一层抽象就多一段时间。UB 去掉这些层，让一次远程访问的耗时逼近线路时延决定的下限；拓扑决定这些访问的距离与带宽。各层各占多少时间，第 7.3、7.4 节推导。
需求改变了要优先解决的瓶颈，也改变了硬件、软件与互联之间的分工：数据搬移塑造了 AI Infra 的架构。
以两卡部署为例：权重均分满足逐卡容量，但每个阶段还要等输入和前序结果。加卡改变了 Mcap 和可用算力，也引入了新的通信量与依赖。模型再大、卡再多，这个分析顺序不变。
四个常见误区
先查是不是受计算限制。例题 1-1 里读取下界远大于计算下界，算力翻倍几乎不改变下界；只加速了一部分时，还要用 Amdahl 定律查收益上限。
权重只是常驻数据的一部分。上下文状态、工作区和运行时预留一起占显存，多卡还要逐卡核算。
不知道极限，就判断不了这三成是逼近上限还是差一个数量级。先算极限，再按 1.3.4 的顺序查差距来自漏项还是开销。
批内复用减少的是每个输出分摊的读取开销，每个请求仍要排队、经历整批执行。吞吐与响应时间要同时报告。
Qwen3-8B 的关键数字
固定 BF16 权重、激活和 KV，并发 1。prefill 一次处理已有输入并得到首个输出；decode 每次送入一个新 token，利用已存的 KV 继续生成。
| 模型需求 | 数值 | 怎么用 |
|---|---|---|
| 完整 BF16 权重 | 16.38 GB | 判断加载所需显存 |
| 每个上下文 token 的全模型 KV | 144 KiB | × 上下文长度 = 单请求 KV 容量 |
| 2048 token 上下文的 KV | 288 MiB | 约 0.302 GB，随独立请求数增加 |
| 2048 token prefill 的矩阵运算 | 29.69 TFLOPs | ÷ 矩阵算力 = 计算时间下界 |
| 一步 decode 的矩阵运算 | 16.34 GFLOPs | 输入一个 token，另访问已有上下文 |
| 一步 decode 的主要权重读取 | 15.14 GB | 权重读一次；嵌入层只读当前 token 那一行 |
| 一步 decode 的旧 KV 读取 | 0.302 GB | 每份上下文 KV 读一次 |
用速查数字估下界
默认 RTX PRO 6000 · 2048 上下文prefill 固定为 2048 token 输入（改变长度时注意力部分不按线性变化，这里不外推）。decode 的旧 KV 读取按 144 KiB × 上下文换算。完整执行还要沿算子顺序加上其他运算、实际访存和启动时间，第 2–5 章逐项建立。
prefill 一次处理大量输入，矩阵工作量大；单请求 decode 每次只处理一个 token，却仍要读大量权重和上下文。提高算力、提高带宽、增加批内复用，分别作用于不同的时间项。
先放得下，再算多久，最后看谁在等
一、上层抽象上移
应用用模型与上下文表达行为，许多任务共享相近的底层计算。掌握计算依赖和状态驻留时间，就能统筹原本分属不同层次的选择：改数据表示、合并执行步骤、复用准备工作、缩短卡间传递与同步。
二、三步估算
先查数据能否放下，再用运算量和读写量估耗时，最后按执行顺序分析重叠与等待。峰值下界就是物理极限，下界/实测就是利用率；差距不是模型漏项，就是系统开销。
三、搬移决定速度
70B 算例里读权重比算慢 148 倍，所以加带宽、少读数据、提高复用才管用。批内共享提高吞吐，但每个请求的响应还包括整批执行和排队。
核心练习 1-2、1-3、1-4 分别练单位换算与可行性判断、条件改变后的资源估算、预测与实测的比较。下一章根据真实模型配置细化 2N 计算量与权重读取量，给出具体的矩阵尺寸与状态大小。