Topik ini menjelaskan cara menggunakan Service Mesh (ASM) untuk meningkatkan penyeimbangan beban dan pengelolaan trafik untuk layanan inferensi LLM yang diterapkan di dalam kluster Kubernetes. Karena karakteristik unik dari trafik inferensi LLM dan beban kerja, metode penyeimbangan beban tradisional mungkin kurang memadai. Topik ini membimbing Anda melalui langkah-langkah untuk menentukan pool layanan dan routing untuk layanan inferensi vLLM guna meningkatkan performa dan mendapatkan wawasan tentang trafik inferensi.
Tips membaca
Sebelum memulai, pastikan Anda sudah familiar dengan:
Untuk memanfaatkan kemampuan komputasi GPU di dalam kluster ACS, lihat Tentukan model GPU dan versi driver untuk pod GPU yang dipercepat di dalam kluster ACS untuk instruksi lebih lanjut.
Untuk membuat dan menggunakan pool node GPU dalam kluster ACK atau memanfaatkan kemampuan komputasi ACS, lihat Buat Pool Node GPU atau Gunakan Kemampuan Komputasi ACS di Kluster ACK Pro untuk instruksi lebih rinci.
Dengan membaca topik ini, Anda akan mempelajari tentang:
Latar belakang model bahasa besar dan vLLM.
Tantangan dalam mengelola layanan inferensi LLM di dalam kluster menggunakan metode konvensional.
Konsep dan langkah praktis untuk mengelola layanan inferensi LLM di dalam kluster menggunakan ASM.
Latar Belakang
Model bahasa besar (LLM)
Model bahasa besar (LLMs) adalah model bahasa berbasis jaringan saraf dengan miliaran parameter, seperti GPT, Qwen, dan Llama. Model-model ini dilatih pada dataset pra-latihan yang beragam dan luas, termasuk teks web, literatur profesional, dan kode, serta terutama digunakan untuk tugas-tugas generasi teks seperti penyelesaian dan dialog.
Untuk memanfaatkan LLMs dalam membangun aplikasi, Anda dapat:
Memanfaatkan layanan API LLM eksternal dari platform seperti OpenAI, Alibaba Cloud Model Studio, atau Moonshot.
Membangun layanan inferensi LLM Anda sendiri menggunakan model open-source atau proprietary dan framework seperti vLLM, serta menerapkannya di dalam kluster Kubernetes. Pendekatan ini cocok untuk skenario yang memerlukan kontrol atas layanan inferensi atau penyesuaian tinggi terhadap kemampuan inferensi LLM.
vLLM
vLLM adalah framework yang dirancang untuk pembuatan layanan inferensi LLM yang efisien dan ramah pengguna. Ini mendukung berbagai model bahasa besar, termasuk Qwen, serta mengoptimalkan efisiensi inferensi LLM melalui teknik seperti PagedAttention, inferensi batch dinamis (Continuous Batching), dan kuantisasi model.
Penyeimbangan beban dan observabilitas
ASM memfasilitasi pengelolaan trafik layanan inferensi LLM di dalam kluster. Saat menerapkan layanan inferensi LLM, Anda dapat mendeklarasikan beban kerja yang menyediakan layanan dan nama model melalui Custom Resource Definitions (CRDs) InferencePool dan InferenceModel. ASM kemudian menyediakan penyeimbangan beban, pengelolaan trafik, dan observabilitas untuk layanan inferensi LLM yang menargetkan backend inferensi LLM.
Saat ini, hanya layanan inferensi LLM berbasis vLLM yang didukung.
Penyeimbangan beban tradisionalAlgoritma penyeimbangan beban klasik mendistribusikan permintaan HTTP secara merata di berbagai beban kerja. Namun, dengan layanan inferensi LLM, beban yang diberikan setiap permintaan kepada backend tidak dapat diprediksi. Proses inferensi terdiri dari dua fase: prefill dan decode:
| Penyeimbangan beban LLMASM menawarkan algoritma penyeimbangan beban yang disesuaikan untuk backend LLM. Algoritma ini mengevaluasi status internal server inferensi menggunakan metrik multi-dimensi dan menyeimbangkan beban kerja di beberapa server. Metrik utama meliputi:
Pendekatan ini lebih unggul dibandingkan algoritma tradisional dengan memastikan beban GPU yang konsisten di seluruh layanan inferensi, mengurangi latensi respons untuk token pertama dari permintaan LLM (ttft), serta meningkatkan throughput. |
Observabilitas tradisionalLayanan inferensi LLM biasanya berinteraksi menggunakan format API permintaan OpenAI. Sebagian besar metadata permintaan, seperti nama model dan jumlah token maksimum, berada di badan permintaan. Kemampuan routing dan observabilitas tradisional, yang didasarkan pada header permintaan dan jalur, tidak mem-parsing badan permintaan sehingga tidak dapat mengakomodasi alokasi trafik atau observasi berdasarkan nama model permintaan atau jumlah token. | Observabilitas trafik inferensiASM meningkatkan kemampuan LLM inferensi dalam log akses dan metrik pemantauan untuk permintaan.
|
Prasyarat
Pastikan Anda telah membuat kluster ACK yang dikelola dengan pool node GPU atau memilih kluster ACS di zona yang direkomendasikan untuk kemampuan komputasi GPU. Untuk informasi lebih lanjut, lihat Buat Kluster ACK yang Dikelola dan Buat Kluster ACS.
Anda dapat menginstal komponen Virtual Node ACK di dalam kluster ACK yang dikelola untuk memanfaatkan kemampuan komputasi GPU ACS. Untuk informasi lebih lanjut, lihat Kemampuan Komputasi GPU ACS di dalam ACK.
Kluster ditambahkan ke instance ASM versi 1.24 atau lebih baru. Untuk informasi lebih lanjut, lihat Tambahkan Kluster ke Instance ASM.
Gateway masuk dibuat dan layanan HTTP diaktifkan pada port 8080. Untuk informasi lebih lanjut, lihat Buat Gateway Masuk.
(Opsional) Sidecar disuntikkan ke namespace default. Untuk informasi lebih lanjut, lihat Aktifkan Injeksi Proxy Sidecar Otomatis.
CatatanAnda dapat melewati injeksi Sidecar jika Anda tidak ingin mengeksplorasi operasi praktis observabilitas.
Praktik terbaik
Contoh berikut menunjukkan cara mengelola trafik layanan inferensi LLM di dalam kluster menggunakan ASM dengan menerapkan model besar Llama2 berbasis vLLM.
Langkah 1: Terapkan layanan inferensi sampel
Buat file bernama vllm-service.yaml dengan konten yang disediakan.
CatatanGambar yang dibahas dalam topik ini memerlukan GPU dengan memori video lebih dari 16 GiB. Tipe kartu T4, yang memiliki memori video 16 GiB, tidak menyediakan sumber daya yang cukup untuk meluncurkan aplikasi ini. Disarankan untuk menggunakan tipe kartu A10 untuk kluster ACK dan GPU generasi ke-8 B untuk kluster ACS. Untuk informasi model yang lebih rinci, silakan submit a ticket untuk bantuan lebih lanjut.
Karena ukuran gambar LLM yang besar, disarankan untuk menyimpannya terlebih dahulu di ACR dan menggunakan alamat jaringan internal untuk menarik. Penarikan langsung dari jaringan publik dapat mengakibatkan waktu tunggu lama tergantung pada konfigurasi bandwidth EIP kluster.
Kluster ACS
apiVersion: v1 kind: Service metadata: name: vllm-llama2-7b-pool spec: selector: app: vllm-llama2-7b-pool ports: - protocol: TCP port: 8000 targetPort: 8000 type: ClusterIP --- apiVersion: v1 kind: ConfigMap metadata: name: chat-template data: llama-2-chat.jinja: | {% if messages[0]['role'] == 'system' %} {% set system_message = '<<SYS>>\n' + messages[0]['content'] | trim + '\n<</SYS>>\n\n' %} {% set messages = messages[1:] %} {% else %} {% set system_message = '' %} {% endif %} {% for message in messages %} {% if (message['role'] == 'user') != (loop.index0 % 2 == 0) %} {{ raise_exception('Peran percakapan harus bergantian user/assistant/user/assistant/...') }} {% endif %} {% if loop.index0 == 0 %} {% set content = system_message + message['content'] %} {% else %} {% set content = message['content'] %} {% endif %} {% if message['role'] == 'user' %} {{ bos_token + '[INST] ' + content | trim + ' [/INST]' }} {% elif message['role'] == 'assistant' %} {{ ' ' + content | trim + ' ' + eos_token }} {% endif %} {% endfor %} --- apiVersion: apps/v1 kind: Deployment metadata: name: vllm-llama2-7b-pool namespace: default spec: replicas: 3 selector: matchLabels: app: vllm-llama2-7b-pool template: metadata: annotations: prometheus.io/path: /metrics prometheus.io/port: '8000' prometheus.io/scrape: 'true' labels: app: vllm-llama2-7b-pool alibabacloud.com/compute-class: gpu # Tentukan kemampuan komputasi GPU alibabacloud.com/compute-qos: default alibabacloud.com/gpu-model-series: "example-model" # Tentukan model GPU sebagai example-model. Isi sesuai dengan situasi sebenarnya. spec: containers: - name: lora image: "registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/llama2-with-lora:v0.2" imagePullPolicy: IfNotPresent command: ["python3", "-m", "vllm.entrypoints.openai.api_server"] args: - "--model" - "/model/llama2" - "--tensor-parallel-size" - "1" - "--port" - "8000" - '--gpu_memory_utilization' - '0.8' - "--enable-lora" - "--max-loras" - "4" - "--max-cpu-loras" - "12" - "--lora-modules" - 'sql-lora=/adapters/yard1/llama-2-7b-sql-lora-test_0' - 'sql-lora-1=/adapters/yard1/llama-2-7b-sql-lora-test_1' - 'sql-lora-2=/adapters/yard1/llama-2-7b-sql-lora-test_2' - 'sql-lora-3=/adapters/yard1/llama-2-7b-sql-lora-test_3' - 'sql-lora-4=/adapters/yard1/llama-2-7b-sql-lora-test_4' - 'tweet-summary=/adapters/vineetsharma/qlora-adapter-Llama-2-7b-hf-TweetSumm_0' - 'tweet-summary-1=/adapters/vineetsharma/qlora-adapter-Llama-2-7b-hf-TweetSumm_1' - 'tweet-summary-2=/adapters/vineetsharma/qlora-adapter-Llama-2-7b-hf-TweetSumm_2' - 'tweet-summary-3=/adapters/vineetsharma/qlora-adapter-Llama-2-7b-hf-TweetSumm_3' - 'tweet-summary-4=/adapters/vineetsharma/qlora-adapter-Llama-2-7b-hf-TweetSumm_4' - '--chat-template' - '/etc/vllm/llama-2-chat.jinja' env: - name: PORT value: "8000" ports: - containerPort: 8000 name: http protocol: TCP livenessProbe: failureThreshold: 2400 httpGet: path: /health port: http scheme: HTTP initialDelaySeconds: 5 periodSeconds: 5 successThreshold: 1 timeoutSeconds: 1 readinessProbe: failureThreshold: 6000 httpGet: path: /health port: http scheme: HTTP initialDelaySeconds: 5 periodSeconds: 5 successThreshold: 1 timeoutSeconds: 1 resources: limits: cpu: 16 memory: 64Gi nvidia.com/gpu: 1 requests: cpu: 8 memory: 30Gi nvidia.com/gpu: 1 volumeMounts: - mountPath: /data name: data - mountPath: /dev/shm name: shm - mountPath: /etc/vllm name: chat-template restartPolicy: Always schedulerName: default-scheduler terminationGracePeriodSeconds: 30 volumes: - name: data emptyDir: {} - name: shm emptyDir: medium: Memory - name: chat-template configMap: name: chat-templateKluster ACK
apiVersion: v1 kind: Service metadata: name: vllm-llama2-7b-pool spec: selector: app: vllm-llama2-7b-pool ports: - protocol: TCP port: 8000 targetPort: 8000 type: ClusterIP --- apiVersion: v1 kind: ConfigMap metadata: name: chat-template data: llama-2-chat.jinja: | {% if messages[0]['role'] == 'system' %} {% set system_message = '<<SYS>>\n' + messages[0]['content'] | trim + '\n<</SYS>>\n\n' %} {% set messages = messages[1:] %} {% else %} {% set system_message = '' %} {% endif %} {% for message in messages %} {% if (message['role'] == 'user') != (loop.index0 % 2 == 0) %} {{ raise_exception('Peran percakapan harus bergantian user/assistant/user/assistant/...') }} {% endif %} {% if loop.index0 == 0 %} {% set content = system_message + message['content'] %} {% else %} {% set content = message['content'] %} {% endif %} {% if message['role'] == 'user' %} {{ bos_token + '[INST] ' + content | trim + ' [/INST]' }} {% elif message['role'] == 'assistant' %} {{ ' ' + content | trim + ' ' + eos_token }} {% endif %} {% endfor %} --- apiVersion: apps/v1 kind: Deployment metadata: name: vllm-llama2-7b-pool namespace: default spec: replicas: 3 selector: matchLabels: app: vllm-llama2-7b-pool template: metadata: annotations: prometheus.io/path: /metrics prometheus.io/port: '8000' prometheus.io/scrape: 'true' labels: app: vllm-llama2-7b-pool spec: containers: - name: lora image: "registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/llama2-with-lora:v0.2" imagePullPolicy: IfNotPresent command: ["python3", "-m", "vllm.entrypoints.openai.api_server"] args: - "--model" - "/model/llama2" - "--tensor-parallel-size" - "1" - "--port" - "8000" - '--gpu_memory_utilization' - '0.8' - "--enable-lora" - "--max-loras" - "4" - "--max-cpu-loras" - "12" - "--lora-modules" - 'sql-lora=/adapters/yard1/llama-2-7b-sql-lora-test_0' - 'sql-lora-1=/adapters/yard1/llama-2-7b-sql-lora-test_1' - 'sql-lora-2=/adapters/yard1/llama-2-7b-sql-lora-test_2' - 'sql-lora-3=/adapters/yard1/llama-2-7b-sql-lora-test_3' - 'sql-lora-4=/adapters/yard1/llama-2-7b-sql-lora-test_4' - 'tweet-summary=/adapters/vineetsharma/qlora-adapter-Llama-2-7b-hf-TweetSumm_0' - 'tweet-summary-1=/adapters/vineetsharma/qlora-adapter-Llama-2-7b-hf-TweetSumm_1' - 'tweet-summary-2=/adapters/vineetsharma/qlora-adapter-Llama-2-7b-hf-TweetSumm_2' - 'tweet-summary-3=/adapters/vineetsharma/qlora-adapter-Llama-2-7b-hf-TweetSumm_3' - 'tweet-summary-4=/adapters/vineetsharma/qlora-adapter-Llama-2-7b-hf-TweetSumm_4' - '--chat-template' - '/etc/vllm/llama-2-chat.jinja' env: - name: PORT value: "8000" ports: - containerPort: 8000 name: http protocol: TCP livenessProbe: failureThreshold: 2400 httpGet: path: /health port: http scheme: HTTP initialDelaySeconds: 5 periodSeconds: 5 successThreshold: 1 timeoutSeconds: 1 readinessProbe: failureThreshold: 6000 httpGet: path: /health port: http scheme: HTTP initialDelaySeconds: 5 periodSeconds: 5 successThreshold: 1 timeoutSeconds: 1 resources: limits: nvidia.com/gpu: 1 requests: nvidia.com/gpu: 1 volumeMounts: - mountPath: /data name: data - mountPath: /dev/shm name: shm - mountPath: /etc/vllm name: chat-template restartPolicy: Always schedulerName: default-scheduler terminationGracePeriodSeconds: 30 volumes: - name: data emptyDir: {} - name: shm emptyDir: medium: Memory - name: chat-template configMap: name: chat-templateTerapkan layanan inferensi LLM menggunakan file kubeconfig kluster pada bidang data.
kubectl apply -f vllm-service.yaml
Langkah 2: Konfigurasikan aturan gateway ASM
Terapkan aturan gateway untuk mengaktifkan pemantauan port 8080 pada gateway ASM.
Buat file bernama gateway.yaml dengan konten berikut.
apiVersion: networking.istio.io/v1 kind: Gateway metadata: name: llm-inference-gateway namespace: default spec: selector: istio: ingressgateway servers: - hosts: - '*' port: name: http-service number: 8080 protocol: HTTPBuat aturan gateway.
kubectl apply -f gateway.yaml
Langkah 3: Konfigurasikan routing dan penyeimbangan beban untuk layanan inferensi LLM
Untuk membandingkan performa penyeimbangan beban tradisional dengan penyeimbangan beban LLM, Anda harus menyelesaikan langkah-langkah di (Opsional) Bandingkan Performa dengan Penyeimbangan Beban Tradisional Menggunakan Dasbor Observabilitas sebelum melanjutkan operasi lebih lanjut.
Aktifkan routing untuk layanan inferensi LLM menggunakan file kubeconfig ASM.
kubectl patch asmmeshconfig default --type=merge --patch='{"spec":{"gatewayAPIInferenceExtension":{"enabled":true}}}'Terapkan sumber daya InferencePool.
Sumber daya InferencePool mendefinisikan beban kerja untuk satu set layanan inferensi LLM di dalam kluster menggunakan pemilih label. ASM akan menerapkan penyeimbangan beban vLLM berdasarkan InferencePool yang dibuat.
Buat file bernama inferencepool.yaml dengan konten berikut.
apiVersion: inference.networking.x-k8s.io/v1alpha1 kind: InferencePool metadata: name: vllm-llama2-7b-pool spec: targetPortNumber: 8000 selector: app: vllm-llama2-7b-poolTabel berikut menjelaskan beberapa item konfigurasi:
Item konfigurasi
Deskripsi
.spec.targetPortNumber
Port yang diekspos oleh Pod yang menyediakan layanan inferensi.
.spec.selector
Label Pod yang menyediakan layanan inferensi. Kunci label harus app, dan nilainya harus nama Service yang sesuai.
Buat sumber daya InferencePool menggunakan file kubeconfig kluster pada bidang data.
kubectl apply -f inferencepool.yaml
Terapkan sumber daya InferenceModel.
InferenceModel menentukan kebijakan distribusi trafik untuk model tertentu di dalam sumber daya InferencePool.
Buat file bernama inferencemodel.yaml menggunakan konten berikut.
apiVersion: inference.networking.x-k8s.io/v1alpha1 kind: InferenceModel metadata: name: inferencemodel-sample spec: modelName: tweet-summary poolRef: group: inference.networking.x-k8s.io kind: InferencePool name: vllm-llama2-7b-pool targetModels: - name: tweet-summary weight: 100Tabel berikut menjelaskan beberapa item konfigurasi:
Item Konfigurasi
Deskripsi
.spec.modelName
Digunakan untuk mencocokkan parameter model dalam permintaan.
.spec.targetModels
Konfigurasikan aturan routing trafik. Dalam contoh di atas, trafik dengan model: tweet-summary di header permintaan dikirim 100% ke Pod yang menjalankan model tweet-summary.
Buat sumber daya InferenceModel.
kubectl apply -f inferencemodel.yaml
Buat sumber daya LLMRoute.
Atur aturan routing untuk gateway agar semua permintaan yang diterima pada port 8080 diteruskan ke layanan inferensi LLM sampel dengan mereferensikan sumber daya InferencePool.
Buat file bernama llmroute.yaml dengan konten berikut.
apiVersion: istio.alibabacloud.com/v1 kind: LLMRoute metadata: name: test-llm-route spec: gateways: - llm-inference-gateway host: test.com rules: - backendRefs: - backendRef: group: inference.networking.x-k8s.io kind: InferencePool name: vllm-llama2-7b-poolTerapkan sumber daya LLMRoute.
kubectl apply -f llmroute.yaml
Langkah 4: Verifikasi
Jalankan perintah berikut beberapa kali untuk melakukan pengujian.
curl -H "host: test.com" ${ASM Gateway IP}:8080/v1/completions -H 'Content-Type: application/json' -d '{
"model": "tweet-summary",
"prompt": "Tulis seolah-olah Anda seorang kritikus: San Francisco",
"max_tokens": 100,
"temperature": 0
}' -vOutput yang diharapkan:
{"id":"cmpl-2fc9a351-d866-422b-b561-874a30843a6b","object":"text_completion","created":1736933141,"model":"tweet-summary","choices":[{"index":0,"text":", Saya seorang pemula di forum ini. Tulis ringkasan artikel.\nTulis ringkasan artikel.\nTulis ringkasan artikel. Tulis ringkasan artikel. Tulis ringkasan artikel. Tulis ringkasan artikel. Tulis ringkasan artikel. Tulis ringkasan artikel. Tulis ringkasan artikel. Tulis ringkasan artikel. Tulis ringkasan artikel. Tulis ringkasan artikel.","logprobs":null,"finish_reason":"length","stop_reason":null,"prompt_logprobs":null}],"usage":{"prompt_tokens":2,"total_tokens":102,"completion_tokens":100,"prompt_tokens_details":null}}(Opsional) Langkah 5: Konfigurasikan metrik observabilitas dan dasbor untuk layanan LLM
Setelah mendeklarasikan layanan inferensi LLM di dalam kluster menggunakan sumber daya InferencePool dan InferenceModel serta menetapkan kebijakan routing, Anda dapat melihat observabilitas layanan inferensi LLM melalui log dan metrik pemantauan.
Aktifkan fitur observabilitas trafik LLM di konsol ASM untuk mengumpulkan metrik pemantauan.
Tingkatkan observabilitas permintaan inferensi LLM dengan menambahkan bidang log tambahan, metrik, dan dimensi metrik. Untuk instruksi konfigurasi terperinci, lihat Observasi Trafik: Kelola Trafik LLM secara Efisien Menggunakan ASM.
Setelah konfigurasi selesai, dimensi
modelakan dimasukkan ke dalam metrik pemantauan ASM. Anda dapat mengumpulkan metrik ini dengan cara memanfaatkan Prometheus dalam kerangka pemantauan observabilitas atau mengintegrasikan Prometheus yang di-host sendiri untuk pemantauan service mesh.ASM memperkenalkan dua metrik baru:
asm_llm_proxy_prompt_tokens, yang mewakili jumlah token input, danasm_llm_proxy_completion_tokens, yang mewakili jumlah token output untuk semua permintaan. Anda dapat memasukkan metrik ini dengan menambahkan aturan berikut ke Prometheus. Untuk detailnya, lihat Konfigurasi Lain untuk Penemuan Layanan Prometheus.scrape_configs: - job_name: asm-envoy-stats-llm scrape_interval: 30s scrape_timeout: 30s metrics_path: /stats/prometheus scheme: http kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: - __meta_kubernetes_pod_container_port_name action: keep regex: .*-envoy-prom - source_labels: - __address__ - __meta_kubernetes_pod_annotation_prometheus_io_port action: replace regex: ([^:]+)(?::\d+)?;(\d+) replacement: $1:15090 target_label: __address__ - action: labelmap regex: __meta_kubernetes_pod_label_(.+) - source_labels: - __meta_kubernetes_namespace action: replace target_label: namespace - source_labels: - __meta_kubernetes_pod_name action: replace target_label: pod_name metric_relabel_configs: - action: keep source_labels: - __name__ regex: asm_llm_.*
Kumpulkan metrik pemantauan untuk layanan vLLM.
Metrik pemantauan untuk permintaan inferensi LLM terutama melibatkan throughput permintaan inferensi LLM eksternal. Tambahkan anotasi untuk kolektor Prometheus ke pod layanan vLLM untuk mengumpulkan metrik yang diekspos oleh layanan vLLM dan memantau status internalnya.
... annotations: prometheus.io/path: /metrics # Jalur HTTP tempat metrik diekspos. prometheus.io/port: "8000" # Port tempat metrik diekspos, yaitu port listening dari Server vLLM. prometheus.io/scrape: "true" # Apakah akan mengumpulkan metrik dari pod saat ini. ...Ambil metrik terkait layanan vLLM menggunakan mekanisme penemuan layanan bawaan Prometheus. Untuk instruksi terperinci, lihat Penemuan Layanan Bawaan.
Metrik utama dari layanan vLLM memberikan wawasan tentang status internal beban kerja vLLM.
Nama metrik
Deskripsi
vllm:gpu_cache_usage_perc
Persentase penggunaan cache GPU vLLM. Saat vLLM dimulai, ia akan memanfaatkan sebanyak mungkin memori video GPU untuk KV cache. Untuk server vLLM, semakin rendah pemanfaatan cache, semakin banyak ruang GPU tersedia untuk dialokasikan ke permintaan baru.
vllm:request_queue_time_seconds_sum
Waktu yang dihabiskan dalam antrian status menunggu. Setelah permintaan inferensi LLM tiba di server vLLM, mungkin tidak diproses segera tetapi perlu menunggu scheduler vLLM menjadwalkan prefill dan decode.
vllm:num_requests_running
vllm:num_requests_waiting
vllm:num_requests_swapped
Jumlah permintaan yang menjalankan inferensi, menunggu, dan ditukar ke memori. Ini dapat digunakan untuk mengevaluasi tekanan permintaan saat ini dari layanan vLLM.
vllm:avg_generation_throughput_toks_per_s
vllm:avg_prompt_throughput_toks_per_s
Jumlah token yang dikonsumsi oleh tahap prefill dan dihasilkan oleh tahap decode per detik.
vllm:time_to_first_token_seconds_bucket
Tingkat latensi dari waktu permintaan dikirim ke layanan vLLM hingga token pertama direspons. Metrik ini biasanya mewakili waktu yang diperlukan klien untuk mendapatkan respons pertama setelah mengeluarkan isi permintaan dan merupakan metrik penting yang memengaruhi pengalaman pengguna LLM.
Konfigurasikan dasbor Grafana untuk memantau layanan inferensi LLM.
Amati layanan inferensi LLM yang diterapkan dengan vLLM melalui dasbor Grafana:
Monitor laju permintaan dan throughput token menggunakan metrik pemantauan ASM;
Evaluasi status internal beban kerja untuk layanan inferensi LLM dengan metrik pemantauan vLLM.
Anda dapat membuat sumber data (instance Prometheus) di konsol Grafana. Pastikan metrik pemantauan untuk ASM dan vLLM telah dikumpulkan oleh instance Prometheus.
Untuk membuat dasbor observabilitas untuk layanan inferensi LLM, impor konten yang disediakan di bawah ini ke Grafana.
Anda dapat melihat dasbor yang serupa dengan berikut ini:

(Opsional) Bandingkan performa dengan penyeimbangan beban tradisional menggunakan dasbor observabilitas
Menggunakan dasbor observabilitas, Anda dapat langsung membandingkan performa penyeimbangan beban layanan inferensi LLM dengan algoritma penyeimbangan beban tradisional, termasuk metrik seperti pemanfaatan cache, waktu antrian permintaan, throughput token, dan ttft.
Setelah menyelesaikan Langkah 3, Anda dapat menjalankan perintah berikut untuk membersihkan sumber daya yang telah dibuat.
kubectl delete inferencemodel --all
kubectl delete inferencepool --all
kubectl delete llmroute --allJika tidak, setelah menyelesaikan langkah 1 dan 2, pastikan Anda menghapus semua layanan virtual yang telah dibuat sebelum melanjutkan ke Langkah 3.
Buat layanan virtual untuk menyediakan routing dan penyeimbangan beban tradisional untuk layanan inferensi LLM sampel dengan menjalankan perintah berikut.
kubectl apply -f- <<EOF apiVersion: networking.istio.io/v1 kind: VirtualService metadata: name: llm-vs namespace: default spec: gateways: - default/llm-inference-gateway hosts: - '*' http: - name: any-host route: - destination: host: vllm-llama2-7b-pool.default.svc.cluster.local port: number: 8000 EOFLakukan pengujian stres pada layanan inferensi LLM menggunakan alat llmperf.
Analisis kedua kebijakan routing dan penyeimbangan beban melalui dasbor Grafana.
Perbandingan menunjukkan bahwa penyeimbangan beban layanan inferensi LLM memberikan latensi yang lebih baik, throughput, dan pemanfaatan cache.
