大模型推理分兩階段：prefill（預填）負責處理輸入並建立 KV cache（key-value 快取），decode（解碼）再用個 cache 逐 token 產出輸出。兩階段嘅計算、記憶體同伸縮特性唔同，所以 vLLM 有「prefill-decode 分離」模式：兩階段跑喺分開嘅引擎實例，各自獨立伸縮同調校，可以提高資源利用率、吞吐量同降低延遲。
但分離有代價：產出 token 之前，KV cache 要由 prefill 實例搬到 decode 實例，而個傳輸時間直接影響 TTFT（time-to-first-token，首 token 延遲）。
原有做法係 pull（拉）模式：prefill 算完 KV cache 後，router 將源端 metadata（包括 block ID）傳去 decode 實例；decode 實例再分配目的區塊、準備 NIXL 傳輸，發起 NIXL READ 拉回資料。呢啲協調同設定步驟喺 prefill 之後、decode 之前逐行發生，拉長咗 TTFT 嘅關鍵路徑。
呢篇 AWS 技術部落格介紹 push（推）模式：將 post-prefill 嘅轉送協調同設定搬出關鍵路徑。decode 實例喺 prefill 仲喺計算時，已經預先註冊目標區塊；當 prefill 區塊一 ready，傳輸即刻開始，避免 producer 同 consumer 嘅串行化。
傳輸透過 NVIDIA Inference Xfer Library（NIXL）connector，行喺支援 RDMA（Remote Direct Memory Access，遠端直接記憶體存取）嘅 interconnect 上，例如 AWS EFA（Elastic Fabric Adapter，低延遲 RDMA 網路）。喺支援嘅實例類型上，AWS EFA 支援 GPUDirect RDMA 同 Neuron Direct RDMA，NIXL 可以直接喺 GPU 或 AWS Trainium 裝置記憶體之間搬 KV 區塊，唔使經 host memory 過水。
AWS 指佢哋喺用 EFA 連接嘅 AWS Trainium 實例集群上開發同驗證呢個功能，再貢獻入 vLLM，作為 accelerator-agnostic（不依賴特定加速器）嘅 feature。本文嘅數據來自 Amazon EC2 P5en（GPU）集群。
基準測試：喺 1P1D（一組 prefill、一組 decode）配置，用 EC2 P5en 實例經 EFA 連接，跑 Qwen3-32B 模型，push 模式相比 pull 模式 TTFT 改善達 3 倍、TPOT（time-per-output-token，每輸出 token 時間）改善達 30%。
要留意呢個數字嘅限定：AWS 自認「results depend on workload and configuration」，即結果取決於負載同配置。呢個係廠商喺自家硬件集群嘅結果，冇獨立第三方複製。
阿調搞兩下：AWS 寫嘢一向係「金主嘅技術文」，成篇冇一句「請用 AWS」，反而講明呢個係 accelerator-agnostic、貢獻咗入 open-source vLLM 嘅 feature，而數據係喺自家 P5en 集群量出嚟。呢個係廠商嘅自家 benchmark，唔係本站實測；數值係唔係喺邊個集群、邊個 workload 下都成立，仲要獨立查證。對部署離線式 vLLM 嘅工程團隊嚟講，呢個 push 模式值唔值得遷，要睇自己嘅 request rate 同硬件；廠商自評數只係入場門檻，唔係決策根據。
阿調｜深度調教
