一、初识 AI Infra

初识 AI Infra：从模型调用到数据搬运的系统分析方法

本文是《深入理解 AI Infra：量化分析与系统设计》第一章的学习总结。

原文：https://bojieli.github.io/ai-infra-book/manuscripts/01-初识 AI Infra.html

一、什么是 AI Infra？

AI Infra（人工智能基础设施）是支撑模型训练和推理的一整套软硬件系统，主要包括：

• 计算设备：CPU、GPU、NPU、TPU 等
• 存储系统：主存、显存、片上缓存、共享存储
• 互联网络：PCIe、GPU 高速互联、数据中心网络
• 系统软件：编译器、算子库、运行时、调度器
• 服务系统：请求路由、批处理、状态管理和资源调度

传统程序主要通过代码表达行为，而 AI 应用增加了一种新的编程方式：

通过“模型 + 上下文 + 工具”表达任务。

例如，一个代码分析 Agent 可以将以下内容交给模型：

• 用户问题
• 源代码
• 测试要求
• 可调用的工具
• 历史执行结果

模型负责判断下一步应该做什么，应用程序负责执行工具、检查权限和保存结果。

因此，AI Infra 的核心问题是：

如何把模型的计算需求、高并发请求和上下文状态，高效地映射到计算、存储和网络资源上？

二、从任务到硬件：AI 系统的六层结构

一次模型请求通常要经过以下六个层次。

1. 应用与任务层

决定用户要完成什么任务，例如：

• 对话问答
• 代码生成
• 文档检索
• 语音识别
• Agent 工具调用

这一层主要关注效果、响应时间和成本。

2. 模型与负载层

模型结构决定需要执行哪些计算，实际负载决定这些计算何时发生。

同一个模型处理一句话问答、一篇长文档或多轮工具调用时，计算量、显存占用和响应时间都可能完全不同。

3. 训练与推理系统层

这一层负责：

• 请求排队
• Batch 组织
• 多用户调度
• KV Cache 管理
• 多卡协作
• 参数更新和故障恢复

4. 算子与编译运行时层

模型中的矩阵乘法、归一化、注意力等操作，需要被转换成 GPU 或其他加速器能够执行的程序。

算子库、编译器和运行时共同决定：

• 数据如何分块
• 中间结果放在哪里
• 计算任务何时提交
• 不同算子是否可以融合

5. 处理器与存储层

包括：

• CPU
• GPU
• NPU
• 显存
• 主存
• 片上缓存
• HBM

这一层决定系统到底有多少计算能力、存储容量和数据读取速度。

6. 互联与数据中心层

包括：

• PCIe
• GPU 间高速互联
• 网卡
• 交换机
• 超节点
• 数据中心网络
• 供电和散热系统

模型规模越大，越需要依赖多卡和多机协作。

三、一次生成请求是如何执行的？

以大语言模型生成回答为例，一次请求大致经历以下步骤：

用户输入 ↓ 请求入口 ↓ 权限与配额检查 ↓ 路由器选择推理实例 ↓ 文本转换为 Token ↓ 进入请求队列 ↓ 组成 Batch ↓ Prefill：处理已有输入 ↓ Decode：逐个生成新 Token ↓ 读取和更新 KV Cache ↓ 流式返回结果

Prefill 阶段

Prefill 用于处理用户已经输入的内容。

例如，用户输入一篇 2048 Token 的文章，模型需要一次性处理这些 Token，并建立后续生成所需的状态。

Decode 阶段

Decode 用于逐步生成回答。每次生成一个新 Token，都需要：

1. 读取模型权重
2. 读取已有的 KV Cache
3. 执行计算
4. 更新 KV Cache
5. 生成下一个 Token

KV Cache 保存历史 Token 产生的 Key 和 Value，避免模型每次都重新计算完整上下文。

这也是为什么上下文变长后，显存占用和数据访问量都会明显增加。

四、分析 AI 系统必须关注四个数字

1. 容量

容量决定数据能不能放下：

M ≤ M c a p M \leq M_{\mathrm{cap}}M≤Mcap​

其中：

• M MM：模型权重、KV Cache 和工作区所需空间
• M c a p M_{\mathrm{cap}}Mcap​：加速器可用显存容量

实际部署时，不能只计算模型权重，还需要考虑：

M W + M s t a t e + M w o r k ≤ M c a p M_W + M_{\mathrm{state}} + M_{\mathrm{work}} \leq M_{\mathrm{cap}}MW​+Mstate​+Mwork​≤Mcap​

也就是说：

显存能放下模型权重，不代表能够支持目标上下文长度和并发数。

2. 计算量

计算时间可以近似表示为：

T c o m p u t e = F Π T_{\mathrm{compute}} = \frac{F}{\Pi}Tcompute​=ΠF​

其中：

• F FF：需要完成的 FLOPs 数量
• Π \PiΠ：硬件计算吞吐率

3. 数据读取量和带宽

数据搬运时间可以表示为：

T m e m o r y = R β T_{\mathrm{memory}} = \frac{R}{\beta}Tmemory​=βR​

其中：

• R RR：需要读取或写入的数据量
• β \betaβ：显存、卡间链路或网络带宽

4. 延迟

带宽解决的是“大数据传输速度”，延迟解决的是“发起一次操作要等多久”。

小数据传输、频繁同步和多次 Kernel 启动，往往更容易受到延迟影响。

五、为什么很多模型推理是“访存受限”？

书中使用一个 70B 模型进行估算。假设：

• 参数量约为 700 亿
• 每个权重占 1 字节
• 每生成一个 Token，需要读取约 70 GB 权重
• H100 SXM 显存带宽为 3.35 TB/s
• BF16 矩阵计算峰值约为 989.4 TFLOP/s

权重读取时间

T m e m o r y = 70 G B 3350 G B / s ≈ 20.90 m s T_{\mathrm{memory}} = \frac{70\,\mathrm{GB}}{3350\,\mathrm{GB/s}} \approx 20.90\,\mathrm{ms}Tmemory​=3350GB/s70GB​≈20.90ms

矩阵计算时间

每个权重通常参与一次乘法和一次加法，因此计算量约为：

F ≈ 2 N = 140 G F L O P s F \approx 2N = 140\,\mathrm{GFLOPs}F≈2N=140GFLOPs

计算时间为：

T c o m p u t e = 140 G F L O P s 989400 G F L O P / s ≈ 0.1415 m s T_{\mathrm{compute}} = \frac{140\,\mathrm{GFLOPs}}{989400\,\mathrm{GFLOP/s}} \approx 0.1415\,\mathrm{ms}Tcompute​=989400GFLOP/s140GFLOPs​≈0.1415ms

两者相差约 148 倍。

因此，这个场景主要受显存带宽限制，而不是计算能力限制。

如果系统是访存受限，那么单纯增加 GPU 算力，收益可能非常有限；提高显存带宽、减少权重大小或增加批内复用，往往更加有效。

六、量化为什么能够提升部署能力？

以 70B 模型为例：

• BF16 权重约为 141.11 GB
• 8 比特量化后约为 73.73 GB
• H100 SXM 显存容量为 80 GB

BF16 权重无法放入单张 H100，需要至少两张卡；量化后则有机会放入一张 80 GB 显存的 H100。

量化的本质是：

用更少的比特数表示模型参数，从而减少显存占用和数据读取量。

但量化也会带来一些额外问题：

• 需要保存 scale 等辅助数据
• 计算前可能需要进行格式转换
• 可能影响模型精度
• 不同算子对量化格式的支持程度不同

所以量化并不是无条件优化，而是容量、带宽和精度之间的权衡。

七、Batch 如何影响吞吐和延迟？

多个请求可以共享同一份模型权重。

假设 8 个请求同时执行：

• 权重只读取一次
• 计算量大约增加 8 倍
• 每个输出可以分摊权重读取成本

理论上，批处理能够显著提高吞吐。

但需要注意：

吞吐增加，不等于单个用户的响应时间缩短。

书中的实测结果显示，从 1 个请求增加到 64 个请求时：

• 整批吞吐约提升 31 倍
• 单请求输出间隔从约 26.5 ms 增加到约 40.5 ms

原因是：

• 多个请求共享模型权重
• 每个请求仍然拥有独立的上下文状态
• Batch 增大后，KV Cache 读写和注意力计算也会增加
• 请求还可能需要排队等待整批任务完成

因此，AI 服务需要同时关注两个指标：

• Throughput：单位时间处理多少 Token 或请求
• Latency：单个请求需要等待多久

八、理论下界和真实性能有什么区别？

系统优化不能只看“比旧版本快了多少”，还要先计算硬件理论上能达到的极限。

如果实测性能明显低于理论下界，通常有两种可能。

1. 模型估算漏项

例如只计算了权重读取，却没有计算：

• KV Cache 读取
• 向量运算
• 采样
• Kernel 启动
• 其他数据访问

这种情况下应该修正性能模型。

2. 系统实现存在额外开销

例如：

• Python 调度
• 驱动调用
• PCIe 传输
• 多次 Kernel 提交
• 日志记录
• CPU 与 GPU 之间同步

这种情况下应该优化系统实现。

排查性能问题时，可以遵循以下顺序：

先检查理论模型是否漏项 ↓ 再检查主机与驱动开销 ↓ 最后检查加速器利用率和数据路径

九、需求如何推动硬件架构变化？

第一章通过三个案例说明，硬件架构通常是被业务需求推动出来的。

1. TPU：语音搜索推动专用芯片

Google 预测语音搜索使用量快速增长后，通用 CPU、GPU 和 FPGA 可能无法经济地满足需求，于是设计了专门用于神经网络推理的 TPU。

核心逻辑是：

Q F 1 = Q × F 1 QF_1 = Q \times F_1QF1​=Q×F1​

当总需求超过通用设备的空闲能力时，专用芯片就可能更划算。

2. SmartNIC：网络处理从 CPU 下沉到网卡

随着云服务器网络带宽提高，数据包处理会消耗越来越多 CPU 核心。

SmartNIC 将部分网络处理逻辑放到网卡或 FPGA 中，从而：

• 减少 CPU 负担
• 提高网络处理效率
• 为租户应用释放 CPU 资源
• 保留一定的软件可编程能力

3. Unified Bus：多设备协同

当单张加速卡无法容纳完整模型时，可以增加多张卡。

但“多张卡的显存总量足够”并不代表系统就能高效运行，因为还需要解决：

• 模型如何切分
• 中间结果如何传递
• 设备之间如何同步
• 远程内存如何访问
• 通信延迟和带宽是否可接受

因此，多卡系统的关键不只是增加设备数量，还要设计高效的互联和数据访问机制。

十、AI Infra 中常见的几个误区

误区一：峰值算力翻倍，性能就会翻倍

如果系统受显存带宽限制，增加计算单元并不能显著降低总耗时。

误区二：显存能装下模型，就能支持高并发

还需要为 KV Cache、工作区和运行时预留空间。

误区三：比旧版本快 30%，优化就成功了

必须先计算理论下界，才能判断当前性能距离硬件极限还有多远。

误区四：吞吐提升，用户体验一定变好

批处理可能提升整体吞吐，却增加单个请求的排队时间和 Token 间隔。

误区五：旧场景中的成熟架构可以直接复用

系统设计依赖特定的负载比例。模型规模、上下文长度、并发数和通信模式发生变化后，原有方案可能不再合适。

十一、第一章最重要的分析方法

分析一个 AI 系统时，可以始终问五个问题：

1. 搬什么？
2. 搬多少？
3. 搬几次？
4. 经过哪里？
5. 谁在等待？

这五个问题可以把模型结构、显存访问、卡间通信、网络传输和执行依赖统一起来。

一个通用的分析流程是：

第一步：检查容量是否足够 第二步：估算计算量 第三步：估算读写量 第四步：根据带宽换算传输时间 第五步：分析计算和读取能否重叠 第六步：检查多卡通信与同步 第七步：用实测结果验证模型

十二、总结

第一章主要建立了三种能力：

1. 理解 AI Infra 的系统边界

AI Infra 不只是 GPU，也包括模型、运行时、存储、互联、调度和数据中心。

2. 学会用数量级分析性能

系统设计不能只看宣传参数，而要把容量、计算量、数据量、带宽和延迟转换成可比较的时间。

3. 建立跨层优化思维

模型结构的变化会影响显存和网络，硬件带宽的变化会影响模型部署方式，应用负载的变化又会推动芯片和系统架构演进。

可以用一句话概括本章：

AI Infra 的核心，不只是“算得快”，而是让数据以正确的方式、在正确的时间、到达正确的计算单元。

后续学习模型架构、推理优化和分布式系统时，都可以回到这条主线：

计算发生在哪里？数据存在哪里？数据如何移动？系统到底在等待什么？