生活分享

AWS 推出多節點 Ray LLM 容器：大型語言模型的「讀提示」與「產生回答」可分給兩台 GPU 節點處理

AWS 推出適用於多節點部署的 Ray LLM Deep Learning Container，並示範在 Amazon EKS 上用兩個 GPU 節點分別負責讀取提示（prefill）與產生回答（decode）。AWS 稱自行架設大型模型服務的團隊可直接使用這個由 AWS 維護並測試的容器，不必自己拼湊軟體堆疊。

閱讀時間約 5 分鐘

AWS 推出多節點 Ray LLM 容器：大型語言模型的「讀提示」與「產生回答」可分給兩台 GPU 節點處理
圖片：Mokaair (Original editorial artwork)

發生了什麼事

AWS 在其部落格文章中表示，隨著適用於多節點部署的 Ray LLM Deep Learning Container（DLC）推出，DLC 的預先建置做法已延伸到多節點推論。依 AWS 的說明，DLC 是預先建置的 Docker 映像，把框架、相依套件與 GPU 軟體堆疊打包成測試並修補過的組合，拉下來就能用。AWS 的文章示範如何在 Amazon EKS（Amazon Elastic Kubernetes Service）上，把單一大型語言模型部署到兩個 GPU 節點，以獨立的 prefill 與 decode 節點，置於同一個相容 OpenAI 的端點之後；也就是說，使用者可以用標準的聊天請求格式呼叫這個服務入口。

AWS 稱 Ray LLM DLC 內含 vLLM 作為推論引擎、Ray Serve 的 HTTP 作為服務層、NIXL（NVIDIA Inference Transfer Library）用於節點間 KV 快取傳輸，以及負責高頻寬節點間通訊的 EFA（Elastic Fabric Adapter）堆疊（libfabric 與 aws-ofi-nccl）。AWS 也稱 DLC 的所有元件在每次發布前一併驗證，因此 CUDA 執行環境、框架與服務層之間不會版本漂移，安全修補則在建置時套用。

AWS 表示整個服務應用只是一段 YAML 設定檔，不需要 handler 類別、模型封存工具或自訂映像；輔助函式 build_pd_openai_app 接收 prefill 與 decode 設定，並在同一個相容 OpenAI 的端點後串接 KV 快取傳輸。

為什麼要把 prefill 與 decode 分開

根據 AWS，大型語言模型的推論有兩個階段：Prefill 會平行處理整個輸入提示並建立 key-value（KV）快取；Decode 則一次產生一個 token（模型輸出文字的單位），並讀取與擴充該快取。AWS 指出，把兩個階段分開，可避免運算量大的長提示拖慢進行中請求的 token 生成，並讓兩個階段能獨立擴展。

AWS 文章對兩個推論階段的說明
項目PrefillDecode
工作內容平行處理整個輸入提示並建立 KV 快取一次產生一個 token，並讀取與擴充該快取
AWS 所述瓶頸受運算能力限制受記憶體頻寬限制
範例中的節點一個 g6.8xlarge GPU 節點另一個 g6.8xlarge GPU 節點

AWS 表示取捨在於：prefill 建立的 KV 快取必須交給 decode 節點，這個傳輸要夠快，才不會抵銷好處，因此節點間的互連很重要。AWS 稱此架構適合檢索增強生成（RAG）、文件摘要與代理式應用等工作負載。

範例架構與需要注意之處

AWS 的範例架構使用一個 CPU 系統節點（m7i.xlarge）承載系統工作負載、KubeRay operator 與 Ray head pod，另有兩個 GPU 工作節點（g6.8xlarge），一個負責 prefill，一個負責 decode。AWS 指出 GPU 節點群組被固定在單一可用區（Availability Zone，簡稱 AZ），因為 EFA 無法跨 AZ。

AWS 的範例以 Qwen3.5-9B 模型為例，設定 max_model_len 為 4096；AWS 稱在 g6.8xlarge 上採用文中的快取設定，模型權重載入時間在重啟時由約 145 秒降到約 2 秒。

AWS 另說明，負責運算的 worker pod 以 privileged: true 的設定執行，因為 NIXL 會把 CUDA VRAM（GPU 記憶體）註冊到 EFA 網卡，單靠 IPC_LOCK 能力不夠。

對一般讀者的實際意義

對一般讀者而言，這代表需要自行架設大型模型服務的團隊，有一個由 AWS 維護並測試的容器可用，不必自己拼湊 GPU 與網路相關的軟體堆疊。AWS 指出常見的多節點推論模式包括張量與管線平行（把單一執行個體放不下的模型拆開）、資料平行（複製模型以提高處理量），以及 prefill/decode 解耦（把推論的兩個階段放到不同節點）。

AWS 列出的先決條件包括：已啟用計費的 AWS 帳戶、足夠執行兩個 g6.8xlarge 執行個體的配額（至少 64 vCPU），以及 AWS CLI、kubectl、eksctl、helm 與 envsubst 等工具。AWS 的部署流程分四步：建立 EKS 叢集（全新執行約 15–20 分鐘）、加入 GPU 工作節點、安裝 KubeRay operator、部署 RayService。為避免持續產生費用，AWS 建議依相反順序拆除資源。

以上皆為 AWS 自身的說明，效能與成本結果請以自己的環境為準。

常見問題

什麼是 prefill/decode 解耦？

根據 AWS，這是把處理輸入提示的 prefill 階段與逐一產生 token 的 decode 階段放在不同節點，讓兩者互不干擾並可獨立擴展。

這個容器是做什麼用的？

AWS 稱 Ray LLM DLC 內含 vLLM、Ray Serve 的 HTTP 服務層、NIXL 與 EFA 堆疊，用於以相容 OpenAI 的端點提供多節點模型推論。

需要寫程式才能部署嗎？

AWS 表示整個服務應用只是一段 YAML，不需要 handler 類別、模型封存工具或自訂映像，但仍需要設定 EKS 叢集與相關工具。

這些效能數字有其他來源佐證嗎？

本文內容皆來自 AWS 自己的部落格文章，屬單一來源，應視為 AWS 的說法。

查看同分類最新消息

同主題延伸閱讀

資料來源

生活分享