📚 课程目录第4章性能分析工具

4、性能分析工具：Profiling工具、性能瓶颈识别方法

4.1 核心原理：为什么“先测后调”是吞吐优化的前提

大模型推理服务的吞吐优化，本质上是一个“受约束的资源调度问题”。GPU算力、显存带宽、显存容量、CPU调度、网络传输共同构成一条服务链，而吞吐瓶颈往往只出现在其中最弱的一环。如果跳过测量直接调参，很容易陷入“优化了A却拖垮B”的局部陷阱。Profiling的核心价值，是把模糊的“服务慢”拆解为可量化的指标：GPU利用率是否打满？算力还是带宽受限？请求排队时间占比多少？KV Cache是否频繁换入换出？只有基于这些数据，才能判断该调整max_batch_size、max_seq_len、调度策略还是量化精度。

下图展示了从请求进入到Token返回的完整链路中，Profiling工具需要观测的关键节点与指标，帮助定位瓶颈位于哪个阶段：

上图揭示了一个关键事实：不同阶段的瓶颈特征完全不同。Prefill阶段是计算密集型的矩阵乘法，主要受GPU算力上限约束；而Decode阶段是逐个Token生成，每次只计算一个Token的注意力，此时显存带宽往往成为主要瓶颈。如果只用“GPU利用率”一个指标，很难区分这两种情况。

4.2 方法流程：主流Profiling工具与使用路径

针对大模型推理服务，业界形成了“硬件层 → 框架层 → 服务层”三层Profiling体系。每层工具回答不同粒度的问题，需要组合使用才能完整定位瓶颈。

层级	工具	核心能力	典型输出
硬件层	NVIDIA Nsight Compute / Nsight Systems	SM利用率、内存带宽、Warp状态、Kernel耗时	Kernel级Profiling报告、Roofline模型
框架层	PyTorch Profiler / TensorBoard	算子耗时、显存分配、CPU/GPU时间线	算子耗时Top-K列表、显存曲线
服务层	vLLM / Triton Metrics、Prometheus + Grafana	请求延迟、吞吐、Batch状态、排队长度	TTFT/TPOT直方图、吞吐时间序列

推荐的Profiling操作流程分为以下五个步骤：

建立基线：在固定负载（如100个并发请求、输入512 Token、输出128 Token）下，记录端到端吞吐、TTFT、TPOT的基线值。
硬件层扫描：使用nsys profile采集GPU Kernel时间线，确认是否存在长时间GPU空闲（等待CPU下发）或某个Kernel异常耗时。
框架层定位：用PyTorch Profiler找出耗时Top-10算子，检查是否有非必要的显存拷贝或CPU同步点。
服务层分析：查看Batch大小分布、请求排队时间、KV Cache命中率，判断调度策略是否合理。
假设验证：针对发现的瓶颈提出优化假设（如增大Batch、开启PagedAttention、使用Continuous Batching），修改后重新Profiling对比。

一个典型的Nsight Systems采集命令示例如下：

# 采集推理服务进程的GPU活动
nsys profile --trace=cuda,nvtx,osrt \
             --output=infer_profile \
             --force-overwrite=true \
             python serve.py --model llama2-7b --batch 32

# 生成交互式报告
nsys stats --report=cuda_gpu_kern_sum,gpu_trace \
           infer_profile.nsys-rep

PyTorch Profiler则更适合定位算子级别的问题：

from torch.profiler import profile, ProfilerActivity

with profile(activities=[ProfilerActivity.CPU, ProfilerActivity.CUDA],
             record_shapes=True, profile_memory=True) as prof:
    output = model.generate(input_ids, max_new_tokens=128)

# 打印耗时Top-10算子
print(prof.key_averages().table(sort_by="cuda_time_total", row_limit=10))

4.3 案例：一次典型的吞吐瓶颈定位过程

某团队部署Llama-2-7B服务，目标吞吐为500 tokens/s，但实测仅达到180 tokens/s。他们按上述流程进行Profiling：

第一步：服务层指标发现异常。通过Grafana面板观察到GPU利用率仅45%，但请求排队时间平均达到800ms，说明GPU并非持续满载，而是存在“饥饿”现象。

第二步：Nsight Systems定位空闲原因。时间线显示GPU Kernel之间存在大量约2~5ms的空隙，这些空隙与CPU侧的Python调度循环时间吻合。进一步发现，每次迭代中CPU需要等待所有请求的torch.cuda.synchronize()完成，导致GPU流水线无法填满。

第三步：PyTorch Profiler确认瓶颈算子。算子耗时表显示aten::copy_（显存拷贝）占总耗时18%，原因是每次迭代都将KV Cache从临时缓冲区拷贝到连续显存区域，产生了大量PCIe/显存带宽消耗。

第四步：针对性优化。团队将静态Batch调度改为Continuous Batching（请求完成即释放槽位），并引入PagedAttention管理KV Cache，避免每次迭代的显存整理。优化后重新Profiling，GPU利用率提升至82%，吞吐达到460 tokens/s，接近目标值。

经验要点：当GPU利用率低于60%时，优先排查CPU调度开销和同步等待；当GPU利用率超过90%但吞吐仍不达标时，才需要深入分析Kernel效率或显存带宽限制。

4.4 误区与复盘：Profiling中常见的五个陷阱

只看平均延迟，忽略长尾：平均TPOT正常但P99极高，往往意味着存在“被抢占”的请求（如长序列Decode阻塞短序列）。应同时监控延迟分布直方图。
在低负载下做Profiling：单请求或低并发下，GPU无法饱和，测得的算子耗时不能代表高吞吐场景下的真实表现。必须在目标并发附近测量。
忽略CPU与GPU的流水线重叠：即使GPU Kernel很快，如果CPU准备数据（Tokenize、Attention Mask计算）是串行的，整体吞吐仍受CPU限制。需要检查CPU与GPU时间线是否重叠。
混淆计算密集与访存密集：仅看SM利用率高就认为是“计算瓶颈”，但若内存带宽利用率同时接近上限，实际是访存瓶颈。应使用Roofline模型或Nsight Compute的Memory Workload Analysis区分。
优化后不回归验证：修改Batch策略或量化方式后，必须重新跑完整Profiling流程，确认没有引入新的瓶颈（如量化后解码速度提升但显存带宽压力增大）。

复盘提醒：在一次实际项目中，团队发现增加max_batch_size后吞吐反而下降。Profiling显示，Batch增大导致KV Cache占用上升，触发显存碎片整理，每200次迭代出现一次长达300ms的停顿。最终通过启用PagedAttention并限制Batch内最大序列长度解决，而非简单调大Batch。

性能分析不是一次性的活动，而是贯穿优化迭代的持续反馈机制。建议每次调整后都保留Profiling报告，形成“假设 → 修改 → 测量 → 对比”的闭环。只有让数据说话，吞吐优化才能从“玄学调参”变成“工程科学”。