Identifikasi ambang metrik penskalaan untuk inferensi AI

Bagian ini menunjukkan cara memuat uji server inferensi vLLM di Amazon EKS untuk mengidentifikasi kapan server tersebut menjadi jenuh. Gunakan hasil uji beban untuk mengonfigurasi kedalaman antrian dan ambang latensi untuk penskalaan otomatis horizontal di Inferensi AI skala otomatis dengan HPA dan KEDA bagian selanjutnya.

Panduan ini menggunakan alat-alat berikut:

Prasyarat

Bagian ini dibangun di atas dua bagian sebelumnya dalam dokumentasi. Selesaikan keduanya sebelum Anda mulai:

Konfirmasikan setiap item di bawah ini sebelum Anda mulai, dan lengkapi bagian yang ditautkan terlebih dahulu jika pemeriksaan gagal.

Jika Anda membuka terminal baru, tetapkan nama cluster dan wilayah yang Anda gunakan sebelumnya:

export CLUSTER_NAME=ai-eks-docs
export AWS_REGION=us-east-2

Tangkap nama bucket model Amazon S3 yang dibuat dalam langkah-langkah Peng aturan Cluster. Generator beban meneruskan nilai ini ke vLLm.

MODEL_BUCKET=$(aws s3api list-buckets \
  --query "Buckets[?starts_with(Name, '${CLUSTER_NAME}-models-')].Name | [0]" \
  --output text)
echo "Model bucket: ${MODEL_BUCKET}"

Konfirmasikan tumpukan pemantauan sedang berjalan

kube-prometheus-stack dari pengaturan Monit oring berjalan di namespace. monitoring

kubectl get pods -n monitoring

Polong Prometheus dan Grafana harus: Running

NAME                                              READY   STATUS    RESTARTS   AGE
kube-prometheus-stack-grafana-6f9c8b7d5c-2xk9p    3/3     Running   0          3h
kube-prometheus-stack-operator-7b8c9d6f4-q4m7n    1/1     Running   0          3h
prometheus-kube-prometheus-stack-prometheus-0     2/2     Running   0          3h

Jika ini hilang, selesaikan pengaturan Pem antauan sebelum melanjutkan.

Konfirmasikan model vLLM sedang berjalan

Pener vllm-inference-app apan dan vllm-inference-svc Layanan dari Model Load & Serve berjalan di default namespace.

kubectl get deployment vllm-inference-app

Deployment harus dilaporkan 1/1 siap:

NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
vllm-inference-app   1/1     1            1           3h

Jika Deployment hilang atau belum siap, selesaikan Load & Serve Model s sebelum melanjutkan.

Akses Grafana

Anda menonton uji beban di dasbor vLLM yang telah dimuat sebelumnya, jadi pastikan penyeimbang beban Grafana yang Anda atur di bagian Akses Grafana dapat dijang kau. Cetak URL-nya:

echo "http://$(kubectl get ingress kube-prometheus-stack-grafana -n monitoring -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')"

Buka URL di browser Anda dan masuk dengan nama pengguna admin dan kata sandi dari perintah berikut:

kubectl --namespace monitoring get secrets kube-prometheus-stack-grafana -o jsonpath="{.data.admin-password}" | base64 -d ; echo

Konfirmasikan bahwa vLLM ada ServiceMonitor

Yang dibuat dalam langkah Monitor vLLM vllm-inference-app ServiceMonitor, berjalan di default namespace dan memberi tahu Prometheus di mana harus mengikis metrik vLLM.

kubectl get servicemonitor vllm-inference-app

Keluaran yang diharapkan

NAME                 AGE
vllm-inference-app   3h

Jika hilang, selesaikan langkah Monitor vLLM.

Langkah 1: Panaskan GPU

Meskipun model dimuat ke dalam memori GPU dan replika melaporkan Siap, permintaan pertama membutuhkan waktu lebih lama daripada yang berikutnya karena vLLM dan GPU selesai menginisialisasi pada kesimpulan pertama. vLLM menangkap grafik CUDA, mengkompilasi dan menyetel otomatis kernel GPU, dan mengalokasikan kumpulan memori cache KV, sementara GPU meningkatkan kecepatan clock dari idle ke rentang dorongannya.

Ini adalah biaya satu kali, jadi mengukur ambang batas sebelum pemanasan mencatat pekerjaan startup alih-alih penyajian kondisi mapan. Pemanasan berikut mengirimkan 100 permintaan berurutan untuk menyelesaikan inisialisasi ini, sehingga uji beban yang mengikuti mengukur kapasitas kondisi mapan.

Pertama, buat ConfigMap yang menampung skrip pemanasan (warmup.js). Skrip membaca model target dari variabel MODEL lingkungan, yang ditetapkan oleh Job dari MODEL_BUCKET nilai yang Anda tangkap sebelumnya:

cat << 'EOF' | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: vllm-warmup-script
  namespace: default
data:
  warmup.js: |
    import http from 'k6/http';

    export default function () {
      const payload = JSON.stringify({
        model: __ENV.MODEL,
        prompt: 'Write a brief technical explanation about cloud computing concepts.',
        max_tokens: 100,
        temperature: 0.7,
      });
      const params = { headers: { 'Content-Type': 'application/json' }, timeout: '240s' };
      http.post('http://vllm-inference-svc:8000/v1/completions', payload, params);
    }
EOF

Kemudian jalankan Pekerjaan pemanasan. Satu klien mengirimkan 100 permintaan berurutan:

cat << EOF | kubectl apply -f -
apiVersion: batch/v1
kind: Job
metadata:
  name: vllm-warmup
  namespace: default
spec:
  backoffLimit: 0
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: k6
          image: grafana/k6:latest
          env:
            - name: MODEL
              value: "s3://${MODEL_BUCKET}/Ministral-3-8B-Instruct-2512/"
          args: ["run", "--vus", "1", "--iterations", "100", "/scripts/warmup.js"]
          volumeMounts:
            - name: script
              mountPath: /scripts
      volumes:
        - name: script
          configMap:
            name: vllm-warmup-script
EOF

Tunggu hingga pemanasan selesai (butuh beberapa menit):

kubectl wait --for=condition=complete job/vllm-warmup --timeout=600s

Buka Grafana (buka nama host penyeimbang beban; lihat Akses Grafana untuk detailnya) dan arahkan ke Dasbor> Pemantauan GPU> Peng ujian Kinerja - Analisis Beban vLLM. Panel Tingkat Permintaan vLLM menunjukkan ledakan lalu lintas pemanasan. Panel VllM Average Latency menunjukkan bahwa permintaan pertama lebih lambat, yang merupakan biaya pemanasan GPU satu kali.

Dasbor vLLM menunjukkan efek pemanasan GPU pada latensi

Kemudian hapus Pekerjaan Pemanasan:

kubectl delete job vllm-warmup

Langkah 2: Kirim beban dengan meningkatkan tarif permintaan

Pada langkah ini, Anda menjalankan uji beban yang mengirimkan permintaan ke replika vLLM tunggal pada tingkat yang meningkat: 10, 20, 30, 40, 50, 60, dan 70 permintaan per detik. Ini mensimulasikan meningkatnya permintaan pengguna. Pengujian menggunakan k6 dalam model tingkat kedatangan konstan, di mana variabel TARGET_RPS lingkungan menetapkan tingkat permintaan target. Setiap kecepatan berjalan selama 60 detik untuk memungkinkan metrik stabil, diikuti dengan jeda 30 detik sebelum kenaikan tarif berikutnya.

Tujuan dari pengujian ini adalah untuk mengidentifikasi titik saturasi, yang merupakan tingkat permintaan di mana replika tunggal tidak dapat lagi mengikuti permintaan yang masuk. Anda memantau kedalaman antrian (vllm:num_requests_waiting) dan latensi ujung ke ujung (vllm:e2e_request_latency_seconds). Meningkatkan kedalaman antrian dan latensi menunjukkan bahwa replika mendekati saturasi.

Pertama, buat ConfigMap yang memegang skrip uji beban k6 (). script.js Skrip membaca model target dari variabel MODEL lingkungan, yang ditetapkan setiap pod dari MODEL_BUCKET nilai yang Anda tangkap sebelumnya:

cat << 'EOF' | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: vllm-loadtest-script
  namespace: default
data:
  script.js: |
    import http from 'k6/http';

    // Dictionary of 10-letter words for variation (prevents prompt caching)
    const words = [
      'revolution', 'technology', 'javascript', 'kubernetes', 'basketball',
      'strawberry', 'watermelon', 'blackberry', 'throughout', 'background',
      'playground', 'understand', 'everything', 'protection', 'complexity'
    ];

    export const options = {
      noConnectionReuse: true,
      scenarios: {
        constant_request_rate: {
          executor: 'constant-arrival-rate',
          rate: __ENV.TARGET_RPS || 10,  // Overridden by TARGET_RPS env var
          timeUnit: '1s',
          duration: __ENV.DURATION || '60s',  // Overridden by DURATION env var
          preAllocatedVUs: 50,
          maxVUs: 500,
        },
      },
    };

    export default function () {
      const randomWord = words[Math.floor(Math.random() * words.length)];
      const payload = JSON.stringify({
        model: __ENV.MODEL,
        prompt: `Starting with the word "${randomWord}", write a brief technical explanation about cloud computing concepts. Cover containerization, orchestration, and scalability in about 80 words.`,
        max_tokens: 100,
        temperature: 0.7,
      });
      const params = { headers: { 'Content-Type': 'application/json' }, timeout: '240s' };
      http.post('http://vllm-inference-svc:8000/v1/completions', payload, params);
    }
EOF

Kemudian jalankan uji beban pada setiap tingkat permintaan. Loop berikut mengirimkan Pekerjaan terpisah untuk setiap tarif:

for RPS in 10 20 30 40 50 60 70; do
  echo "=== Testing at ${RPS} req/s ==="
  cat << EOF | kubectl apply -f -
apiVersion: batch/v1
kind: Job
metadata:
  name: vllm-loadtest-${RPS}
  namespace: default
  labels:
    app: vllm-loadtest
spec:
  backoffLimit: 0
  template:
    metadata:
      labels:
        app: vllm-loadtest
    spec:
      restartPolicy: Never
      containers:
        - name: k6
          image: grafana/k6:latest
          env:
            - name: K6_PROMETHEUS_RW_SERVER_URL
              value: "http://kube-prometheus-stack-prometheus.monitoring.svc.cluster.local:9090/api/v1/write"
            - name: MODEL
              value: "s3://${MODEL_BUCKET}/Ministral-3-8B-Instruct-2512/"
            - name: TARGET_RPS
              value: "${RPS}"
            - name: DURATION
              value: "60s"
          args: ["run", "-o", "experimental-prometheus-rw", "/scripts/script.js"]
          volumeMounts:
            - name: script
              mountPath: /scripts
      volumes:
        - name: script
          configMap:
            name: vllm-loadtest-script
EOF
  kubectl wait --for=condition=complete job/vllm-loadtest-${RPS} --timeout=180s
  sleep 30
done

Tonton metrik di Grafana saat pengujian berjalan (lihat Langkah 3). Setiap tingkat membuat Job (vllm-loadtest-10throughvllm-loadtest-70) sendiri, sehingga Anda dapat memeriksa proses apa pun dengankubectl get jobs. Setelah selesai, hapus semua Load-test Jobs:

kubectl delete jobs -l app=vllm-loadtest

Langkah 3: Mengukur metrik di bawah beban

Saat beban berjalan, perhatikan dua metrik yang mendorong penskalaan otomatis:

Lihat metrik di Grafana

Buka Grafana (buka nama host penyeimbang beban dan masuk sebagaiadmin; lihat Akses Grafana untuk detailnya) dan arahkan ke Dasbor> Pemantauan GPU> Peng ujian Kinerja - Analisis Beban VllM. Dasbor ini membaca dari Amazon Managed Service for Prometheus, sehingga panel dapat menunda status langsung hingga satu menit karena metrik ditulis dari jarak jauh dalam batch.

Pengujian Kinerja - Dasbor Analisis Beban vLLm selama uji beban

Berdasarkan hasil uji beban, kedalaman antrian tetap mendekati nol melalui 50 permintaan bersamaan. Kemudian meningkat tajam pada 60 permintaan bersamaan, memuncak antara sekitar 150 dan 350 permintaan antri. Pada saat yang sama, latensi ujung ke ujung p95 naik dari baseline stabil sekitar 2,5 detik menjadi 6-10 detik. Perilaku ini menunjukkan timbulnya kelebihan beban berkelanjutan dan menyarankan bahwa penskalaan otomatis harus dimulai sebelum kedalaman antrian mencapai tingkat yang menyebabkan latensi mendekati 10 detik. Titik awal praktis adalah memicu penskalaan ketika kedalaman antrian melebihi 25 permintaan selama 30-60 detik. Sebagai sinyal sekunder, Anda juga dapat memicu penskalaan ketika latensi ujung ke ujung p95 melebihi 5 detik selama interval yang sama. Ini membantu memperhitungkan pola beban kerja di mana latensi meningkat sebelum kedalaman antrian menumpuk.

Langkah 4: Pilih metrik dan ambang batas untuk diskalakan

Menggunakan metrik yang diamati pada titik saturasi, Anda menentukan ambang batas yang digunakan untuk mengonfigurasi penskalaan otomatis di bagian berikutnya.

Nilai-nilai ini memberikan titik awal untuk mengonfigurasi penskalaan otomatis di bagian berikutnya. Ulangi proses ini untuk model, jenis GPU, dan pola permintaan Anda sendiri untuk menentukan ambang batas yang sesuai untuk penerapan Anda.