跑多輪對話嘅 agentic（代理）工作負載，每一輪都要將不斷長大嘅對話歷史重推一次，延遲越嚟越高。
呢個問題係點樣產生
喺 Prefill-decode（P-D）disaggregation（分體式服務）架構入面，每個請求拆去專門嘅節點處理：prefill 節點處理 prompt 並建立 KV cache，decode 節點再取用呢啲 KV block 產生回應。但傳統做法只係單向：KV cache 只可以由 prefill 傳去 decode。
呢個單向流喺多輪工作負載造成兩個效率問題。第一，decode 節點生成回應後，同時持有 prompt 同新生成 token 嘅 KV cache；處理下一輪時，prefill 節點攞唔到呢啲項目，就必須對上一輪嘅回應 token 重新計算 KV projection。第二，decode 節點保存 session 狀態而 prefill 節點唔保存，令 prefill 節點對活躍 session 嘅 cache eviction（緩存驅逐）機率增加；一旦完全 cache miss，就必須對整段對話歷史——包括系統指令、先前用户請求、工具結果同模型回應——全部重算。對話越長，呢啲冗餘工作越食 accelerator（加速器）容量，TTFT（time to first token，首 token 延遲）就越高。
點樣解決
Bi-directional KV transfer 嘅機制，係 decode 節點喺對話後續輪次，將之前已計算嘅 KV 傳返落 prefill 節點。呢個避免 prefill 節點重複計算共享上下文，並受一個可配置嘅「KV recompute threshold」（KV 重算閾值）控制。
測試數字
AWS 喺一個 1P1D（一 prefill 一 decode）部署、使用 Amazon EC2 P5en 實例上跑多輪 benchmark，雙向 KV 傳輸將 TTFT 最多降低：Qwen3-32B 達 1.6 倍，zai-org/GLM-5-FP8 達 3.3 倍。結果會隨工作負載同配置而變。實例之間用 AWS EFA（Elastic Fabric Adapter）低延遲 RDMA 網絡連接；喺支持嘅實例類型上，AWS EFA 支持 GPUDirect RDMA 同 Neuron Direct RDMA，可以直接喺 prefill 同 decode 節點嘅 GPU 或 AWS Trainium 設備記憶之間搬移 KV block。
呢個功能原本喺 AWS Trainium 實例叢集上開發同驗證，以 accelerator-agnostic（加速器無關）嘅能力貢獻返去 vLLM；本文展示嘅結果來自 P5en GPU 叢集，顯示效益同樣遷移到 GPU。
待問
呢個係 AWS 自己嘅 benchmark，未經本站獨立重現；其他推理引擎、其他規模部署嘅實際表現，仲有待第三方測試。
阿調搞兩下：長對話嘅 TTFT 問題，唔係模型傻，係架構設計嘅欠嘢。以前 decode 算完就攞走，prefill 下一輪又要重頭算，同個鐘點工做雙份工冇分別。雙向傳輸至少將呢個「雙份工」減咗半，但「最多 3.3 倍」係 P5en 實例、特定模型同配置嘅數字，換一套硬件或者 workload，數字會唔一樣，讀法時要清楚呢個係 AWS 自家數據。
