**協助改進此頁面** 

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 GitHub 上編輯此頁面**連結。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 快速入門：Amazon EKS 上使用 vLLM 進行高輸送量 LLM 推論
<a name="ml-realtime-inference-llm-inference-vllm"></a>

## 簡介
<a name="_introduction"></a>

本快速入門指南提供使用 LLMs 和 GPUs 在 Amazon EKS 上部署大型語言模型 (LLM) 的逐步解說，以供文字型即時推論應用程式使用。

該解決方案利用 Amazon EKS 進行容器協同運作和 vLLM 提供高效率的模型服務，讓您能夠使用 GPU 加速和高輸送量推論服務來建置可擴展的 AI 應用程式。Llama 3.1 8B 指示模型用於示範，但您可以部署任何其他 vLLM 支援的 LLM （如需支援的模型清單，請參閱 [vLLM 文件](https://docs.vllm.ai/en/latest/models/supported_models.html#list-of-text-only-language-models))。為了測試 LLM 推論，我們使用以專案 [nextjs-vllm-ui](https://github.com/yoziru/nextjs-vllm-ui) 為基礎的範例聊天機器人應用程式。最後，我們使用 GuideLLM 對 vLLM 組態參數進行基準測試和調校，以最佳化推論效能。

 **EKS 上的 vLLM 架構** 

![vLLM 架構圖](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/llm-inference-vllm-architecture.png)


當您完成此程序時，將會有針對輸送量和低延遲最佳化的 vLLM 推論端點，而且您可以透過聊天前端應用程式與 Llama 模型互動，示範聊天機器人助理和其他 LLM 型應用程式的典型使用案例。

如需其他指引和進階部署資源，請參閱我們的 [AI/ML 工作負載和生產就緒 AI on EKS 推論圖表的 EKS 最佳實務指南](https://docs.aws.amazon.com/eks/latest/best-practices/aiml.html)。 [https://github.com/awslabs/ai-on-eks/tree/main/blueprints/inference/inference-charts](https://github.com/awslabs/ai-on-eks/tree/main/blueprints/inference/inference-charts)

## 開始之前
<a name="_before_you_begin"></a>

開始使用之前，請確定您已：
+ 具有下列主要元件的 Amazon EKS 叢集：具有 G5 或 G6 EC2 執行個體系列的 Karpenter 節點集區、安裝在已啟用 GPU 的工作者節點上的 NVIDIA 裝置外掛程式，以及已安裝的 S3 掛載點 CSI 驅動程式。若要建立此基準設定，請遵循中的步驟[Amazon EKS 即時推論的最佳實務叢集設定指南](ml-realtime-inference-cluster.md)，直到完成步驟 \#4。
+ Hugging Face 帳戶。若要註冊，請參閱 https：//https://huggingface.co/login。

## 使用 Amazon S3 設定模型儲存
<a name="_set_up_model_storage_with_amazon_s3"></a>

在 Amazon S3 中有效率地存放大型 LLM 檔案，以將儲存與運算資源分開。此方法可簡化模型更新、降低成本，並簡化生產設定中的管理。S3 可靠地處理大量檔案，而透過掛載點 CSI 驅動程式與 Kubernetes 整合可讓 Pod 存取本機儲存體等模型，無需在啟動期間進行耗時的下載。請依照下列步驟建立 S3 儲存貯體、上傳 LLM，並將其掛載為推論服務容器中的磁碟區。

其他儲存解決方案也可用於模型快取的 EKS，例如 EFS 和 FSx for Lustre。如需詳細資訊，請參閱 [EKS 最佳實務](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-storage.html)。

### 設定環境變數
<a name="_set_environment_variables"></a>

為我們將在本指南稍後建立的新 Amazon S3 儲存貯體建立唯一名稱。建立之後，請針對所有步驟使用相同的儲存貯體名稱。例如：

```
MY_BUCKET_NAME=model-store-$(date +%s)
```

定義環境變數並將其存放在檔案中：

```
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
```

在 shell 環境中載入環境變數。如果您關閉目前的 shell 環境並開啟新的環境，請務必使用此相同的命令來重新來源環境變數：

```
source .env-quickstart-vllm
```

### 建立 S3 儲存貯體以存放模型檔案
<a name="_create_an_s3_bucket_to_store_model_files"></a>

建立 S3 儲存貯體以存放模型檔案：

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

### 從 Hugging Face 下載模型
<a name="_download_model_from_hugging_face"></a>

Hugging Face 是存取 LLM 模型的主要模型中樞之一。若要下載 Llama 模型，您需要接受模型授權並設定權杖身分驗證：

1. 接受位於 https：//https://huggingface.co/meta-llama/Llama-3.1-8B-Instruct 的 Llama 3.1 8B 指示模型授權。

1. 產生存取權杖 （前往您的設定檔 > 設定 > 存取權杖，然後使用讀取權杖類型建立新的權杖）。

使用 Hugging Face 字符設定環境變數：

```
export HF_TOKEN=your_token_here
```

如果您的環境中尚未安裝 pip3 套件，請進行安裝。Amazon Linux 2023 中的範例命令：

```
sudo dnf install -y python3-pip
```

安裝 [Hugging Face CLI](https://huggingface.co/docs/huggingface_hub/main/en/guides/cli)：

```
pip install huggingface-hub
```

使用 `--exclude`旗標從 Hugging Face (\~15 GB) 下載 Llama-3.1-8B-Instruct 模型，以略過舊版 PyTorch 格式，並僅下載最佳化的安全張量格式檔案，減少下載大小，同時維持與熱門推論引擎的完整相容性：

```
huggingface-cli download meta-llama/Meta-Llama-3.1-8B-Instruct \
  --exclude "original/*" \
  --local-dir ./llama-3.1-8b-instruct \
  --token $HF_TOKEN
```

驗證下載的檔案：

```
$ ls llama-3.1-8b-instruct
```

預期的輸出應類似以下：

```
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
```

### 上傳模型檔案
<a name="_upload_model_files"></a>

啟用 AWS 通用執行時間 (CRT) 以改善 S3 傳輸效能。以 CRT 為基礎的傳輸用戶端可為大型檔案操作提供增強的輸送量和可靠性：

```
aws configure set s3.preferred_transfer_client crt
```

上傳模型：

```
aws s3 cp ./llama-3.1-8b-instruct s3://$BUCKET_NAME/llama-3.1-8b-instruct \
  --recursive
```

預期的輸出應類似以下：

```
...
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
```

### 設定 S3 掛載點 CSI 許可
<a name="_set_up_s3_mountpoint_csi_permissions"></a>

S3 掛載點 CSI 驅動程式可在 Kubernetes 和 S3 之間進行原生整合，讓 Pod 如同本機儲存一樣直接存取模型檔案，無需在容器啟動期間進行本機複本。

建立 IAM 政策以允許 S3 掛載點從您的 S3 儲存貯體讀取：

```
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}/*\"]}]}"
```

檢查 S3 CSI 驅動程式服務帳戶註釋，以尋找 S3 掛載點 CSI 驅動程式使用的 IAM 角色名稱：

```
ROLE_NAME=$(kubectl get serviceaccount s3-csi-driver-sa -n kube-system -o jsonpath='{.metadata.annotations.eks\.amazonaws\.com/role-arn}' | cut -d'/' -f2)
```

使用 S3 掛載點 CSI 角色連接您的 IAM 政策：

```
aws iam attach-role-policy \
 --role-name ${ROLE_NAME} \
 --policy-arn arn:aws:iam::${AWS_ACCOUNT_ID}:policy/S3BucketAccess-${BUCKET_NAME}
```

如果叢集中未安裝 S3 掛載點 CSI，請遵循中的部署步驟[Amazon EKS 即時推論的最佳實務叢集設定指南](ml-realtime-inference-cluster.md)。

### 將 S3 儲存貯體掛載為 Kubernetes 磁碟區
<a name="_mount_s3_bucket_as_a_kubernetes_volume"></a>

建立持久性磁碟區 (PV) 和持久性磁碟區宣告 (PVC)，以跨多個推論 Pod 提供對 S3 儲存貯體的唯讀存取。ReadOnlyMany 存取模式可確保同時存取模型檔案，而 CSI 驅動程式則處理 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
```

## GPU 基礎設施設定
<a name="_gpu_infrastructure_setup"></a>

### 叢集節點
<a name="_cluster_nodes"></a>

我們使用在 中建立的 EKS 叢集[Amazon EKS 即時推論的最佳實務叢集設定指南](ml-realtime-inference-cluster.md)。此叢集包含 Karpenter 節點集區，可佈建已啟用 GPU 的節點，並具有足夠的節點儲存體，以下載 vLLM 容器映像。如果使用您的自訂 EKS 叢集，請確保它可以啟動已啟用 GPU 的節點。

 **執行個體選取** 

LLM 推論的適當執行個體選擇需要確保可用的 GPU 記憶體足以載入模型權重。Llama 3.1 8B Instruct 的模型權重約為 16GB （模型檔案的大小 .safetensor)，因此我們需要為 vllm 程序提供至少此數量的記憶體，才能載入模型。

 具有 A10G GPUs 的 [Amazon G5 EC2 執行個體](https://aws.amazon.com/ec2/instance-types/g5/)和具有 L4 GPUs 的 [G6 EC2 執行個體](https://aws.amazon.com/ec2/instance-types/g6/)每個 GPU 都提供 24GB VRAM，足以載入 Llama 3.1 8B 指示權重。如果您要部署具有較大權重的模型，請考慮使用多 GPU 執行個體類型或多節點設定。

 **NVIDIA 裝置驅動程式** 

NVIDIA 驅動程式為容器提供必要的執行期環境，以有效率地存取 GPU 資源。它可在 Kubernetes 中啟用 GPU 資源配置和管理，讓 GPUs 成為可排程的資源。

我們的叢集使用 EKS Bottlerocket AMIs，其中包含所有必要的 NVIDIA 裝置驅動程式和所有啟用 GPU 節點的外掛程式，確保容器化工作負載的立即 GPU 可存取性，而無需額外設定。如果您使用其他類型的 EKS 節點，則需要確保已安裝所有必要的驅動程式和外掛程式。

### 測試 GPU 基礎設施
<a name="_test_gpu_infrastructure"></a>

透過執行以下步驟來測試叢集的 GPU 功能，以確保 Pod 可以存取 NVIDIA GPU 資源，並在啟用 GPU 的節點上正確排程。

部署 Nvidia SMI 測試 Pod：

```
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
```

檢閱 Pod 日誌以檢查是否已列出 GPU 詳細資訊，類似於以下輸出 （不一定是相同的 GPU 模型）：

```
$ 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                                                             |
+-----------------------------------------------------------------------------------------+
```

此輸出顯示 Pod 可以成功存取 GPU 資源。

 **重要：**此 Pod 使用符合 中 Karpenter 節點集區的 nodeSelector 組態[Amazon EKS 即時推論的最佳實務叢集設定指南](ml-realtime-inference-cluster.md)。如果您使用不同的節點集區，請確保 Pod 相應地符合 nodeSelector 和容錯。

## 部署推論容器
<a name="_deploy_inference_container"></a>

服務堆疊可決定推論基礎設施的效能和可擴展性功能。vLLM 已成為生產部署的領導解決方案。vLLM 的架構透過 PagedAttention 提供動態請求處理的持續批次處理、加速推論的核心最佳化，以及高效率的 GPU 記憶體管理。這些功能結合生產就緒的 REST API 和對熱門模型格式的支援，使其成為高效能推論部署的最佳選擇。

### 選取 AWS 深度學習容器映像
<a name="select_shared_aws_deep_learning_container_image"></a>

 [AWS 深度學習容器 ](https://github.com/aws/deep-learning-containers/tree/master)(DLCs) 為預先最佳化的環境提供安全性更新、 AWS 基礎設施相容性和最佳化驅動程式組態。這可降低部署複雜性和維護開銷，同時確保生產準備。

在此部署中，我們將使用適用於 vLLM 0.9 的 AWS DLC，其中包括 Nvidia 程式庫和專門針對 GPU 執行個體上的轉換器模型推論而調整的最佳化 AWS GPU 效能組態。

```
image: 763104351884.dkr.ecr.us-east-1.amazonaws.com/vllm:0.9-gpu-py312-ec2
```

### 套用 vLLM Kubernetes 資訊清單
<a name="_apply_vllm_kubernetes_manifests"></a>

在 EKS 中部署 vLLM 有多種方式。本指南示範使用 Kubernetes 部署的 vLLM 部署，這是 Kubernetes 原生且易於入門的方式。如需進階部署選項，請參閱 [vLLM 文件](https://docs.vllm.ai/en/latest/deployment/k8s.html)和 [AI on EKS 藍圖](https://awslabs.github.io/ai-on-eks/docs/blueprints)。

透過 Kubernetes 資訊清單定義部署參數，以控制資源配置、節點放置、運作狀態探查、公開服務等。將部署設定為使用 vLLM AWS 的深度學習容器映像執行已啟用 GPU 的 Pod。設定 LLM 推論的最佳化參數，並透過 AWS Load Balancer服務公開 vLLM OpenAPI 相容端點：

```
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
```

檢查 vLLM Pod 是否處於 `Ready 1/1` 狀態：

```
kubectl get pod -l app=vllm-inference-app -w
```

預期的輸出結果：

```
NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
vllm-inference-app-65df5fddc8-5kmjm   1/1     1            1           5m
```

提取容器映像和 vLLM 將模型檔案載入 GPU 記憶體時，可能需要幾分鐘的時間。只有在 Pod 就緒且可用時，才能繼續。

### 公開服務
<a name="_expose_the_service"></a>

透過本機開發和測試的 Kubernetes 連接埠轉送，在本機公開推論端點。讓此命令在不同的終端機視窗中執行：

```
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控制器會自動建立 Network Load Balancer，在外部公開 vLLM 服務端點。執行下列動作以擷取 NLB 端點：

```
NLB=$(kubectl get service vllm-inference-svc -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
```

需要安裝 AWS Load Balancer控制器？ 遵循中的部署步驟[使用 AWS Load Balancer控制器路由網際網路流量](aws-load-balancer-controller.md)。

## 執行推論
<a name="_run_inference"></a>

### 驗證推論 Pod
<a name="_validate_inference_pod"></a>

透過轉送連接埠在本機驗證推論容器功能。傳送連線請求，並確保回應包含 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
```

透過 NLB 端點傳送完成請求至 LLM，以測試推論功能並驗證外部連線：

```
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
  }'
```

此端點遵循 OpenAI API 格式，使其與現有應用程式相容，同時提供可設定的產生參數，例如回應長度和溫度，以控制輸出多樣性。

### 執行聊天機器人應用程式
<a name="_run_chatbot_app"></a>

為了示範，本指南使用專案 [nextjs-vllm-ui](https://github.com/yoziru/nextjs-vllm-ui) 執行範例聊天機器人應用程式，以展示使用者與模型的互動。

將聊天機器人 UI 做為 Docker 容器執行，將連接埠 3000 映射至 localhost，並連線至 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
```

開啟您的 Web 瀏覽器並導覽至：http：//localhost：3000/

您應該會看到聊天界面，您可以在其中與 Llama 模型互動。

 **聊天 UI 介面** 

![聊天 UI 介面](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/llm-inference-vllm-chatui.png)


## 最佳化推論效能
<a name="_optimize_inference_performance"></a>

vLLM 等專用推論引擎提供進階功能，可大幅提升推論效能，包括持續批次處理、高效 KV 快取和最佳化記憶體關注機制。您可以調校 vLLM 組態參數來改善推論效能，同時滿足您的特定使用案例需求和工作負載模式。適當的組態對於達到 GPU 飽和至關重要，可確保從昂貴的 GPU 資源中擷取最大值，同時提供高輸送量、低延遲和經濟實惠的操作。下列最佳化可協助您在 EKS 上最大化 vLLM 部署的效能。

### 基準 vLLM 組態
<a name="_benchmark_vllm_configurations"></a>

若要調整使用案例的 vLLM 組態參數，請使用 [GuideLLM](https://github.com/vllm-project/guidellm) 等全面的推論基準測試工具來基準測試不同的設定。這將收集關鍵指標，例如每秒請求輸送量 (RPS)、end-to-end(E2E)、到第一個字符的時間 (TTFT) 和每個輸出字符的時間 (TPOT)，以比較不同的組態。

### 基準 vLLM 組態
<a name="_baseline_vllm_configuration"></a>

這是用來執行 vLLM 的基準組態：


| vLLM 參數 | Description | 
| --- | --- | 
| tensor\_parallel\_size：1 | 在 1 個 GPU 之間分佈模型 | 
| gpu\_memory\_utilization：0.90 | 為系統額外負荷預留 10% GPU 記憶體 | 
| max\_sequence\_length：8192 | 總序列長度上限 （輸入 \+ 輸出） | 
| max\_num\_seqs：1 | 每個 GPU 的並行請求上限 （批次） | 

使用此基準設定執行 GuideLLM，以建立效能基準。在此測試中，GuideLLM 設定為每秒產生 1 個請求，其中包含 256 個金鑰請求和 128 個金鑰回應。

```
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"
```

預期的輸出結果：

 **基準基準指標結果** 

![基準基準指標結果](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/llm-inference-vllm-guidellm-baseline.png)


### 調校後的 vLLM 組態
<a name="_tuned_vllm_configuration"></a>

調整 vLLM 參數以更好地利用 GPU 資源和平行處理：


| vLLM 參數 | Description | 
| --- | --- | 
| tensor\_parallel\_size：1 | 保留在 1 個 GPU。Tensor 平行處理必須符合 vLLM 要使用的 GPUs 數量 | 
| gpu\_memory\_utilization：0.92 | 盡可能減少額外負荷 GPU 記憶體，同時確保 vLLM 繼續執行而不會發生錯誤 | 
| max\_sequence\_length：4096 | 根據您的使用案例需求調整最大序列；較低的最大序列釋放可用於增加平行處理的資源 | 
| max\_num\_seqs：8 | 增加最大 seq 會增加輸送量，但也會增加延遲。增加此值以最大化輸送量，同時確保延遲保持在您的使用案例需求內 | 

使用 kubectl 修補程式命令將這些變更套用至執行中的部署：

```
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"}
]'
```

檢查 vLLM Pod 是否處於 `Ready 1/1` 狀態：

```
kubectl get pod -l app=vllm-inference-app -w
```

預期的輸出結果：

```
NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
vllm-inference-app-65df5fddc8-5kmjm   1/1     1            1           5m
```

然後使用與之前相同的基準值再次執行 GuideLLM：

```
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"
```

預期的輸出結果：

 **最佳化基準結果** 

![最佳化基準結果](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/llm-inference-vllm-guidellm-optimized.png)


### 基準化結果
<a name="_benchmarking_results"></a>

運算基準測試會產生基準和最佳化 vLLM 組態的資料表：


| 平均值 | 基準組態 | 最佳化組態 | 
| --- | --- | --- | 
| RPS | 0.23 要求/秒 | 0.86 要求/秒 | 
| E2E | 12.99 秒 | 5.19 秒 | 
| TTFT | 8637.2 毫秒 | 147.9 毫秒 | 
| TPOT | 34.0 毫秒 | 39.5 毫秒 | 

最佳化的 vLLM 組態大幅改善推論輸送量 (RPS) 並降低延遲 (E2E、TTFT)，每個輸出字符 (TPOT) 的時間僅稍微增加一毫秒。這些結果示範 vLLM 如何大幅改善推論效能，讓每個容器在更短的時間內處理更多請求，以實現經濟實惠的操作。