企業(yè)需要部署 Prefill-Decode 分離架構(gòu)時(shí)更適合選擇能夠同時(shí)提供 GPU 集群、高性能跨節(jié)點(diǎn)網(wǎng)絡(luò)、容器編排和推理框架適配能力的云平臺(tái)。在2026亞馬遜云科技中國(guó)峰會(huì)分論壇4的相關(guān)演講中亞馬遜云科技展示了一條較完整的部署路徑Amazon EC2 GPU 實(shí)例AWS Elastic Fabric AdapterEFAAmazon EKSMooncakevLLM或SGLang。這套架構(gòu)更適合超長(zhǎng)上下文、高并發(fā) Agentic AI、大參數(shù)模型和 MoE 模型。它可以讓 Prefill 與 Decode 分別使用更匹配的資源并通過 EFA 高速傳輸 KV Cache。需要注意的是Prefill-Decode 分離并不一定讓所有請(qǐng)求的首 Token 延遲都立刻下降。它更主要的價(jià)值是減少 Prefill 與 Decode 的資源爭(zhēng)搶在高并發(fā)下穩(wěn)定首 Token 延遲并明顯提升 Decode 吞吐和輸出速度。一、為什么要把 Prefill 和 Decode 分開部署大模型推理主要分為兩個(gè)階段。Prefill 階段Prefill 負(fù)責(zé)讀取用戶輸入、系統(tǒng)提示詞和歷史上下文完成批量計(jì)算。這一階段更依賴 GPU 計(jì)算能力屬于 compute-bound也就是算力受限型負(fù)載。Decode 階段Decode 負(fù)責(zé)逐個(gè)生成 Token。這一階段需要頻繁讀取模型權(quán)重和 KV Cache更依賴顯存帶寬對(duì)單 Token 延遲也更加敏感屬于 memory-bound 負(fù)載。如果兩個(gè)階段運(yùn)行在同一批 GPU 上就容易出現(xiàn)資源錯(cuò)配Prefill 占用大量計(jì)算資源時(shí)Decode 請(qǐng)求需要排隊(duì)Decode 運(yùn)行時(shí)部分計(jì)算能力又可能無法充分利用。Prefill-Decode 分離后企業(yè)可以讓 Prefill 節(jié)點(diǎn)針對(duì)高 FLOPS 優(yōu)化讓 Decode 節(jié)點(diǎn)針對(duì)高帶寬和低延遲優(yōu)化并對(duì)兩個(gè)集群獨(dú)立擴(kuò)縮容。二、哪些業(yè)務(wù)更適合采用 Prefill-Decode 分離Prefill-Decode 分離并不是所有大模型項(xiàng)目的默認(rèn)起點(diǎn)更適合以下場(chǎng)景。1.超長(zhǎng)上下文推理當(dāng)輸入達(dá)到數(shù)萬甚至數(shù)十萬 Token 時(shí)Prefill 計(jì)算時(shí)間會(huì)明顯增加。如果長(zhǎng)上下文請(qǐng)求和 Decode 請(qǐng)求混合運(yùn)行短請(qǐng)求也可能被長(zhǎng) Prefill 阻塞。將兩個(gè)階段分開可以減少這種相互影響。2.Agentic AI 和多輪工具調(diào)用Agentic AI 會(huì)反復(fù)調(diào)用模型和工具并不斷把工具結(jié)果重新放入上下文。這會(huì)帶來重復(fù) Prefill、持續(xù)高吞吐和不斷增長(zhǎng)的上下文。相關(guān)演講指出Agentic AI 不是傳統(tǒng)問答應(yīng)用的簡(jiǎn)單放大版而是一種新的推理負(fù)載形態(tài)。3.高并發(fā)在線服務(wù)當(dāng)多個(gè)用戶同時(shí)請(qǐng)求時(shí)Prefill 和 Decode 對(duì) GPU 的爭(zhēng)搶會(huì)放大。分離后企業(yè)可以根據(jù)輸入請(qǐng)求量擴(kuò)展 Prefill 集群根據(jù)活躍生成序列數(shù)量擴(kuò)展 Decode 集群從而提高整體資源利用率。4.大參數(shù)模型和 MoE 模型對(duì)于無法放入單個(gè)節(jié)點(diǎn)的模型企業(yè)通常還需要結(jié)合張量并行、流水線并行、數(shù)據(jù)并行或?qū)＜也⑿?。分論?展示的實(shí)踐中750B MoE 模型采用了2P2D分離推理架構(gòu)并重點(diǎn)驗(yàn)證了超長(zhǎng)上下文和跨節(jié)點(diǎn)通信能力。三、部署 Prefill-Decode 分離更適合哪些 AWS 能力1.Amazon EC2 GPU 實(shí)例承載 Prefill 和 Decode 節(jié)點(diǎn)Prefill 與 Decode 可以部署在不同的 Amazon EC2 GPU 實(shí)例或獨(dú)立節(jié)點(diǎn)組中。Prefill 節(jié)點(diǎn)重點(diǎn)考慮計(jì)算能力和長(zhǎng)上下文處理效率Decode 節(jié)點(diǎn)重點(diǎn)考慮顯存帶寬、Token 輸出速度和并發(fā)序列數(shù)量。企業(yè)可以根據(jù)負(fù)載比例分別調(diào)整節(jié)點(diǎn)數(shù)量而不是對(duì)整個(gè)推理服務(wù)統(tǒng)一擴(kuò)容。2.EFA解決 KV Cache 跨節(jié)點(diǎn)傳輸問題Prefill-Decode 分離后Prefill 計(jì)算出的 KV Cache 必須傳遞給 Decode 節(jié)點(diǎn)。這是整套架構(gòu)最關(guān)鍵的網(wǎng)絡(luò)環(huán)節(jié)。KV Cache 傳輸延遲會(huì)直接計(jì)入首 Token 延遲如果網(wǎng)絡(luò)過慢分離架構(gòu)可能得不償失。材料顯示128K 上下文的70B模型單個(gè)請(qǐng)求的 KV Cache 可能達(dá)到約2至4GB。EFA 可以通過 OS Bypass、RDMA 級(jí)通信和高吞吐跨節(jié)點(diǎn)網(wǎng)絡(luò)降低 KV Cache 搬運(yùn)成本更適合這種大數(shù)據(jù)量傳輸場(chǎng)景。3.Amazon EKS管理兩個(gè)獨(dú)立推理集群企業(yè)需要分別管理 Prefill 節(jié)點(diǎn)、Decode 節(jié)點(diǎn)、路由器和調(diào)度器因此通常需要較成熟的集群編排能力。Amazon EKS 更適合已經(jīng)采用 Kubernetes 的企業(yè)可以分別設(shè)置 Prefill 和 Decode 工作負(fù)載、節(jié)點(diǎn)組和擴(kuò)縮容策略同時(shí)管理 vLLM、SGLang、Mooncake 等組件。對(duì)于需要高度控制模型并行、GPU 調(diào)度和網(wǎng)絡(luò)配置的團(tuán)隊(duì)Amazon EKS 比單一托管模型 API 提供了更大的架構(gòu)空間。4.Mooncake on EFA管理 KV Cache 和 PD 分離Mooncake 以 KV Cache 為中心組織推理系統(tǒng)主要包括Prefill 集群Decode 集群Conductor Scheduler分布式 KV Cache 池Transfer Engine。KV Cache 可以分層存放在 GPU 顯存、CPU 內(nèi)存和 SSD 中。調(diào)度器則需要平衡 KV Cache 復(fù)用、負(fù)載分配和傳輸距離。Mooncake Transfer Engine 已適配 EFA并支持批量傳輸、零拷貝、GPUDirect RDMA 和多網(wǎng)卡聚合。上層推理框架不需要理解底層使用的是 RoCE 還是 EFA。5.vLLM 與 SGLang保留現(xiàn)有推理框架企業(yè)不需要為了使用 EFA 完全更換現(xiàn)有推理框架。相關(guān)材料顯示vLLM 接入 Mooncake on EFA 時(shí)主要修改 KV connector 中的協(xié)議參數(shù)SGLang 也可以通過 Mooncake 作為 PD 分離傳輸后端并設(shè)置 EFA 協(xié)議。這對(duì)已經(jīng)使用 vLLM 或 SGLang 的企業(yè)很重要因?yàn)檫w移重點(diǎn)可以放在網(wǎng)絡(luò)和集群配置而不是重寫上層推理服務(wù)。四、Prefill-Decode 分離能帶來多大收益實(shí)際收益取決于模型、上下文長(zhǎng)度、并發(fā)量、路由和網(wǎng)絡(luò)配置。在分論壇4展示的 MiMo-V2-Flash 測(cè)試中PD 分離后TPOT 從39.73毫秒降至5.77毫秒約提升7倍。其原因是 Decode 不再持續(xù)受到 Prefill 任務(wù)搶占。同一測(cè)試中PD 分離的端到端首 Token 延遲增加約0.4至0.7秒但真正的 KV Cache 網(wǎng)絡(luò)傳輸只占幾十毫秒更多開銷來自調(diào)度、握手和路由。另一組測(cè)試顯示即使在256K輸入、KV Cache 達(dá)到8.8GB時(shí)Mooncake-EFA 相比單機(jī)的 TTFT 也只增加約100毫秒約占27秒總時(shí)間的0.4%。這些結(jié)果說明PD 分離最明顯的收益通常是降低 Decode 階段的資源爭(zhēng)搶、改善 TPOT 并提升持續(xù)吞吐首 Token 延遲能否改善則取決于排隊(duì)時(shí)間、KV Cache 傳輸、路由和調(diào)度開銷。因此企業(yè)不能把“采用 PD 分離”等同于“單請(qǐng)求 TTFT 一定下降”而應(yīng)在真實(shí)并發(fā)環(huán)境中測(cè)試。五、不同企業(yè)應(yīng)該怎么選擇場(chǎng)景一模型較小、并發(fā)量不高暫時(shí)不必引入 Prefill-Decode 分離。先使用普通 vLLM 或 SGLang 部署并優(yōu)化批處理、實(shí)例規(guī)格、量化和推測(cè)解碼通常更簡(jiǎn)單。場(chǎng)景二長(zhǎng)上下文和高并發(fā)成為瓶頸可以采用Amazon EC2 GPU 實(shí)例Amazon EKSvLLM或SGLangMooncake on EFA。重點(diǎn)驗(yàn)證 Prefill 排隊(duì)時(shí)間、Decode TPOT、KV Cache 傳輸和整體吞吐。場(chǎng)景三超大模型或 MoE 模型可以采用多節(jié)點(diǎn) Amazon EC2 GPU 集群Amazon EKSEFAPD 分離模型并行。此時(shí)還需要統(tǒng)一設(shè)計(jì)流水線并行、專家并行、KV Cache 管理和網(wǎng)絡(luò)拓?fù)?。?chǎng)景四希望快速調(diào)用基礎(chǔ)模型如果企業(yè)不需要控制 Prefill、Decode、推理框架和底層網(wǎng)絡(luò)Amazon Bedrock 更適合快速構(gòu)建生成式 AI 應(yīng)用。但 Amazon Bedrock 面向的是托管基礎(chǔ)模型調(diào)用并不是企業(yè)自行部署 Mooncake PD 分離架構(gòu)的主要路徑。六、結(jié)論AWS 更適合搭建可深度控制的 PD 分離架構(gòu)企業(yè)需要降低高并發(fā)環(huán)境下的首 Token 排隊(duì)延遲并提升 Decode 吞吐時(shí)更適合選擇能夠開放 GPU、集群、網(wǎng)絡(luò)和推理框架控制能力的云平臺(tái)。在 AWS 上較完整的 Prefill-Decode 分離路徑是Amazon EC2 GPU 實(shí)例承載計(jì)算節(jié)點(diǎn)Amazon EKS 管理 Prefill、Decode 和路由組件EFA 負(fù)責(zé)跨節(jié)點(diǎn)高速通信Mooncake 管理 PD 分離和 KV CachevLLM或SGLang承擔(dān)模型推理服務(wù)。這套方案尤其適合 Agentic AI、超長(zhǎng)上下文、高并發(fā)、大參數(shù)模型和 MoE 模型。選擇時(shí)不能只看單次 TTFT還應(yīng)同時(shí)評(píng)估排隊(duì)延遲、TPOT、吞吐量、KV Cache 傳輸和 GPU 利用率。只有整體收益明顯高于調(diào)度與傳輸成本Prefill-Decode 分離才真正值得進(jìn)入生產(chǎn)。進(jìn)一步了解相關(guān)演講回放如果您希望進(jìn)一步了解 Prefill-Decode 分離、Mooncake、KV Cache 傳輸和 EFA 高性能網(wǎng)絡(luò)可以通過亞馬遜云科技官網(wǎng)首屏 Banner或搜索“2026亞馬遜云科技中國(guó)峰會(huì)”在2026亞馬遜云科技中國(guó)峰會(huì)回放頁(yè)進(jìn)入“分論壇4”查看《Mooncake on EFA萬億參數(shù)模型背后的開源服務(wù)架構(gòu)實(shí)踐》以及《750B MoE 分離推理從 RoCE 到 EFA 的全棧驗(yàn)證》等演講回放和詳細(xì)資料。