本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 可观测性
**提示**
通过 Amazon EKS 研讨会@@ [探索](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)最佳实践。
## 监控和可观测性
### GPU 指标详解
GPU 利用率指标显示 GPU 在示例窗口中是否运行了任何工作。该指标捕获 GPU 执行至少一条指令的时间百分比，但它并未显示 GPU 使用其硬件的效率。GPU 包含多个流式多处理器 (SMs)，它们是执行指令的并行处理单元。100% 的利用率读数可能意味着 GPU 在所有工作中运行了繁重的并行工作负载 SMs，也可能意味着在采样周期内，一条小指令激活了 GPU。要了解实际利用率，您需要检查硬件架构的多个级别的 GPU 指标。每个流式多处理器都由不同的内核类型构建，并且每层都具有不同的性能特征。顶级指标（GPU 利用率、内存利用率、GPU 功率和 GPU 温度，可通过 nvidia-smi 查看）显示设备是否处于活动状态。更深入的指标（SM 利用率、SM 活动和张量内核使用率）揭示了 GPU 使用其资源的效率。
### 瞄准高 GPU 功耗使用率
由于工作负载无法同时使用所有 GPU 组件，因此未充分利用会 GPUs 浪费计算容量并增加成本。对于 Amazon EKS 上的 AI/ML 工作负载，请作为代理跟踪 GPU 功耗以识别实际的 GPU 活动。GPU 利用率报告 GPU 执行任何内核的时间百分比，但它不会显示流式多处理器、内存控制器和张量内核是否同时处于活动状态。功耗暴露了这种差距，因为与运行轻量级内核或在任务之间闲置的硬件相比，完全投入的硬件消耗的电量要多得多。将功耗与 GPU 的散热设计能力 (TDP) 进行比较，以发现利用率不足，然后调查您的工作负载是否受到 CPU 预处理、网络 I/O 或批量大小效率低下的瓶颈。
在 Amazon EKS 上设置 Contain CloudWatch er Insights，以识别 GPU 功耗较低的 pod、节点或工作负载。该工具直接与 Amazon EKS 集成，允许您监控 GPU 功耗，并在功耗低于目标水平时调整 Pod 调度或实例类型。如果你需要高级可视化或自定义仪表板，可以使用 NVIDIA 的 DCGM-Exporter 和 Prometheus 和 Grafana 进行 Kubernetes 原生监控。两者都接近NVIDIA的关键指标，例如`nvidia_smi_power_draw`（GPU功耗）和`nvidia_smi_temperature_gpu`（GPU温度）。如需指标列表，请浏览 https://docs.aws.amazon.com/AmazonCloudWatch/ latest/monitoring/CloudWatch-Agent-NVIDIA-GPU.htm。寻找模式，例如在特定时间或特定工作中持续低功耗。这些趋势可帮助您确定在何处整合工作负载或调整资源分配。
Kubernetes 中的静态资源限制（例如 CPU、内存和 GPU 数量）通常会导致过度配置或利用不足，尤其是对于需求波动的推理等动态 AI/ML 工作负载。分析您的利用率趋势，将工作负载整合到更少的工作负载上 GPUs。在分配其他 GPU 之前，请确保每个 GPU 达到最大利用率。这种方法可以减少浪费并降低成本。有关优化调度和共享策略的详细指南，请参阅 [EKS 计算和自动缩放最佳实践](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html)
## 可观察性和指标
### 为您的 AI/ML 工作负载使用监控和可观测性工具
现代 AI/ML 服务需要在基础架构、建模和应用程序逻辑之间进行协调。平台工程师管理基础设施和可观测性堆栈。他们收集、存储和可视化指标。 AI/ML 工程师定义特定于模型的指标，并在不同的负载和数据分布下监控性能。应用程序开发人员消费 APIs、路由请求并跟踪服务级别指标和用户互动。如果没有统一的可观测性实践，这些团队就会各自为政，错过有关系统运行状况和性能的关键信号。建立跨环境的共享可见性可确保所有利益相关者都能及早发现问题并保持可靠的服务。
针对 AI/ML 工作负载优化 Amazon EKS 集群带来了独特的监控挑战，尤其是在GPU内存管理方面。如果没有适当的监控，组织就会面临 out-of-memory (OOM) 错误、资源效率低下和不必要的成本。有效的监控可确保 EKS 客户获得更好的性能、弹性和更低的成本。使用结合三个监控层的整体方法。首先，使用 [NVIDIA DCGM](https://docs.nvidia.com/datacenter/dcgm/latest/gpu-telemetry/dcgm-exporter.html) Exporter 监控精细的 GPU 指标，以跟踪 GPU 功耗使用情况、GPU 温度、SM 活动、SM 占用率和 XID 错误。其次，监控 [Ray](https://docs.ray.io/en/latest/serve/monitoring.html) 和 [vLLM](https://docs.vllm.ai/en/v0.8.5/design/v1/metrics.html) 等推理服务框架，通过其原生指标获得分布式工作负载见解。第三，收集应用程序级别的见解，以跟踪特定于您的工作负载的自定义指标。这种分层方法使您可以从硬件利用率到应用程序性能全方位了解情况。
#### 工具和框架
有几种工具和框架提供了用于监控 AI/ML 工作负载的本机 out-of-the-box指标。这些内置指标消除了对自定义仪器的需求，并缩短了设置时间。这些指标侧重于性能方面，例如延迟、吞吐量和令牌生成，这些方面对于推理服务和基准测试至关重要。使用原生指标可以立即开始监控，而无需构建自定义收集管道。
+ **vlLM**：适用于大型语言模型的高吞吐量服务引擎 (LLMs)，可提供请求延迟和内存使用量等原生指标。
+ **Ray**：一种分布式计算框架，它为可扩展的 AI 工作负载发布指标，包括任务执行时间和资源利用率。
+ **Hugging Face 文本生成推理 (TGI**)：用于部署和 LLMs服务的工具包，内置推理性能指标。
+ **NVIDIA genai-perf**：一款命令行工具，用于对生成人工智能模型进行基准测试，测量吞吐量、延迟和特定于 LLM 的指标，例如在特定时间间隔内完成的请求。
#### 可观测性方法
我们建议通过以下方式之一实现任何其他可观测性机制。
**CloudWatch 容器见解**[如果您的组织更喜欢设置最少的 AWS 原生工具，我们建议CloudWatch 使用容器见解。](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html)它与 [NVIDIA DCGM Exporter](https://docs.nvidia.com/datacenter/dcgm/latest/gpu-telemetry/dcgm-exporter.html) 集成以收集 GPU 指标，并提供预先构建的仪表板以快速获得见解。通过在集群上安装[CloudWatch 可观察性插件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-EKS-addon.html)，Container Insights 可以部署和管理 [NVIDIA DCGM Exporter 的生命周期，该导](https://docs.nvidia.com/datacenter/dcgm/latest/gpu-telemetry/dcgm-exporter.html)出器从 Nvidia 的驱动程序中收集 GPU 指标并将其公开。 CloudWatch
安装 Container Insights 后， CloudWatch 会自动检测环境 GPUs 中的 NVIDIA 并收集关键的运行状况和性能指标。这些指标显示在精心策划的 out-of-the-box仪表板上。您还可以 CloudWatch 使用 Unif [ied A CloudWatch gent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/UseCloudWatchUnifiedAgent.html) 将 [Ray](https://docs.ray.io/en/latest/cluster/vms/user-guides/launching-clusters/aws.html) 和 [vlLM](https://docs.vllm.ai/en/latest/) 与发送其原生指标进行集成。这种统一的方法简化了 EKS 环境中的可观察性，让团队可以专注于性能调整和成本优化，而不是构建监控基础架构。
有关可用指标的完整列表，请参阅 [Amazon EKS 和 Kubernetes 容器](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html#Container-Insights-metrics-EKS-GPU)洞察指标。有关实施 GPU 监控的 step-by-step指南，请参阅[使用 Amazon Contain CloudWatch er Insights 获取 NVIDIA GPU 工作负载的运营见解](https://aws.amazon.com/blogs/mt/gain-operational-insights-for-nvidia-gpu-workloads-using-amazon-cloudwatch-container-insights/)。有关优化推理延迟的实际示例，请参阅优[化 AI 响应能力：Amazon Bedrock 延迟优化推理实用指南](https://aws.amazon.com/blogs/machine-learning/optimizing-ai-responsiveness-a-practical-guide-to-amazon-bedrock-latency-optimized-inference/)。
**托管 Prometheus 和 Grafana 如果您的组织需要自定义仪表板和**[高级可视化功能，请使用 NVIDIA DCGM-Exporter 和 Grafana 部署 Prometheus 进行原生监控。](https://catalog.ngc.nvidia.com/orgs/nvidia/teams/k8s/containers/dcgm-exporter)Prometheus 从 DCGM-Exporter 中抓取和存储 GPU 指标，而 Grafana 则提供灵活的可视化和警报功能。与 Contain CloudWatch er Insights 相比，这种方法可以让你更好地控制仪表板设计和指标保留率。
您可以通过集成 Ray 和 vlLM Ray 和 vLLM 等开源框架来扩展此监控堆栈，将其原生指标导出到 [Promethe](https://awslabs.github.io/ai-on-eks/docs/blueprints/inference/GPUs/vLLM-rayserve) us。您还可以[将 Grafana 连接到 AWS X-Ray 数据](https://docs.aws.amazon.com/grafana/latest/userguide/x-ray-data-source.html)源，以可视化分布式跟踪并识别推理管道中的性能瓶颈。这种组合提供了从 GPU 级别指标到应用程序级请求流 end-to-end的可见性。
有关部署此监控堆栈的 step-by-step指南，请参阅[使用 AWS 托管开源服务在 Amazon EKS 上监控 GPU 工作负载](https://aws.amazon.com/blogs/mt/monitoring-gpu-workloads-on-amazon-eks-using-aws-managed-open-source-services/)。
### 考虑监控核心训练并微调指标
监控核心训练指标，跟踪 Amazon EKS 集群的运行状况和性能以及在其上运行的机器学习工作负载。训练工作负载的监控要求与推理工作负载不同，因为它们运行时间长，消耗资源的方式不同，并且需要对模型融合和数据管道效率的可见性。以下指标可帮助您识别瓶颈、优化资源分配并确保训练作业成功完成。有关实施此监控方法的 step-by-step指导，请参阅在 [Amazon EKS 上观察机器学习工作负载简介](https://aws.amazon.com/blogs/containers/part-1-introduction-to-observing-machine-learning-workloads-on-amazon-eks/)。
**资源使用量指标**
监控资源使用指标，以验证您的资源是否被正确消耗。这些指标可帮助您确定性能问题的瓶颈和根本原因。
+ **CPU、内存、网络、GPU 功率和 GPU 温度**-监控这些指标，确保分配的资源满足工作负载需求并确定优化机会。跟踪 gpu\$1memory\$1usage\$1bytes 等指标，以识别内存消耗模式并检测峰值使用情况。计算百分位数，例如第 95 个百分位数 (P95)，以了解训练期间的最高内存需求。此分析可帮助您优化模型和基础架构，以避免 OOM 错误并降低成本。
+ **SM 占用率、SM FPxx 活动、活动** ——监控这些指标以了解 GPU 底层资源的使用情况。根据[经验，SM Activity 的](https://docs.nvidia.com/datacenter/dcgm/latest/user-guide/feature-overview.html#metrics)目标为 0.8。
+ **节点和 Pod 资源利用率**-跟踪节点和 Pod 级别的资源使用情况，以确定资源争用和潜在瓶颈。监控节点是否接近容量限制，这可能会延迟 Pod 调度并减慢训练作业。
+ **资源利用率与请求和限制**的比较-将实际资源使用量与配置的请求和限制进行比较，以确定您的集群能否处理当前工作负载并适应未来的工作负载。此比较揭示了您是否需要调整资源分配以避免 OOM 错误或资源浪费。
+ **来自机器学习框架的内部指标**-从机器学习框架（例如和）中捕获内部训练 TensorFlow 和融合指标 PyTorch。这些指标包括损失曲线、学习率、批处理时间和训练步骤持续时间。使用 TensorBoard 或类似的工具可视化这些指标，以跟踪模型收敛性并识别训练效率低下的情况。
**模型性能指标**
监控模型性能指标，以验证您的训练过程生成的模型是否符合准确性和业务要求。这些指标可帮助您确定何时停止训练、比较模型版本以及识别性能下降情况。
+ **准确性、精度、召回率和 F1-Sc** ore — 跟踪这些指标以了解您的模型在验证数据上的表现如何。在每个训练周期之后，计算验证集上的 F1 分数，以评估模型是否在改进以及何时达到可接受的性能水平。
+ **特定于业务的指标以及 KPIs** — 定义和跟踪可直接衡量 AI/ML 计划业务价值的指标。对于推荐系统，跟踪点击率或转化率等指标，以确保模型推动预期的业务成果。
+ **一段时间内的性能**-比较不同模型版本和训练运行的性能指标，以确定趋势并检测性能下降。与基准模型相比，跟踪较新的型号版本是保持还是提高了性能。这种历史比较可以帮助您决定是部署新模型还是调查训练问题。
**数据质量和漂移指标**
监控数据质量和偏差指标，确保您的训练数据保持一致和具有代表性。随着时间的推移，数据漂移会导致模型性能下降，而数据质量问题可能会导致模型无法收敛或产生不可靠的结果。
+ **输入数据的统计特性**-跟踪统计属性，例如平均值、标准差和输入特征随时间的分布，以检测数据漂移或异常。监控特征分布是否与基线训练数据相比有显著变化。例如，如果关键要素的均值变化超过两个标准差，请调查您的数据管道是否已更改或底层数据源是否发生了变化。
+ **数据漂移检测和警报**-实施自动化机制，在数据质量问题影响训练之前对其进行检测和提醒。使用诸如 Kolmogorov-Smirnov 检验或卡方检验之类的统计检验，将当前的数据分布与原始训练数据进行比较。在测试检测到明显偏差时设置警报，以便您可以使用更新的数据重新训练模型或调查数据管道问题。
**延迟和吞吐量指标**
监控延迟和吞吐量指标，以识别训练管道中的瓶颈并优化资源利用率。这些指标可帮助您了解训练期间花在何处以及将优化工作重点放在哪里。
+ **End-to-End 机器学习训练管道的延迟** — 测量数据流经整个训练管道的总时间，从数据摄取到模型更新。在整个训练运行中跟踪此指标，以确定管道变化是提高还是降低了性能。高延迟通常表示节点间的数据加载、预处理或网络通信存在瓶颈。
+ **训练吞吐量和处理率** — 跟踪您的训练管道在单位时间内处理的数据量，以确保有效的资源利用率。监控指标，例如每秒处理的样本或每分钟完成的批次。相对于硬件容量而言，吞吐量较低意味着数据加载、预处理或模型计算效率低下，从而浪费 GPU 周期。
+ **检查点保存和恢复延迟** — 监控恢复作业或从故障中恢复时将模型检查点保存到存储（S3、EFS FSx）以及将其恢复到 GPU 或 CPU 内存所需的时间。缓慢的检查点操作会延长任务恢复时间并增加成本。跟踪检查点大小、保存持续时间、恢复持续时间和失败次数，以确定优化机会，例如压缩或更快的存储层。
+ **数据加载和预处理时间**-测量从存储中加载数据和应用预处理转换所花费的时间。将此时间与模型计算时间进行比较，以确定您的训练是数据绑定还是计算绑定。如果数据加载消耗的训练时间超过总训练时间的 20%，可以考虑通过缓存、预取或更快的存储来优化数据管道。
**错误率和失败率**
监控整个训练管道的错误率和失败率，以保持可靠性并防止浪费计算资源。未被发现的错误可能会导致训练作业静默失败，生成无效的模型，或者在你发现问题之前浪费数小时的 GPU 时间。
+ **管道错误监控**-跟踪机器学习管道所有阶段的错误，包括数据预处理、模型训练和检查点操作。记录错误类型、频率和受影响的组件，以快速识别问题。常见错误包括数据格式不匹配、预处理期间 out-of-memory失败以及存储限制导致的检查点保存失败。在错误率超过基线阈值时设置警报，以便在错误级联之前进行调查。
+ **重复错误分析** — 识别和调查反复出现的错误模式，以防止 future 出现故障并提高管道可靠性。分析日志，以了解特定的数据样本、批量大小或训练配置是否始终导致故障。例如，如果某些输入数据类型触发了预处理错误，请在管道的早期添加验证检查或更新数据清理逻辑。跟踪平均故障间隔时间 (MTBF)，以衡量管道可靠性是否随着时间的推移而改善。 ”
**Kubernetes 和 EKS 的特定指标**
监控 Kubernetes 和 EKS 指标，确保您的集群基础设施保持健康并能够支持您的训练工作负载。这些指标可帮助您在基础设施问题导致训练作业失败或性能下降之前对其进行检测。
+ **Kubernetes 集群状态指标** — 监控 Kubernetes 对象的运行状况和状态，包括 Pod、节点、部署和服务。跟踪 pod 状态以识别 pod 处于待处理、失败或崩溃循环状态的 pod。监控节点状况以检测磁盘压力、内存压力或网络不可用等问题。使用 kubectl 或监控工具持续检查这些指标，并在 Pod 启动失败或节点不可调度时设置警报。
+ **训练管道执行指标**-跟踪成功和失败的管道运行、作业持续时间、步骤完成时间和编排错误。监控训练作业是否在预期的时间窗口内完成，以及失败率是否会随着时间的推移而增加。跟踪工作成功率、平均作业持续时间和失败时间等指标。这些指标可帮助您确定基础架构问题、配置问题或数据质量问题是否会导致训练失败。
+ **AWS 服务指标** — 跟踪支持 EKS 基础设施和培训工作负载的 AWS 服务的指标。监控 S3 指标，例如请求延迟、错误率和吞吐量，以确保数据加载性能保持一致。跟踪 EBS 卷指标，包括 IOPS、吞吐量和队列长度，以检测存储瓶颈。监控 VPC 流日志和网络指标，以确定节点之间或与外部服务的连接问题。
+ **Kubernetes 控制平面指标** — 监控 API 服务器、调度器、控制器管理器和 etcd 数据库，以检测影响集群操作的性能问题或故障。跟踪 API 服务器请求延迟、请求速率和错误率，确保控制平面快速响应调度请求。监控 etcd 数据库大小、提交持续时间和领导者更改，以检测稳定性问题。高的 API 服务器延迟或频繁的 etcd 领导者更改可能会延迟 pod 调度并延长训练作业的启动时间。
**应用程序和实例日志**
收集和分析应用程序和实例日志，以诊断仅靠指标无法解释的问题。日志提供了有关错误、状态更改和系统事件的详细背景信息，可帮助您了解训练作业失败或表现不佳的原因。将日志与指标关联可让您更快地查明根本原因。
+ **应用程序日志**-从训练作业、数据管道和机器学习框架中收集应用程序日志，以识别瓶颈并诊断故障。这些日志捕获有关任务执行的详细信息，包括数据加载错误、模型初始化失败、检查点保存错误和特定于框架的警告。将日志时间戳与指标峰值关联起来，以了解导致性能下降或故障的原因。例如，如果 GPU 利用率突然下降，请检查应用程序日志中是否存在表明数据管道停止或预处理失败的错误。使用 CloudWatch Logs 或 Fluent Bit 等集中式日志工具汇总来自所有 pod 的日志并使其可搜索。
+ **实例日志**-收集实例级日志，例如系统日志和 dmesg 输出，以检测硬件问题和内核级问题。这些日志揭示了 GPU 驱动程序错误、内存分配故障、磁盘 I/O 错误和网络接口问题等问题，这些问题可能不会出现在应用程序日志中。将实例日志与应用程序日志和指标关联起来，以确定训练失败是由硬件问题还是应用程序问题引起的。例如，如果训练作业因 out-of-memory错误而失败，请查看 dmesg 日志中是否有内核 OOM 杀手级消息，这些消息表明系统是否耗尽了内存或者应用程序是否超出了其容器限制。针对严重的硬件错误（例如 GPU XID 错误或磁盘故障）设置警报，这样您就可以在故障实例造成大规模训练中断之前将其替换。
[以下各节介绍如何使用 AWS 推荐的两种方法收集上述指标：[CloudWatch 容器见解](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html)和亚马逊托管 Prometheus 使用亚马逊托管 Grafana 的 Prometheus Amazon Managed [Pro](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-getting-started.html) metheus。](https://docs.aws.amazon.com/grafana/latest/userguide/getting-started-with-AMG.html)如果您更喜欢设置最少且预先构建的仪表板的 AWS 原生工具，请选择 Contain CloudWatch er Insights。如果您需要自定义控制面板、高级可视化功能或想要与基于普罗米修斯的现有监控基础设施集成，请选择带有 Amazon Managed Grafana 的 Amazon Managed Prometheus。有关可用容器洞察指标的完整列表，请参阅 [Amazon EKS 和 Kubernetes 容器](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-enhanced-EKS.html)洞察指标。
### 考虑监控实时在线推理指标
在实时系统中，低延迟对于向用户或其他依赖系统提供及时响应至关重要。高延迟会降低用户体验或违反性能要求。影响推理延迟的组件包括模型加载时间、预处理时间、实际预测时间、后处理时间、网络传输时间。我们建议监控推理延迟以确保响应符合服务级别协议 (SLAs) 的低延迟，并针对以下内容制定自定义指标。在预期负载下进行测试，包括网络延迟、考虑并发请求以及使用不同的批量大小进行测试。
+ **第一个令牌的时间 (TTFT)** — 从用户提交请求到收到回复的开头（第一个单词、令牌或块）的时间长度。例如，在聊天机器人中，你需要检查在用户提问后生成第一条输出（令牌）需要多长时间。
+ **End-to-End 延迟**-这是从收到请求到返回响应的总时间。例如，测量从请求到响应的时间。
+ **每秒输出令牌 (TPS)**-表示模型开始响应后生成新标记的速度。例如，在聊天机器人中，你可以跟踪基线文本的语言模型的生成速度。
+ **错误率**-跟踪失败的请求，这可能表明存在性能问题。例如，监控对大型文档或某些字符的失败请求。
+ **吞吐量**-测量系统在单位时间内可以处理的请求或操作的数量。例如，跟踪每秒请求以处理峰值负载。
K/V (Key/Value) cache can be a powerful optimization technique for inference latency, particularly relevant for transformer-based models. K/V cache stores the key and value tensors from previous transformer layer computations, reducing redundant computations during autoregressive inference, particularly in large language models (LLMs). Cache Efficiency Metrics (specifically for K/V或使用会话缓存）：
+ **缓存 hit/miss 比率** — 对于利用缓存（K/V 或嵌入式缓存）的推理设置，请测量缓存起作用的频率。低命中率可能表示缓存配置或工作负载变化不佳，这两者都会增加延迟。
在随后的主题中，我们将演示如何收集上述几个指标的数据。[我们将举例说明两种 AWS 推荐的方法：A [WS 原生 CloudWatch 容器见解](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html)和开源 Amazon Managed Grafana 的 A [mazon Managed Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-getting-started.html)。](https://docs.aws.amazon.com/grafana/latest/userguide/getting-started-with-AMG.html)您可以根据自己的整体可观测性需求选择其中一种解决方案。有关容器洞察[指标的完整列表，请参阅 Amazon EKS 和 Kubernetes 容器洞察指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-enhanced-EKS.html)。
### 跟踪 GPU 内存使用情况
如[考虑监控核心训练并微调指标](#aiml-consider-monitor-fine-tuning-metrics)主题中所述，GPU 内存使用对于防止 out-of-memory (OOM) 错误和确保高效利用资源至关重要。以下示例演示如何对训练应用程序进行检测以显示自定义直方图指标`gpu_memory_usage_bytes`，以及如何计算 P95 内存使用量以确定峰值消耗。请务必在暂存环境中使用样本训练作业（例如，微调变压器模型）进行测试。
**AWS 原生 CloudWatch 容器见解示例**
此示例演示如何使用 AWS 原生方法对训练应用程序进行检测，使其显示`gpu_memory_usage_bytes`为直方图。请注意，您的 AI/ML 容器必须配置为以 CloudWatch [嵌入式指标格式 (EMF) 格式](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Specification.html)发出结构化日志。 CloudWatch 日志解析 EMF 并发布指标。在训练应用程序中使用 [aws\$1embedded\$1metrics 将 EMF 格式的结构化日志发送到日志， CloudWatch 日志会提取 GPU 指标](https://github.com/awslabs/aws-embedded-metrics-python)。
```
from aws_embedded_metrics import metric_scope
import torch
import numpy as np
memory_usage = []
@metric_scope
def log_gpu_memory(metrics):
# Record current GPU memory usage
mem = torch.cuda.memory_allocated()
memory_usage.append(mem)
# Log as histogram metric
metrics.set_namespace("MLTraining/GPUMemory")
metrics.put_metric("gpu_memory_usage_bytes", mem, "Bytes", "Histogram")
# Calculate and log P95 if we have enough data points
if len(memory_usage) >= 10:
p95 = np.percentile(memory_usage, 95)
metrics.put_metric("gpu_memory_p95_bytes", p95, "Bytes")
print(f"Current memory: {mem} bytes, P95: {p95} bytes")
# Example usage in training loop
for epoch in range(20):
# Your model training code would go here
log_gpu_memory()
```
**Prometheus 和 Grafana 示例**
此示例演示如何使用 Python 中的 Prometheus 客户端库对训练应用程序进行检测，使其显示`gpu_memory_usage_bytes``为直方图。
```
from prometheus_client import Histogram
from prometheus_client import start_http_server
import pynvml
start_http_server(8080)
memory_usage = Histogram(
'gpu_memory_usage_bytes',
'GPU memory usage during training',
['gpu_index'],
buckets=[1e9, 2e9, 4e9, 8e9, 16e9, 32e9]
)
# Function to get GPU memory usage
def get_gpu_memory_usage():
if torch.cuda.is_available():
# Get the current GPU device
device = torch.cuda.current_device()
# Get memory usage in bytes
memory_allocated = torch.cuda.memory_allocated(device)
memory_reserved = torch.cuda.memory_reserved(device)
# Total memory usage (allocated + reserved)
total_memory = memory_allocated + memory_reserved
return device, total_memory
else:
return None, 0
# Get GPU memory usage
gpu_index, memory_used = get_gpu_memory_usage()
```
### 跟踪实时在线推理的推理请求持续时间
如[考虑监控核心训练并微调指标](#aiml-consider-monitor-fine-tuning-metrics)主题中所述，低延迟对于向用户或其他依赖系统提供及时响应至关重要。以下示例说明如何跟踪推理应用程序公开的自定义直方图指标。`inference_request_duration_seconds`计算第 95 个百分位 (P95) 延迟以专注于最坏的情况，在暂存环境中使用合成推理请求（例如，通过 Locust）进行测试，并设置警报阈值（例如 >500 毫秒）以检测 SLA 违规行为。
**AWS 原生 CloudWatch 容器见解示例**
此示例演示了如何使用 AWS 嵌入式指标格式在推理应用程序中为 inference\$1request\$1duration\$1seconds 创建自定义直方图指标。 CloudWatch
```
import boto3
import time
from aws_embedded_metrics import metric_scope, MetricsLogger
cloudwatch = boto3.client('cloudwatch')
@metric_scope
def log_inference_duration(metrics: MetricsLogger, duration: float):
metrics.set_namespace("ML/Inference")
metrics.put_metric("inference_request_duration_seconds", duration, "Seconds", "Histogram")
metrics.set_property("Buckets", [0.1, 0.5, 1, 2, 5])
@metric_scope
def process_inference_request(metrics: MetricsLogger):
start_time = time.time()
# Your inference processing code here
# For example:
# result = model.predict(input_data)
duration = time.time() - start_time
log_inference_duration(metrics, duration)
print(f"Inference request processed in {duration} seconds")
# Example usage
process_inference_request()
```
**Prometheus 和 Grafana 示例**
此示例演示如何使用 Python 中的 Prometheus 客户端库在推理应用程序中为 ference\$1request\$1duration\$1seconds 创建自定义直方图指标：
```
from prometheus_client import Histogram
from prometheus_client import start_http_server
import time
start_http_server(8080)
request_duration = Histogram(
'inference_request_duration_seconds',
'Inference request latency',
buckets=[0.1, 0.5, 1, 2, 5]
)
start_time = time.time()
# Process inference request
request_duration.observe(time.time() - start_time)
```
在 Grafana 中，使用`histogram_quantile(0.95, sum(rate(inference_request_duration_seconds_bucket[5m])) by (le, pod))`查询可视化 P95 延迟趋势。[要了解更多信息，请参阅 [Prometheus 直方图文档和 Prometheus 客户文档](https://prometheus.io/docs/practices/histograms/)。](https://github.com/prometheus/client_python)
### 跟踪代币吞吐量以进行实时在线推理
如[考虑监控核心训练并微调指标](#aiml-consider-monitor-fine-tuning-metrics)主题中所述，我们建议监控代币处理时间，以衡量模型性能并优化扩展决策。以下示例说明如何跟踪推理应用程序公开的自定义直方图指标。`token_processing_duration_seconds`计算第 95 个百分位 (P95) 持续时间以分析处理效率，在非生产集群中使用模拟的请求负载（例如 100 到 1000 个请求/秒）进行测试，并调整 KEDA 触发器以优化扩展。
**AWS 原生 CloudWatch 容器见解示例**
此示例演示如何使用 AWS 嵌入式指标格式在推理应用程序中为 token\$1processing\$1duration\$1seconds 创建自定义直方图指标。 CloudWatch 它使用维度（`set\$1dimension `) with a custom `get_duration_bucket` 函数将持续时间归类为存储桶（例如，“0.01”、“>1”）。
```
import boto3
import time
from aws_embedded_metrics import metric_scope, MetricsLogger
cloudwatch = boto3.client('cloudwatch')
@metric_scope
def log_token_processing(metrics: MetricsLogger, duration: float, token_count: int):
metrics.set_namespace("ML/TokenProcessing")
metrics.put_metric("token_processing_duration_seconds", duration, "Seconds")
metrics.set_dimension("ProcessingBucket", get_duration_bucket(duration))
metrics.set_property("TokenCount", token_count)
def get_duration_bucket(duration):
buckets = [0.01, 0.05, 0.1, 0.5, 1]
for bucket in buckets:
if duration <= bucket:
return f"<={bucket}"
return f">{buckets[-1]}"
@metric_scope
def process_tokens(input_text: str, model, tokenizer, metrics: MetricsLogger):
tokens = tokenizer.encode(input_text)
token_count = len(tokens)
start_time = time.time()
# Process tokens (replace with your actual processing logic)
output = model(tokens)
duration = time.time() - start_time
log_token_processing(metrics, duration, token_count)
print(f"Processed {token_count} tokens in {duration} seconds")
return output
```
**Prometheus 和 Grafana 示例**
此示例演示了如何使用 Python 中的 Prometheus 客户端库在推理应用程序中为 token\$1processing\$1duration\$1seconds 创建自定义直方图指标。
```
from prometheus_client import Histogram
from prometheus_client import start_http_server
import time
start_http_server(8080)
token_duration = Histogram(
'token_processing_duration_seconds',
'Token processing time per request',
buckets=[0.01, 0.05, 0.1, 0.5, 1]
)
start_time = time.time()
# Process tokens
token_duration.observe(time.time() - start_time)
```
在 Grafana 中，使用`histogram_quantile(0.95, sum(rate(token_processing_duration_seconds_bucket[5m])) by (le, pod))``查询可视化 P95 处理时间趋势。[要了解更多信息，请参阅 [Prometheus 直方图文档和 Prometheus 客户文档](https://github.com/prometheus/client_python)。](https://github.com/prometheus/client_python)
**测量检查点恢复延迟**
如[考虑监控核心训练并微调指标](#aiml-consider-monitor-fine-tuning-metrics)主题所述，检查点延迟是模型生命周期多个阶段的关键指标。以下示例说明如何跟踪您的应用程序公开的自定义直方图指标。`checkpoint_restore_duration_seconds``计算第 95 个百分位数 (P95) 持续时间以监控恢复性能，在非生产集群中使用 Spot 中断进行测试，并设置警报阈值（例如 <30 秒）以检测延迟。
**AWS 原生 CloudWatch 容器见解示例**
此示例演示了如何使用 Insights 对批处理应用程序进行检测，以将 checkpoint\$1restore\$1duration\$1seconds 显示为直方图： CloudWatch
```
import boto3
import time
import torch
from aws_embedded_metrics import metric_scope, MetricsLogger
@metric_scope
def log_checkpoint_restore(metrics: MetricsLogger, duration: float):
metrics.set_namespace("ML/ModelOperations")
metrics.put_metric("checkpoint_restore_duration_seconds", duration, "Seconds", "Histogram")
metrics.set_property("Buckets", [1, 5, 10, 30, 60])
metrics.set_property("CheckpointSource", "s3://my-bucket/checkpoint.pt")
@metric_scope
def load_checkpoint(model, checkpoint_path: str, metrics: MetricsLogger):
start_time = time.time()
# Load model checkpoint
model.load_state_dict(torch.load(checkpoint_path))
duration = time.time() - start_time
log_checkpoint_restore(metrics, duration)
print(f"Checkpoint restored in {duration} seconds")
```
**Prometheus 和 Grafana 示例**
此示例演示如何使用 Python 中的 Prometheus `checkpoint_restore_duration_seconds` 客户端库对批处理应用程序进行检测，使其显示为直方图：
```
from prometheus_client import Histogram
from prometheus_client import start_http_server
import torch
start_http_server(8080)
restore_duration = Histogram(
'checkpoint_restore_duration_seconds',
'Time to restore checkpoint',
buckets=[1, 5, 10, 30, 60]
)
with restore_duration.time():
model.load_state_dict(torch.load("s3://my-bucket/checkpoint.pt"))
```
在 Grafana 中，使用`histogram_quantile(0.95, sum(rate(checkpoint_restore_duration_seconds_bucket[5m]) by (le))`查询可视化 P95 恢复延迟趋势。[要了解更多信息，请参阅 [Prometheus 直方图文档和 Prometheus 客户文档](https://prometheus.io/docs/practices/histograms/)。](https://github.com/prometheus/client_python)