Pemantauan dan Observabilitas Observabilitas dan Metrik

Observabilitas

Pemantauan dan Observabilitas

Targetkan pemanfaatan GPU yang tinggi

Kurang dimanfaatkan GPUs menunjukkan bahwa sumber daya GPU yang dialokasikan tidak sepenuhnya dimanfaatkan oleh beban kerja, yang menyebabkan kapasitas komputasi terbuang sia-sia. Untuk AI/ML beban kerja di Amazon EKS, kami merekomendasikan pemantauan pemanfaatan GPU untuk menargetkan penggunaan GPU yang tinggi dan mengoptimalkan efisiensi sumber daya. Kapasitas komputasi GPUs limbah yang kurang dimanfaatkan dan meningkatkan biaya, sementara penjadwalan yang berlebihan dapat menyebabkan pertikaian dan penurunan kinerja.

Sebaiknya siapkan Cloudwatch Container Insights di Amazon EKS untuk mengidentifikasi pod, node, atau beban kerja tertentu dengan metrik pemanfaatan GPU rendah. Ini mudah diintegrasikan dengan Amazon EKS, memungkinkan Anda memantau pemanfaatan GPU dan menyesuaikan penjadwalan pod atau jenis instance jika pemanfaatan berada di bawah level target. Atau, jika ini tidak memenuhi persyaratan spesifik Anda (misalnya, visualisasi lanjutan), pertimbangkan untuk menggunakan Eksportir DCGM NVIDIA bersama Prometheus dan Grafana untuk pemantauan asli Kubernetes. Kedua pendekatan memberikan wawasan tentang metrik GPU, memungkinkan Anda untuk menyesuaikan penjadwalan pod atau jenis instance jika pemanfaatan berada di bawah level target. Periksa metrik NVIDIA seperti nvidia_smi_utilization_gpu (penggunaan komputasi GPU) dan nvidia_smi_utilization_memory (penggunaan memori GPU) melalui DCGM-Exporter atau. CloudWatch Carilah tren, seperti pemanfaatan rendah secara konsisten selama jam-jam tertentu atau untuk pekerjaan tertentu.

Batas sumber daya statis di Kubernetes (misalnya, jumlah CPU, memori, dan GPU) dapat menyebabkan penyediaan berlebih atau kurang dimanfaatkan, terutama untuk beban kerja dinamis seperti inferensi. AI/ML Kami merekomendasikan untuk menganalisis tren pemanfaatan dan mengkonsolidasikan beban kerja ke lebih sedikit GPUs, memastikan setiap GPU dimanfaatkan sepenuhnya sebelum mengalokasikan yang baru. Jika kurang GPUs dimanfaatkan, pertimbangkan strategi berikut untuk mengoptimalkan penjadwalan dan berbagi. Untuk mempelajari lebih lanjut, lihat praktik terbaik EKS Compute and Autoscaling untuk detailnya.

Observabilitas dan Metrik

Menggunakan Alat Pemantauan dan Pengamatan untuk Beban Kerja Anda AI/ML

AI/ML Layanan modern beroperasi di persimpangan infrastruktur, pemodelan, dan logika aplikasi. Insinyur platform mengelola infrastruktur, tumpukan observabilitas, dan memastikan metrik dikumpulkan, disimpan, dan divisualisasikan. AI/ML Insinyur mendefinisikan metrik spesifik model dan fokus pada kinerja di bawah berbagai beban dan distribusi. Pengembang aplikasi menggunakan api, permintaan rute, dan melacak metrik tingkat layanan dan interaksi pengguna. Keberhasilan bergantung pada pembentukan praktik observabilitas terpadu di seluruh lingkungan yang memberikan visibilitas semua pemangku kepentingan ke dalam kesehatan dan kinerja sistem.

Mengoptimalkan kluster Amazon EKS untuk AI/ML beban kerja menghadirkan tantangan pemantauan yang unik, terutama seputar manajemen memori GPU. Tanpa pemantauan yang tepat, organisasi sering menghadapi kesalahan out-of-memory (OOM), inefisiensi sumber daya, dan biaya yang tidak perlu. Untuk pelanggan EKS, pemantauan yang efektif memastikan kinerja yang lebih baik, ketahanan, dan biaya yang lebih rendah. Pendekatan holistik yang menggabungkan pemantauan GPU granular menggunakan NVIDIA DCGM Exporter (misalnya, memori GPU yang digunakan, memori GPU gratis), memantau dan mengoptimalkan penyajian inferensi untuk wawasan beban kerja terdistribusi dengan metrik asli mereka menggunakan kerangka kerja seperti Ray, VllM, dan wawasan tingkat aplikasi untuk metrik khusus.

Alat dan kerangka kerja

Alat dan kerangka kerja tertentu menawarkan out-of-the-box metrik asli untuk memantau AI/ML beban kerja, memungkinkan integrasi yang lebih mudah tanpa pengaturan khusus tambahan. Ini berfokus pada aspek kinerja seperti latensi, throughput, dan pembuatan token, yang sangat penting untuk penyajian inferensi dan pembandingan. Contohnya termasuk:

VllM: Mesin servis throughput tinggi untuk model bahasa besar (LLMs) yang menyediakan metrik asli seperti latensi permintaan dan penggunaan memori.
Ray: Kerangka kerja komputasi terdistribusi yang memancarkan metrik untuk beban kerja AI yang dapat diskalakan, termasuk waktu eksekusi tugas dan pemanfaatan sumber daya.
Hugging Face Text Generation Inference (TGI): Toolkit untuk menerapkan dan LLMs melayani, dengan metrik bawaan untuk kinerja inferensi.
NVIDIA genai-perf: Alat baris perintah untuk membandingkan model AI generatif, mengukur throughput, latensi, dan metrik khusus LLM, seperti permintaan yang diselesaikan dalam interval waktu tertentu.

Metode observabilitas

Kami merekomendasikan untuk menerapkan mekanisme observabilitas tambahan dengan salah satu cara berikut.

CloudWatch Wawasan Kontainer Jika organisasi Anda lebih menyukai alat asli AWS dengan pengaturan minimal, kami merekomendasikan CloudWatch Wawasan Kontainer. Ini terintegrasi dengan Eksportir NVIDIA DCGM untuk mengumpulkan metrik GPU dan menawarkan dasbor pra-bangun untuk wawasan cepat. Diaktifkan dengan menginstal add-on CloudWatch Observability di cluster Anda, Container Insights menyebarkan dan mengelola siklus hidup Eksportir NVIDIA DCGM yang mengumpulkan metrik GPU dari driver Nvidia dan memaparkannya. CloudWatch

Setelah onboard ke Container Insights, CloudWatch secara otomatis mendeteksi NVIDIA GPUs di lingkungan Anda, mengumpulkan metrik kesehatan dan kinerja penting NVIDIA Anda GPUs sebagai CloudWatch metrik dan membuatnya tersedia di dasbor yang dikurasi. out-of-the-box Selain itu, Ray dan Vllm dapat diintegrasikan dengan CloudWatch menggunakan CloudWatch Agen Terpadu untuk mengirim metrik. Ini menyederhanakan observabilitas di lingkungan EKS, memungkinkan tim untuk fokus pada penyetelan kinerja dan pengoptimalan biaya.

Untuk informasi selengkapnya, untuk melihat daftar lengkap metrik yang tersedia, lihat metrik Amazon EKS dan Kubernetes Container Insights. Lihat Dapatkan wawasan operasional untuk beban kerja GPU NVIDIA menggunakan Amazon CloudWatch Container Insights dan Mengoptimalkan respons AI: Panduan praktis untuk inferensi yang dioptimalkan dengan latensi Amazon Bedrock untuk implementasi terperinci.

Prometheus dan Grafana Terkelola Jika organisasi Anda merasa nyaman dengan alat sumber terbuka dan dasbor khusus, kami sarankan untuk menerapkan Prometheus dengan Eksportir NVIDIA DCGM dan Grafana untuk pemantauan asli Kubernetes dengan visualisasi lanjutan. Prometheus menggores metrik, dan Grafana menciptakan visualisasi tingkat lanjut.

Selain itu, Anda dapat menggunakan kerangka kerja open source seperti Ray dan Vllm untuk mengekspor metrik ke Prometheus (yang dapat divisualisasikan menggunakan Grafana), atau Anda dapat Connect ke sumber data AWS X-Ray, lalu membuat dasbor untuk melihat analitik, wawasan, atau jejak.

Untuk informasi selengkapnya, lihat Memantau beban kerja GPU di Amazon EKS menggunakan layanan sumber terbuka yang dikelola AWS untuk implementasi terperinci.

Pertimbangkan untuk Memantau Pelatihan Inti & Metrik Penyetelan Sempurna

Untuk metrik pelatihan inti untuk AI/ML beban kerja di EKS, pertimbangkan kombinasi metrik yang menunjukkan kesehatan dan kinerja klaster Amazon EKS Anda dan beban kerja pembelajaran mesin yang berjalan di dalamnya. Lihat Pengantar untuk mengamati beban kerja pembelajaran mesin di Amazon EKS untuk implementasi terperinci. Di bawah ini, kami memecah metrik yang kami rekomendasikan untuk dipantau.

Metrik Penggunaan Sumber Daya:

Penggunaan Memori CPU, Memori, GPU, dan GPU - Memantau metrik ini untuk beban kerja ML memungkinkan Anda memastikan sumber daya yang dialokasikan cukup dan mengidentifikasi peluang untuk pengoptimalan. Misalnya, melacak metrik sepertigpu_memory_usage_bytes, Anda dapat mengidentifikasi pola konsumsi memori, mendeteksi penggunaan puncak, dan menghitung persentil seperti persentil ke-95 (P95) untuk memahami tuntutan memori tertinggi selama pelatihan. Ini membantu mengoptimalkan model dan infrastruktur Anda untuk menghindari kesalahan OOM dan mengurangi biaya.
Pemanfaatan Sumber Daya Node dan Pod — Melacak penggunaan sumber daya di tingkat node dan pod membantu Anda mengidentifikasi pertentangan sumber daya dan potensi kemacetan. Misalnya, periksa apakah ada node yang terlalu banyak digunakan, yang dapat memengaruhi penjadwalan pod.
Perbandingan Pemanfaatan Sumber Daya dengan Permintaan dan Batas — Ini memberikan wawasan tentang apakah klaster Anda dapat menangani beban kerja saat ini dan mengakomodasi beban kerja masa depan. Misalnya, bandingkan penggunaan memori aktual dengan batas untuk menghindari out-of-memory kesalahan.
Metrik Internal dari Kerangka Kerja ML — Tangkap metrik pelatihan dan konvergensi internal dari kerangka kerja ML (TensorFlow, PyTorch), seperti kurva kerugian, laju pembelajaran, waktu pemrosesan batch, dan durasi langkah pelatihan—sering divisualisasikan dengan atau serupa. TensorBoard

Metrik Kinerja Model:

Akurasi, Presisi, Ingat, dan skor F1 — Ini sangat penting untuk memahami kinerja model ML Anda. Misalnya, setelah pelatihan, hitung skor F1 pada set validasi untuk menilai kinerja.
Metrik Khusus Bisnis dan KPIs — Tentukan dan lacak metrik yang terkait langsung dengan nilai bisnis inisiatif Anda. AI/ML Misalnya, dalam sistem rekomendasi, lacak peningkatan keterlibatan pengguna.
Melacak metrik ini dari waktu ke waktu — Ini membantu mengidentifikasi penurunan kinerja model. Misalnya, bandingkan metrik kinerja di seluruh versi model untuk melihat tren.

Kualitas Data dan Metrik Drift:

Sifat Statistik Data Input — Pantau ini dari waktu ke waktu untuk mendeteksi penyimpangan data atau anomali yang dapat memengaruhi kinerja model. Misalnya, lacak rata-rata fitur input untuk mendeteksi pergeseran.
Deteksi dan Peringatan Drift Data — Menerapkan mekanisme untuk mendeteksi dan memperingatkan secara otomatis tentang masalah kualitas data. Misalnya, gunakan tes untuk membandingkan data saat ini dengan data pelatihan dan waspada pada penyimpangan yang signifikan.

Metrik Latensi dan Throughput:

End-to-End Latensi Pipa Pelatihan ML — Pantau waktu yang dibutuhkan data untuk mengalir melalui seluruh jalur pelatihan. Misalnya, ukur total waktu dari konsumsi data hingga pembaruan model.
Throughput Pelatihan dan Tingkat Pemrosesan - Lacak volume data yang diproses selama pelatihan untuk memastikan efisiensi. Misalnya, pantau sampel positif dan negatif yang diproses per detik.
Checkpoint Restore Latency — Pantau waktu yang dibutuhkan untuk memuat pos pemeriksaan model yang disimpan dari lokasi penyimpanan (S3, EFS FSx , dll) kembali GPU/CPU ke memori saat melanjutkan pekerjaan, pulih dari kegagalan, atau menginisialisasi. Metrik ini secara langsung memengaruhi waktu pemulihan pekerjaan, kinerja start dingin, dan efisiensi jaringan pipa interferensi secara keseluruhan. Dalam layanan inferensi auto-scaling, pemuatan pos pemeriksaan yang lambat dapat menyebabkan penundaan start dingin dan pengalaman pengguna yang merendahkan. Metrik terkait ini juga biasa digunakan untuk meningkatkan pos pemeriksaan model: latensi waktu henti pos pemeriksaan, waktu deserialisasi model, ukuran pos pemeriksaan, dan jumlah kegagalan pemulihan pos pemeriksaan.
Durasi Permintaan Inferensi - Pantau waktu yang diperlukan untuk menyelesaikan permintaan inferensi. Ini adalah waktu dari permintaan awal yang diterima hingga respons lengkap dari model.
Token Throughput - Memantau waktu pemrosesan token untuk mengukur kinerja model dan mengoptimalkan keputusan penskalaan. Pemrosesan yang lambat dapat menunjukkan inefisiensi atau sumber daya yang kurang dimanfaatkan, berdampak pada efektivitas biaya. Melacak metrik seperti token dalam per detik dan token keluar per detik, di samping waktu pemrosesan, dapat membantu mengidentifikasi kemacetan kinerja, perlambatan, dan pendorong biaya.
Mengidentifikasi Kemacetan Kinerja — Gunakan metrik ini untuk menentukan area untuk pengoptimalan dalam proses pelatihan. Misalnya, menganalisis waktu yang dihabiskan dalam pemuatan data versus perhitungan model.

Tingkat Kesalahan dan Kegagalan:

Memantau kesalahan di seluruh pipeline ML — Ini termasuk preprocessing data, pelatihan model, dan inferensi. Misalnya, kesalahan log dalam pra-pemrosesan untuk mengidentifikasi masalah dengan cepat.
Mengidentifikasi dan menyelidiki kesalahan berulang — Ini membantu mempertahankan model berkualitas tinggi dan memastikan kinerja yang konsisten. Misalnya, analisis log untuk menemukan pola seperti data tertentu yang menyebabkan kegagalan.

Metrik Khusus Kubernetes dan EKS:

Metrik Status Cluster Kubernetes — Memantau kesehatan dan status berbagai objek Kubernetes, termasuk pod, node, dan bidang kontrol. Misalnya, gunakan alat seperti kubectl untuk memeriksa status pod.
Success/Failed Pipeline Runs - Lacak proses successful/failed pipeline, durasi pekerjaan, waktu penyelesaian langkah, dan kesalahan orkestrasi (misalnya, menggunakan peristiwa). Kubeflow/Mlflow/Argo
AWS Service Metrics — Lacak metrik untuk layanan AWS lain yang mendukung infrastruktur EKS Anda dan aplikasi yang berjalan di dalamnya. Misalnya, jika menggunakan Amazon S3, pantau ukuran bucket untuk melacak penggunaan penyimpanan.
Kubernetes Control Plane Metrics — Memantau server API, scheduler, controller manager, dan database etcd untuk masalah atau kegagalan kinerja. Misalnya, lacak latensi permintaan server API untuk responsif.

Dalam topik berikutnya, kami mendemonstrasikan pengumpulan data untuk beberapa metrik yang disebutkan di atas. Kami akan memberikan contoh dengan dua pendekatan yang direkomendasikan AWS: Wawasan CloudWatch Kontainer Asli AWS dan Prometheus Terkelola Amazon sumber terbuka dengan Grafana Terkelola Amazon. Anda akan memilih salah satu dari solusi ini berdasarkan kebutuhan observabilitas Anda secara keseluruhan. Lihat metrik Amazon EKS dan Kubernetes Container Insights untuk mengetahui daftar lengkap metrik Container Insights.

Pertimbangkan untuk Memantau Metrik Inferensi Online Waktu Nyata

Dalam sistem real-time, latensi rendah sangat penting untuk memberikan respons tepat waktu kepada pengguna atau sistem dependen lainnya. Latensi tinggi dapat menurunkan pengalaman pengguna atau melanggar persyaratan kinerja. Komponen yang mempengaruhi latensi inferensi termasuk waktu pemuatan model, waktu pra-pemrosesan, waktu prediksi aktual, waktu pasca-pemrosesan, waktu transmisi jaringan. Kami merekomendasikan pemantauan latensi inferensi untuk memastikan respons latensi rendah yang memenuhi perjanjian tingkat layanan (SLAs) dan mengembangkan metrik khusus untuk hal-hal berikut. Uji di bawah beban yang diharapkan, termasuk latensi jaringan, memperhitungkan permintaan bersamaan, dan uji dengan berbagai ukuran batch.

Time to First Token (TTFT) — Jumlah waktu dari saat pengguna mengirimkan permintaan hingga mereka menerima awal respons (kata pertama, token, atau potongan). Misalnya, di chatbots, Anda akan memeriksa berapa lama waktu yang dibutuhkan untuk menghasilkan bagian pertama dari output (token) setelah pengguna mengajukan pertanyaan.
End-to-End Latensi — Ini adalah total waktu dari saat permintaan diterima hingga saat respons dikirim kembali. Misalnya, ukur waktu dari permintaan ke respons.
Output Tokens Per Second (TPS) — Menunjukkan seberapa cepat model Anda menghasilkan token baru setelah mulai merespons. Misalnya, di chatbots, Anda akan melacak kecepatan pembuatan untuk model bahasa untuk teks dasar.
Tingkat Kesalahan - Melacak permintaan yang gagal, yang dapat menunjukkan masalah kinerja. Misalnya, pantau permintaan yang gagal untuk dokumen besar atau karakter tertentu.
Throughput — Mengukur jumlah permintaan atau operasi yang dapat ditangani sistem per unit waktu. Misalnya, lacak permintaan per detik untuk menangani beban puncak.

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/Vatau penggunaan cache sesi):

hit/miss Rasio cache — Untuk pengaturan inferensi yang memanfaatkan caching (K/V atau menyematkan cache), ukur seberapa sering cache membantu. Tingkat hit yang rendah dapat mengindikasikan konfigurasi cache suboptimal atau perubahan beban kerja, yang keduanya dapat meningkatkan latensi.

Melacak Penggunaan Memori GPU

Seperti yang dibahas dalam Pertimbangkan untuk Memantau Pelatihan Inti & Metrik Penyetelan Sempurna topik, penggunaan memori GPU sangat penting untuk mencegah kesalahan out-of-memory (OOM) dan memastikan pemanfaatan sumber daya yang efisien. Contoh berikut menunjukkan cara instrumen aplikasi pelatihan Anda untuk mengekspos metrik histogram khusus,gpu_memory_usage_bytes, dan menghitung penggunaan memori P95 untuk mengidentifikasi konsumsi puncak. Pastikan untuk menguji dengan pekerjaan pelatihan sampel (misalnya, menyempurnakan model transformator) di lingkungan pementasan.

Contoh Wawasan CloudWatch Kontainer Asli AWS

Sampel ini menunjukkan cara instrumen aplikasi pelatihan Anda untuk mengekspos gpu_memory_usage_bytes sebagai histogram menggunakan pendekatan AWS-native. Perhatikan bahwa AI/ML container Anda harus dikonfigurasi untuk memancarkan log terstruktur dalam format CloudWatch Embedded Metrics Format (EMF). CloudWatch log mem-parsing EMF dan menerbitkan metrik. Gunakan aws_embedded_metrics dalam aplikasi pelatihan Anda untuk mengirim log terstruktur dalam format EMF ke Log, yang mengekstrak metrik GPU. CloudWatch


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

Contoh Prometheus dan Grafana

Contoh ini menunjukkan cara instrumen aplikasi pelatihan Anda untuk mengekspos gpu_memory_usage_bytes` sebagai histogram menggunakan pustaka klien Prometheus dengan Python.


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

Durasi Permintaan Inferensi Lacak untuk Inferensi Online Waktu Nyata

Seperti yang dibahas dalam Pertimbangkan untuk Memantau Pelatihan Inti & Metrik Penyetelan Sempurna topik, latensi rendah sangat penting untuk memberikan respons tepat waktu kepada pengguna atau sistem dependen lainnya. Contoh berikut menunjukkan cara melacak metrik histogram kustominference_request_duration_seconds, yang diekspos oleh aplikasi inferensi Anda. Hitung latensi persentil ke-95 (P95) untuk fokus pada skenario terburuk, uji dengan permintaan inferensi sintetis (misalnya, melalui Locust) di lingkungan pementasan, dan tetapkan ambang peringatan (misalnya, > 500 ms) untuk mendeteksi pelanggaran SLA.

Contoh Wawasan CloudWatch Kontainer Asli AWS

Contoh ini menunjukkan cara membuat metrik histogram kustom dalam aplikasi inferensi Anda untuk inference_request_duration_seconds menggunakan AWS Embedded Metric Format. 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()

Contoh Prometheus dan Grafana

Contoh ini menunjukkan cara membuat metrik histogram kustom dalam aplikasi inferensi Anda untuk inference_request_duration_seconds menggunakan pustaka klien Prometheus dengan Python:


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)

Di Grafana, gunakan kueri histogram_quantile(0.95, sum(rate(inference_request_duration_seconds_bucket[5m])) by (le, pod)) untuk memvisualisasikan tren latensi P95. Untuk mempelajari lebih lanjut, lihat Dokumentasi Histogram Prometheus dan Dokumentasi Klien Prometheus.

Lacak Throughput Token untuk Inferensi Online Waktu Nyata

Seperti yang dibahas dalam Pertimbangkan untuk Memantau Pelatihan Inti & Metrik Penyetelan Sempurna topik, kami merekomendasikan pemantauan waktu pemrosesan token untuk mengukur kinerja model dan mengoptimalkan keputusan penskalaan. Contoh berikut menunjukkan cara melacak metrik histogram kustomtoken_processing_duration_seconds, yang diekspos oleh aplikasi inferensi Anda. Hitung durasi persentil ke-95 (P95) untuk menganalisis efisiensi pemrosesan, uji dengan beban permintaan simulasi (misalnya, 100 hingga 1000 permintaan/detik) dalam cluster non-produksi, dan sesuaikan pemicu KEDA untuk mengoptimalkan penskalaan.

Contoh Wawasan CloudWatch Kontainer Asli AWS

Contoh ini menunjukkan cara membuat metrik histogram kustom dalam aplikasi inferensi Anda untuk token_processing_duration_seconds menggunakan AWS Embedded Metric Format. CloudWatch Ini menggunakan dimensi () with a custom `get_duration_bucketfungsi `set_dimension untuk mengkategorikan durasi ke dalam ember (misalnya, “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

Contoh Prometheus dan Grafana

Contoh ini menunjukkan cara membuat metrik histogram kustom dalam aplikasi inferensi Anda untuk token_processing_duration_seconds menggunakan pustaka klien Prometheus dengan Python.


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)

Di Grafana, gunakan kueri histogram_quantile(0.95, sum(rate(token_processing_duration_seconds_bucket[5m])) by (le, pod))` untuk memvisualisasikan tren waktu pemrosesan P95. Untuk mempelajari lebih lanjut, lihat Dokumentasi Histogram Prometheus dan Dokumentasi Klien Prometheus.

Ukur Latensi Pemulihan Pos Pemeriksaan

Seperti yang dibahas dalam Pertimbangkan untuk Memantau Pelatihan Inti & Metrik Penyetelan Sempurna topik, latensi pos pemeriksaan adalah metrik penting selama beberapa fase siklus hidup model. Contoh berikut menunjukkan cara melacak metrik histogram kustomcheckpoint_restore_duration_seconds`, yang diekspos oleh aplikasi Anda. Hitung durasi persentil ke-95 (P95) untuk memantau kinerja pemulihan, uji dengan interupsi Spot di klaster non-produksi, dan atur ambang peringatan (misalnya, <30 detik) untuk mendeteksi penundaan.

Contoh Wawasan CloudWatch Kontainer Asli AWS

Contoh ini menunjukkan cara instrumen aplikasi batch Anda untuk mengekspos checkpoint_restore_duration_seconds sebagai histogram menggunakan Insights: 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")

Contoh Prometheus dan Grafana

Contoh ini menunjukkan cara instrumen aplikasi batch Anda untuk mengekspos checkpoint_restore_duration_seconds sebagai histogram menggunakan pustaka klien Prometheus dengan Python:


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

Di Grafana, gunakan kueri histogram_quantile(0.95, sum(rate(checkpoint_restore_duration_seconds_bucket[5m]) by (le)) untuk memvisualisasikan tren latensi pemulihan P95. Untuk mempelajari lebih lanjut, lihat Dokumentasi Histogram Prometheus dan Dokumentasi Klien Prometheus.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Penyimpanan

Performa