应用量化 (quantization)、蒸馏或采样器修改等优化技术非常必要，但其效果必须严格衡量。仅仅实现一项优化是不够的；你需要客观数据来了解它对速度、资源消耗和成本的影响。基准测试提供了这种重要的反馈机制，让你能够验证改进，比较不同的策略，并对为特定需求部署最有效的模型做出明智的决定。
定义性能基准
有效的基准测试要求清楚定义你打算测量什么以及如何测量。对于扩散模型推理 (inference)，主要衡量指标通常围绕速度、容量和成本：
-
延迟： 这衡量完成单个推理请求所需的时间。它通常会进一步细分：
- 端到端延迟： 从API端点接收请求到最终结果（例如，生成的图像）返回给客户端的总时间。这包括网络开销、排队时间、预处理/后处理以及实际的模型推理。
- 推理延迟： 纯粹在扩散模型采样循环中花费的时间。这是大多数模型优化技术的目标。
- 每步延迟： 扩散过程中单个去噪步骤的平均时间。有助于诊断采样器或模型架构内的瓶颈。
延迟通常不仅以平均值报告，还使用百分位数（例如P50、P90、P95、P99）来掌握分布情况和最差性能。例如，P95延迟表明95%的请求在此时间内完成。
-
吞吐量 (throughput)： 这衡量系统的容量，通常表示为：
- 每秒请求数 (RPS)： 系统在一秒内能成功处理的推理请求数量。
- 每秒图像数 (IPS)： 类似于RPS，但特指图像生成的速度，如果请求可以生成多张图像，这个值可能会有所不同。
吞吐量受延迟、并行工作数量和硬件资源的很大影响。更高的吞吐量通常表示更好的资源使用率。
-
成本： 这将性能与货币开支关联起来。主要的成本指标包括：
- 每次推理/每张图像成本： 生成单张图像或完成一个请求相关的基础设施成本。
- 每小时成本： 部署在一段时间内的总运营成本。
成本直接与所用硬件（GPU类型、CPU、内存）、使用时长（受延迟和吞吐量影响）以及定价模式（按需与竞价实例）挂钩。
-
资源使用率： 监测底层硬件的使用效率也很重要：
- GPU使用率 (%)： GPU计算单元活跃时间百分比。低使用率可能表明CPU瓶颈、I/O问题或批处理效率低下。
- GPU内存使用率 (%)： GPU显存 (VRAM)的使用量。这对于确保模型符合内存限制以及优化批处理大小非常必要。
建立基准测试方法
为了获得可靠和可比较的结果，请遵循一致的方法：
- 隔离变量： 比较优化技术（例如，基线与FP16量化 (quantization)）时，一次只改变一个变量。对于所有要比较的测试，使用相同的硬件、软件依赖项（CUDA、cuDNN、框架版本）、输入提示和生成参数 (parameter)（分辨率、步数）。
- 一致环境： 在一个与目标生产环境高度相似的受控环境中运行基准测试。硬件（即使是同一类中不同的GPU型号）、驱动程序版本或后台进程的变化都可能使结果失真。
- 预热运行： 初次推理 (inference)请求通常会产生模型加载、CUDA上下文 (context)初始化或JIT编译的开销。在开始实际测量之前进行几次“预热”运行，以确保你正在测试稳态性能。
- 多次试验： 性能可能因系统级变化而波动。多次运行每个基准测试（例如，几十或数百个请求），并汇总结果（平均值、中位数、标准差、百分位数），以获得具有统计意义的数据。
- 负载测试（针对吞吐量 (throughput)）： 测量吞吐量需要模拟实际负载。
locust、k6或自定义脚本等工具可以向你的推理服务发送并发请求，以确定其最大可持续RPS或IPS。从低并发开始，并逐渐增加，直到延迟明显下降或发生错误。
- 工具选择： 使用合适的测量工具。
- 代码级计时： Python的
time.time()或time.perf_counter()可以测量特定代码块。torch.cuda.Event等库提供精确的GPU计时。
- 分析器： NVIDIA Nsight Systems (
nsys)或PyTorch Profiler等工具提供CPU和GPU活动的详细分类，有助于找出模型执行或数据加载阶段的瓶颈。
- 基础设施监测： 稍后讨论的工具（Prometheus、Grafana、CloudWatch）对于跟踪已部署系统中GPU使用率、请求计数和错误率等指标非常必要。
示例：比较基线与量化 (quantization)模型的延迟
当对Stable Diffusion模型应用优化技术，例如FP16量化时，基准测试过程通常包含：
- 设置： 在相同的GPU实例（例如AWS g5.xlarge）上部署原始的FP32模型和量化的FP16模型。确保两个部署都使用相同的容器镜像、依赖项和API服务器配置。
- 测试计划： 定义一组10个不同的文本提示。对于每个提示，在执行5次预热请求后，向每个模型端点发送20个顺序推理 (inference)请求。记录这20个测量请求中每个请求的端到端延迟。
- 执行： 运行测试计划，收集FP32和FP16模型的延迟数据。
- 分析： 计算每个模型在所有提示和试验中的平均、P50（中位数）、P95和P99延迟。将结果可视化以清晰显示性能差异。
基线FP32模型与FP16量化版本的延迟分布比较，显示所有百分位数都有明显改进。
这种结构化方法为优化的影响提供了具体证据。你可能会发现，FP16量化在所选硬件上将P95延迟降低了35%。
速度基准测试
虽然延迟和吞吐量 (throughput)是优化过程中的主要关注点，但请记住性能并非唯一因素。请考虑以下几点：
- 质量影响： 优化如何影响生成图像的质量？激进的量化 (quantization)或步数减少等技术可能会降低输出质量。使用定性评估（人工评价）或定量指标（FID、CLIP分数）来衡量这种权衡，尽管这些通常与纯性能基准测试分开评估。
- 稳定性： 优化后的模型处理边缘情况或多样化提示是否与原始模型一样好？使用更广泛的输入进行测试。
- 内存使用： 测量GPU峰值内存消耗。量化等优化通常会减少内存占用，可能允许更大的批处理大小或部署在成本较低的硬件上。
基准测试并非一次性任务。它应整合到你的MLOps工作流程中。每当你修改模型、更新依赖项、更改硬件或调整部署配置时，重新运行基准测试，以确保性能特征得到持续了解并满足要求。准确测量是高效优化和大规模部署扩散模型的根本。
