本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

可观测性

监控和可观测性

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 计算和自动缩放最佳实践

可观察性和指标

为您的 AI/ML 工作负载使用监控和可观测性工具

现代 AI/ML 服务需要在基础架构、建模和应用程序逻辑之间进行协调。平台工程师管理基础设施和可观测性堆栈。他们收集、存储和可视化指标。 AI/ML 工程师定义特定于模型的指标，并在不同的负载和数据分布下监控性能。应用程序开发人员消费 APIs、路由请求并跟踪服务级别指标和用户互动。如果没有统一的可观测性实践，这些团队就会各自为政，错过有关系统运行状况和性能的关键信号。建立跨环境的共享可见性可确保所有利益相关者都能及早发现问题并保持可靠的服务。

针对 AI/ML 工作负载优化 Amazon EKS 集群带来了独特的监控挑战，尤其是在GPU内存管理方面。如果没有适当的监控，组织就会面临 out-of-memory (OOM) 错误、资源效率低下和不必要的成本。有效的监控可确保 EKS 客户获得更好的性能、弹性和更低的成本。使用结合三个监控层的整体方法。首先，使用 NVIDIA DCGM Exporter 监控精细的 GPU 指标，以跟踪 GPU 功耗使用情况、GPU 温度、SM 活动、SM 占用率和 XID 错误。其次，监控 Ray 和 vLLM 等推理服务框架，通过其原生指标获得分布式工作负载见解。第三，收集应用程序级别的见解，以跟踪特定于您的工作负载的自定义指标。这种分层方法使您可以从硬件利用率到应用程序性能全方位了解情况。

工具和框架

有几种工具和框架提供了用于监控 AI/ML 工作负载的本机 out-of-the-box指标。这些内置指标消除了对自定义仪器的需求，并缩短了设置时间。这些指标侧重于性能方面，例如延迟、吞吐量和令牌生成，这些方面对于推理服务和基准测试至关重要。使用原生指标可以立即开始监控，而无需构建自定义收集管道。

可观测性方法

我们建议通过以下方式之一实现任何其他可观测性机制。

CloudWatch 容器见解如果您的组织更喜欢设置最少的 AWS 原生工具，我们建议CloudWatch 使用容器见解。它与 NVIDIA DCGM Exporter 集成以收集 GPU 指标，并提供预先构建的仪表板以快速获得见解。通过在集群上安装CloudWatch 可观察性插件，Container Insights 可以部署和管理 NVIDIA DCGM Exporter 的生命周期，该导出器从 Nvidia 的驱动程序中收集 GPU 指标并将其公开。 CloudWatch

安装 Container Insights 后， CloudWatch 会自动检测环境 GPUs 中的 NVIDIA 并收集关键的运行状况和性能指标。这些指标显示在精心策划的 out-of-the-box仪表板上。您还可以 CloudWatch 使用 Unif ied A CloudWatch gent 将 Ray 和 vlLM 与发送其原生指标进行集成。这种统一的方法简化了 EKS 环境中的可观察性，让团队可以专注于性能调整和成本优化，而不是构建监控基础架构。

有关可用指标的完整列表，请参阅 Amazon EKS 和 Kubernetes 容器洞察指标。有关实施 GPU 监控的 step-by-step指南，请参阅使用 Amazon Contain CloudWatch er Insights 获取 NVIDIA GPU 工作负载的运营见解。有关优化推理延迟的实际示例，请参阅优化 AI 响应能力：Amazon Bedrock 延迟优化推理实用指南。

托管 Prometheus 和 Grafana 如果您的组织需要自定义仪表板和高级可视化功能，请使用 NVIDIA DCGM-Exporter 和 Grafana 部署 Prometheus 进行原生监控。Prometheus 从 DCGM-Exporter 中抓取和存储 GPU 指标，而 Grafana 则提供灵活的可视化和警报功能。与 Contain CloudWatch er Insights 相比，这种方法可以让你更好地控制仪表板设计和指标保留率。

您可以通过集成 Ray 和 vlLM Ray 和 vLLM 等开源框架来扩展此监控堆栈，将其原生指标导出到 Promethe us。您还可以将 Grafana 连接到 AWS X-Ray 数据源，以可视化分布式跟踪并识别推理管道中的性能瓶颈。这种组合提供了从 GPU 级别指标到应用程序级请求流 end-to-end的可见性。

有关部署此监控堆栈的 step-by-step指南，请参阅使用 AWS 托管开源服务在 Amazon EKS 上监控 GPU 工作负载。

考虑监控核心训练并微调指标

监控核心训练指标，跟踪 Amazon EKS 集群的运行状况和性能以及在其上运行的机器学习工作负载。训练工作负载的监控要求与推理工作负载不同，因为它们运行时间长，消耗资源的方式不同，并且需要对模型融合和数据管道效率的可见性。以下指标可帮助您识别瓶颈、优化资源分配并确保训练作业成功完成。有关实施此监控方法的 step-by-step指导，请参阅在 Amazon EKS 上观察机器学习工作负载简介。

资源使用量指标

监控资源使用指标，以验证您的资源是否被正确消耗。这些指标可帮助您确定性能问题的瓶颈和根本原因。

模型性能指标

监控模型性能指标，以验证您的训练过程生成的模型是否符合准确性和业务要求。这些指标可帮助您确定何时停止训练、比较模型版本以及识别性能下降情况。

数据质量和漂移指标

监控数据质量和偏差指标，确保您的训练数据保持一致和具有代表性。随着时间的推移，数据漂移会导致模型性能下降，而数据质量问题可能会导致模型无法收敛或产生不可靠的结果。

延迟和吞吐量指标

监控延迟和吞吐量指标，以识别训练管道中的瓶颈并优化资源利用率。这些指标可帮助您了解训练期间花在何处以及将优化工作重点放在哪里。

错误率和失败率

监控整个训练管道的错误率和失败率，以保持可靠性并防止浪费计算资源。未被发现的错误可能会导致训练作业静默失败，生成无效的模型，或者在你发现问题之前浪费数小时的 GPU 时间。

Kubernetes 和 EKS 的特定指标

监控 Kubernetes 和 EKS 指标，确保您的集群基础设施保持健康并能够支持您的训练工作负载。这些指标可帮助您在基础设施问题导致训练作业失败或性能下降之前对其进行检测。

应用程序和实例日志

收集和分析应用程序和实例日志，以诊断仅靠指标无法解释的问题。日志提供了有关错误、状态更改和系统事件的详细背景信息，可帮助您了解训练作业失败或表现不佳的原因。将日志与指标关联可让您更快地查明根本原因。

以下各节介绍如何使用 AWS 推荐的两种方法收集上述指标：CloudWatch 容器见解和亚马逊托管 Prometheus 使用亚马逊托管 Grafana 的 Prometheus Amazon Managed Pro metheus。如果您更喜欢设置最少且预先构建的仪表板的 AWS 原生工具，请选择 Contain CloudWatch er Insights。如果您需要自定义控制面板、高级可视化功能或想要与基于普罗米修斯的现有监控基础设施集成，请选择带有 Amazon Managed Grafana 的 Amazon Managed Prometheus。有关可用容器洞察指标的完整列表，请参阅 Amazon EKS 和 Kubernetes 容器洞察指标。

考虑监控实时在线推理指标

在实时系统中，低延迟对于向用户或其他依赖系统提供及时响应至关重要。高延迟会降低用户体验或违反性能要求。影响推理延迟的组件包括模型加载时间、预处理时间、实际预测时间、后处理时间、网络传输时间。我们建议监控推理延迟以确保响应符合服务级别协议 (SLAs) 的低延迟，并针对以下内容制定自定义指标。在预期负载下进行测试，包括网络延迟、考虑并发请求以及使用不同的批量大小进行测试。

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或使用会话缓存）：

在随后的主题中，我们将演示如何收集上述几个指标的数据。我们将举例说明两种 AWS 推荐的方法：A WS 原生 CloudWatch 容器见解和开源 Amazon Managed Grafana 的 A mazon Managed Prometheus。您可以根据自己的整体可观测性需求选择其中一种解决方案。有关容器洞察指标的完整列表，请参阅 Amazon EKS 和 Kubernetes 容器洞察指标。

跟踪 GPU 内存使用情况

如考虑监控核心训练并微调指标主题中所述，GPU 内存使用对于防止 out-of-memory (OOM) 错误和确保高效利用资源至关重要。以下示例演示如何对训练应用程序进行检测以显示自定义直方图指标gpu_memory_usage_bytes，以及如何计算 P95 内存使用量以确定峰值消耗。请务必在暂存环境中使用样本训练作业（例如，微调变压器模型）进行测试。

AWS 原生 CloudWatch 容器见解示例

此示例演示如何使用 AWS 原生方法对训练应用程序进行检测，使其显示gpu_memory_usage_bytes为直方图。请注意，您的 AI/ML 容器必须配置为以 CloudWatch 嵌入式指标格式 (EMF) 格式发出结构化日志。 CloudWatch 日志解析 EMF 并发布指标。在训练应用程序中使用 aws_embedded_metrics 将 EMF 格式的结构化日志发送到日志， CloudWatch 日志会提取 GPU 指标。

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()

跟踪实时在线推理的推理请求持续时间

如考虑监控核心训练并微调指标主题中所述，低延迟对于向用户或其他依赖系统提供及时响应至关重要。以下示例说明如何跟踪推理应用程序公开的自定义直方图指标。inference_request_duration_seconds计算第 95 个百分位 (P95) 延迟以专注于最坏的情况，在暂存环境中使用合成推理请求（例如，通过 Locust）进行测试，并设置警报阈值（例如 >500 毫秒）以检测 SLA 违规行为。

AWS 原生 CloudWatch 容器见解示例

此示例演示了如何使用 AWS 嵌入式指标格式在推理应用程序中为 inference_request_duration_seconds 创建自定义直方图指标。 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_request_duration_seconds 创建自定义直方图指标：

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 客户文档。

跟踪代币吞吐量以进行实时在线推理

如考虑监控核心训练并微调指标主题中所述，我们建议监控代币处理时间，以衡量模型性能并优化扩展决策。以下示例说明如何跟踪推理应用程序公开的自定义直方图指标。token_processing_duration_seconds计算第 95 个百分位 (P95) 持续时间以分析处理效率，在非生产集群中使用模拟的请求负载（例如 100 到 1000 个请求/秒）进行测试，并调整 KEDA 触发器以优化扩展。

AWS 原生 CloudWatch 容器见解示例

此示例演示如何使用 AWS 嵌入式指标格式在推理应用程序中为 token_processing_duration_seconds 创建自定义直方图指标。 CloudWatch 它使用维度（`set_dimension ) 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_processing_duration_seconds 创建自定义直方图指标。

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 客户文档。

测量检查点恢复延迟

如考虑监控核心训练并微调指标主题所述，检查点延迟是模型生命周期多个阶段的关键指标。以下示例说明如何跟踪您的应用程序公开的自定义直方图指标。checkpoint_restore_duration_seconds`计算第 95 个百分位数 (P95) 持续时间以监控恢复性能，在非生产集群中使用 Spot 中断进行测试，并设置警报阈值（例如 <30 秒）以检测延迟。

AWS 原生 CloudWatch 容器见解示例

此示例演示了如何使用 Insights 对批处理应用程序进行检测，以将 checkpoint_restore_duration_seconds 显示为直方图： 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 客户文档。