AWS 推出多節點 Ray LLM DLC，用兩個 GPU 節點部署單一 LLM

背景

AWS DLC（Deep Learning Containers，深度學習容器）是 AWS 預先建好、經過效能調校的 Docker 映像檔（打包好、可直接執行的軟體環境），把框架、相依套件和 GPU（圖形處理器）相關軟體組成經過測試、已套用修補的組合，拉下來就能使用。Ray 是分散式運算框架，以 Ray Serve 作為服務層的部署可以跨多個節點（叢集中的個別機器）。AWS 說明，客戶使用多節點 Ray Serve 的原因包括：模型太大、單一 GPU 放不下；需要比單一副本更高的吞吐量；或想把推論的兩個階段分開以改善效能。這些情境過去都得自行挑選相容的函式庫，並在元件版本不一致時自己除錯，AWS 稱之為無差異化的工作；推出多節點版本的 Ray LLM DLC，就是把 DLC 的做法延伸到多節點推論。 AWS ML Blog 官方原文・github.com

發生什麼事

AWS ML Blog 於 2026 年 10 月 12 日發文，介紹供多節點部署使用的 Ray LLM DLC，並示範在 Amazon EKS（Elastic Kubernetes Service，AWS 代管的 Kubernetes 容器調度服務）上，把一個 LLM（大型語言模型）部署到兩個 GPU 節點，對外只提供一個與 OpenAI 相容的 API（應用程式介面，讓程式彼此呼叫的接口）端點。AWS 先前推出的 Ray Serve DLC，是在單一 GPU 節點上架設小模型。 AWS ML Blog

配套範例放在 GitHub 的 aws-samples/sample-aws-deep-learning-containers，會把 Qwen/Qwen3.5-9B 部署到 2 台 g6.8xlarge（AWS 的 GPU 執行個體類型）工作節點。範例採用 prefill/decode（PD）分離：一台負責 prefill（一次平行處理整段輸入提示並建立 KV cache 的階段；KV cache 是 key-value 快取，存放模型算過的中間結果供後續生成讀取），另一台負責 decode（讀取並延伸 KV cache、一次產生一個 token 的回應生成階段；token 是模型處理文字的基本單位）。prefill 節點建好 KV cache 後，透過 NIXL（NVIDIA Inference Xfer Library，NVIDIA 用來加速 AI 推論框架點對點傳輸的函式庫）交給 decode 節點產生回應。 官方原文・github.com AWS ML Blog 官方原文・github.com

重點內容

AWS 解釋分離的理由：prefill 受運算能力限制，decode 受記憶體頻寬限制；兩者共用一張 GPU 時會搶資源，突發且吃運算的 prefill 會干擾需要穩定、對延遲敏感的 decode。分開後，運算量大的長提示不會卡住已在進行中請求的 token 生成，兩個階段也能各自選擇硬體並各自擴充。代價是 KV cache 必須從 prefill 節點傳到 decode 節點，傳輸要夠快才不會抵銷好處，因此節點之間的連線很關鍵。 AWS ML Blog

容器內含 vLLM（推論引擎）、Ray Serve LLM（Ray Serve 中用來部署 LLM 的函式庫）、NIXL，以及 EFA（Elastic Fabric Adapter，AWS 用於節點間高頻寬通訊的網路介面）軟體堆疊，包括 libfabric 與 aws-ofi-nccl 兩個通訊函式庫。所有元件在每次發布前一起驗證，CUDA（NVIDIA 的 GPU 運算平台）執行環境、框架和服務層之間不會出現版本落差，安全修補在建置時套用。整個服務應用就是一段 YAML（以縮排表示結構的設定檔格式），不必寫 Python 程式；內建的 build_pd_openai_app 接收 prefill_config 與 decode_config 兩份設定，並串起兩者之間的 KV cache 傳輸。 AWS ML Blog 官方原文・github.com

範例設定中，max_model_len: 4096 依實測的 KV cache 大小設定上下文長度；dtype: bfloat16（一種 16 位元浮點數格式）與 gpu_memory_utilization: 0.90 決定精度與 vLLM 可占用的顯示記憶體比例；enforce_eager: true 會略過 CUDA graph（把一連串 GPU 運算預先錄製再重複執行的機制）擷取，以降低 GPU 記憶體峰值。關鍵設定是 kv_connector_extra_config: { backends: ["LIBFABRIC"] }，少了這一行，NIXL 會預設改用 UCX（一套開源通訊框架），即使在 EFA 上也只有 TCP（一般網路傳輸協定）的速度。每個工作 pod（Kubernetes 中執行容器的基本單位）各要求一張 GPU 與一個 EFA 介面。 AWS ML Blog 官方原文・github.com

對使用者的意義

AWS 表示這種做法適合 RAG（檢索增強生成，先查找資料再交給模型回答）、文件摘要與代理型應用等工作負載。要照著做，需要已啟用計費的 AWS 帳號、在目標區域有足以執行兩台 g6.8xlarge 的服務配額（至少 64 vCPU，vCPU 是虛擬處理器核心），並安裝 AWS CLI（命令列介面，用打字下指令操作的工具）、kubectl（操作 Kubernetes 叢集的命令列工具）、eksctl（建立與管理 EKS 叢集的命令列工具）、helm（Kubernetes 套件管理工具）與 envsubst（產生設定檔的小工具）。範例腳本依序建立 EKS 叢集（全新執行 15-20 分鐘）、GPU 節點群組（5-20 分鐘）、安裝 KubeRay（在 Kubernetes 上自動管理 Ray 叢集的元件，1-2 分鐘），最後部署 Ray 服務；完成後可對 /v1/chat/completions 用 OpenAI 格式送出請求。 AWS ML Blog 官方原文・github.com

限制與未定事項

範例的 GPU 節點群組固定在單一 AZ（可用區域，AWS 區域內彼此獨立的資料中心群），因為 EFA 無法跨 AZ。NIXL 若無法使用 libfabric，會在不報錯的情況下退回 TCP 速度的傳輸，範例提供查詢工作節點日誌的指令，用來確認實際使用的是 LIBFABRIC 還是 UCX。NIXL 本身只支援 Linux，在 Ubuntu（22.04/24.04）與 Fedora 上測試，目前不支援 macOS 與 Windows。範例預設區域為 sa-east-1（AWS 區域代碼），可透過 scripts/env.sh 改寫。 AWS ML Blog 官方原文・github.com 官方原文・github.com