Bantu tingkatkan halaman ini
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Untuk berkontribusi pada panduan pengguna ini, pilih Edit halaman ini pada GitHub tautan yang terletak di panel kanan setiap halaman.
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Quickstart: Inferensi LLM throughput tinggi dengan VLLM di Amazon EKS
Pengantar
Panduan memulai cepat ini menyediakan panduan untuk menerapkan Large Language Models () LLMs di Amazon EKS menggunakan VllM dan GPUs untuk aplikasi inferensi real-time berbasis teks.
Solusi ini memanfaatkan Amazon EKS untuk orkestrasi kontainer dan VllM untuk penyajian model yang efisien, memungkinkan Anda membangun aplikasi AI yang dapat diskalakan dengan akselerasi GPU dan penyajian inferensi throughput tinggi. Model Instruct Llama 3.1 8B digunakan untuk demonstrasi, tetapi Anda dapat menerapkan LLM lain yang didukung oleh VllM (periksa dokumentasi VllM untuk daftar model yang didukung).
Arsitektur VllM di EKS
Ketika Anda menyelesaikan prosedur ini, Anda akan memiliki titik akhir inferensi VLLM yang dioptimalkan untuk throughput dan latensi rendah, dan Anda akan dapat berinteraksi dengan model Llama melalui aplikasi frontend obrolan, menunjukkan kasus penggunaan khas untuk asisten chatbot dan aplikasi berbasis LLM lainnya.
Untuk panduan tambahan dan sumber daya penerapan lanjutan, lihat Panduan Praktik Terbaik EKS kami untuk AI/ML beban kerja dan AI
Sebelum Anda mulai
Sebelum memulai, pastikan Anda memiliki:
-
Cluster Amazon EKS dengan komponen utama berikut: Nodepool Karpenter dengan keluarga EC2 instans G5 atau G6, Plugin Perangkat NVIDIA yang diinstal pada node pekerja berkemampuan GPU, dan Driver CSI S3 Mountpoint diinstal. Untuk membuat penyiapan dasar ini, ikuti langkah-langkahPanduan Pengaturan Kluster Praktik Terbaik untuk Inferensi Waktu Nyata di Amazon EKS, hingga menyelesaikan langkah #4.
-
Akun Hugging Face. Untuk mendaftar, lihat https://huggingface.co/login.
Mengatur Penyimpanan Model dengan Amazon S3
Simpan file LLM besar secara efisien di Amazon S3 untuk memisahkan penyimpanan dari sumber daya komputasi. Pendekatan ini merampingkan pembaruan model, mengurangi biaya, dan menyederhanakan manajemen dalam pengaturan produksi. S3 menangani file besar dengan andal, sementara integrasi dengan Kubernetes melalui driver Mountpoint CSI memungkinkan pod mengakses model seperti penyimpanan lokal—tidak perlu mengunduh yang memakan waktu selama startup. Ikuti langkah-langkah berikut untuk membuat bucket S3, mengunggah LLM, dan memasangnya sebagai volume dalam wadah penyajian inferensi Anda.
Solusi penyimpanan lainnya juga tersedia di EKS untuk caching model, seperti EFS dan FSx untuk Lustre. Untuk informasi lebih lanjut, periksa Praktik Terbaik EKS.
Tetapkan variabel lingkungan
Buat nama unik untuk bucket Amazon S3 baru yang akan kami buat nanti di panduan ini. Setelah dibuat, gunakan nama bucket yang sama ini untuk semua langkah. Contoh:
MY_BUCKET_NAME=model-store-$(date +%s)
Tentukan variabel lingkungan dan simpan dalam file:
cat << EOF > .env-quickstart-vllm export BUCKET_NAME=${MY_BUCKET_NAME} export AWS_REGION=us-east-1 export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) EOF
Muat variabel lingkungan di lingkungan shell Anda. Jika Anda menutup lingkungan shell saat ini dan membuka yang baru, pastikan untuk mengambil kembali variabel lingkungan menggunakan perintah yang sama ini:
source .env-quickstart-vllm
Buat bucket S3 untuk menyimpan file model
Buat bucket S3 untuk menyimpan file model:
aws s3 mb s3://${BUCKET_NAME} --region ${AWS_REGION}
Unduh model dari Hugging Face
Hugging Face adalah salah satu hub model utama untuk mengakses model LLM. Untuk mengunduh model Llama, Anda harus menerima lisensi model dan mengatur otentikasi token:
-
Terima lisensi model Instruct Llama 3.1 8B di https://huggingface. co/meta-llama/Llama-3.1-8B-Instruksikan.
-
Hasilkan token akses (buka Profile > Settings > Access Tokens, lalu buat token baru menggunakan tipe Read token).
Tetapkan variabel lingkungan dengan token Hugging Face Anda:
export HF_TOKEN=your_token_here
Instal paket pip3 jika belum diinstal di lingkungan Anda. Contoh perintah di Amazon Linux 2023:
sudo dnf install -y python3-pip
Instal CLI Hugging
pip install huggingface-hub
Unduh model Llama-3.1-8B-Instruct dari Hugging Face (~ 15 GB) --exclude menggunakan bendera untuk melewati format lama dan hanya mengunduh file format safetensors PyTorch yang dioptimalkan, yang mengurangi ukuran unduhan sambil mempertahankan kompatibilitas penuh dengan mesin inferensi populer:
huggingface-cli download meta-llama/Meta-Llama-3.1-8B-Instruct \ --exclude "original/*" \ --local-dir ./llama-3.1-8b-instruct \ --token $HF_TOKEN
Verifikasi file yang diunduh:
$ ls llama-3.1-8b-instruct
Output yang diharapkan akan terlihat seperti ini:
LICENSE config.json model-00002-of-00004.safetensors model.safetensors.index.json tokenizer_config.json README.md generation_config.json model-00003-of-00004.safetensors special_tokens_map.json USE_POLICY.md model-00001-of-00004.safetensors model-00004-of-00004.safetensors tokenizer.json
Unggah file model
Aktifkan AWS Common Runtime (CRT) untuk meningkatkan kinerja transfer S3. Klien transfer berbasis CRT menyediakan throughput dan keandalan yang ditingkatkan untuk operasi file besar:
aws configure set s3.preferred_transfer_client crt
Unggah model:
aws s3 cp ./llama-3.1-8b-instruct s3://$BUCKET_NAME/llama-3.1-8b-instruct \ --recursive
Output yang diharapkan akan terlihat seperti ini:
... upload: llama-3.1-8b-instruct/tokenizer.json to s3://model-store-1753EXAMPLE/llama-3.1-8b-instruct/tokenizer.json upload: llama-3.1-8b-instruct/model-00004-of-00004.safetensors to s3://model-store-1753890326/llama-3.1-8b-instruct/model-00004-of-00004.safetensors upload: llama-3.1-8b-instruct/model-00002-of-00004.safetensors to s3://model-store-1753890326/llama-3.1-8b-instruct/model-00002-of-00004.safetensors upload: llama-3.1-8b-instruct/model-00003-of-00004.safetensors to s3://model-store-1753890326/llama-3.1-8b-instruct/model-00003-of-00004.safetensors upload: llama-3.1-8b-instruct/model-00001-of-00004.safetensors to s3://model-store-1753890326/llama-3.1-8b-instruct/model-00001-of-00004.safetensors
Mengatur izin S3 Mountpoint CSI
Driver S3 Mountpoint CSI memungkinkan integrasi asli antara Kubernetes dan S3, memungkinkan pod untuk langsung mengakses file model seolah-olah mereka adalah penyimpanan lokal, menghilangkan kebutuhan akan salinan lokal selama startup container.
Buat kebijakan IAM agar titik pemasangan S3 dapat dibaca dari bucket S3 Anda:
aws iam create-policy \ --policy-name S3BucketAccess-${BUCKET_NAME} \ --policy-document "{\"Version\": \"2012-10-17\", \"Statement\": [{\"Effect\": \"Allow\", \"Action\": [\"s3:GetObject\", \"s3:GetObjectVersion\", \"s3:ListBucket\", \"s3:GetBucketLocation\"], \"Resource\": [\"arn:aws:s3:::${BUCKET_NAME}\", \"arn:aws:s3:::${BUCKET_NAME}/*\"]}]}"
Temukan nama peran IAM yang digunakan oleh S3 Mountpoint CSI Driver dengan memeriksa anotasi akun layanan S3 CSI Driver:
ROLE_NAME=$(kubectl get serviceaccount s3-csi-driver-sa -n kube-system -o jsonpath='{.metadata.annotations.eks\.amazonaws\.com/role-arn}' | cut -d'/' -f2)
Lampirkan kebijakan IAM Anda dengan peran S3 Mountpoint CSI:
aws iam attach-role-policy \ --role-name ${ROLE_NAME} \ --policy-arn arn:aws:iam::${AWS_ACCOUNT_ID}:policy/S3BucketAccess-${BUCKET_NAME}
Jika S3 Mountpoint CSI tidak diinstal di cluster, ikuti langkah-langkah penerapan di. Panduan Pengaturan Kluster Praktik Terbaik untuk Inferensi Waktu Nyata di Amazon EKS
Pasang bucket S3 sebagai volume Kubernetes
Buat Persistent Volume (PV) dan Persistent Volume Claim (PVC) untuk menyediakan akses read-only ke bucket S3 di beberapa pod inferensi. Mode ReadOnlyMany akses memastikan akses bersamaan ke file model, sedangkan driver CSI menangani pemasangan bucket S3:
cat <<EOF | envsubst | kubectl apply -f - apiVersion: v1 kind: PersistentVolume metadata: name: model-store spec: storageClassName: "" capacity: storage: 100Gi accessModes: - ReadOnlyMany persistentVolumeReclaimPolicy: Retain mountOptions: - region ${AWS_REGION} csi: driver: s3.csi.aws.com volumeHandle: model-store volumeAttributes: bucketName: ${BUCKET_NAME} --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: model-store spec: storageClassName: "" volumeName: model-store accessModes: - ReadOnlyMany resources: requests: storage: 100Gi EOF
Pengaturan Infrastruktur GPU
Node cluster
Kami menggunakan cluster EKS yang dibuat diPanduan Pengaturan Kluster Praktik Terbaik untuk Inferensi Waktu Nyata di Amazon EKS. Cluster ini mencakup nodepool Karpenter yang dapat menyediakan node berkemampuan GPU dengan penyimpanan node yang cukup untuk mengunduh gambar kontainer VllM. Jika menggunakan kluster EKS kustom Anda, pastikan klaster tersebut dapat meluncurkan node berkemampuan GPU.
Pemilihan Instance
Pemilihan instans yang tepat untuk inferensi LLM mengharuskan memastikan bahwa memori GPU yang tersedia cukup untuk memuat bobot model. Bobot model untuk Llama 3.1 8B Instruct kira-kira 16GB (ukuran file model.safetensor), oleh karena itu kita perlu menyediakan setidaknya jumlah memori ini ke proses vllm untuk memuat model.
Instans Amazon G5 dengan EC2 instans
Driver perangkat NVIDIA
Driver NVIDIA menyediakan lingkungan runtime yang diperlukan untuk kontainer untuk mengakses sumber daya GPU secara efisien. Ini memungkinkan alokasi dan manajemen sumber daya GPU di dalam Kubernetes, sehingga GPUs tersedia sebagai sumber daya yang dapat dijadwalkan.
Cluster kami menggunakan EKS Bottlerocket AMIs, yang mencakup semua driver dan plugin perangkat NVIDIA yang diperlukan di semua node yang mendukung GPU, memastikan aksesibilitas GPU langsung untuk beban kerja dalam kontainer tanpa pengaturan tambahan. Jika Anda menggunakan jenis node EKS lainnya, Anda perlu memastikan semua driver dan plugin yang diperlukan diinstal.
Uji Infrastruktur GPU
Uji kemampuan GPU klaster Anda dengan menjalankan langkah-langkah di bawah ini untuk memastikan pod dapat mengakses sumber daya GPU NVIDIA dan menjadwalkan dengan benar pada node yang mendukung GPU.
Menerapkan pod uji Nvidia SMI:
cat <<EOF | envsubst | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: gpu-nvidia-smi-test spec: restartPolicy: OnFailure tolerations: - key: "nvidia.com/gpu" operator: "Exists" effect: "NoSchedule" nodeSelector: role: gpu-worker # Matches GPU NodePool's label containers: - name: cuda-container image: nvidia/cuda:12.9.1-base-ubuntu20.04 command: ["nvidia-smi"] resources: requests: memory: "24Gi" limits: nvidia.com/gpu: 1 EOF
Tinjau log pod untuk memeriksa apakah detail GPU terdaftar, mirip dengan output di bawah ini (belum tentu model GPU yang sama):
$ kubectl wait --for=jsonpath='{.status.phase}'=Succeeded pod/gpu-nvidia-smi-test $ kubectl logs gpu-nvidia-smi-test
Wed Jul 30 15:39:58 2025 +-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 570.172.08 Driver Version: 570.172.08 CUDA Version: 12.9 | |-----------------------------------------+------------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+========================+======================| | 0 NVIDIA A10G On | 00000000:00:1E.0 Off | 0 | | 0% 30C P8 9W / 300W | 0MiB / 23028MiB | 0% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+ +-----------------------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=========================================================================================| | No running processes found | +-----------------------------------------------------------------------------------------+
Output ini menunjukkan bahwa pod dapat berhasil mengakses sumber daya GPU.
PENTING: Pod ini menggunakan konfigurasi nodeSelector yang sejajar dengan kumpulan node Karpenter di dalamnya. Panduan Pengaturan Kluster Praktik Terbaik untuk Inferensi Waktu Nyata di Amazon EKS Jika Anda menggunakan kumpulan node yang berbeda, pastikan pod cocok dengan NodeSelector dan Tolerations yang sesuai.
Menyebarkan Wadah Inferensi
Tumpukan penyajian menentukan kinerja dan kemampuan skalabilitas infrastruktur inferensi Anda. VllM telah muncul sebagai solusi terdepan untuk penerapan produksi. Arsitektur vllM menyediakan batching berkelanjutan untuk pemrosesan permintaan dinamis, pengoptimalan kernel untuk inferensi yang lebih cepat, dan manajemen memori GPU yang efisien. PagedAttention Fitur-fitur ini, dikombinasikan dengan REST API siap produksi dan dukungan untuk format model populer, menjadikannya pilihan optimal untuk penerapan inferensi berkinerja tinggi.
Pilih gambar AWS Deep Learning Container
AWS Deep Learning Containers
Untuk penerapan ini, kami akan menggunakan AWS DLC untuk VllM 0.9, yang mencakup pustaka Nvidia dan konfigurasi kinerja GPU yang dioptimalkan yang secara khusus disetel untuk inferensi model transformator pada instance GPU. AWS
image: 763104351884.dkr.ecr.us-east-1.amazonaws.com/vllm:0.9-gpu-py312-ec2
Terapkan manifes VllM Kubernetes
Ada beberapa cara untuk menerapkan VllM di EKS. Panduan ini mendemonstrasikan penerapan VLLM menggunakan penerapan Kubernetes, yang merupakan cara asli Kubernetes dan mudah untuk memulai. Untuk opsi penerapan lanjutan, lihat dokumen VllM dan AI
Tentukan parameter penerapan melalui manifes Kubernetes untuk mengontrol alokasi sumber daya, penempatan node, probe kesehatan, mengekspos layanan, dll. Konfigurasikan penerapan Anda untuk menjalankan pod berkemampuan GPU menggunakan image AWS Deep Learning Container untuk VllM. Tetapkan parameter yang dioptimalkan untuk inferensi LLM dan paparkan titik akhir yang kompatibel dengan OpenAPI VLLM melalui layanan Load Balancer: AWS
cat <<EOF | envsubst | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: vllm-inference-app spec: replicas: 1 selector: matchLabels: app: vllm-inference-app template: metadata: labels: app: vllm-inference-app spec: tolerations: - key: "nvidia.com/gpu" operator: "Exists" effect: "NoSchedule" nodeSelector: role: gpu-worker containers: - name: vllm-inference image: 763104351884.dkr.ecr.us-east-1.amazonaws.com/vllm:0.9-gpu-py312-ec2 ports: - containerPort: 8000 env: - name: MODEL_PATH value: "/mnt/models/llama-3.1-8b-instruct" args: - "--model=/mnt/models/llama-3.1-8b-instruct" - "--host=0.0.0.0" - "--port=8000" - "--tensor-parallel-size=1" - "--gpu-memory-utilization=0.9" - "--max-model-len=8192" - "--max-num-seqs=1" readinessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 30 periodSeconds: 5 timeoutSeconds: 10 resources: limits: nvidia.com/gpu: 1 requests: memory: "24Gi" cpu: "4" ephemeral-storage: "25Gi" # Ensure enough node storage for vLLM container image volumeMounts: - name: models mountPath: /mnt/models readOnly: true volumes: - name: models persistentVolumeClaim: claimName: model-store --- apiVersion: v1 kind: Service metadata: name: vllm-inference-svc annotations: service.beta.kubernetes.io/aws-load-balancer-type: nlb service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing spec: type: LoadBalancer ports: - port: 80 targetPort: 8000 protocol: TCP selector: app: vllm-inference-app EOF
Periksa apakah pod VllM dalam Ready 1/1 status:
kubectl get pod -l app=vllm-inference-app -w
Keluaran yang diharapkan
NAME READY UP-TO-DATE AVAILABLE AGE vllm-inference-app-65df5fddc8-5kmjm 1/1 1 1 5m
Mungkin diperlukan beberapa menit saat gambar kontainer ditarik dan Vllm memuat file model ke dalam memori GPU. Hanya lanjutkan ketika pod sudah Siap dan Tersedia.
Mengekspos layanan
Paparkan titik akhir inferensi secara lokal melalui penerusan port Kubernetes untuk pengembangan dan pengujian lokal. Biarkan perintah ini berjalan di jendela terminal terpisah:
export POD_NAME=$(kubectl get pod -l app=vllm-inference-app -o jsonpath='{.items[0].metadata.name}') kubectl port-forward pod/$POD_NAME 8000:8000
AWS Load Balancer Controller secara otomatis membuat Network Load Balancer yang mengekspos titik akhir layanan VLLm secara eksternal. Ambil titik akhir NLB dengan menjalankan:
NLB=$(kubectl get service vllm-inference-svc -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
Perlu menginstal AWS Load Balancer Controller? Ikuti langkah-langkah penerapan diRute lalu lintas internet dengan AWS Load Balancer Controller.
Jalankan inferensi
Validasi pod inferensi
Validasi fungsionalitas kontainer inferensi secara lokal melalui port yang diteruskan. Kirim permintaan koneksi dan pastikan bahwa responsnya menyertakan kode HTTP 200:
$ curl -IX GET "http://localhost:8000/v1/models"
HTTP/1.1 200 OK date: Mon, 13 Oct 2025 23:24:57 GMT server: uvicorn content-length: 516 content-type: application/json
Uji kemampuan inferensi dan validasi konektivitas eksternal dengan mengirimkan permintaan penyelesaian ke LLM melalui titik akhir NLB:
curl -X POST "http://$NLB:80/v1/completions" \ -H "Content-Type: application/json" \ -d '{ "model": "/mnt/models/llama-3.1-8b-instruct", "prompt": "Explain artificial intelligence:", "max_tokens": 512, "temperature": 0.7 }'
Titik akhir ini mengikuti format OpenAI API, membuatnya kompatibel dengan aplikasi yang ada sambil menyediakan parameter generasi yang dapat dikonfigurasi seperti panjang respons dan suhu untuk mengontrol keragaman keluaran.
Jalankan aplikasi chatbot
Untuk demonstrasi, panduan ini menjalankan contoh aplikasi chatbot menggunakan proyek nextjs-vllm-ui
Jalankan UI chatbot sebagai wadah Docker yang memetakan port 3000 ke localhost dan terhubung ke titik akhir VllM NLB:
docker run --rm \ -p 3000:3000 \ -e VLLM_URL="http://${NLB}:80" \ --name nextjs-vllm-ui-demo \ ghcr.io/yoziru/nextjs-vllm-ui:latest
Buka browser web Anda dan arahkan ke: http://localhost:3000/
Anda akan melihat antarmuka obrolan tempat Anda dapat berinteraksi dengan model Llama.
Antarmuka UI Obrolan
Optimalkan kinerja inferensi
Mesin inferensi khusus seperti VllM menyediakan fitur-fitur canggih yang secara signifikan meningkatkan kinerja inferensi, termasuk batching berkelanjutan, caching KV yang efisien, dan mekanisme perhatian memori yang dioptimalkan. Anda dapat menyetel parameter konfigurasi VllM untuk meningkatkan kinerja inferensi sambil memenuhi persyaratan kasus penggunaan spesifik dan pola beban kerja Anda. Konfigurasi yang tepat sangat penting untuk mencapai saturasi GPU, memastikan Anda mengekstrak nilai maksimum dari sumber daya GPU yang mahal sambil memberikan throughput tinggi, latensi rendah, dan operasi hemat biaya. Pengoptimalan berikut akan membantu Anda memaksimalkan kinerja penerapan VLLM Anda di EKS.
Konfigurasi Benchmark VllM
Untuk menyetel parameter konfigurasi vLLM untuk kasus penggunaan Anda, benchmark pengaturan yang berbeda menggunakan alat benchmarking inferensi komprehensif seperti GuidelLM.
Konfigurasi Vllm dasar
Ini adalah konfigurasi dasar yang digunakan untuk menjalankan VllM:
| Parameter Vllm | Deskripsi |
|---|---|
|
tensor_parallel_size: 1 |
Mendistribusikan model di 1 GPU |
|
gpu_memory_utilization: 0,90 |
Cadangan memori GPU 10% untuk overhead sistem |
|
max_sequence_length: 8192 |
Panjang urutan total maksimum (input+output) |
|
max_num_seqs: 1 |
Permintaan bersamaan maksimum per GPU (Batching) |
Jalankan GuidelLM dengan pengaturan dasar ini untuk membuat baseline kinerja. Untuk pengujian ini, GuidellM dikonfigurasi untuk menghasilkan 1 permintaan per detik, dengan 256-token request dan 128-token response.
guidellm benchmark \ --target "http://${NLB}:80" \ --processor meta-llama/Llama-3.1-8B-Instruct \ --rate-type constant \ --rate 1 \ --max-seconds 30 \ --data "prompt_tokens=256,output_tokens=128"
Keluaran yang diharapkan
Hasil Tolok Ukur Dasar
Konfigurasi Vllm yang disetel
Sesuaikan parameter VllM untuk memanfaatkan sumber daya GPU dan paralelisasi dengan lebih baik:
| Parameter Vllm | Deskripsi |
|---|---|
|
tensor_parallel_size: 1 |
Tetap di 1 GPU. Paralelisasi tensor harus sesuai dengan jumlah yang akan digunakan oleh GPUs VllM |
|
gpu_memory_utilization: 0,92 |
Kurangi memori GPU overhead jika memungkinkan, sambil memastikan bahwa VllM terus berjalan tanpa kesalahan |
|
max_sequence_length: 4096 |
Sesuaikan urutan maks sesuai persyaratan kasus penggunaan Anda; urutan maks yang lebih rendah membebaskan sumber daya yang dapat digunakan untuk meningkatkan paralelisasi |
|
max_num_seqs: 8 |
Meningkatkan max seq meningkatkan throughput tetapi juga meningkatkan latensi. Tingkatkan nilai ini untuk memaksimalkan throughput sekaligus memastikan bahwa latensi tetap sesuai dengan persyaratan kasus penggunaan Anda |
Terapkan perubahan ini ke penerapan yang sedang berjalan menggunakan perintah kubectl patch:
kubectl patch deployment vllm-inference-app --type='json' -p='[ {"op": "replace", "path": "/spec/template/spec/containers/0/args/4", "value": "--gpu-memory-utilization=0.92"}, {"op": "replace", "path": "/spec/template/spec/containers/0/args/5", "value": "--max-model-len=4096"}, {"op": "replace", "path": "/spec/template/spec/containers/0/args/6", "value": "--max-num-seqs=8"} ]'
Periksa apakah pod VllM dalam Ready 1/1 status:
kubectl get pod -l app=vllm-inference-app -w
Keluaran yang diharapkan
NAME READY UP-TO-DATE AVAILABLE AGE vllm-inference-app-65df5fddc8-5kmjm 1/1 1 1 5m
Kemudian jalankan GuidellM lagi menggunakan nilai benchmarking yang sama seperti sebelumnya:
guidellm benchmark \ --target "http://${NLB}:80" \ --processor meta-llama/Llama-3.1-8B-Instruct \ --rate-type constant \ --rate 1 \ --max-seconds 30 \ --data "prompt_tokens=256,output_tokens=128"
Keluaran yang diharapkan
Hasil Benchmark yang Dioptimalkan
Hasil benchmarking
Hitung hasil benchmarking dalam tabel untuk konfigurasi VllM dasar dan yang dioptimalkan:
| Nilai Rata-Rata | Konfigurasi dasar | Konfigurasi yang dioptimalkan |
|---|---|---|
|
RPS |
0,23 req/detik |
0,86 req/detik |
|
E2E |
12,99 s |
5.19 s |
|
TTFT |
8637,2 ms |
147,9 ms |
|
TPOT |
34,0 ms |
39,5 ms |
Konfigurasi VllM yang dioptimalkan secara signifikan meningkatkan throughput inferensi (RPS) dan mengurangi latensi (E2E, TTFT) dengan hanya peningkatan milidetik kecil dalam latensi ekor (TPOT). Hasil ini menunjukkan bagaimana VllM secara signifikan meningkatkan kinerja inferensi, memungkinkan setiap kontainer memproses lebih banyak permintaan dalam waktu yang lebih singkat untuk operasi yang hemat biaya.
