有效的监控从识别和追踪正确的指标开始。对于扩散模型部署来说,这些部署通常涉及计算密集型、长时间运行的任务,一组特定的指标对于了解性能、资源消耗和整体系统状况尤为重要。这些指标为诊断问题、优化资源分配和确保服务稳定提供了定量依据。我们可以将这些核心指标大致分为性能、资源使用和可靠性。虽然输出质量和运营成本等方面也同样非常重要(并将在后续章节介绍),但这些核心运营指标能让您即时掌握系统的运行状态。性能指标性能指标直接衡量您的部署处理用户请求的速度和效率。对于扩散模型进行的图像生成等生成任务,延迟和吞吐量通常是主要关注点。生成延迟 ($L_{gen}$)延迟衡量完成一项任务所需的时间。对于扩散模型,最相关的延迟通常是端到端生成时间:从接收用户请求到返回生成输出(例如图像)的持续时间。然而,将其进一步细分是有益的:端到端延迟: 用户体验到的总时间。模型推理延迟: 纯粹在扩散模型采样循环内花费的时间。由于扩散的迭代性质,这通常是最大的组成部分。队列等待时间: 请求在处理前在队列中等待的时间(异步架构中常见)。预处理/后处理时间: 花费在提示处理、图像编码/解码或安全过滤等任务上的时间。通过追踪性能指标,可以找出模型部署中的瓶颈。高模型推理延迟可能需要模型优化(第二章),而高队列等待时间可能表明处理能力不足或调度效率低下。为了更好的用户体验,通常期望低延迟,但扩散模型本质上涉及生成步骤(质量)和速度之间的权衡。监控 $L_{gen}$ 使您能够针对特定的服务水平目标(SLOs)量化这种权衡。请求吞吐量 ($T_{req}$)吞吐量衡量您的系统成功处理请求的速率,通常表示为每秒请求数(RPS)或每分钟请求数。它反映了部署的整体容量。对于扩散模型,影响吞吐量的因素包括:可用处理单元的数量(例如,GPU)。每个单元的效率(受模型优化和硬件影响)。每个请求的平均生成延迟。服务基础设施的开销(API 处理、队列、负载均衡)。监控 $T_{req}$ 对于容量规划和扩展非常重要。吞吐量突然下降可能表明资源争用、实例故障或下游服务问题等潜在问题。了解延迟和吞吐量之间的关系也很重要;激进的批处理可能会增加吞吐量,但也可能会增加单个请求的平均延迟。资源使用指标扩散模型是资源密集型模型,尤其涉及GPU资源。监控使用率可确保您高效使用昂贵的硬件而不会使其过载。GPU使用率 ($U_{gpu}$)这可以说是扩散模型部署最重要的资源指标。它需要从多个维度进行监控:GPU计算使用率(%): 衡量 GPU 处理核心的繁忙程度。持续低使用率可能表明 I/O 瓶颈、批处理效率低下或受 CPU 限制的预处理/后处理步骤。持续高使用率(接近 100%)可能表示系统已满负荷运行或潜在过载,导致延迟增加。GPU内存使用率(%): 扩散模型,尤其是大型模型,会消耗大量 GPU 内存(VRAM)。监控内存使用情况对于避免内存不足(OOM)错误至关重要,这些错误会导致推理过程崩溃。它还为批大小以及潜在的模型量化或剪枝决策提供依据。GPU功耗(瓦特): 可以作为实际工作负载的一个有用的代理指标,并直接影响运营成本。对 $U_{gpu}$ 的有效监控有助于优化实例类型、调整批大小,并基于实际需求而非仅仅 CPU 指标实施有效的自动扩缩。{"data": [{"x": ["10:00", "10:05", "10:10", "10:15", "10:20", "10:25", "10:30"], "y": [25, 30, 88, 92, 91, 45, 40], "type": "scatter", "mode": "lines+markers", "name": "GPU使用率 (%)", "line": {"color": "#228be6"}, "marker": {"color": "#1c7ed6"}}], "layout": {"title": "GPU计算使用率示例", "xaxis": {"title": "时间"}, "yaxis": {"title": "使用率 (%)", "range": [0, 100]}, "margin": {"l": 50, "r": 20, "t": 40, "b": 40}}}示例展示了 GPU 计算使用率在 30 分钟内随工作负载变化而波动的情况。峰值表示请求量大或生成任务复杂的时期。CPU使用率尽管核心扩散过程受 GPU 限制,但 CPU 在请求处理、数据预处理/后处理、网络 I/O 以及运行应用程序服务器本身方面仍发挥作用。高 CPU 使用率可能成为瓶颈,特别是当存在复杂的预处理逻辑或服务器框架效率低下时。系统内存使用情况监控宿主系统或容器的 RAM 使用情况也是必要的。系统内存不足可能导致操作系统层面的交换或 OOM 错误,影响整体稳定性。这与 GPU 内存不同但同样重要。可靠性指标可靠性指标追踪服务的稳定性及正确性。错误率追踪错误的频率和类型是基本的。重要的错误类别包括:HTTP 服务器错误(5xx): 表明您的服务内部存在阻止请求完成的问题(例如,推理工作进程崩溃、内部超时、配置问题)。模型运行时错误: 源自模型推理代码本身的错误(例如,CUDA 错误、维度不匹配、GPU 上的 OOM 错误)。失败请求: 因任何原因(包括输入验证错误、超时或资源耗尽)而无法成功处理的请求。质量故障(如果自动追踪): 由自动化检查标记出的无意义或有问题的输出错误(更多内容见“监控生成质量”)。监控按类型细分的错误率,可直接反映部署的状况和稳定性。特定错误类型的激增有助于指导调试工作。可用性 / 运行时长可用性衡量服务处于运行状态并能成功响应请求的时间百分比。它是整体可靠性的高级指标,通常在 SLOs 中定义(例如,99.9% 运行时长)。虽然单个错误率提供细粒度细节,但可用性呈现了用户感知可靠性的整体情况。通过系统地追踪这些性能、资源和可靠性指标,您将获得有效运营、排查故障和优化扩散模型部署所需的可见性。这些指标构成了仪表板、警报系统以及关于扩展和成本管理的明智决策的依据,我们将在后续章节中进一步讨论。