可观测性 - Amazon EKS
监控和可观测性可观察性和指标

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

可观测性

监控和可观测性

瞄准高 GPU 利用率

未充分利用 GPUs 表示分配的 GPU 资源未被工作负载充分利用，从而导致计算容量浪费。对于 Amazon EKS 上的 AI/ML 工作负载，我们建议监控 GPU 利用率，以瞄准高 GPU 使用率并优化资源效率。未充分利用会 GPUs 浪费计算容量并增加成本，而过度调度则可能导致争用和性能下降。

我们建议在 Amazon EKS 上设置 Cloudwatch Container Insights，以识别 GPU 利用率指标较低的特定容器、节点或工作负载。它可轻松与 Amazon EKS 集成，使您能够监控 GPU 利用率，并在利用率低于目标水平时调整 Pod 调度或实例类型。或者，如果这不符合你的特定要求（例如高级可视化），可以考虑使用英伟达的DCGM-Exporter以及Prometheus和Grafana进行Kubernetes原生监控。这两种方法都提供了对 GPU 指标的见解，使您能够在利用率低于目标水平时调整 Pod 调度或实例类型。通过 DCGM-Exporter 查看 NVIDIA 指标，例如 nvidia_smi_utilization_gpunvidia_smi_utilization_memory（GPU 计算使用率）和（GPU 内存使用率）或。 CloudWatch寻找趋势，例如在某些时段或特定作业的利用率持续较低。

Kubernetes 中的静态资源限制（例如 CPU、内存和 GPU 数量）可能会导致过度配置或利用不足，对于推理等动态工作负载尤其如此。 AI/ML 我们建议分析利用率趋势，将工作负载整合到更少的工作负载上 GPUs，确保在分配新 GPU 之前充分利用每个 GPU。如果未 GPUs 得到充分利用，请考虑以下策略来优化日程安排和共享。要了解更多信息，请参阅 EKS 计算和自动缩放最佳实践，了解详细信息。

可观察性和指标

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

现代 AI/ML 服务在基础架构、建模和应用程序逻辑的交汇处运行。平台工程师管理基础架构、可观测性堆栈，并确保指标得到收集、存储和可视化。 AI/ML 工程师定义特定于模型的指标，并专注于在不同负载和分布下的性能。应用程序开发人员使用 API、路由请求并跟踪服务级别指标和用户互动。成功取决于跨环境建立统一的可观测性实践，让所有利益相关者都能看到系统的运行状况和性能。

针对 AI/ML 工作负载优化 Amazon EKS 集群带来了独特的监控挑战，尤其是在GPU内存管理方面。如果没有适当的监控，组织往往会面临 out-of-memory (OOM) 错误、资源效率低下和不必要的成本。对于 EKS 客户，有效的监控可确保更好的性能、弹性和更低的成本。一种整体方法，将使用 NVIDIA DCGM Exporter 进行精细的 GPU 监控（例如，使用的 GPU 内存、空闲的 GPU 内存）、监控和优化分布式工作负载见解的推理服务与使用 Ray、vLLM 等框架的原生指标相结合，以及自定义指标的应用程序级见解。

工具和框架

某些工具和框架提供用于监控 AI/ML 工作负载的原生 out-of-the-box指标，无需额外的自定义设置即可更轻松地进行集成。它们侧重于性能方面，例如延迟、吞吐量和令牌生成，这些方面对于推理服务和基准测试至关重要。示例包括：

  • vlLM：适用于大型语言模型的高吞吐量服务引擎 (LLMs)，可提供请求延迟和内存使用量等原生指标。

  • Ray：一种分布式计算框架，它为可扩展的 AI 工作负载发布指标，包括任务执行时间和资源利用率。

  • Hugging Face 文本生成推理 (TGI)：用于部署和 LLMs服务的工具包，内置推理性能指标。

  • NVIDIA genai-perf：一款命令行工具，用于对生成人工智能模型进行基准测试，测量吞吐量、延迟和特定于 LLM 的指标，例如在特定时间间隔内完成的请求。

可观测性方法

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

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

登录 Container Insights 后， CloudWatch 会自动检测您环境 GPUs 中的 NVIDIA，将您的 NVIDIA 的关键运行状况和性能指标 GPUs 作为 CloudWatch 指标收集，并将其显示在精选 out-of-the-box的仪表板上。此外，Ray 和 vLLM 可以与 CloudWatch 使用统一 CloudWatch 代理进行集成，以发送指标。这简化了 EKS 环境中的可观察性，使团队能够专注于性能调整和成本优化。

有关更多信息，要查看可用指标的完整列表，请参阅 Amazon EKS 和 Kubernetes 容器洞察指标。有关详细实现，请参阅使用 Amazon Contain CloudWatch er Insights 获取 NVIDIA GPU 工作负载的运营见解和优化 A I 响应能力：Amazon Bedrock 延迟优化推理实用指南。

托管 Prometheus 和 Grafana 如果您的组织对开源工具和自定义仪表板感到满意，我们建议使用 NVIDIA DCGM-Exporter 部署 Prometheus，使用高级可视化功能部署 Grafana 进行 Kubernetes 原生监控。Prometheus 抓取指标，Grafana 创建高级可视化效果。

此外，您可以使用 Ray 和 vLLM 等开源框架将指标导出到 Prometheus（可以使用 Grafana 对其进行可视化），也可以连接到 AWS X-Ray 数据源，然后构建仪表板以查看分析、见解或跟踪。

有关更多信息，请参阅使用 AWS 托管开源服务监控 Amazon EKS 上的 GPU 工作负载，了解详细的实现方式。

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

要获取 EKS 上 AI/ML 工作负载的核心训练指标，请考虑使用多种指标来表示 Amazon EKS 集群的运行状况和性能以及在其上运行的机器学习工作负载。有关详细实现方法，请参阅在 Amazon EKS 上观察机器学习工作负载简介。下面，我们将分解我们建议监控的指标。

资源使用量指标：

  • CPU、内存、GPU 和 GPU 内存使用情况 — 监控机器学习工作负载的这些指标可以确保分配的资源充足，并确定优化的机会。例如，跟踪诸如此类的指标gpu_memory_usage_bytes，您可以识别内存消耗模式，检测峰值使用情况，并计算百分位数（例如第 95 个百分位数 (P95)），以了解训练期间的最高内存需求。这有助于优化模型和基础架构，以避免 OOM 错误并降低成本。

  • 节点和 Pod 资源利用率 — 跟踪节点和 Pod 级别的资源使用情况可帮助您识别资源争用和潜在瓶颈。例如，检查是否有任何节点被过度利用，这可能会影响 Pod 的调度。

  • 资源利用率与请求和限制的比较-这可以深入了解您的集群是否可以处理当前工作负载并适应未来的工作负载。例如，将实际内存使用量与限制进行比较，以避免 out-of-memory出错。

  • 来自机器学习框架的内部指标 — 从机器学习框架 (TensorFlow, PyTorch) 中捕获内部训练和收敛指标，例如损失曲线、学习率、批处理时间和训练步骤持续时间，通常使用或类似方式进行可视化。 TensorBoard

模型性能指标：

  • 准确性、精度、召回率和 F1 分数 — 这些对于了解机器学习模型的性能至关重要。例如，训练结束后，计算验证集上的 F1 分数以评估性能。

  • 特定于业务的指标以及 KPIs — 定义和跟踪与您的 AI/ML 计划的业务价值直接相关的指标。例如，在推荐系统中，跟踪用户参与度的提高。

  • 随着时间的推移跟踪这些指标 — 这有助于识别模型性能的任何下降。例如，比较各模型版本的性能指标以发现趋势。

数据质量和漂移指标：

  • 输入数据的统计特性-随着时间的推移对其进行监控，以检测可能影响模型性能的数据偏差或异常。例如，跟踪输入要素的均值以检测偏移。

  • 数据漂移检测和警报-实施自动检测数据质量问题并发出警报的机制。例如，使用测试将当前数据与训练数据进行比较，并在出现明显偏差时发出警报。

延迟和吞吐量指标：

  • End-to-End 机器学习训练管道的延迟 — 监控数据流经整个训练管道所花费的时间。例如，测量从数据摄取到模型更新的总时间。

  • 训练吞吐量和处理速率-跟踪训练期间处理的数据量以确保效率。例如，监测每秒处理的阳性和阴性样本。

  • 检查点还原延迟 — 监控恢复作业、从故障中恢复或初始化时将保存的模型检查点从存储位置（S3、EFS FSx 等）加载回 GPU/CPU 内存所花费的时间。该指标直接影响任务恢复时间、冷启动性能和干扰管道的整体效率。在 auto-scaling 推理服务中，缓慢的检查点加载可能会导致冷启动延迟并降低用户体验。这些相关指标也常用于改进模型检查点：检查点停机延迟、模型反序列化时间、检查点大小和检查点还原失败次数。

  • 推理请求持续时间-监控完成推理请求所需的时间。这是从收到初始请求到模型完成响应的时间。

  • 代币吞吐量-监控代币处理时间，以衡量模型性能并优化扩展决策。处理速度慢可能表示效率低下或资源利用不足，从而影响成本效益。跟踪每秒输入的代币和每秒的代币流出量，以及处理时间，可以帮助识别性能瓶颈、减速和成本驱动因素。

  • 识别性能瓶颈-使用这些指标来查明训练过程中需要优化的领域。例如，分析数据加载所花费的时间与模型计算所花费的时间。

错误率和失败率：

  • 监控整个 ML 管道中的错误 — 这包括数据预处理、模型训练和推理。例如，记录预处理中的错误以快速识别问题。

  • 识别和调查反复出现的错误 — 这有助于维护高质量的模型并确保性能的一致性。例如，分析日志以找出导致故障的特定数据之类的模式。

Kubernetes 和 EKS 的特定指标：

  • Kubernetes 集群状态指标 — 监控各种 Kubernetes 对象的运行状况和状态，包括容器、节点和控制平面。例如，使用诸如检查 pod 状态kubectl之类的工具。

  • 成功/失败的管道运行-跟踪 successful/failed 管道运行、作业持续时间、步骤完成时间和编排错误（例如，使用Kubeflow/Mlflow/Argo事件）。

  • AWS 服务指标 — 跟踪支持您的 EKS 基础设施及其上运行的应用程序的其他 AWS 服务的指标。例如，如果使用 Amazon S3，则监控存储桶大小以跟踪存储使用情况。

  • Kubernetes 控制平面指标 — 监控 API 服务器、调度器、控制器管理器和 etcd 数据库是否存在性能问题或故障。例如，跟踪 API 服务器请求的响应延迟。

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

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

在实时系统中，低延迟对于向用户或其他依赖系统提供及时响应至关重要。高延迟会降低用户体验或违反性能要求。影响推理延迟的组件包括模型加载时间、预处理时间、实际预测时间、后处理时间、网络传输时间。我们建议监控推理延迟以确保响应符合服务级别协议 (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 容器见解和开源 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 客户文档。