AI 系统看起来确实很复杂，各种组件层层嵌套，让人眼花缭乱。但说到底，它的性能瓶颈和优化思路，可以压缩成非常简单的三句话。

1. 尽量少搬数据：很多时候不是算不动，而是数据在内存和计算单元之间搬来搬去，拖慢了整个节奏。
2. 尽量提高有效计算密度：让硬件（尤其是GPU）花更多时间在做真正有价值的矩阵乘法，而不是空转或者做些低效操作。
3. 尽量重叠计算与通信：无论是训练还是推理，都要避免设备在那“干等”数据，让计算和通信并行起来。

所以，AI 性能问题本质上就是计算（Compute）、访存（Memory）和通信（Communication）这三个维度的协同难题。把这三点想透了，整个系统的优化方向就清楚了。

1. AI 系统栈

2. AI 硬件与体系结构：算力的物理根基

2.1 CPU、GPU、ASIC 的职责划分

这三类芯片的角色分得很清楚：

• CPU（中央处理器）：就像总指挥，擅长处理复杂逻辑、系统调度，但并行能力有限。
• GPU（图形处理器）：好比超大规模的流水线工人，能同时处理成千上万个计算任务，特别适合矩阵乘法这类运算。
• ASIC（专用芯片）：像是定制的专机，只做某几类工序，效率极高，但缺乏通用性（例如 TPU、NPU）。

打个比方：CPU 是“指挥+少量专家”，GPU 是“万人工厂”，ASIC 则是“一个只做A、B、C工序但极快的专用机器”。

2.2 GPU 的执行单位：SIMT、Warp、Block

理解 GPU 的执行模型是优化性能的关键：

• SIMT（单指令多线程）：同一段程序被大量线程同时执行。
• Warp：GPU 调度的基本单位，常见为 32 个线程组成一个 Warp。
• Thread Block（线程块）：由多个 Warp 组成，可以共享一块片上内存。

写高性能 GPU 代码，有几个需要关注的性能点：

1. Warp Divergence（分支发散）：如果同一个 Warp 里的线程走了不同的分支，就会串行执行，吞吐会大幅下降。
2. Coalesced Access（内存合并访问）：尽量让连续的线程访问连续的内存地址，这样能有效减少内存访问次数。
3. Occupancy（占用率）：指同时有多少线程驻留在 SM（流式多处理器）上。不是越高越好，因为会占用寄存器，要平衡好。

2.3 内存层级决定“真实速度”

从快到慢，GPU 的内存层级大致是：

1. Register（寄存器）：最快的存储，但容量极小。
2. Shared Memory / SRAM（共享内存/片上存储）：速度很快，是优化 kernel 的“主战场”。
3. L2 Cache：二级缓存。
4. HBM（高带宽显存）：全局显存，容量大但相对慢。
5. Host Memory（主机内存）：CPU 端的内存，速度最慢。
6. Remote Memory（远端节点）：跨机器的内存访问。

高性能 kernel 的核心目标，就是尽量让热点数据停留在更靠近计算单元（如寄存器、共享内存）的层级上。

2.4 互联与通信：单机多卡到多机集群

模型变大了，单卡不够用，就得考虑多卡甚至多机协作。这背后依赖的是通信：

• PCIe：通用的互联接口，带宽相对有限。
• NVLink/NVSwitch：NVIDIA GPU 专用的高带宽、低延迟互联。
• InfiniBand + RDMA：用于多机集群的高性能网络技术。

训练中常见的通信操作包括：

• All-Reduce：聚合所有卡的数据，然后广播给每一张卡（常用于梯度同步）。
• All-Gather：把每张卡上的数据片段收集起来，发给所有卡。
• Reduce-Scatter：先在各卡上做归约（如求和），再分散开。常与 All-Gather 配合使用。

3. AI 编译与计算架构：模型代码如何变成硬件指令

3.1 为什么需要 AI 编译器

现在框架那么多（PyTorch、TensorFlow、JAX），硬件也杂（GPU、NPU、CPU），如果每个框架都手写每种芯片的底层代码，那就要处理 N × M 的组合爆炸问题。

AI 编译器通过中间表示来解耦这个问题，把流程变成：

前端框架 ➡ IR（中间表示） ➡ 后端硬件

代表性系统有：TVM、XLA、TensorRT、MLIR 生态等。

3.2 多级 IR（Intermediate Representation，中间表示）

IR 一般分好几层，从左往右越来越接近硬件：

1. High-level IR（高层图 IR）：描述算子之间的依赖关系，便于做图级别的优化。
2. Tensor/Loop IR（张量或循环 IR）：描述循环和访存行为，方便做调度优化。
3. Low-level IR（低层 IR）：接近目标指令，如 PTX 或 LLVM IR。

3.3 前端优化（硬件无关）

这些优化和具体硬件无关，主要是清理和重整计算图：

• 常量折叠：编译时就把常量表达式算出来，减少运行时开销。
• 死代码消除：删掉不影响最终结果的计算。
• 算子融合：把多个小算子合并成一个，减少中间计算结果在显存中“搬进搬出”的次数。
• 形状推导：提前推断出张量的维度，减少运行时的计算开销。

一个典型例子：MatMul -> Add -> GELU 这三个 kernel 可以融合成一个，省去了两次中间张量从显存中写入和读出的开销，性能提升非常明显。

3.4 后端优化（硬件相关）

这些优化是针对特定硬件的，目标是榨干硬件的最后一丝性能：

• Tiling（分块）：把大矩阵切成小块，提高缓存命中率。
• 向量化：一条指令处理多个数据元素。
• 循环展开：减少循环跳转次数，提升指令级并行。
• 双缓冲：计算当前块的同时，预取下一个块的数据，隐藏访存延迟。
• 自动调优：自动搜索 block size、tile size 等最佳参数，找出最合适的执行配置。

3.5 CUDA 编程模型（理解“手写 kernel 为何快”）

CUDA 是理解 GPU 编程的基础，核心概念很清楚：

• Grid：一次 kernel 启动的全部线程块集合。
• Block：一组可以共享共享内存的线程。
• Thread：最小的执行单元。

手写 kernel 之所以在某些场景下比通用库更快，主要是因为：

1. 可以将小算子链直接融合，消去中间结果。
2. 对于特殊 shape（比如超长序列），通用库可能不是最优方案。
3. 在延迟极其敏感的在线推理场景，手写 kernel 能更好地控制延迟。

4. AI 框架核心模块：训练引擎的心脏

4.1 Tensor 与计算图

• Tensor（张量）：一切数据的载体，包含 shape、dtype、layout、device 和 stride 等信息。
• Computational Graph（计算图）：描述算子和张量之间依赖关系的图结构。
• DAG（有向无环图）：计算图通常是 DAG，这意味着可以按拓扑顺序执行，也方便进行各种优化。

动态图和静态图的区别：

• 动态图（如 PyTorch eager）：边执行边建图，调试非常灵活，是开发的王道。
• 静态图（如 XLA 图模式）：先把图建好再编译，优化空间大，但灵活性稍差。

现代框架的趋势是动静结合：开发时用动态图，部署时转为静态图进行编译优化。

4.2 Autograd（自动微分）到底在做什么

自动微分不是数值微分那种近似方法，也不是纯符号推导，它是“程序级的链式法则”。

举个例子：

• 前向：y = (w*x + b)²
• 反向：框架会自动记录依赖关系，并帮你计算 dy/dw = 2*(w*x+b)*x，dy/db = 2*(w*x+b)。

你只需要调用 loss.backward()，框架就完成了拓扑回溯和梯度累加，省去了大量手动推导的工作。

工程上的关键点包括：

1. 激活重计算：省显存，但代价是额外计算。
2. 混合精度：用 BF16/FP16 计算，提升吞吐量。
3. 损失缩放：防止低精度下梯度下溢。

4.3 分布式并行：LLM 训练为什么离不开它

单卡有明摆着的瓶颈：参数量放不下、激活值放不下、计算量跟不上。

常见的并行策略：

1. DP（数据并行）：每张卡都复制一份模型，但数据切分到不同卡上。
2. TP（张量并行）：把一个矩阵运算按维度切分到多张卡上。
3. PP（流水线并行）：按层切分，不同层放在不同设备上，按流水线方式执行。
4. FSDP/ZeRO（全分片数据并行）：把模型参数、梯度、优化器状态都分片到各卡上，显存友好。

还是用比喻好理解：

• DP：每家分店用同样的菜单，为不同的顾客服务。
• TP：一道超大菜由几个厨师同时做不同部分。
• PP：后厨流水线，A备料，B烹饪，C装盘，流水作业。

4.4 集合通信库 NCCL 的地位

• NCCL：是 NVIDIA 的 GPU 集合通信库，是分布式训练的核心组件。
• 对于大规模训练来说，通信效率直接决定了整体扩展效率。
• 优化的终极目标是重叠（Overlap）：让反向计算和梯度通信同时进行，最大限度减少空等时间。

5. AI 推理系统与引擎：走向生产的最后一公里

5.1 训练关注“学会”，推理关注“服务好”

训练的目标是提高吞吐、收敛到更好精度，而推理的目标则是低延迟、高并发、低成本、高稳定性。是时候转换视角了。

5.2 推理引擎的核心职责

一个推理引擎要处理的事情不少：

1. 模型加载与图优化。
2. 请求排队、动态批处理（dynamic batching）、并发调度。
3. KV Cache 的高效管理。
4. 选择合适的 kernel 并执行。
5. 监控关键指标：TTFT、TPOT、P95/P99 延迟。

5.3 Prefill 与 Decode 的优化重点不同

LLM 的推理过程分两部分，优化重点截然不同：

• Prefill：处理输入的上下文，计算密集，重点看吞吐和 Tensor Core 利用率。
• Decode：逐 token 生成，访存和调度密集，重点看单步延迟和 KV Cache 命中率。

5.4 模型转换：训练框架与部署环境解耦

训练好模型后，不能直接拿去上线，需要经过一个转换流程：

1. 从训练框架导出模型（如导出为 ONNX 或引擎专用格式）。
2. 推理引擎对模型做图优化和算子替换（比如把某些算子替换成更高效的手写版）。
3. 针对目标硬件构建执行计划（Engine Build）。
4. 发布到线上，进行灰度验证。

一些核心术语：

• ONNX：跨框架模型交换格式，方便生态互通。
• Engine Build：根据目标硬件生成最优执行计划的过程，通常很耗时。

5.5 模型轻量化：量化、剪枝、蒸馏

为了在更少的资源下跑得更快、更省，模型轻量化技术派上用场：

1. 量化：把 FP16 或 FP32 的参数转成 INT8 或 INT4，大幅降低显存和带宽开销。
2. 剪枝：删除掉对模型贡献不大的连接或通道，相当于帮模型“瘦身”。
3. 知识蒸馏：用一个更大、更精确的模型来指导一个更小的模型学习，让小的模型也能达到接近的精度。

生活化例子：

• 量化就像把 RAW 格式照片压成高质量 JPEG，体积小了，细节略损但可接受。
• 剪枝像修剪盆景的无效枝杈，让营养集中到主干上。
• 蒸馏像名师把重点题型浓缩成小册子，学生高效学习。

5.6 LLM 推理热点技术

这几年 LLM 推理的优化技术层出不穷，核心思路就是“既要马儿跑，又要马儿少吃草”：

• PagedAttention（分页注意力）：把 KV Cache 像虚拟内存一样分页管理，降低碎片率。
• Continuous Batching（连续批处理）：动态拼接请求，提升设备利用率。
• Prefix Cache（前缀缓存）：复用共享的提示词前缀，避免重复计算 Prefill。
• Speculative Decoding（投机解码）：用小模型“草拟”多个 token，大模型“校验”后决定是否采纳，能显著提速。
• CUDA Graph：把固定的 GPU 执行图录制下来并重复使用，省掉 kernel launch 的开销。

5.7 线上必须看的指标与告警

上线后，没有监控就像蒙着眼睛开车，至少要关注这几个维度：

• 业务层：QPS、成功率、P95/P99 延迟。
• 模型层：TTFT、TPOT、tokens/s。
• 资源层：GPU 利用率、显存水平、KV Cache 命中率。
• 稳定性：OOM 次数、重试率、超时率、节点漂移。

6. 端到端工程实战：一条训练与部署链路

下面是一条比较常见的端到端流程，可以作为团队实施的模板：

1. 训练侧

   • 准备数据与特征。
   • 选择合适的并行策略（DP/TP/PP/FSDP）。
   • 开启混合精度与梯度检查点。
   • 监控 MFU、通信时间占比、loss 曲线。

2. 导出与优化侧

   • 固化模型版本与 checksum。
   • 导出 ONNX 或目标引擎格式。
   • 跑量化标定（PTQ）或量化感知训练（QAT）。
   • 进行 engine build 与 benchmark。

3. 推理侧

   • 上线前压测：TTFT / TPOT / P99。
   • 打开连续批处理与 KV 分页。
   • 设置多级降级策略（限流、降精度、短路回复）。
   • 灰度发布，监控回归。

4. 回路闭环

   • 采集线上 bad case。
   • 进入下一轮训练与蒸馏。
   • 通过 A/B 测试验证收益。

结语

从一行简单的 model.forward(x) 到底层 GPU 上数十亿晶体管的翻转，AI 系统是一套跨学科工程：

• 体系结构决定物理上限。
• 编译器决定代码能否逼近物理上限。
• 框架决定训练是否可扩展、可维护。
• 推理系统决定模型能否稳定地创造业务价值。

真正稀缺的能力，不只是“会训练模型”，而是能把模型在真实生产环境中稳定、低成本、高性能地跑起来。

附录：AI 术语词典（按模块整理）

1 硬件与体系结构

2 编译与执行

3 框架与训练

4 推理与服务