**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 High-throughput LLM dengan VllM di Amazon EKS
<a name="ml-realtime-inference-llm-inference-vllm"></a>

## Pengantar
<a name="_introduction"></a>

Panduan memulai cepat ini menyediakan panduan untuk menerapkan Model Bahasa Besar (LLM) di Amazon EKS menggunakan VLLm dan GPU 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).](https://docs.vllm.ai/en/latest/models/supported_models.html#list-of-text-only-language-models) [Untuk menguji inferensi LLM, kami menggunakan contoh aplikasi chatbot berdasarkan proyek nextjs-vllm-ui.](https://github.com/yoziru/nextjs-vllm-ui) Terakhir, kami menggunakan GuidelLM untuk membandingkan dan menyetel parameter konfigurasi VLLM untuk mengoptimalkan kinerja inferensi.

 **Arsitektur VllM di EKS** 

![Diagram Arsitektur VllM](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/llm-inference-vllm-architecture.png)


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 lainnya. LLM-based 

Untuk panduan tambahan dan sumber daya penerapan lanjutan, lihat [Panduan Praktik Terbaik EKS kami untuk AI/ML beban kerja](https://docs.aws.amazon.com/eks/latest/best-practices/aiml.html) dan [AI](https://github.com/awslabs/ai-on-eks/tree/main/blueprints/inference/inference-charts) siap produksi pada bagan inferensi EKS.

## Sebelum Anda mulai
<a name="_before_you_begin"></a>

Sebelum memulai, pastikan Anda memiliki:
+ Cluster Amazon EKS dengan komponen utama berikut: Nodepool Karpenter dengan keluarga instans G5 atau G6 EC2, Plugin Perangkat NVIDIA yang diinstal pada node GPU-enabled pekerja Anda, dan Driver CSI S3 Mountpoint diinstal. Untuk membuat penyiapan dasar ini, ikuti langkah-langkah[Panduan Pengaturan Kluster Praktik Terbaik untuk Inferensi Waktu Nyata di Amazon EKS](ml-realtime-inference-cluster.md), hingga menyelesaikan langkah \#4.
+ Akun Hugging Face. Untuk mendaftar, lihat https://huggingface.co/login.

## Mengatur Penyimpanan Model dengan Amazon S3
<a name="_set_up_model_storage_with_amazon_s3"></a>

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 for Lustre. Untuk informasi lebih lanjut, periksa [Praktik Terbaik EKS](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-storage.html).

### Tetapkan variabel lingkungan
<a name="_set_environment_variables"></a>

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
<a name="_create_an_s3_bucket_to_store_model_files"></a>

Buat bucket S3 untuk menyimpan file model:

```
aws s3 mb s3://${BUCKET_NAME} --region ${AWS_REGION}
```

### Unduh model dari Hugging Face
<a name="_download_model_from_hugging_face"></a>

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:

1. Terima lisensi model Instruct Llama 3.1 8B di https://huggingface.co/meta-llama/Llama-3.1-8B-Instruct.

1. 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](https://huggingface.co/docs/huggingface_hub/main/en/guides/cli) Face:

```
pip install huggingface-hub
```

Unduh Llama-3.1-8B-Instruct model dari Hugging Face (\~ 15 GB) menggunakan `--exclude` bendera untuk melewati format PyTorch lama dan hanya mengunduh file format safetensor 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
<a name="_upload_model_files"></a>

Aktifkan AWS Common Runtime (CRT) untuk meningkatkan kinerja transfer S3. Klien CRT-based transfer 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
<a name="_set_up_s3_mountpoint_csi_permissions"></a>

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](ml-realtime-inference-cluster.md)

### Pasang bucket S3 sebagai volume Kubernetes
<a name="_mount_s3_bucket_as_a_kubernetes_volume"></a>

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
<a name="_gpu_infrastructure_setup"></a>

### Node cluster
<a name="_cluster_nodes"></a>

Kami menggunakan cluster EKS yang dibuat di[Panduan Pengaturan Kluster Praktik Terbaik untuk Inferensi Waktu Nyata di Amazon EKS](ml-realtime-inference-cluster.md). 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 EC2 dengan GPU A10G dan instans](https://aws.amazon.com/ec2/instance-types/g5/) [G6 EC2 dengan GPU L4 keduanya menyediakan VRAM 24GB per GPU, cukup untuk memuat bobot Instruct](https://aws.amazon.com/ec2/instance-types/g6/) Llama 3.1 8B. Jika Anda menerapkan model dengan bobot yang lebih besar, pertimbangkan untuk menggunakan tipe instans multi-GPU atau pengaturan multi-node.

 **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, membuat GPU tersedia sebagai sumber daya yang dapat dijadwalkan.

Cluster kami menggunakan EKS Bottlerocket AMI, yang mencakup semua driver dan plugin perangkat NVIDIA yang diperlukan di semua GPU-enabled node, memastikan aksesibilitas GPU langsung untuk beban kerja kontainer tanpa pengaturan tambahan. Jika Anda menggunakan jenis node EKS lainnya, Anda perlu memastikan semua driver dan plugin yang diperlukan diinstal.

### Uji Infrastruktur GPU
<a name="_test_gpu_infrastructure"></a>

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. GPU-enabled 

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](ml-realtime-inference-cluster.md) Jika Anda menggunakan kumpulan node yang berbeda, pastikan pod cocok dengan NodeSelector dan Tolerations.

## Menyebarkan Wadah Inferensi
<a name="_deploy_inference_container"></a>

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
<a name="select_shared_aws_deep_learning_container_image"></a>

 [AWS Deep Learning Containers](https://github.com/aws/deep-learning-containers/tree/master) (DLC) menyediakan lingkungan yang telah dioptimalkan sebelumnya dengan pembaruan keamanan, kompatibilitas AWS infrastruktur, dan konfigurasi driver yang dioptimalkan. Ini mengurangi kompleksitas penerapan dan overhead pemeliharaan sekaligus memastikan kesiapan produksi.

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
<a name="_apply_vllm_kubernetes_manifests"></a>

Ada beberapa cara untuk menerapkan VllM di EKS. Panduan ini mendemonstrasikan penerapan VLLM menggunakan penerapan Kubernetes, yang merupakan cara mudah untuk memulai. Kubernetes-native Untuk opsi penerapan lanjutan, lihat [dokumen VllM dan [AI](https://awslabs.github.io/ai-on-eks/docs/blueprints) di cetak biru EKS](https://docs.vllm.ai/en/latest/deployment/k8s.html).

Tentukan parameter penerapan melalui manifes Kubernetes untuk mengontrol alokasi sumber daya, penempatan node, probe kesehatan, mengekspos layanan, dll. Konfigurasikan penerapan Anda untuk menjalankan GPU-enabled pod menggunakan image AWS Deep Learning Container untuk VllM. Tetapkan parameter yang dioptimalkan untuk inferensi LLM dan paparkan titik akhir VllM OpenAPI-compatible 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
<a name="_expose_the_service"></a>

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 di[Rute lalu lintas internet dengan AWS Load Balancer Controller](aws-load-balancer-controller.md).

## Jalankan inferensi
<a name="_run_inference"></a>

### Validasi pod inferensi
<a name="_validate_inference_pod"></a>

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
<a name="_run_chatbot_app"></a>

Untuk demonstrasi, panduan ini menjalankan contoh aplikasi chatbot menggunakan project [nextjs-vllm-ui](https://github.com/yoziru/nextjs-vllm-ui) untuk menampilkan interaksi pengguna dengan model.

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 ::3000/ http://localhost

Anda akan melihat antarmuka obrolan tempat Anda dapat berinteraksi dengan model Llama.

 **Antarmuka UI Obrolan** 

![Antarmuka UI Obrolan](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/llm-inference-vllm-chatui.png)


## Optimalkan kinerja inferensi
<a name="_optimize_inference_performance"></a>

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
<a name="_benchmark_vllm_configurations"></a>

[Untuk menyetel parameter konfigurasi vLLM untuk kasus penggunaan Anda, benchmark pengaturan yang berbeda menggunakan alat benchmarking inferensi komprehensif seperti GuidelLM.](https://github.com/vllm-project/guidellm) Ini akan mengumpulkan metrik kunci seperti request per second throughput (RPS), end-to-end latency (E2E), time to first token (TTFT), dan time per output token (TPOT) untuk membandingkan konfigurasi yang berbeda.

### Konfigurasi Vllm dasar
<a name="_baseline_vllm_configuration"></a>

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 penyiapan 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** 

![Hasil Tolok Ukur Dasar](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/llm-inference-vllm-guidellm-baseline.png)


### Konfigurasi Vllm yang disetel
<a name="_tuned_vllm_configuration"></a>

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 GPU yang akan digunakan oleh 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 Benchmark yang Dioptimalkan](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/llm-inference-vllm-guidellm-optimized.png)


### Hasil benchmarking
<a name="_benchmarking_results"></a>

Hitung hasil benchmarking dalam tabel untuk konfigurasi VllM dasar dan yang dioptimalkan:


| Nilai Rata-rata | Konfigurasi dasar | Konfigurasi yang dioptimalkan | 
| --- | --- | --- | 
| RPS | 0,23 req/sec | 0,86 req/sec | 
| 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 waktu per token keluaran (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.