Dalam tutorial ini, Anda mengonfigurasi perutean sadar beban pada Application Load Balancer (ALB) Edisi Ekstensibel untuk mengoptimalkan distribusi lalu lintas bagi layanan inferensi AI generatif. Dengan mengumpulkan metrik backend secara real-time—seperti panjang antrian permintaan, pemanfaatan cache GPU, dan jumlah permintaan yang sedang berjalan—ALB mengarahkan permintaan ke replika dengan beban kerja lebih ringan, sehingga mengurangi latensi inferensi dan meningkatkan throughput keseluruhan.
Skenario
Perutean sadar beban cocok untuk skenario di mana instans backend memiliki perbedaan beban signifikan, biaya permintaan tidak merata, serta sensitivitas latensi yang tinggi. Skenario khas meliputi:
Layanan inferensi AI generatif — Permintaan inferensi LLM sangat bervariasi dalam hal biaya. Memori GPU, pemanfaatan cache KV, dan status antrian berfluktuasi secara real-time di berbagai instans. Perutean sadar beban mengirimkan permintaan ke instans dengan beban kerja lebih ringan, mencegah akumulasi pada instans yang kelebihan beban, serta mengurangi waktu hingga token pertama (TTFT) dan latensi ekor.
Beban backend tidak merata — Saat tugas-tugas berbiaya tinggi menyebabkan beberapa instans menjadi sangat sibuk, algoritma penjadwalan statis menurunkan performa pada instans tersebut. Perutean sadar beban mendeteksi beban secara real-time dan secara dinamis menghindari instans yang sangat sibuk, sehingga memperbaiki latensi ekor akibat ketidakseimbangan.
Kluster inferensi elastis berkonkurensi tinggi — Saat backend merupakan replika inferensi yang dideploy secara batch dalam kluster kontainer ACK atau ACS, perutean sadar beban mengoptimalkan distribusi permintaan di bawah tekanan tinggi pada kluster secara keseluruhan, mengurangi antrean ekstrem, dan meningkatkan throughput keseluruhan.
Arsitektur
Setelah permintaan klien mencapai instans ALB Edisi Ekstensibel, aturan pengalihan mengarahkan lalu lintas ke grup server yang dikaitkan dengan komponen perutean sadar beban. Node pengalihan ALB secara berkala mengumpulkan metrik real-time dari setiap backend dalam grup server. Komponen perutean sadar beban memberi skor dan mengurutkan backend berdasarkan metrik tersebut, dengan memprioritaskan backend yang memiliki beban paling rendah (skor terbaik). Jika beberapa backend memiliki skor optimal yang mirip, penjadwalan sekunder menggunakan algoritma weighted round-robin (WRR).
Instans ALB Edisi Ekstensibel — Menyediakan load balancing dan pengalihan lalu lintas. Node pengalihan juga menangani pengumpulan metrik backend.
Grup server — Mendukung tipe server dan tipe IP, serta dapat mencakup backend kontainer ACK atau ACS. Algoritma penjadwalan harus diatur ke weighted round-robin dan grup harus dikaitkan dengan Service Extension yang berisi komponen perutean sadar beban.
Service Extension — Menampung komponen perutean sadar beban. Berlaku setelah dikaitkan ke grup server.
Komponen perutean sadar beban — Plugin yang dibangun ke dalam rantai pengalihan ALB yang memberi skor dan mengurutkan backend berdasarkan metrik yang dikumpulkan oleh node pengalihan, lalu menghasilkan backend optimal untuk penjadwalan.
Layanan inferensi backend — Mengekspos metrik inferensi dalam format Prometheus (saat ini mendukung framework vLLM) untuk dikumpulkan oleh ALB.
Prinsip penjadwalan
Pengumpulan metrik — Node pengalihan secara berkala mengirim permintaan HTTP ke path pengumpulan backend (default
/metrics) untuk mengumpulkan metrik. Saluran pengumpulan ini terpisah dari saluran pemeriksaan kesehatan. Jika pengumpulan metrik gagal untuk backend tertentu, backend tersebut dihapus dari penjadwalan. Jika pengumpulan gagal untuk semua backend, sistem kembali menggunakan weighted round-robin.Pemberian skor dan pengurutan — Setiap metrik penilaian dinormalisasi di seluruh himpunan backend, lalu diberi bobot dan dijumlahkan sesuai bobot yang dikonfigurasi untuk menghasilkan skor beban bagi setiap backend. Nilai metrik yang lebih rendah menunjukkan backend yang lebih idle, dan backend dengan skor lebih baik dipilih terlebih dahulu.
Penjadwalan sekunder — Jika hasil pengurutan berisi beberapa backend dengan skor optimal yang mirip (tumpang tindih), weighted round-robin memilih di antara backend tersebut berdasarkan bobot. Jika tidak ada tumpang tindih, backend dengan skor terbaik dipilih langsung.
Perutean sadar beban mendukung metrik keputusan berikut secara default:
Metric | Type | Description | vLLM metric |
TotalQueuedRequests (panjang antrian permintaan) | Gauge | Jumlah permintaan yang saat ini dalam antrian dan menunggu untuk diproses. |
|
KVCacheUtilization (pemanfaatan cache GPU) | Gauge | Persentase pemanfaatan cache KV saat ini yang digunakan untuk menyimpan hasil inferensi antara. |
|
RunningRequests (jumlah permintaan yang sedang berjalan) | Gauge | Jumlah permintaan yang sedang diproses. |
|
Prasyarat
Anda telah memperoleh akses pratinjau publik ALB Edisi Ekstensibel.
Anda telah membuat VPC (
VPC1) di wilayah China (Shanghai), dengan vSwitchVSW1di Zona B dan vSwitchVSW2di Zona F.Anda telah membuat kluster ACK dengan node GPU di
VPC1dan men-deploy layanan inferensi yang mengekspos metrik inferensi dalam format Prometheus. Topik ini menggunakanDeepSeek-R1-Distill-Qwen-1.5Byang dideploy dengan vLLM sebagai contoh. Layanan ini mendengarkan pada port8000dan mengekspos metrik di/metrics.
Prosedur
1. (Opsional) Deploy layanan inferensi contoh
Langkah ini menyediakan layanan inferensi vLLM contoh yang mengekspos metrik Prometheus (menggunakan DeepSeek-R1-Distill-Qwen-1.5B sebagai contoh, dengan tipe instans ECS ecs.gn7i-c16g1.4xlarge). Layanan ini digunakan untuk pengumpulan metrik dan penjadwalan perutean sadar beban pada langkah-langkah berikutnya. Bagian uji verifikasi juga menggunakan model contoh ini untuk benchmarking. Jika Anda telah men-deploy layanan inferensi seperti yang dijelaskan di bagian Prasyarat, Anda dapat melewati langkah ini. Anda juga dapat merujuk ke Deploy layanan inferensi model besar Qwen.
Siapkan model dan konfigurasikan volume penyimpanan. Setelah mengunduh model dan mengunggahnya ke OSS, rujuk ke Konfigurasi volume penyimpanan OSS untuk mengonfigurasi PV dan PVC (seperti
example-oss-swap) untuk kluster, yang akan dimount oleh layanan inferensi untuk mengakses model. Menyimpan model di OSS dan menariknya melalui jaringan internal menghindari waktu lama yang diperlukan untuk unduhan melalui jaringan publik.# 1. Unduh model GIT_LFS_SKIP_SMUDGE=1 git clone https://www.modelscope.cn/deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B.git cd DeepSeek-R1-Distill-Qwen-1.5B git lfs pull # 2. Unggah model ke OSS ossutil mkdir oss://<Your-Bucket-Name>/DeepSeek-R1-Distill-Qwen-1.5B ossutil cp -r ./DeepSeek-R1-Distill-Qwen-1.5B oss://<Your-Bucket-Name>/DeepSeek-R1-Distill-Qwen-1.5BBuat Deployment dan Service untuk layanan inferensi di kluster ACK. Konfigurasi berikut menjalankan layanan inferensi menggunakan vLLM dan mendeklarasikan anotasi pengumpulan Prometheus pada Pod, mengekspos endpoint metrik di
/metricspada port8000.apiVersion: apps/v1 kind: Deployment metadata: labels: app: deepseek-r1-distill-qwen-1.5b name: deepseek-r1-distill-qwen-1.5b namespace: default spec: replicas: 4 selector: matchLabels: app: deepseek-r1-distill-qwen-1.5b template: metadata: labels: app: deepseek-r1-distill-qwen-1.5b annotations: prometheus.io/path: /metrics prometheus.io/port: "8000" prometheus.io/scrape: "true" spec: volumes: - name: model persistentVolumeClaim: claimName: example-oss-swap - name: dshm emptyDir: medium: Memory sizeLimit: 30Gi containers: - command: - sh - -c - vllm serve /models/DeepSeek-R1-Distill-Qwen-1.5B --port 8000 --trust-remote-code --served-model-name deepseek-r1-distill-qwen-1.5b --gpu-memory-utilization 0.95 --enforce-eager image: registry-cn-hangzhou.ack.aliyuncs.com/dev/vllm:0.10.0 env: - name: SAFETENSORS_FAST_GPU_TRANSFER value: "0" - name: SAFETENSORS_MAX_HEADER_LENGTH value: "10000000" name: vllm ports: - containerPort: 8000 readinessProbe: tcpSocket: port: 8000 initialDelaySeconds: 30 periodSeconds: 30 resources: limits: nvidia.com/gpu: "1" volumeMounts: - mountPath: /models/ name: model - mountPath: /dev/shm name: dshm --- apiVersion: v1 kind: Service metadata: name: deepseek-r1-distill-qwen-1-5b-v1 spec: type: ClusterIP ports: - port: 8000 protocol: TCP targetPort: 8000 selector: app: deepseek-r1-distill-qwen-1.5bSetelah Pod siap, masuk ke salah satu Pod untuk memverifikasi bahwa endpoint metrik diekspos dengan benar. Respons harus berisi metrik seperti
vllm:num_requests_waiting,vllm:gpu_cache_usage_perc, danvllm:num_requests_running.curl http://<Pod-IP>:8000/metrics
2. Buat instans ALB Edisi Ekstensibel
Masuk ke Konsol ALB. Pilih wilayah China (Shanghai) dan klik Create ALB.
Di halaman pembelian, lengkapi konfigurasi berikut dan klik Create Now.
Region: Pilih China (Shanghai).
Instance Network Type: Pilih Internet.
VPC dan Zone: Pilih
VPC1, centang Shanghai Zone B dan Shanghai Zone F, lalu pilihVSW1danVSW2.IP Version: Pilih IPv4.
Edition (Instance Fee): Pilih Extensible Edition.
Di halaman Confirm Order, konfirmasi detail konfigurasi instans dan klik Activate Now.
3. Buat Service Extension dan tambahkan komponen perutean sadar beban
Permintaan pengumpulan metrik dikirim melalui HTTP 1.1 hanya menggunakan alamat IPv4. Backend IPv6 tidak didukung. Badan respons pengumpulan metrik untuk satu backend dibatasi hingga 10 KB secara default. Tempatkan metrik yang diperlukan (vllm:num_requests_waiting, vllm:gpu_cache_usage_perc, vllm:num_requests_running) dalam 10 KB pertama output metrik. Untuk detail tambahan, lihat Limits.
Di Konsol Service Extension, klik Create Service Extension. Di bagian Service Extension Configuration, masukkan Extension name seperti
ext-load-aware-routing.Extension Type diatur ke Plug-in secara default. Dari dropdown Component name, pilih Load-Aware Routing. Lengkapi konfigurasi berikut dan klik Create.
Collection Configuration:
Host: Nilai header permintaan
Hostuntuk permintaan pengumpulan metrik. Biarkan bidang ini kosong dalam contoh ini, artinya sistem menggunakanIP:Portmasing-masing backend dalam grup server untuk pengumpulan.Path: Path permintaan untuk pengumpulan metrik. Contoh ini menggunakan
/metrics.Response Timeout: Default adalah
5detik.Interval: Atur ke
1detik.
Metric Configuration: Pilih ketiganya: Total Queued Requests, GPU Cache Utilization, dan Running Requests. Atur bobot masing-masing menjadi
100,90, dan80.
Komponen perutean sadar beban harus digunakan dengan grup server Server atau IP Address, dan tidak dapat ditambahkan ke Service Extension yang sama dengan komponen lain.
4. Buat grup server dan kaitkan Service Extension
Buat grup server untuk menampung replika inferensi backend dan kaitkan dengan Service Extension perutean sadar beban yang dibuat di Langkah 3.
Di Konsol Grup Server, pilih wilayah China (Shanghai). Klik Create Server Group, lengkapi konfigurasi berikut, dan klik Create.
Server Group Type: Pilih IP Address.
Server Group Name: Masukkan nama kustom seperti
sgp-load-aware.VPC: Pilih
VPC1.Scheduling Algorithm: Gunakan default Weighted Round-robin. Perutean sadar beban hanya mendukung kombinasi dengan weighted round-robin.
Nonaktifkan Health Check.
Dalam contoh ini, Pod backend tidak menyediakan antarmuka yang diperlukan untuk pemeriksaan kesehatan ALB. Jika pemeriksaan kesehatan diaktifkan, backend akan ditentukan tidak sehat, sehingga perutean sadar beban dilewati. Jika backend Anda menyediakan antarmuka pemeriksaan kesehatan, tetap aktifkan pemeriksaan kesehatan. Menonaktifkan tidak disarankan.
Pengumpulan metrik dalam perutean sadar beban memiliki deteksi ketersediaan bawaan: backend yang metriknya tidak dapat dikumpulkan akan dihapus secara otomatis, memberikan kemampuan serupa dengan pemeriksaan kesehatan.
Pilih kotak centang For Extensible instances di bagian bawah halaman. Aktifkan Associate Service Extension dan Use Existing Service Extension. Pilih
ext-load-aware-routingyang dibuat di Langkah 3.
Setelah Server Group Created, klik Add Backend Servers. Di panel Add Backend Server, tambahkan alamat Pod dari layanan inferensi yang telah dideploy (dapat diperoleh dari daftar kluster ACK > Details > Network > Services). Klik Add IP Address untuk menambahkan beberapa entri, lalu klik Next.
Di langkah Ports/Weights, atur Port ke
8000, pertahankan Weight pada nilai default, dan klik OK.
5. Buat listener
Di Konsol ALB, klik ID instans target untuk membuka halaman Instance Details. Di tab Listener, klik Create Listener.
Di langkah Configure Listener, atur Listener Protocol ke HTTP dan Listener Port ke
80. Di Advanced Settings, atur Connection Request Timeout ke3600detik. Lalu klik Next.Contoh ini menggunakan listener HTTP untuk menyederhanakan konfigurasi dan fokus pada verifikasi efek penjadwalan perutean sadar beban. Di lingkungan produksi, gunakan listener HTTPS dengan sertifikat yang dikonfigurasi untuk keamanan transport.
Permintaan inferensi LLM (terutama saat menghasilkan banyak token output) dapat memakan waktu lama per respons. Jika waktu respons melebihi timeout permintaan default listener (60 detik), permintaan akan dihentikan sebelum waktunya. Contoh ini mengatur timeout permintaan menjadi 3600 detik untuk mencegah respons panjang terputus. Sesuaikan nilai ini berdasarkan durasi permintaan aktual Anda.
Di langkah Select Server Group, pilih grup server
sgp-load-awareyang dibuat di Langkah 4. Lalu klik Next.Di langkah Configuration Review, konfirmasi konfigurasi dan klik Submit.
6. Konfigurasi resolusi DNS
Arahkan domain kustom Anda ke nama DNS instans ALB melalui rekaman CNAME agar klien dapat mengakses ALB melalui domain kustom Anda.
Contoh ini menggunakan DNS Alibaba Cloud. Untuk domain yang tidak didaftarkan di Alibaba Cloud, Anda harus terlebih dahulu menambahkan domain ke konsol DNS.
Di Konsol ALB, salin Domain Name instans target.
Masuk ke Konsol DNS. Di kolom Actions domain target, klik Settings. Di halaman Settings, klik Add Record.
Tambahkan rekaman CNAME dengan informasi berikut, lalu klik OK.
Record Type: Pilih CNAME.
Hostname: Masukkan awalan domain seperti
test. Jika domain root Anda adalahexample.com, domain untuk mengakses ALB adalahtest.example.com.Query Source dan TTL: Pertahankan nilai default.
Record Value: Masukkan nama DNS instans ALB.
Di kotak dialog Change Resource Record Confirmation yang muncul, konfirmasi informasi resolusi dan klik OK.
7. Uji verifikasi
Gunakan tool benchmarking vllm bench serve untuk menjalankan uji stres terhadap backend. Untuk menghindari gangguan dari lebar pita jaringan publik, latensi, dan jitter terhadap hasil pengujian, contoh ini menjalankan benchmark dari lingkungan jaringan internal dalam VPC yang sama dengan ALB: Pod benchmark khusus dideploy (hanya menginstal tool vLLM dan memount model yang sama, tanpa menjalankan layanan inferensi) sebagai klien pengujian, terpisah dari backend yang diuji, untuk menghindari konsumsi sumber daya inferensi atau mengganggu pengumpulan metrik.
Dengan mengatur target konkurensi yang jauh melebihi batas performa layanan, GPU backend berjalan di bawah beban ekstrem. Hal ini memvalidasi apakah perutean sadar beban dapat mengoptimalkan distribusi permintaan, mengurangi antrean ekstrem, dan mempercepat throughput keseluruhan.
Pengalihan Kubernetes Service
Jalankan benchmark terhadap Kubernetes Service dari layanan inferensi backend. Service mendistribusikan koneksi secara merata ke semua replika inferensi tanpa mendeteksi beban real-time.
Ganti --host dengan ClusterIP Service (dapat diperoleh dari daftar kluster ACK > Details > Network > Services).
vllm bench serve \
--backend vllm \
--model /models/DeepSeek-R1-Distill-Qwen-1.5B \
--served-model-name deepseek-r1-distill-qwen-1.5b \
--trust-remote-code \
--dataset-name random \
--random-prefix-len 1000 \
--random-input-len 3000 \
--random-output-len 3000 \
--random-range-ratio 0.2 \
--num-prompts 3000 \
--max-concurrency 600 \
--host <Service-ClusterIP> \
--port 8000 \
--endpoint /v1/completions \
--save-result \
2>&1 | tee benchmark_svc.txtPerutean sadar beban ALB
Jalankan benchmark terhadap instans ALB. Perutean sadar beban menjadwalkan permintaan di seluruh replika inferensi yang sama berdasarkan beban real-time.
Ganti --host dengan alamat IP virtual (VIP) instans ALB (dapat diperoleh dari halaman produk instans). Pertahankan semua parameter lainnya sama.
vllm bench serve \
--backend vllm \
--model /models/DeepSeek-R1-Distill-Qwen-1.5B \
--served-model-name deepseek-r1-distill-qwen-1.5b \
--trust-remote-code \
--dataset-name random \
--random-prefix-len 1000 \
--random-input-len 3000 \
--random-output-len 3000 \
--random-range-ratio 0.2 \
--num-prompts 3000 \
--max-concurrency 600 \
--host <ALB-VIP> \
--port 80 \
--endpoint /v1/completions \
--save-result \
2>&1 | tee benchmark_alb.txtPerbandingan metrik utama antara kedua pendekatan adalah sebagai berikut. Data di bawah ini berasal dari lingkungan pengujian dalam contoh ini dan hanya sebagai referensi. Hasil aktual bergantung pada lingkungan Anda sendiri.
Metric | Pengalihan Kubernetes Service | Perutean Sadar Beban ALB |
P99 TTFT (ms) | 71872,40 | 60504,53 |
Rata-rata TTFT (ms) | 12709,49 | 12043,91 |
Median TTFT (ms) | 7156,46 | 5492,57 |
Throughput token total (token/detik) | 18285,60 | 18784,43 |
Durasi benchmark (detik) | 959,95 | 935,97 |
Dengan jumlah backend yang sama, perutean sadar beban secara signifikan mengurangi waktu hingga token pertama (TTFT) dengan menjadwalkan permintaan secara preferensial ke replika yang beban kerjanya lebih ringan. Dalam pengujian ini, P99 TTFT menurun sekitar 16% dan Median TTFT menurun sekitar 23%, sementara throughput keseluruhan sedikit meningkat dan distribusi latensi permintaan menjadi lebih stabil.
Informasi lebih lanjut
Tagihan
ALB Edisi Ekstensibel — Saat ini dalam pratinjau publik dan tersedia gratis.
Kluster ACK dan instans GPU — Layanan inferensi backend berjalan pada node GPU di kluster ACK. Penagihan mengikuti aturan harga Container Service dan instans ECS yang sesuai. Jika dibuat untuk tujuan pengujian, gunakan instans pay-as-you-go dan segera lepas setelah selesai.
Biaya domain dan resolusi DNS publik — Selain biaya domain dari penyedia domain Anda, konfigurasi resolusi DNS publik di Alibaba Cloud dikenai biaya resolusi otoritatif publik.
Batasan
Permintaan pengumpulan metrik dikirim menggunakan HTTP 1.1 melalui alamat IPv4. Backend IPv6 saat ini tidak didukung.
Badan respons pengumpulan metrik untuk satu backend dibatasi hingga 10 KB secara default. Konten yang melebihi batas ini akan dibuang, yang dapat menyebabkan pengumpulan metrik tidak lengkap. Perutean sadar beban hanya menggunakan tiga metrik:
vllm:num_requests_waiting,vllm:gpu_cache_usage_perc, danvllm:num_requests_running. Tempatkan metrik ini dalam 10 KB pertama output metrik untuk memastikan pengumpulan yang tepat.
FAQ
Setelah mengaktifkan perutean sadar beban, distribusi permintaan sama seperti weighted round-robin?
Verifikasi pengaturan berikut:
Algoritma penjadwalan — Algoritma penjadwalan grup server diatur ke weighted round-robin.
Asosiasi Service Extension — Grup server dikaitkan dengan benar ke Service Extension yang berisi komponen perutean sadar beban.
Eksposur metrik — Backend mengekspos metrik vLLM dengan benar di path pengumpulan metrik. Jika pengumpulan metrik gagal, perutean sadar beban kembali menggunakan weighted round-robin.
Pemeriksaan kesehatan — Verifikasi apakah status pemeriksaan kesehatan normal. Saat diaktifkan, backend yang gagal pemeriksaan kesehatan dihapus dan dilewati oleh penjadwalan sadar beban. Saat semua backend tidak sehat, perutean sadar beban sepenuhnya kembali ke weighted round-robin.