📚 课程目录第2章 AI推理基础

AI推理基础：模型推理流程、延迟来源分析与性能指标

2.1 模型推理的完整流程

AI推理（Inference）是指将训练完成的模型部署到生产环境，对新的输入数据执行前向计算并产生预测结果的过程。与训练阶段不同，推理阶段对延迟和吞吐有极高要求，且模型参数已固定，不再进行梯度回传。理解推理流程是定位延迟瓶颈的第一步。

一个典型的在线推理请求从客户端发出到最终返回结果，需要经过以下环节：

客户端请求：用户请求以HTTP/gRPC/WebSocket等协议发送至推理服务网关。
网关路由与鉴权：负载均衡、API密钥校验、请求限流等前置逻辑。
请求预处理：包括反序列化、文本清洗、图像解码、缩放归一化、Tokenization（将文本转为token ID序列）等。
模型前向计算：核心环节，即张量在神经网络各层中依次传播，执行矩阵乘法、卷积、注意力计算等算子。
后处理与解码：对模型输出的logits进行softmax、argmax、贪心/束搜索解码，或对检测框做NMS（非极大值抑制）。
响应返回：将结果序列化并通过网络回传客户端。

下图展示了这一完整链路及各阶段可能引入的延迟分量：

2.2 延迟来源深度分析

推理延迟并非均匀分布，不同来源的延迟具有截然不同的优化空间。我们将延迟来源分为以下四类：

延迟类别	典型占比	主要成因	优化方向
计算延迟	50%~80%	矩阵乘法、注意力计算、激活函数等算子执行时间	算子融合、量化、剪枝、TensorRT等编译优化
访存延迟	10%~30%	模型参数从HBM/DRAM加载到SRAM/寄存器的带宽瓶颈	KV Cache、内存池复用、权重共享、FlashAttention
通信延迟	5%~15%	多卡/多机张量并行时的All-Reduce、All-to-All通信	通信与计算重叠、梯度压缩、拓扑优化
调度与排队延迟	5%~20%	请求排队、动态批调度、GPU资源争抢、CPU-GPU数据拷贝	连续批处理、抢占调度、异步流水线

以自回归语言模型（如GPT类）为例，其推理延迟可进一步拆解为两个阶段：

Prefill（预填充）阶段：处理完整的输入提示词（Prompt），并行计算所有输入token的KV状态。该阶段属于计算密集型（compute-bound），延迟与输入长度近似线性相关。
Decode（解码）阶段：逐token生成输出，每个token依赖前一个token的输出。该阶段属于访存密集型（memory-bound），因为每步仅计算一个token，但需读取全部模型权重（如7B模型约14GB权重），GPU算力利用率往往不足5%。

关键公式：单请求总延迟 ≈ Prefill延迟 + Decode延迟 × 输出Token数 + 网络/调度开销

总延迟 = T_prefill(input_len) + T_decode × output_tokens + T_overhead

其中T_decode通常为10~50ms/token（取决于模型规模与硬件），这也是为什么长输出任务对延迟优化更敏感。

2.3 核心性能指标：延迟、吞吐与效率

评估AI推理系统性能不能只看单一指标，需要从用户体验、系统产能和成本效率三个维度综合衡量。以下是业界最常用的指标：

2.3.1 延迟类指标

首Token延迟（TTFT, Time To First Token）：从请求发出到收到第一个输出token的时间。直接影响用户“感觉系统快不快”，通常要求小于500ms~1s。
单Token生成延迟（TPOT, Time Per Output Token）：Decode阶段生成每个token的平均耗时，决定输出流畅度。
端到端延迟（E2E Latency）：完整请求从发起到全部输出结束的总时间。

2.3.2 吞吐类指标

吞吐量（Throughput）：单位时间内系统能处理的请求数或生成的token数，常用“requests/s”或“tokens/s”表示。
并发数（Concurrency）：系统同时处理的请求数量，与吞吐量强相关。

2.3.3 效率与成本指标

算力利用率（MFU, Model FLOPs Utilization）：实际计算量占硬件理论峰值算力的比例。Decode阶段MFU通常极低（<5%），是优化重点。
每Token成本：单位token生成所需的硬件成本或能耗，用于评估经济性。

实践建议：在优化延迟时，务必同时关注TTFT和TPOT两个指标。例如，某系统将TTFT从800ms优化到200ms，但TPOT从20ms恶化到40ms，对于输出1000 token的请求，总延迟反而增加了约20秒。优化必须从用户可感知的端到端体验出发。

2.4 案例：一个典型LLM推理请求的延迟拆解

假设我们部署了一个7B参数的LLM（FP16精度，权重约14GB），运行在单张NVIDIA A100（80GB HBM，峰值算力312 TFLOPS，HBM带宽2TB/s）上。输入提示词为500 token，输出为200 token。

实测各阶段延迟如下：

阶段                    耗时          占比
网络传输(RTT)            5 ms          0.6%
网关鉴权+路由            3 ms          0.4%
预处理(Tokenize)         2 ms          0.2%
Prefill(500 token)      180 ms        21.4%
Decode(200 token)       640 ms        76.1%   (平均3.2ms/token)
后处理+序列化            6 ms          0.7%
响应传输                 4 ms          0.5%
----------------------------------------------
端到端总延迟             840 ms        100%

分析结论：

Decode阶段占总延迟的76%，是绝对瓶颈。虽然3.2ms/token已接近A100上7B模型的访存理论上限（14GB / 2TB/s ≈ 7ms，实际通过算子优化达到3.2ms），但仍有优化空间。
Prefill阶段180ms，对于500 token输入，吞吐约2778 token/s，属于正常水平。
网络与预处理开销仅占1.2%，优化价值有限。

针对该案例，可采取的优化策略包括：

量化到INT8/INT4：将权重从FP16压缩至INT8，访存数据量减半，Decode延迟可降低约40%。
使用KV Cache：避免重复计算历史token的Key/Value，Prefill阶段可提速数倍。
连续批处理（Continuous Batching）：在Decode阶段同时处理多个请求，提高GPU利用率，摊薄固定开销。

2.5 常见误区与复盘

误区一：只优化模型计算，忽略访存瓶颈。很多团队一上来就做算子融合或图优化，却发现收益有限。实际上，对于Decode阶段，访存带宽才是硬约束。先分析是compute-bound还是memory-bound，再决定优化手段。

误区二：用平均延迟掩盖长尾问题。P99延迟（99%请求的延迟上限）比平均延迟更能反映用户体验。在批处理场景中，个别大请求可能阻塞其他小请求，导致P99急剧恶化。应同时监控P50、P95、P99延迟。

误区三：盲目增大Batch Size提升吞吐，牺牲TTFT。增大batch可以提升吞吐，但会线性增加排队等待时间。对于在线交互场景，TTFT超过2秒用户就会明显感到卡顿。需要根据业务SLA动态调整batch策略。

复盘要点：在优化推理延迟前，务必先建立完整的延迟拆解工具链——记录每个阶段的耗时、GPU利用率、显存带宽利用率等指标。没有量化数据支撑的优化往往事倍功半。建议使用nsys、ncu（NVIDIA工具）或py-spy（Python进程分析）进行性能剖析，定位真实瓶颈后再动手优化。