推理基础：模型推理流程、延迟与吞吐量指标、性能分析工具

核心原理：一次推理请求的完整生命周期

模型推理并非简单的“输入-输出”黑盒操作，而是一条由多个阶段串联而成的数据处理流水线。理解这条流水线是定位性能瓶颈的前提。一次典型的在线推理请求会经历以下阶段：

1. 请求解析与预处理：将原始输入（文本、图像、Tensor）转换为模型所需的张量格式，包括Tokenization、Resize、Normalize等操作。此阶段常涉及CPU密集型计算。
2. 模型计算（核心阶段）：张量在GPU/NPU等加速器上执行前向传播。此阶段由算子（Operator）逐层执行，包括矩阵乘法（GEMM）、卷积（Convolution）、激活函数（Activation）等。
3. 后处理与响应返回：将模型输出的原始张量转换为用户可读的结果（如解码文本、绘制检测框），并封装为HTTP响应返回客户端。

在实际生产环境中，上述阶段往往与批处理（Batching）、缓存（Caching）、动态形状（Dynamic Shape）等机制交织在一起。下图展示了单次推理请求在服务端内部的典型数据流与耗时构成：

核心指标：延迟与吞吐量的度量与权衡

性能优化必须建立在可量化的指标之上。在推理场景中，最核心的两个指标是延迟（Latency）和吞吐量（Throughput），它们之间存在典型的“跷跷板”关系。

方法流程：性能分析的标准步骤与工具链

面对一个推理性能问题，建议遵循“先测量，再定位，后优化”的流程。切忌盲目修改代码或调整参数。

1. 建立基线：在固定硬件、固定模型版本、固定数据集下，测量当前的延迟分布和吞吐量。
2. 分层剖析：将耗时拆解到预处理、模型计算、后处理、网络传输四个环节，确定瓶颈所在层。
3. 算子级定位：若瓶颈在模型计算层，使用Profiler工具找出耗时最高的算子（如某个大矩阵乘法或Attention计算）。
4. 系统资源检查：确认GPU利用率、显存带宽、CPU占用是否均衡，是否存在数据加载瓶颈。
5. 假设验证与优化：基于定位结果，尝试针对性优化（如算子融合、KV Cache复用、动态Batch），并重新测量对比。

以下是在实际工作中最常用的性能分析工具组合：

# 1. PyTorch Profiler（模型级分析）
with torch.profiler.profile(
    activities=[torch.profiler.ProfilerActivity.CUDA],
    schedule=torch.profiler.schedule(wait=1, warmup=1, active=3),
    on_trace_ready=torch.profiler.tensorboard_trace_handler('./log')
) as prof:
    for step in range(5):
        output = model(input_tensor)
        prof.step()

# 2. NVIDIA Nsight Systems（系统级分析）
nsys profile --trace=cuda,nvtx,osrt --output=profile_result python inference.py

# 3. NVIDIA Nsight Compute（算子级分析）
ncu --set full --target-processes all python inference.py

# 4. 简单时间戳打点（快速定位阶段耗时）
import time
start = time.time()
preprocessed = preprocess(raw_input)
pre_time = time.time() - start

start = time.time()
output = model(preprocessed)
infer_time = time.time() - start

print(f"预处理: {pre_time*1000:.2f}ms, 推理: {infer_time*1000:.2f}ms")

案例场景：一个典型的性能问题定位过程

假设你部署了一个基于BERT的文本分类模型，线上反馈P99延迟从50ms恶化到200ms。按照上述流程进行排查：

• 分层剖析结果：预处理耗时5ms（正常），模型计算耗时180ms（异常），后处理耗时2ms。瓶颈锁定在模型计算层。
• 算子级定位：使用PyTorch Profiler发现，aten::bmm（批量矩阵乘法）和aten::softmax算子耗时占比超过70%。进一步观察发现，动态输入长度导致Batch内各样本的Padding比例过高，大量计算浪费在无效的Padding Token上。
• 系统资源检查：GPU利用率仅45%，显存带宽未饱和，说明计算并非真正密集，而是存在大量无效计算和内存访问。
• 优化措施：改用动态Batch + 长度分桶（Length Bucketing）策略，将相似长度的请求合并为一个Batch，减少Padding比例。同时开启算子融合（将LayerNorm与Attention融合）。
• 优化结果：P99延迟从200ms降至65ms，吞吐量提升2.3倍。

误区与复盘：性能分析中的常见陷阱