Amazon SageMaker AI LLM推理的全面可观测性：从GPU利用率到LLM质量

在Amazon SageMaker AI推理上大规模部署大型语言模型（LLM）时，可观测性成为任何生产级机器学习策略的关键支柱。与传统软件返回确定性输出不同，LLM生成可变、自由形式的响应，难以用标准指标验证。LLM输出质量会随着输入分布的变化而随时间改变，质量监控有助于及早发现这些变化。对于生成式AI工作负载，可观测性还包括模型服务基础设施，其中不可预测的token消耗、GPU内存压力和延迟峰值使容量规划和成本控制成为移动目标。

一个全面的LLM推理可观测性方法必须解决两个不同但互补的维度：模型服务基础设施（数量）和LLM质量（质量）。数量监控侧重于推理基础设施的运行健康，跟踪请求吞吐量和资源利用率。这些指标有助于检测瓶颈、合理调整计算资源并控制成本。质量监控侧重于LLM本身的性能，评估响应准确性、合规性和一致性随时间的变化。

大多数团队分阶段构建LLM可观测性。第一阶段建立对核心运营指标的可见性，如延迟、错误和资源利用率。这些信号确认推理端点的可靠性。下一阶段通过采样和评估添加LLM质量，揭示模型漂移、退化或生成响应中的意外行为等问题。

当两个维度都就位后，您可以引入结合基础设施和质量信号的阈值和自动警报。随着时间的推移，实践扩展到跨模型和配置的比较分析，以便持续优化成本、性能和输出质量。数量和质量指标相互依赖：一个端点可能在运营上看似健康，但产生糟糕或不安全的响应；或者它可以提供高质量输出，但运行效率低下且基础设施过度配置。当两个维度同时被监控、关联并协同优化时，生产级LLM可观测性才真正实现。

本文演示了使用Amazon Managed Grafana仪表板的全面可观测性解决方案，为部署在Amazon SageMaker AI端点上的LLM提供质量和数量两个维度的整体视图。

工作流架构

为了在数量和监控两个维度上全面可见LLM，我们构建了一个使用三个核心AWS服务的解决方案，每个服务在LLM可观测性中扮演特定角色。下图显示了三个核心组件：Amazon SageMaker AI端点（含推理组件）、Amazon CloudWatch和Amazon Managed Grafana。

Amazon SageMaker AI推理组件作为模型托管层。单个SageMaker AI端点可以托管多个推理组件，每个组件运行不同的LLM（例如，架构图中的gpt-oss-20b和Qwen2.5-7B-Instruct）。推理组件允许您在共享基础设施上部署、扩展和管理多个模型，同时保持每个模型的隔离，用于流量路由、扩展策略和指标属性。

Amazon CloudWatch作为集中式指标存储。它从每个推理组件接收两个不同的数据流：增强指标和自定义质量指标。增强指标由SageMaker AI在端点配置中启用后自动发布。这些指标包括实例级、容器级和每GPU维度，为您提供每个模型的调用次数、延迟、错误率和GPU/CPU利用率的精细可见性。增强指标记录到/aws/sagemaker/InferenceComponents/命名空间（例如，/aws/sagemaker/InferenceComponents/gpt-oss-20b）。有关详细信息，请参阅Amazon SageMaker AI增强指标文档和增强指标深度博客文章。

自定义质量指标捕获LLM输出质量，如综合质量得分、安全得分和评估延迟。这些指标发布到单独的用户配置的CloudWatch命名空间/aws/sagemaker/inference-quality/，将质量信号与运营指标清晰分离。下表总结了两个CloudWatch指标命名空间：

CloudWatch指标命名空间 捕获内容 目的 /aws/sagemaker/InferenceComponents/ 增强指标：实例级、容器级和每GPU维度 提供每个模型的调用次数、延迟、错误率和GPU/CPU利用率的精细可见性 /aws/sagemaker/inference-quality/ 自定义质量指标：综合质量得分、安全得分和评估延迟 捕获LLM输出质量信号，与运营指标保持清晰分离

Amazon Managed Grafana提供可视化层，使用CloudWatch作为其原生数据源。在本文中，我们描述了两个专用仪表板，显示SageMaker AI端点LLM数量和质量指标，如下截图所示。

Grafana数量仪表板显示每个推理组件的GPU内存利用率、CPU使用率和调用指标。质量仪表板显示综合质量得分、安全得分和质量评估延迟，并在模型之间进行比较，如下图所示。您可以根据业务或应用程序用例创建新仪表板来扩展Grafana仪表板。

监控数量

数量监控为您提供SageMaker AI端点上LLM的运营可见性。没有它，您可能会丢失流量模式、资源饱和、成本归属和扩展行为，所有这些都直接影响可用性和支出。对于使用推理组件的多模型端点，数量监控回答了关键的运营问题：每个模型服务于多少请求？GPU是合理调整还是过度配置？哪个模型驱动成本？

除了基础设施指标外，数量监控还帮助您评估LLM推理组件的运营健康和业务影响，涵盖性能与可靠性、资源利用率以及任何特定于组织的业务指标。这些视图一起显示延迟发生在哪里，成本增长是由流量增加还是GPU分配低效引起，以及扩展策略是否适当响应需求。

以下Amazon Managed Grafana仪表板示例将这些数量监控维度应用于三个关键领域。第一组面板涵盖LLM调用和延迟。如下示例Grafana仪表板输出所示，面板显示模型延迟作为时间序列趋势、模型间总调用比较（例如gpt-oss与Qwen）以及每个模型副本的调用分解。这些面板帮助操作员了解请求吞吐量模式、识别延迟峰值并比较模型副本间的调用分布。

下一组面板关注GPU计算和内存利用率。以下Grafana仪表板示例显示两个模型（例如Qwen和gpt-oss）的GPU计算百分比和GPU内存百分比面板。这种跨模型比较帮助ML工程师和站点可靠性工程师快速确定性能问题是GPU计算受限还是内存受限，以及一个模型是否在共享基础设施上消耗了不成比例的资源。

第三组面板提供端点使用和成本详细信息。以下集群概览和成本Grafana仪表板示例显示已用GPU与空闲GPU以及总实例以可视化集群容量，同时显示每个模型的每小时成本（例如gpt-oss和Qwen）。此视图显示哪个模型驱动成本，GPU是过度配置还是饱和，以及自动扩展策略是否响应需求。

下表总结了Grafana仪表板中涵盖的三个数量监控领域及其相关指标和目的：

指标类型 仪表板指标名称 捕获内容 目的 模型调用与延迟 模型延迟、总调用（gpt-oss vs Qwen）、每副本调用（gpt-oss）、每副本调用（Qwen） 请求吞吐量、响应时间和每副本调用分布 识别延迟峰值、比较模型吞吐量、了解模型间调用负载均衡 GPU计算与内存利用率 GPU计算百分比（Qwen）、GPU计算百分比（gpt-oss）、GPU内存百分比（Qwen）、GPU内存百分比（gpt-oss） 每个模型的GPU计算和内存利用率百分比 确定问题是GPU计算受限还是内存受限，检测模型间不成比例的资源消耗 端点使用与成本 已用GPU/空闲GPU/实例、每小时成本（gpt-oss）、每小时成本（Qwen） 集群容量、GPU分配状态和每个模型每小时成本归属 识别成本驱动因素、检测过度配置或饱和的GPU、验证自动扩展响应能力

这些仪表板共同为操作员提供了一个单一视图，以关联端点上服务的模型之间的成本、容量和利用率。要在您的环境中设置这些仪表板，请遵循AWS samples GitHub存储库示例笔记本，并扩展解决方案以创建适合您组织要求的仪表板。

监控质量

虽然数量指标告诉您LLM服务基础设施是否健康，但质量指标告诉您LLM是否仍按预期运行。由于输入提示分布的变化、概念漂移或现实世界条件的改变，LLM性能可能随着时间的推移而悄然下降。与延迟峰值或500错误不同，质量退化很少触发传统警报。

质量监控通过评估模型输出在业务重要维度上的表现来解决这个问题：响应质量（与用户查询的相关性、事实准确性、完整性和一致性）、安全与合规（有害内容检测、偏差监控、隐私合规和法规遵守）、用户体验质量（有用性、清晰性、适当语气和多轮对话连贯性）以及领域特定质量（专业领域的技术准确性、检索增强生成（RAG）应用的引用质量、编程助手的代码正确性）。这些维度共同帮助治理团队实施护栏，产品所有者跟踪面向用户的质量随时间的变化，数据科学家确定质量下降是由特定提示模式、模型更新还是数据分布变化引起的。

以下Amazon Managed Grafana仪表板示例输出展示了SageMaker AI端点推理组件（例如LLM gpt-oss-20b和Qwen2.5-7B-Instruct）的质量监控。示例仪表板跟踪四个质量得分，每个显示为带有可配置警报阈值（约85%和95%的虚线）的时间序列折线图。第一个面板显示综合质量得分，一个结合质量维度的综合健康指标。该指标显示整体质量趋势随时间的变化，使得持续退化与可能关联特定提示类型间歇性质量下降一目了然。

第二组面板跟踪特定的LLM响应质量指标：安全得分、相关性得分和专业语气得分。安全得分监控有害或不合规内容的检测。在仪表板输出中，该得分是四项指标中最稳定的，始终保持在目标阈值范围内，这表明两个模型的安全护栏可靠。下一个面板是相关性得分，它测量响应与输入提示的关联程度。在示例中，相关性得分显示出某些波动，两次显著下降接近警报阈值，提示需要调查这些下降是否由特定提示模式引起。专业语气得分评估响应的正式性和适当性，其变化通常与安全性和相关性相关。

通过组合这些面板，团队可以快速区分是由基础设施问题还是质量退化引起的问题，并采取纠正措施。例如，如果安全得分下降但延迟正常，可能表明需要改进安全过滤器；如果相关性得分下降伴随GPU利用率增加，可能表明模型在处理困难提示时产生更长响应但质量更差。质量监控仪表板提供了必要的可见性，以将指标与业务结果关联并维护LLM驱动的应用的信任。