協助改進此頁面

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

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

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

快速入門：Amazon EKS 上使用 vLLM 進行高輸送量 LLM 推論

簡介

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

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

EKS 上的 vLLM 架構

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

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

開始之前

開始使用之前，請確定您已：

使用 Amazon S3 設定模型儲存

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

其他儲存解決方案也可用於模型快取的 EKS，例如 EFS 和 FSx for Lustre。如需詳細資訊，請參閱 EKS 最佳實務。

設定環境變數

為我們將在本指南稍後建立的新 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 儲存貯體以存放模型檔案

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

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

從 Hugging Face 下載模型

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

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

export HF_TOKEN=your_token_here

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

sudo dnf install -y python3-pip

安裝 Hugging Face 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

上傳模型檔案

啟用 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 許可

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 即時推論的最佳實務叢集設定指南。

將 S3 儲存貯體掛載為 Kubernetes 磁碟區

建立持久性磁碟區 (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 基礎設施設定

叢集節點

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

執行個體選取

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

具有 A10G GPUs 的 Amazon G5 EC2 執行個體和具有 L4 GPUs 的 G6 EC2 執行個體每個 GPU 都提供 24GB VRAM，足以載入 Llama 3.1 8B 指示權重。如果您要部署具有較大權重的模型，請考慮使用多 GPU 執行個體類型或多節點設定。

NVIDIA 裝置驅動程式

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

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

測試 GPU 基礎設施

透過執行以下步驟來測試叢集的 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 即時推論的最佳實務叢集設定指南。如果您使用不同的節點集區，請確保 Pod 相應地符合 nodeSelector 和容錯。

部署推論容器

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

選取 AWS 深度學習容器映像

AWS 深度學習容器 (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 資訊清單

在 EKS 中部署 vLLM 有多種方式。本指南示範使用 Kubernetes 部署的 vLLM 部署，這是 Kubernetes 原生且易於入門的方式。如需進階部署選項，請參閱 vLLM 文件和 AI on EKS 藍圖。

透過 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 就緒且可用時，才能繼續。

公開服務

透過本機開發和測試的 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控制器路由網際網路流量。

執行推論

驗證推論 Pod

透過轉送連接埠在本機驗證推論容器功能。傳送連線請求，並確保回應包含 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 格式，使其與現有應用程式相容，同時提供可設定的產生參數，例如回應長度和溫度，以控制輸出多樣性。

執行聊天機器人應用程式

為了示範，本指南使用專案 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 介面

最佳化推論效能

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

基準 vLLM 組態

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

基準 vLLM 組態

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

使用此基準設定執行 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"

預期的輸出結果：

基準基準指標結果

調校後的 vLLM 組態

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

使用 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"

預期的輸出結果：

最佳化基準結果

基準化結果

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

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