協助改進此頁面

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

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

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

在 Amazon EKS 上加速模型載入

當您在 Amazon EKS 上部署大型語言模型 (LLMs) 時，模型載入時間會直接影響 Pod 開始提供推論請求的速度。在擴展事件期間，當新的 Pod 或節點必須在處理流量之前載入模型時，尤其如此。模型啟動有兩個階段，您可以透過調校和編譯成品快取來改善這些階段：

本主題說明如何最佳化 Run：ai Model Streamer 效能和 torch.compile 快取，以減少模型載入程序的兩個階段。如需在 Amazon EKS 上部署 vLLM 以進行推論的完整程序，請參閱 在 Amazon EKS 上載入並提供模型。

最佳化 EKS Auto 模式上的 S3 網路路徑

如果您在 EKS Auto Mode 上執行，且私有子網路中有 GPU 節點，建議您使用適用於 S3 的閘道 VPC 端點來最佳化節點與 S3 之間的網路路徑。使用閘道 VPC 端點時，對 S3 的流量會保留在 AWS 網路上，並完全略過 NAT 閘道，因此沒有共用頻寬上限和每 GB NAT 資料處理費用。如果沒有閘道 VPC 端點，當流量周遊 NAT 閘道時，NAT 閘道會在多個節點同時提取模型時，在擴展期間成為共用瓶頸。

EKS Auto Mode 通常會將節點放置在私有子網路中，因此 S3 的流量預設會流經 NAT Gateway。NAT Gateway 為每個目的地提供高達 100 Gbps 的頻寬和 55，000 個同時連線。不過，該頻寬會跨私有子網路中的每個節點共用。在擴展事件期間，多個節點一次下載完整模型會爭用相同的 NAT Gateway 頻寬，這可能會減慢載入所有模型的模型權重。

Run：ai 模型串流器效能調校

vLLM 和 SGLang 等推論引擎使用 Run：ai Model Streamer 作為在推論啟動期間載入權重的替代機制。

根據預設，從 S3 下載模型權重檔案時，Run：ai Model Streamer 會使用保守並行設定。增加下載並行和區塊大小可減少模型權重載入時間，方法是平行下載更多資料。

計算最佳並行

將最佳並行值計算為：

concurrency = ceil(total_model_size_gb / chunk_size_gb)

根據模型大小和區塊大小來取代您使用concurrency的值。如需一些範例，請參閱下表。例如，使用 67 GB 模型和 4 GB 區塊大小：ceil(67 / 4) = 17。

套用組態

將下列引數和環境變數新增至您的推論容器規格：

containers:
- name: vllm-inference
  image: vllm/vllm-openai:v0.21.0
  command:
    - python3
    - -m
    - vllm.entrypoints.openai.api_server
  args:
  # ... your existing args ...
  - --model=s3://<MODEL_PATH>
  - --tensor-parallel-size=2
  - --load-format=runai_streamer
  - --model-loader-extra-config={"concurrency":17,"distributed":true}
  env:
  - name: RUNAI_STREAMER_CHUNK_BYTESIZE
    value: "4294967296"
  - name: RUNAI_STREAMER_S3_REQUEST_TIMEOUT_MS
    value: "3000"
  - name: RUNAI_STREAMER_S3_LOW_SPEED_LIMIT
    value: "1048576"
         

最佳化 torch.compile 冷啟動

推論服務程序中torch.compile的步驟會追蹤模型的運算圖形 （數學運算序列），並將其編譯為最佳化的融合 CUDA/Triton 核心。它不會編譯模型權重，只會編譯轉換模型權重的操作。

推論引擎使用 torch.compile，因為它會自動提供顯著的輸送量改善，而不需要每個模型架構的自訂核心工程：

下表顯示使用 torch.compile 的常見推論服務引擎。

torch.compile 冷啟動問題

torch.compile 的權衡是第一個推論 Pod 必須編譯，才能處理請求。此編譯可能需要幾分鐘的時間，視模型大小而定。編譯的成品很小 (60 GB 模型約為 15 MB)，但可大幅增加冷啟動時間。由於成品是小型且決定性的，因此您可以快取和重複使用它們，以消除後續 Pod 和節點啟動時的冷啟動懲罰。

成品包含：

--enforce-eager 權衡

vLLM 預設會啟用 torch.compile和 CUDA 圖形擷取。--enforce-eager 標記會同時關閉並在急迫模式下執行模型，其中每個操作都會立即透過 Python 解譯器執行。由於急切模式會同時略過編譯和圖形擷取，因此一些快速入門指南 - 包括 中的基本部署 在 Amazon EKS 上載入並提供模型 - 用來更快--enforce-eager地啟動 Pod。

--enforce-eager 是偵錯、記憶體限制部署或模型架構的有效選擇，這些架構無法順利編譯，因此您可以在生產環境中使用它。雖然它可以減輕torch.compile冷啟動懲罰，但我們建議您使用其他方法，例如本頁後續章節中詳述的方法，以在生產環境中維持執行期效能。

在生產環境中部署--enforce-eager之前，了解 的啟動時間與執行時間效能權衡。

快取相同節點上的 torch.compile 成品

當您使用支援 的推論引擎時torch.compile，例如 vLLM （預設為啟用） 或 SGLang （透過 啟用），就會套用此技術--enable-torch-compile。只有在 torch.compile 處於作用中狀態時，也就是--enforce-eager未設定 時，才會運作。

當推論引擎在第一次啟動時編譯模型的運算圖表時，您可以在節點的本機儲存體上快取產生的最佳化核心。相同節點上的後續 Pod 會重複使用快取的成品，並完全略過編譯步驟，進而大幅縮短啟動時間。

新增快取環境變數

將下列環境變數新增至推論容器規格，以將 torch.compile 和 Triton 快取導向持久性主機路徑。我們建議使用節點的本機 NVMe 執行個體存放區，而不是 的根 Amazon Elastic Block Store (Amazon EBS) 磁碟區hostPath。如需範例，請參閱下一節。

containers:
- name: vllm-inference
  env:
  # torch.compile cache
  - name: XDG_CACHE_HOME
    value: "/compile-cache"
  - name: TORCHINDUCTOR_CACHE_DIR
    value: "/compile-cache/inductor"
  - name: TRITON_CACHE_DIR
    value: "/compile-cache/triton"
  volumeMounts:
  - name: compile-cache
    mountPath: /compile-cache
volumes:
- name: compile-cache
  hostPath:
    path: /mnt/k8s-disks/0/compile-cache
    type: DirectoryOrCreate

將快取路徑設定為 NVMe 執行個體存放區

編譯的成品和串流權重受益於快速的本機儲存。在具有 NVMe 執行個體存放區的 GPU 執行個體 （例如 G-family 和 P-family 執行個體） 上，執行個體存放區提供大約 30 GB/s，相較於根 Amazon EBS 磁碟區大約 1 GB/s。將快取導向 NVMe hostPath 掛載點，以最佳化輸送量。

NVMe 掛載點，以及 EKS Auto Mode 和自我管理節點之間的啟用方式：

對於 EKS Auto 模式，在您的容器規格/mnt/.ephemeral/compile-cache中將 hostPath 設定為 ：

volumes:
- name: compile-cache
  hostPath:
    path: /mnt/.ephemeral/compile-cache
    type: DirectoryOrCreate

對於自我管理的 Karpenter，請在容器規格/mnt/k8s-disks/0/compile-cache中將 hostPath 設定為 ：

volumes:
- name: compile-cache
  hostPath:
    path: /mnt/k8s-disks/0/compile-cache
    type: DirectoryOrCreate

範例結果

下表顯示不同模型大小的相同節點快取改進：

新節點上的暖機前 torch.compile 快取

當您跨節點使用同質 GPUs、張量平行處理、模型和 PyTorch 版本執行多節點推論時，就會套用此技術。中的技術快取相同節點上的 torch.compile 成品著重於單一節點案例，但在擴展事件期間新增的新節點會從空的 torch.compile 快取開始。若要進一步縮短新初始化節點的冷啟動時間，您可以實作快取機制，將編譯的 torch.compile 成品存放在 S3 中，並在它們加入叢集時預先將其下載到新節點。

一般方法為：

例如，您可以實作在封裝 torch.compile 快取並將其上傳至 S3 的 GPU 節點上執行的 DaemonSet。它也可以將該快取同步到本機節點儲存，然後再將推論 Pod 排程在新節點上。

跨節點快取的考量事項

當您跨節點快取 torch.compile 成品時，只有在產生快取的節點與使用快取的節點之間符合這些參數時，編譯的核心才有效。您的快取機制必須考慮所有這些項目。任何參數不相符都會產生無效的快取，強制重新編譯或導致執行時間錯誤。您的快取工具必須透過這些參數來區分成品，例如，將成品整合到 S3 物件金鑰或快取目錄結構中。

範例結果

使用跨節點快取預暖 (Qwen3-6-35B-A3B、67 GB、2x GPU 搭配 p5.48xlarge 上的 TP=2) 進行定向測試時，新擴展節點上的第一個 Pod 與已暖節點上後續 Pod 的啟動時間相同：

部署範例

下列範例將 Run：ai Model Streamer 效能調校和 torch.compile 快取合併為單一 vLLM 部署資訊清單。將預留位置值取代為您自己的組態：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-inference
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vllm-inference
  template:
    metadata:
      labels:
        app: vllm-inference
    spec:
      serviceAccountName: <SERVICE_ACCOUNT_NAME>
      nodeSelector:
        karpenter.sh/nodepool: <GPU_NODEPOOL>
      tolerations:
        - key: nvidia.com/gpu
          operator: Exists
          effect: NoSchedule
      containers:
        - name: vllm
          image: vllm/vllm-openai:v0.21.0
          command:
            - python3
            - -m
            - vllm.entrypoints.openai.api_server
          args:
            - --model=s3://<BUCKET_NAME>/<MODEL_PATH>
            - --load-format=runai_streamer
            - --model-loader-extra-config={"concurrency":17,"distributed":true}
            - --tensor-parallel-size=2
            - --max-model-len=8192
            - --host=0.0.0.0
            - --port=8000
          ports:
            - containerPort: 8000
              name: http
          env:
            # Run:ai streamer tuning
            - name: RUNAI_STREAMER_CHUNK_BYTESIZE
              value: "4294967296"
            - name: RUNAI_STREAMER_S3_REQUEST_TIMEOUT_MS
              value: "3000"
            - name: RUNAI_STREAMER_S3_LOW_SPEED_LIMIT
              value: "1048576"
            # torch.compile cache
            - name: XDG_CACHE_HOME
              value: "/compile-cache"
            - name: TORCHINDUCTOR_CACHE_DIR
              value: "/compile-cache/inductor"
            - name: TRITON_CACHE_DIR
              value: "/compile-cache/triton"
          resources:
            requests:
              cpu: "12"
              memory: 80Gi
              nvidia.com/gpu: "2"
            limits:
              nvidia.com/gpu: "2"
          volumeMounts:
            - name: compile-cache
              mountPath: /compile-cache
          startupProbe:
            httpGet:
              path: /health
              port: 8000
            periodSeconds: 10
            failureThreshold: 60
            initialDelaySeconds: 30
          readinessProbe:
            httpGet:
              path: /health
              port: 8000
            periodSeconds: 5
            timeoutSeconds: 3
      volumes:
        - name: compile-cache
          hostPath:
            path: /mnt/k8s-disks/0/compile-cache
            type: DirectoryOrCreate