Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Observabilitas

Pemantauan dan Observabilitas

Metrik GPU Dijelaskan

Metrik Pemanfaatan GPU menunjukkan apakah GPU menjalankan pekerjaan apa pun selama jendela sampel. Metrik ini menangkap persentase waktu GPU mengeksekusi setidaknya satu instruksi, tetapi tidak mengungkapkan seberapa efisien GPU menggunakan perangkat kerasnya. GPU berisi beberapa Streaming Multiprocessors (SMs), yang merupakan unit pemrosesan paralel yang menjalankan instruksi. Pembacaan pemanfaatan 100% dapat berarti GPU menjalankan beban kerja paralel yang berat di semua miliknya SMs, atau itu bisa berarti satu instruksi kecil mengaktifkan GPU selama periode sampel. Untuk memahami pemanfaatan aktual, Anda perlu memeriksa metrik GPU di berbagai tingkatan arsitektur perangkat keras. Setiap Multiprosesor Streaming dibangun dari tipe inti yang berbeda, dan setiap lapisan memperlihatkan karakteristik kinerja yang berbeda. Metrik tingkat atas (Pemanfaatan GPU, Pemanfaatan Memori, Daya GPU, dan Suhu GPU, terlihat melalui nvidia-smi) menunjukkan apakah perangkat aktif. Metrik yang lebih dalam (pemanfaatan SM, Aktivitas SM, dan penggunaan inti tensor) mengungkapkan seberapa efisien GPU menggunakan sumber dayanya.

Targetkan penggunaan daya GPU yang tinggi

Kapasitas komputasi GPUs limbah yang kurang dimanfaatkan dan meningkatkan biaya karena beban kerja gagal melibatkan semua komponen GPU secara bersamaan. Untuk AI/ML beban kerja di Amazon EKS, lacak penggunaan daya GPU sebagai proxy untuk mengidentifikasi aktivitas GPU yang sebenarnya. Pemanfaatan GPU melaporkan persentase waktu GPU mengeksekusi kernel apa pun, tetapi tidak mengungkapkan apakah Multiprosesor Streaming, pengontrol memori, dan inti tensor semuanya aktif pada saat yang bersamaan. Penggunaan daya memperlihatkan celah ini karena perangkat keras yang terlibat penuh menarik daya secara signifikan lebih banyak daripada perangkat keras yang menjalankan kernel ringan atau duduk diam di antara tugas. Bandingkan daya tarik dengan daya desain termal (TDP) GPU untuk melihat kurangnya pemanfaatan, kemudian selidiki apakah beban kerja Anda terhambat oleh preprocessing CPU, I/O jaringan, atau ukuran batch yang tidak efisien.

Siapkan CloudWatch Container Insights di Amazon EKS untuk mengidentifikasi pod, node, atau beban kerja dengan konsumsi daya GPU rendah. Alat ini terintegrasi langsung dengan Amazon EKS dan memungkinkan Anda memantau konsumsi daya GPU dan menyesuaikan penjadwalan pod atau jenis instance saat penggunaan daya turun di bawah level target Anda. Jika Anda membutuhkan visualisasi lanjutan atau dasbor khusus, gunakan Eksportir DCGM NVIDIA dengan Prometheus dan Grafana untuk pemantauan asli Kubernetes. Keduanya mendekati metrik NVIDIA kunci permukaan seperti nvidia_smi_power_draw (konsumsi daya GPU) dan nvidia_smi_temperature_gpu (suhu GPU). Untuk daftar metrik, jelajahi https://docs.aws.amazon.com/AmazonCloudWatch/ latest/monitoring/CloudWatch -Agent-NVIDIA-GPU.htm. Carilah pola seperti penggunaan daya rendah secara konsisten selama jam-jam tertentu atau untuk pekerjaan tertentu. Tren ini membantu Anda mengidentifikasi tempat untuk mengkonsolidasikan beban kerja atau menyesuaikan alokasi sumber daya.

Batas sumber daya statis di Kubernetes (seperti jumlah CPU, memori, dan GPU) sering menyebabkan penyediaan berlebih atau kurang dimanfaatkan, terutama untuk beban kerja dinamis seperti inferensi di mana permintaan berfluktuasi. AI/ML Analisis tren pemanfaatan Anda dan konsolidasikan beban kerja menjadi lebih sedikit. GPUs Pastikan setiap GPU mencapai pemanfaatan penuh sebelum Anda mengalokasikan yang tambahan. Pendekatan ini mengurangi limbah dan menurunkan biaya. Untuk panduan terperinci tentang mengoptimalkan strategi penjadwalan dan berbagi, lihat praktik terbaik EKS Compute and Autoscaling

Observabilitas dan Metrik

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

AI/ML Layanan modern membutuhkan koordinasi lintas infrastruktur, pemodelan, dan logika aplikasi. Insinyur platform mengelola infrastruktur dan tumpukan observabilitas. Mereka mengumpulkan, menyimpan, dan memvisualisasikan metrik. AI/ML insinyur menentukan metrik spesifik model dan memantau kinerja di bawah berbagai beban dan distribusi data. Pengembang aplikasi mengkonsumsi APIs, merutekan permintaan, dan melacak metrik tingkat layanan dan interaksi pengguna. Tanpa praktik observabilitas terpadu, tim-tim ini bekerja dalam silo dan kehilangan sinyal kritis tentang kesehatan dan kinerja sistem. Membangun visibilitas bersama di seluruh lingkungan memastikan semua pemangku kepentingan dapat mendeteksi masalah sejak dini dan mempertahankan layanan yang andal.

Mengoptimalkan kluster Amazon EKS untuk AI/ML beban kerja menghadirkan tantangan pemantauan yang unik, terutama seputar manajemen memori GPU. Tanpa pemantauan yang tepat, organisasi menghadapi kesalahan out-of-memory (OOM), inefisiensi sumber daya, dan biaya yang tidak perlu. Pemantauan yang efektif memastikan kinerja yang lebih baik, ketahanan, dan biaya yang lebih rendah untuk pelanggan EKS. Gunakan pendekatan holistik yang menggabungkan tiga lapisan pemantauan. Pertama, pantau metrik GPU granular menggunakan NVIDIA DCGM Exporter untuk melacak penggunaan daya GPU, suhu GPU, aktivitas SM, hunian SM, dan kesalahan XID. Kedua, pantau kerangka kerja penyajian inferensi seperti Ray dan VllM untuk mendapatkan wawasan beban kerja terdistribusi melalui metrik asli mereka. Ketiga, kumpulkan wawasan tingkat aplikasi untuk melacak metrik kustom khusus untuk beban kerja Anda. Pendekatan berlapis ini memberi Anda visibilitas dari pemanfaatan perangkat keras melalui kinerja aplikasi.

Alat dan kerangka kerja

Beberapa alat dan kerangka kerja menyediakan out-of-the-box metrik asli untuk memantau AI/ML beban kerja. Metrik bawaan ini menghilangkan kebutuhan akan instrumentasi khusus dan mengurangi waktu penyiapan. Metrik berfokus pada aspek kinerja seperti latensi, throughput, dan pembuatan token, yang sangat penting untuk penyajian inferensi dan pembandingan. Menggunakan metrik asli memungkinkan Anda untuk segera memulai pemantauan tanpa membuat pipeline koleksi khusus.

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 Anda menginstal Container Insights, CloudWatch secara otomatis mendeteksi NVIDIA GPUs di lingkungan Anda dan mengumpulkan metrik kesehatan dan kinerja yang penting. Metrik ini muncul di dasbor yang out-of-the-box dikuratori. Anda juga dapat mengintegrasikan Ray dan Vllm dengan CloudWatch menggunakan CloudWatch Agen Terpadu untuk mengirim metrik asli mereka. Pendekatan terpadu ini menyederhanakan observabilitas di lingkungan EKS dan memungkinkan tim fokus pada penyetelan kinerja dan pengoptimalan biaya alih-alih membangun infrastruktur pemantauan.

Untuk daftar lengkap metrik yang tersedia, lihat metrik Amazon EKS dan Kubernetes Container Insights. Untuk step-by-step panduan penerapan pemantauan GPU, lihat Dapatkan wawasan operasional untuk beban kerja GPU NVIDIA menggunakan Amazon CloudWatch Container Insights. Untuk contoh praktis mengoptimalkan latensi inferensi, lihat Mengoptimalkan respons AI: Panduan praktis untuk inferensi yang dioptimalkan dengan latensi Amazon Bedrock.

Prometheus dan Grafana Terkelola Jika organisasi Anda membutuhkan dasbor yang disesuaikan dan kemampuan visualisasi tingkat lanjut, terapkan Prometheus dengan Eksportir DCGM NVIDIA dan Grafana untuk pemantauan asli Kubernetes. Prometheus menggores dan menyimpan metrik GPU dari eksportir DCGM, sementara Grafana memberikan visualisasi yang fleksibel dan kemampuan peringatan. Pendekatan ini memberi Anda kontrol lebih besar atas desain dasbor dan retensi metrik dibandingkan dengan CloudWatch Wawasan Kontainer.

Anda dapat memperluas tumpukan pemantauan ini dengan mengintegrasikan kerangka kerja sumber terbuka seperti Ray dan Vllm Ray dan VllM untuk mengekspor metrik asli mereka ke Prometheus. Anda juga dapat menghubungkan Grafana ke sumber data AWS X-Ray untuk memvisualisasikan jejak terdistribusi dan mengidentifikasi kemacetan kinerja di seluruh pipeline inferensi Anda. Kombinasi ini memberikan end-to-end visibilitas dari metrik tingkat GPU melalui alur permintaan tingkat aplikasi.

Untuk step-by-step panduan tentang penerapan tumpukan pemantauan ini, lihat Memantau beban kerja GPU di Amazon EKS menggunakan layanan sumber terbuka yang dikelola AWS.

Pertimbangkan untuk Memantau Pelatihan Inti & Metrik Penyetelan Sempurna

Pantau metrik pelatihan inti untuk melacak kesehatan dan kinerja klaster Amazon EKS Anda dan beban kerja pembelajaran mesin yang berjalan di dalamnya. Beban kerja pelatihan memiliki persyaratan pemantauan yang berbeda dari beban kerja inferensi karena mereka berjalan untuk waktu yang lama, mengkonsumsi sumber daya secara berbeda, dan memerlukan visibilitas ke dalam konvergensi model dan efisiensi pipa data. Metrik di bawah ini membantu Anda mengidentifikasi kemacetan, mengoptimalkan alokasi sumber daya, dan memastikan pekerjaan pelatihan berhasil diselesaikan. Untuk step-by-step panduan dalam menerapkan pendekatan pemantauan ini, lihat Pengantar untuk mengamati beban kerja pembelajaran mesin di Amazon EKS.

Metrik Penggunaan Sumber Daya

Pantau metrik penggunaan sumber daya untuk memvalidasi bahwa sumber daya Anda dikonsumsi dengan benar. Metrik ini membantu Anda mengidentifikasi kemacetan dan akar penyebab masalah kinerja.

Metrik Kinerja Model

Pantau metrik kinerja model untuk memvalidasi bahwa proses pelatihan Anda menghasilkan model yang memenuhi akurasi dan persyaratan bisnis. Metrik ini membantu Anda menentukan kapan harus menghentikan pelatihan, membandingkan versi model, dan mengidentifikasi penurunan kinerja.

Kualitas Data dan Metrik Drift

Pantau kualitas data dan metrik drift untuk memastikan data pelatihan Anda tetap konsisten dan representatif. Penyimpangan data dapat menyebabkan kinerja model menurun seiring waktu, sementara masalah kualitas data dapat mencegah model konvergen atau menghasilkan hasil yang tidak dapat diandalkan.

Metrik Latensi dan Throughput

Pantau metrik latensi dan throughput untuk mengidentifikasi hambatan dalam jalur pelatihan Anda dan mengoptimalkan pemanfaatan sumber daya. Metrik ini membantu Anda memahami di mana waktu dihabiskan selama pelatihan dan di mana harus memfokuskan upaya pengoptimalan.

Tingkat Kesalahan dan Kegagalan

Pantau tingkat kesalahan dan kegagalan di seluruh jalur pelatihan Anda untuk menjaga keandalan dan mencegah sumber daya komputasi yang terbuang. Kesalahan yang tidak terdeteksi dapat menyebabkan pekerjaan pelatihan gagal secara diam-diam, menghasilkan model yang tidak valid, atau membuang waktu berjam-jam GPU sebelum Anda melihat masalah.

Metrik Khusus Kubernetes dan EKS

Pantau metrik Kubernetes dan EKS untuk memastikan infrastruktur klaster Anda tetap sehat dan dapat mendukung beban kerja pelatihan Anda. Metrik ini membantu Anda mendeteksi masalah infrastruktur sebelum menyebabkan kegagalan pekerjaan pelatihan atau penurunan kinerja.

Aplikasi dan Log Instance

Kumpulkan dan analisis log aplikasi dan instance untuk mendiagnosis masalah yang tidak dapat dijelaskan oleh metrik saja. Log memberikan konteks terperinci tentang kesalahan, perubahan status, dan peristiwa sistem yang membantu Anda memahami mengapa pekerjaan pelatihan gagal atau berkinerja buruk. Mengkorelasikan log dengan metrik memungkinkan Anda menentukan akar penyebab lebih cepat.

Bagian berikut menunjukkan cara mengumpulkan metrik yang dijelaskan di atas menggunakan dua pendekatan yang direkomendasikan AWS: Wawasan CloudWatch Kontainer dan Prometheus Amazon Managed Prometheus Amazon Managed Prometheus dengan Grafana yang Dikelola Amazon. Pilih CloudWatch Container Insights jika Anda lebih suka alat asli AWS dengan pengaturan minimal dan dasbor pra-bangun. Pilih Prometheus yang Dikelola Amazon dengan Grafana Terkelola Amazon jika Anda memerlukan dasbor yang disesuaikan, kemampuan visualisasi lanjutan, atau ingin berintegrasi dengan infrastruktur pemantauan berbasis Prometheus yang ada. Untuk daftar lengkap metrik Container Insights yang tersedia, lihat metrik Amazon EKS dan Kubernetes 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.

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

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.

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 cluster 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.