延迟与吞吐量的考虑

有效部署扩散模型，取决于对两个基本性能指标的管理：延迟和吞吐量 (throughput)。如前所述，扩散过程的迭代特性带来了大量的计算要求。了解这些要求如何转化为响应速度和处理能力，对于设计可扩展系统非常重要。

在图像生成方面，延迟指的是用户提交请求（例如，文本提示）到接收最终生成图像之间所花费的时间。吞吐量衡量的是系统的处理能力，通常量化 (quantization)为单位时间内处理的请求数量或生成的图像数量（例如，每秒图像数或每分钟请求数）。这两个指标常常存在冲突；优化其中一个可能会对另一个产生负面影响。

延迟的来源

扩散模型通过一系列去噪步骤生成图像。每一步都涉及数据经过一个大型神经网络 (neural network)，通常是U-Net架构。这种迭代过程是推理 (inference)延迟的主要因素。有几个因素会影响具体的时间长短：

1. 推理步骤数量： 扩散模型通常需要多个步骤（通常20-100步，有时更多）才能将噪声细化为清晰图像。更多步骤通常会带来更高质量，但会直接增加延迟。 $延迟 \propto 步骤数量$。
2. 模型大小和复杂性： 参数 (parameter)更多的大型模型每一步需要更多计算，并占用更多显存（VRAM），从而增加每步时间。
3. 图像分辨率： 生成更高分辨率的图像需要在每一步处理更多数据，这会明显影响计算时间和内存使用。
4. 硬件： 硬件基础的速度，特别是GPU，是一个重要因素。GPU的计算能力、内存带宽和VRAM容量直接影响每个去噪步骤的执行速度。
5. 采样器选择： 存在不同的采样算法（例如DDIM、PNDM、Euler），其中一些可以在比其他算法更少的步骤中达到良好结果，从而影响总延迟。

对于一个常见配置（例如512x512分辨率、50步，在现代GPU上），每张图像的延迟可能从几秒到几十秒不等。更高的分辨率或老旧的硬件可能会使其达到数分钟。这种固有的延迟通常远高于用户对一般网络服务的预期。

了解吞吐量 (throughput)的限制

吞吐量代表系统的处理速率。对于扩散模型，它常常受限于硬件可以支持的并发推理 (inference)过程数量。影响吞吐量的主要因素包括：

1. GPU可用性： 由于单个图像生成任务可以占用GPU数秒，可用GPU的数量通常是吞吐量的主要瓶颈。
2. GPU内存（VRAM）： 每个运行中的模型实例都会占用大量VRAM（通常10GB或更多）。总可用VRAM限制了单个GPU或多个GPU上可以并发加载的模型数量。
3. 模型加载时间： 扩散模型很大。将模型从存储加载到GPU内存可能需要几秒钟，可能会增加额外负担，尤其是在按需加载模型的环境中（例如，无服务器冷启动）。
4. 请求处理： 周边基础设施（API服务器、请求队列、负载均衡器）的效率也有一定作用，尽管GPU计算通常是主要的限制。

如果单个GPU生成一张图像需要10秒，其最大理论吞吐量为每分钟6张图像。为了获得更高的吞吐量，通常需要将工作负载并行化到多个GPU上。

延迟与吞吐量 (throughput)的权衡

优化扩散模型部署常常涉及在最小化单个请求延迟和最大化系统整体吞吐量之间进行权衡。

考虑请求批处理。将多个传入请求分组并作为单个批次处理，可以显著提高GPU利用率。GPU不是一次处理一张图像，而是在模型的前向传播中并行处理多个图像。这会增加吞吐量，因为启动计算的开销分摊到更多样本上。然而，批处理通常会增加单个请求的感知延迟。请求可能需要等待批次满员或整个批次完成，即使其特定计算已经提前完成。动态批处理策略试图通过在达到一定数量的请求或超时后立即处理批次来平衡这一点。

此图展示了不同配置如何影响延迟和吞吐量。增加硬件或优化模型通常都能改善两者，而批处理等技术主要提升吞吐量，但可能以增加平均延迟为代价。

减少推理 (inference)步骤数量是另一种策略。这会直接降低延迟，但可能会影响图像质量。反之，增加步骤会提高质量但会增加延迟。

硬件扩展给这种权衡带来了另一个方面。

• 垂直扩展（使用更强大的GPU）： 主要减少每个请求的延迟。它还可以通过使每个请求更快完成，从而释放资源，略微增加吞吐量。
• 水平扩展（添加更多GPU）： 主要通过允许更多请求并行处理来增加吞吐量。它通常不会减少单个请求的延迟（除非负载导致排队延迟）。

模型优化技术，例如量化 (quantization)或知识蒸馏 (knowledge distillation)（我们将在第2章中讨论），提供了一种在不明显降低质量的情况下使模型更小更快，从而潜在改善延迟和吞吐量的方法。

对系统设计和用户体验的影响

可接受的延迟和所需的吞吐量 (throughput)很大程度上取决于应用的使用场景。

• 交互式应用： 用于实时图像编辑或快速原型制作的工具要求低延迟（理想情况下几秒钟）。高延迟会导致糟糕的用户体验。
• 批处理： 生成大量合成图像数据集或处理后台任务可能容忍更高的延迟（每张图像数分钟），只要总吞吐量足以满足截止时间。

高延迟通常需要异步API设计。API可能不会让用户等待图像生成（同步），而是立即返回一个作业ID。用户可以稍后查询结果，或者在生成完成后通过Webhook收到通知。这改善了长时间运行任务的用户体验，但增加了系统架构的复杂性。我们将在本章稍后讨论同步与异步模式。

吞吐量要求直接影响基础设施成本。支持高吞吐量（每分钟数百或数千张图像）需要大量投入GPU资源和有效的调度。

测量是必要项

考虑到这些复杂性，在实际条件下准确测量延迟和吞吐量 (throughput)非常重要。

• 延迟： 平均、中位数（p50）、90百分位数（p90）和99百分位数（p99）的延迟展现了典型和最差情况下的性能表现。
• 吞吐量： 每秒请求数（RPS）、每分钟请求数（RPM），或每分钟/小时生成的图像数。

基准测试应模拟预期的请求模式，包括提示复杂度或请求图像尺寸的变化，以获得系统性能的真实感受。

最终，为扩散模型设计一个生产系统，需要仔细考虑应用和用户期望驱动的具体的延迟和吞吐量目标。在模型优化、硬件配置、批处理策略和系统架构方面所做的选择，都围绕着如何有效地管理这一基本权衡。后续章节将提供应对这些挑战的技术和模式。