最近看了幾篇關於閘道器和PD分離的論文，分享下個人想法。在閘道器、P、D這三者之中，P是最重要的。因為：
- Prefill階段決定了time-to-first-token
- PD分離的效果很大程度上受限於kvcache的傳輸的代價（kvcache是以GB為單位的，跑RDMA也需要100毫秒級的時間）。而kvcache主要是P產生的。
由於P主導了kvcache的傳輸，所以最佳的D是由P選擇的。對於閘道器，就只需要選擇最佳的P。整個系統是閘道器到P到D。
那麼接下來討論如何選擇最佳的P。這裡先不考慮kvcache命中的事情，即最佳的P是空閒的P。
https://arxiv.org/html/2408.08147v1#S3 裡提到閘道器透過在給定時間內反覆重試不同的P來找到空閒的P（見 3.5 On-demand Forwarding for Idle Prefill 一節）。但這種做法的問題在於閘道器和P的數目差別不能太多。因為單次重試的時間取決於網路延時，難以透過最佳化閘道器來減少。如果一個閘道器需要對應幾十臺P，顯然沒辦法把它們都重試一遍。延長總重試時間則與減少TTFT的目標相違背。然而P作為計算密集型，閘道器作為IO密集型，它們之間天然會出現單閘道器對應大量P的情況。
另一種思路是P上報相關的metric，閘道器根據metric來找到最佳的P。但只根據metric會有驚群的風險。因為每個閘道器看到的metric是一樣的，他們找到的空閒的P也是一樣的。提高metric上報的頻率（比如收到新的任務就上報）可以減少驚群的影響（因為減少了不同時間內每個閘道器看到同樣metric的可能性）。但無法根除驚群。
如果消滅驚群，那麼引入一個全域性元件也許是個辦法。由一個具有全域性視角的元件來分配任務是最公平的。當然全域性元件固有問題就要考慮下了：
- 高可用（這種元件讀寫都多，主寫從讀可能還不夠。當然不同階段下具體問題具體分析……）
- 延遲（閘道器側和P側各有一次呼叫，不過TTFT單位是100毫秒級，同叢集兩次呼叫對比起來其實還好，吧？）
- 效能（推理的 QPS 都不高，所以效能要求也其實還好，吧？）
如果考慮kvcache命中，那麼閘道器和P將更加緊密。Context cache作為實打實可以減少推理成本的方式，凡是做AI閘道器都是繞不過的。而context cache的形態其實是由cache kvcache的方式決定的（注意中間的cache是動詞）。大部分推理服務都是透過公共prefix來cache kvcache cache（比如vllm的APC），所以context cache就主要看prefix。如果某些業務只會排程到某些P上面，就意味著context cache裡的cache id會跟著業務走。另外P上說不定會有prefix之外的形態，比如https://arxiv.org/html/2410.15332v1。
總而言之，在設計AI閘道器時，需要從整體來看閘道器在推理鏈路裡的角色。