LLM Disaggregated Serving怎麼落地？Dynamo、NIXL、Router與條件式P／D

LLM Disaggregated Serving怎麼落地？Dynamo、NIXL、Router與條件式P／D

先講結論：LLM Disaggregated Serving把Prefill與Decode拆成獨立Worker Pool，再以Dynamo、NIXL與KV-aware Router協調請求。本文解析條件式P／D、KV傳輸、Topology、相容性、失敗治理與Benchmark。

LLM Disaggregated Serving怎麼落地？Dynamo、NIXL、Router與條件式P／D在講什麼？ LLM Disaggregated Serving把Prefill與Decode拆成獨立Worker Pool，再以Dynamo、NIXL與KV-aware Router協調請求。本文解析條件式P／D、KV傳輸、Topology、相容性、失敗治理與Benchmark。

先記住哪個結論？ 核心是把「LLM Disaggregated Serving怎麼落地？Dynamo、NIXL、Router與條件式P／D」放回完整脈絡，區分已知資訊、背景與可延伸的判斷。

文中整理了哪些重點？ 文章依序整理：LLM Disaggregated Serving把Prefill與Decode拆成獨立Worker Pool，再以Dynamo、NIXL與KV-aware Router協調請求。本文解析條件式P／D、KV傳輸、Topology、相容性、失敗治理與Benchmark。，並補充相關背景、影響與讀者可查證的線索。

讀者最容易忽略什麼？ 不要只看標題；請同時確認時間、人物、作品或事件名稱，以及資訊的原始來源。

這個主題和台灣讀者有何關係？ 對台灣讀者而言，清楚的中文脈絡、關鍵字與可延伸閱讀入口，能讓後續查證更有效率。

哪些資訊需要再核對？ 涉及日期、名單、票價、健康、政策、交通或產品規格時，仍應以文章列出的一手來源與最新公告為準。

如果只看一段，建議看哪裡？ 可先讀這個答案區與文章開頭，再依需求回到正文的背景、分析與常見問題。

這篇內容適合誰？ 適合想快速掌握「LLM Disaggregated Serving怎麼落地 Dynamo NIXL…」並需要延伸閱讀入口的讀者。

一句話總結？ 一句話：LLM Disaggregated Serving把Prefill與Decode拆成獨立Worker Pool，再以Dynamo、NIXL與KV-aware Router協調請求。本文解析條件式P／D、KV傳輸、Topology、相容性、失敗治理與Benchmark。

Disaggregated Serving把大型語言模型推論中的Prefill與Decode拆到不同Worker Pool，讓兩個階段分別擴縮與配置硬體。它最適合長Prompt、檢索型流量、高Concurrency和長輸出明顯不對稱的服務；短Prompt、低流量或缺少高速KV傳輸時，Aggregated Serving往往更簡單。

現代分離式推論不應理解成「所有請求都固定先去Prefill Server」。NVIDIA Dynamo等系統會把Router、KV Cache Locality、Decode Load與Topology一起考慮；短Prefill或Decode Worker已有高Prefix Hit時，本地完成Prefill可能比遠端計算再搬KV更快。

• Aggregated Worker同時做Prefill與Decode，部署最簡單。
• Disaggregated Worker把Prefill和Decode放到獨立Pool。
• KV Transfer位於兩階段之間，是分離架構的Critical Path。
• 條件式P／D會判斷本地或遠端Prefill，而非固定分離所有Request。
• Dynamo KV Router同時考慮可重用Blocks與Active Decode Load。
• NIXL負責跨GPU、Host與Network資料傳輸抽象。
• Prefill與Decode必須使用相同Model、Dtype、Block Size和KV Layout。
• 是否值得導入，要用相同Trace比較TTFT、TPOT、Goodput和成本。

LLM Disaggregated Serving 的落地架構

LLM Disaggregated Serving 怎麼落地，需把 Dynamo、NIXL、Router、Prefill／Decode 分離與條件式 P／D 放在同一條資料流。文章觀察計算、記憶體、網路與請求路由如何被拆成可擴展元件。

為什麼要拆 Prefill 與 Decode

• Prefill：處理輸入上下文，偏向計算密集。
• Decode：逐 token 生成，偏向延遲與 KV cache 管理。
• Router：依佇列、SLO、KV 狀態與硬體負載分派請求。
• NIXL／Dynamo：負責資料搬運、服務編排或相關基礎設施，實際介面需以版本文件為準。

本文以「LLM Disaggregated Serving 的落地架構」為主線，補回人物、作品、制度、技術、場景與它們之間的關係，讓讀者能從具名實體一路追到實際流程與文化語境。

Aggregated與Disaggregated差在哪？

面向	Aggregated	Disaggregated
Worker	同一程序處理Prefill與Decode	獨立Prefill／Decode Pool
KV	留在本地Worker	需傳輸或暴露給Decode
擴縮	兩階段一起擴	可依Input／Output Token獨立擴
部署	簡單	Router、Transfer、Failure更複雜
適合	短請求、低流量、單機	長Prompt、高Concurrency、大叢集

通用Prefill／Decode資源差異可閱讀Prefill和Decode為什麼要拆？；DistServe研究原型則由DistServe是什麼？負責。

Dynamo分離式推論的四個元件

OpenAI-compatible Frontend
          ↓
KV-aware / Disaggregated Router
    ├─ Prefill Workers
    │      ↓ KV via NIXL / connector
    └─ Decode Workers
           ↓ streaming tokens

• Frontend：接收請求、Tokenize與Streaming。
• Router：選擇Prefill和Decode Worker，平衡Cache與Load。
• Prefill Pool：處理Prompt並建立初始KV。
• Decode Pool：接收KV後逐Token生成。
• Transfer Path：以NIXL、Connector或Backend搬移KV。

條件式P／D為什麼重要？

固定遠端Prefill會替每個Request加入Router、Queue和KV Transfer。當Prompt很短，或Decode Worker已經保存大部分共同Prefix時，本地Prefill可能更快。條件式分離會估算兩條路徑：

remote_cost =
prefill_queue
+ remote_prefill
+ kv_transfer
+ synchronization

local_cost =
missing_prefix_compute
+ local_queue
+ decode_interference

Router選擇預估完成時間較低的路徑。這個判斷需要Prompt Length、Prefix Cache Hit、Worker Queue、KV Bytes與Topology資料，不能只用固定Token門檻。

KV-aware Router如何選Worker？

Dynamo的KV Router會同時估算需要重新Prefill的Blocks與Worker目前的Decode負載。高Cache Hit Worker若已經過載，不一定是最佳選擇；完全空閒但沒有Prefix的Worker，也可能因重算太多而拖慢TTFT。

routing_cost ≈
cache_miss_prefill_blocks × prefill_weight
+ active_decode_blocks
+ queue_and_topology_penalty

• KV Event用來追蹤Block建立與刪除。
• Prefix Overlap降低預估Prefill成本。
• Active Blocks反映未來Decode Load。
• Temperature可控制選擇確定性。
• 無KV Event時只能用路由歷史近似Cache狀態。

NIXL在做什麼？

NVIDIA Inference Transfer Library（NIXL）是Dynamo資料移動層，用來把KV和其他Tensor在GPU、Host Memory及Network Backend之間傳送。架構重點是讓上層Serving不必為每種RDMA、Shared Memory或Storage路徑重寫全部邏輯。

• 跨節點GPU-to-GPU KV傳輸。
• 和vLLM NixlConnector整合。
• 和LMCache等多層KV Backend組合。
• 依Topology限制或偏好Decode Worker。
• 在不支援RDMA時提供替代路徑。

NIXL降低傳輸介面碎片，不會消除物理Bandwidth和Latency。40GB KV仍需要實際跨NIC搬移，也要處理Queue、Registration與同步。

Prefill與Decode相容條件

• Model Weight與Revision完全一致。
• Tokenizer和Chat Template一致。
• KV Dtype、Quantization與Scale一致。
• Block Size與Attention Layout一致。
• Tensor／Pipeline／Expert Parallel映射可轉換。
• LoRA、Adapter與Multimodal Hash一致。
• RoPE、Sliding Window與Hybrid Attention配置一致。

只要其中一項不同，Decode可能拒絕KV，或更危險地產生錯誤結果。部署應把Model Compatibility寫入Worker Registration與Route Filter。

Topology-aware KV Transfer

跨Rack或跨Zone傳輸的成本可能遠高於同機NVLink或同Rack RDMA。Topology-aware Routing會限制或偏好和Prefill位於相同Transfer Domain的Decode Worker。

路徑	一般延遲	適合
同機NVLink	最低	小型固定P／D配對
同機PCIe	低至中	通用GPU P2P
同Rack RDMA	中	Scale-out Pool
跨Rack／Zone	最高且抖動大	容錯或容量溢出

物理拓撲可閱讀GPU拓撲感知通訊怎麼做？。

Failure與取消

• Prefill完成但KV只傳了一部分。
• Decode Worker在接收後Crash。
• Client取消但Transfer仍在進行。
• Router重試造成重複Prefill。
• Worker版本滾動更新造成Layout不相容。
• KV Metadata存在但實際Buffer已被回收。

每個Request需要Run ID、Model Revision、KV Generation、Checksum、Timeout與Cancellation Token。外部Tool或付款副作用不應因推論重試而重複執行。

何時應使用Disaggregated Serving？

• 長Prompt或RAG請求讓Prefill成為主要成本。
• 長輸出與高Concurrency讓Decode需要更多KV容量。
• Input／Output Token比例明顯不對稱。
• 兩階段需要不同TP或GPU類型。
• 已有RDMA、KV Connector與跨Pool Trace。
• Aggregated與Chunked Prefill仍無法達成SLO。

何時應保持Aggregated？

• 短Prompt、短Output和低Concurrency。
• 單機或少量GPU已能承載。
• KV Transfer慢於本地重算。
• 模型與功能更新頻繁。
• 團隊缺少Router、Network與Failure治理。
• 瓶頸在應用Tool、Database或前端。

Benchmark矩陣

維度	測試
ISL	128、2K、16K、128K
OSL	16、256、1K、4K
Prefix	Cold、Partial Hit、Full Hit
Topology	同機、同Rack、跨Rack
模式	Aggregated、Fixed P／D、Conditional P／D
流量	穩定、Burst、Mixed Length

• TTFT、TPOT與End-to-end P99。
• 符合SLO的Goodput。
• Remote Prefill比例。
• KV Transfer Bytes和Time。
• Router誤判與Fallback。
• GPU、NIC與Cost per Accepted Request。

常見問題

Disaggregated Serving一定要遠端Prefill嗎？

不一定。條件式架構可讓短Prompt或高Prefix Hit請求在Decode Worker本地完成Prefill。

KV-aware Routing和P／D分離一樣嗎？

不同。P／D分離決定兩階段是否拆開；KV-aware Routing決定請求應送到哪個有相關Cache且負載合理的Worker。

NIXL會自動讓KV傳輸零成本嗎？

不會。它提供資料傳輸抽象與高效路徑，實際速度仍由KV大小、Registration、Topology、NIC和壅塞決定。

官方資料

• NVIDIA Dynamo Disaggregated Serving
• Dynamo KV-aware Routing
• Dynamo Architecture Flow與NIXL

Disaggregated Serving的成熟度取決於Router能否正確判斷、KV能否及時到位，以及失敗時能否安全重建。把Prefill和Decode畫成兩個方框很容易；讓每個Request選到成本最低且可回復的路徑，才是Production問題。

YOLO_DEPTH_IMAGE_26448_20260817

Disaggregated Serving 的真正難題，不是把 Prefill 和 Decode 畫成兩個方框，而是要證明「拆開之後，整體服務真的更好」。分離會帶來獨立擴縮、不同 GPU 配置與更清楚的資源邊界，但同時也新增 Router、Queue、KV 傳輸、版本相容、取消、超時和故障重建。只要其中一段沒有被量測，系統就可能把原本的本地等待，換成更難追蹤的遠端等待。

比較穩健的判斷方式，是先建立三條可比較的路徑：Aggregated Serving 在同一個 Worker 完成兩階段；Fixed P／D 固定把所有請求拆到遠端 Prefill；Conditional P／D 則依 Prompt、Prefix Cache、Queue、KV bytes 和拓撲估算本地或遠端成本。三條路徑要使用相同模型、精度、請求 trace、SLO 和資源預算，否則得到的只是配置差異，不是架構差異。

分離的收益從哪裡來

Prefill 通常需要一次處理較長的輸入，計算密度和記憶體流量都可能很高；Decode 則反覆產生 token，對 KV cache、排程和每步延遲更敏感。當輸入長度和輸出長度的比例高度不對稱時，讓同一組 Worker 同時承擔兩種工作，會造成某一階段的尖峰干擾另一階段。獨立 Pool 可以依需求配置不同 GPU 數量、Batch 策略和擴縮規則。

但獨立 Pool 只有在資源不對稱足以抵銷額外通信成本時才值得。若 Prompt 很短、流量很低、Prefix Cache 命中率很高，遠端 Prefill 的排隊和 KV 搬運可能比本地重算更慢。這也是條件式 P／D 的必要性：分離不是信仰，而是一個每次請求都要重新估算的成本選擇。

把一次請求拆成可觀察的狀態機

一個完整的分離式請求至少可分成：accepted、route_selected、prefill_started、prefill_completed、kv_published、kv_transfer_started、kv_transfer_completed、decode_started、streaming 和 completed。每個狀態都要帶 Run ID、Model Revision、KV Generation、Worker ID、Topology Domain 和時間戳。若只記錄「Router 已送出」，發生 KV 不完整或 Decode Crash 時，就無法判斷哪個副作用已經成立。

狀態機還要定義可重試與不可重試的邊界。Router 暫時沒有可用 Worker，可能可以退避重試；KV transfer timeout 可能可以改走本地重算；但 Decode 已經開始向客戶端串流後，重新分配請求就必須處理已送出的 token、順序和取消語義。把所有錯誤都交給一個通用 retry loop，通常會造成重複 Prefill、孤兒 KV buffer 或客戶端收到兩段不一致的輸出。

Conditional P／D 的成本模型

條件式路由不應只用固定 Token 門檻。更接近實際的判斷，至少要估算本地路徑的缺失 Prefix 計算、Local Queue 和 Decode 干擾，也要估算遠端路徑的 Prefill Queue、Prefill Compute、KV Bytes、傳輸時間、同步時間與拓撲懲罰。這些數值不必一開始就非常精準，但必須能從 trace 回頭比較預估與實際。

remote_cost = prefill_queue
            + remote_prefill
            + kv_transfer
            + synchronization
            + topology_penalty

local_cost  = missing_prefix_compute
            + local_queue
            + decode_interference

成本模型應保留不確定性，而不是把估算結果當成事實。網路壅塞、Prefix Cache 失效、Worker 突然退出和 Burst 流量都會讓過去的平均值失真。可以用保守的 P95 或上限估算，並在遠端路徑失敗時保留本地 fallback；但 fallback 也要有限制，否則所有錯誤最後都集中到一個 Decode Worker。

實作時可以把路由決策保存成一筆可重播的事件：請求收到時的輸入長度、Prefix 指紋、候選 Worker、各路徑估算、最終選擇、實際 transfer bytes 與完成時間都要一起記錄。這讓團隊能回答「當時為什麼選遠端」以及「哪個估算開始失真」。如果只保存最後的 Worker ID，性能退化時就無法分辨是 Cache 命中率下降、Queue 估算過時，還是跨 Rack 網路變慢。

KV-aware Router 不只是找 Cache Hit

有 Prefix Cache 的 Worker 不一定是最佳目的地。它可能已經承擔大量 Active Decode Blocks，或位於較慢的跨 Rack 路徑；另一個沒有 Cache 的 Worker，卻可能有足夠算力與較短的傳輸距離。Router 應把 Cache Reuse、目前負載、Queue、KV 容量、網路拓撲和請求期限一起考慮，而不是用單一 Cache Hit 布林值決策。

Router 還需要處理資訊延遲。KV Event 到達 Router 時，實際 Buffer 可能已被淘汰；Worker 回報的 Queue 也可能在下一個瞬間改變。這代表路由決策必須有版本、TTL 和失效策略。若選中的 Worker 發現 KV Generation 不符，應能安全地回到重新 Prefill 或另一個已確認相容的 Worker，而不是繼續使用不確定資料。

對讀取中的 KV，還要區分「可定位」和「可消費」。Metadata 可能告訴 Router 某個 Block 曾經存在，但它不一定仍在正確的記憶體、仍持有有效 lease，或仍符合目前的 Model Fingerprint。Decode Worker 接手前應做最後一次 generation、layout 和 checksum 檢查；檢查失敗時，寧可支付一次本地重算，也不要用不確定的 cache 產生看似正常、實際錯誤的 token。

路由結果要能被解釋。每次選擇至少記錄候選 Worker、Cache Hit／Miss、預估 Prefill Blocks、Active Decode Blocks、Transfer Domain、成本分數與最後的 fallback 原因。沒有這些欄位，性能下降時只能猜測是 Router、KV、網路還是模型本身造成。

NIXL 與資料移動邊界

NIXL 的價值在於把 GPU、Host Memory 和 Network Backend 間的資料移動抽象化，讓上層服務不必為每條 RDMA、Shared Memory 或儲存路徑重新實作完整邏輯。但抽象不會消除物理成本。KV 的 bytes 仍然要經過記憶體、NIC、交換器和同步；Registration、Buffer Life Cycle、Queue Depth、Copy／DMA 排程都會影響尾端延遲。

因此，NIXL connector 的驗收不能只看「傳輸成功」。要量測 KV bytes、transfer start 到 completion、實際路徑、重試次數、Buffer 釋放時間、NIC 利用率和 Decode 等待時間。若 transfer 正在進行時請求被取消，系統要能取消或隔離這段搬運，避免已經沒有消費者的 KV 繼續佔用網路與記憶體。

資料移動層也需要清楚的 ownership。Prefill Worker 產生 KV 後，誰負責保存？Decode Worker 讀取後，何時可以回收？Router 持有的是 metadata 還是 buffer lease？如果這些問題沒有契約，常見結果就是 metadata 還存在，但真正的 buffer 已經被回收；或者 buffer 長時間不釋放，造成容量逐步下降。

Ownership 最好以 lease 和明確的生命週期表示，而不是靠服務之間的默契。建立 KV 時產生 generation 與 expiry，傳輸開始時鎖定讀取範圍，Decode 完成或取消時釋放 lease，reconciler 則定期找出逾時的孤兒 buffer。這套機制也要能處理 Prefill Worker 在發布 metadata 後立即崩潰、Decode Worker 只收到部分資料，或同一個 Run ID 被重試兩次的情況。每個狀態都必須可觀察、可去重、可回收，否則容量問題往往會在高峰過後才爆發。

這也說明為什麼分離式服務必須把觀測性當成資料平面的一部分。Trace 要串起 Router 決策、Prefill 計算、KV 發布、傳輸、Decode 等待與串流完成；Metrics 要能按 Model Revision、Topology Domain、Cache 狀態和失敗類型切分；Log 則保存足以重建事件的識別碼。沒有這些證據，團隊只能看到延遲變高，卻無法知道是哪一段先失去健康。

可觀測性還要保留一次請求的完整因果鏈，讓性能、正確性和資源回收能一起驗證，而不是各自報表互相矛盾。

只有把事件、版本、路徑、等待與回退原因連在一起，才能安全調整路由政策並重現問題。

這是分離架構能否長期維護的基本證據。

也讓調度決策真正可以被檢查。

相容性是路由前置條件

Prefill 與 Decode 必須對同一份 KV 使用相同的語義。Model Revision、Tokenizer、Chat Template、Dtype、Quantization、Scale、Block Size、Attention Layout、RoPE、Sliding Window、Hybrid Attention、LoRA／Adapter 與 Multimodal 設定，任何一項不同，都可能使 KV 無法使用或產生更危險的錯誤結果。

這些條件不應只放在部署文件裡，而要進入 Worker Registration 和 Route Filter。Worker 啟動時註冊 Model Fingerprint、KV Layout Hash、Parallel Mapping、Dtype、Block Size、Adapter Hash、Transfer Capability 和 Topology Domain。Router 只把相容的 Worker 放入候選集合；若沒有相容目的地，應回傳明確的 fallback 或 blocked，而不是把不相容 KV 送過去碰碰運氣。

滾動更新時尤其要小心。新舊 Worker 同時存在的窗口，可能讓同一個模型名稱指向不同 Revision。可以用 generation 或 compatibility epoch 隔離它們，等舊請求排空後再回收舊 KV。版本一致不是部署完成後的一次檢查，而是每個 Request、KV Generation 與 Worker Pair 都要持續驗證的條件。

Topology-aware Transfer

同機 NVLink、同機 PCIe、同 Rack RDMA 和跨 Rack／Zone 的延遲與抖動不同。Router 應把 Transfer Domain 當成成本的一部分：如果本地重算只需要幾個短 kernel，跨 Zone 搬一大塊 KV 通常不划算；如果 Prompt 很長而同 Rack 有空閒 Prefill，遠端計算加 RDMA 可能仍然值得。

拓撲資料也需要新鮮度和故障處理。NIC 降速、交換器壅塞或某個 Rack 進入維護狀態時，原本的成本矩陣就失效。系統可用 health score、bandwidth probe、transfer history 和 circuit breaker 更新拓撲偏好，但不要讓 Router 為了追逐瞬時數值而頻繁抖動。路由穩定性本身也是服務品質的一部分。

Failure、取消與重建

分離式服務的失敗路徑至少包括：Prefill 完成但 KV 只傳一部分、Decode Worker 在接收後崩潰、Client 取消但 transfer 尚未停止、Router 重試造成重複 Prefill、版本更新讓 Layout 不相容，以及 metadata 存在但 buffer 已被回收。每一種錯誤都要分類，並指定是重試、重新計算、改路徑、等待人工還是直接終止。

Run ID、KV Generation、Checksum、Timeout 和 Cancellation Token 是基本欄位。若允許重新 Prefill，要使用可去重的 operation id；若允許把同一請求轉到另一個 Decode Worker，要保存已送出的 token、目前序列位置與 KV 版本；若客戶端已取消，後端必須讓 cancellation 穿過 Router、Transfer 和 Worker，而不是只在 Frontend 停止等待。

故障演練要包含「看似成功但結果不完整」的情境。HTTP 200 不等於 KV 已可讀，Transfer completion 不等於 Decode 使用了正確 generation，Worker heartbeat 正常也不等於它仍有可用 HBM。獨立 verifier 應從 consumer 角度讀回狀態，確認資料身份、版本、checksum 和實際可消費性。

Benchmark 不只看 TTFT

分離式架構常在首 token 延遲（TTFT）與每 token 延遲（TPOT）之間產生取捨。遠端 Prefill 可能改善 Prefill Queue，卻增加 KV Transfer；Decode Pool 可能提高輸出吞吐，卻讓短請求的排隊變長。完整 benchmark 要同時看 End-to-end P50／P95／P99、Goodput、KV Transfer Bytes、Transfer Time、Remote Prefill Ratio、Fallback Ratio、GPU／NIC 利用率與每個已接受請求成本。

測試矩陣至少要包含 Cold Prefix、Partial Hit、Full Hit；短、中、長 ISL；短、長 OSL；穩定流量、Burst 與混合長度；同機、同 Rack 與跨 Rack。每一組都要比較 Aggregated、Fixed P／D 和 Conditional P／D，並固定模型、精度、GPU 數量、Trace、SLO 與成本口徑。只展示最佳平均值，會掩蓋尾端延遲與 fallback 失敗。

何時不要拆

短 Prompt、短 Output、低 Concurrency、單機部署、KV Transfer 比本地重算更慢，或團隊尚未具備 Router、Network、版本和 Failure 治理能力時，Aggregated Serving 通常更合理。架構複雜度本身是一種成本，不能只用模型吞吐抵銷。若瓶頸其實在 Tool、Database、Tokenization 或前端排程，先拆 Prefill／Decode 不會解決真正問題。

相反地，當 Input／Output Token 比例明顯不對稱、長 Prompt 或 RAG 讓 Prefill 成為主要成本、Decode 需要獨立的 KV 容量，或兩階段需要不同 GPU 與擴縮策略時，分離才值得進行小規模試驗。試驗要從可回復的 shadow 或 bounded canary 開始，先證明路由和 read-back，再擴大流量。

來源與實作邊界

本文以NVIDIA Dynamo 官方文件核對分散式推論、disaggregated serving、KV-aware routing、cache management 與 engine interoperability 的系統脈絡；以Dynamo 官方 GitHub repository核對開源架構與實作入口；以NIXL 官方 GitHub repository核對資料移動層與 GPU、Host、Network backend 的整合邊界。文中的成本模型、狀態機、相容性欄位、失敗分類與 benchmark 矩陣，是依官方概念提出的工程設計建議，不代表任何單一叢集的性能保證。

原創編輯圖由 YOLO LAB 生成，以 Prefill Pool、KV Transfer Fabric、KV-aware Router、Decode Pool、Topology 與失敗回退路徑呈現分離式推論；不是 NVIDIA Dynamo、NIXL 或任何產品的官方架構圖、介面截圖或品牌素材。實際部署仍需以目標模型、硬體、驅動、網路、Connector 版本和真實流量做可回復 benchmark。

Disaggregated Serving 的驗收標準不是「已經把兩個 Worker Pool 啟動」，而是每個請求都能被正確路由、KV 能在期限內以正確版本抵達、失敗時能重算或回退、取消不會留下孤兒工作，並且端到端 SLO、Goodput、成本和故障行為都比 Aggregated baseline 更符合需求。只有這樣，分離才是架構改進，而不是把一個簡單問題拆成更多服務。

增量：Disaggregated Serving 的核心，是把 prefill 與 decode 的資源節奏分開管理

Prefill 偏向大批量矩陣計算，Decode 則反覆讀取 KV Cache、逐 token 產生結果。兩者混在同一組 GPU 上時，容易互相干擾；拆分後可以分別配置硬體、批次策略與服務目標，但代價是要搬運 KV、管理路由與處理故障。

因此 P／D disaggregation 不是「拆了就會快」。Router 必須知道請求狀態、cache 位置、序列長度、網路擁塞與可用容量；NIXL 或類似傳輸層則要讓資料搬運的尾延遲不會抵消計算側節省的時間。

落地時應先定義條件式路由：短請求、低重用率或網路繁忙時，合併服務可能更划算；長上下文、高併發或 prefill／decode 資源需求明顯不同時，拆分才可能有收益。這些條件要由 benchmark 驗證，不應只看架構圖。

驗收至少包含 TTFT、每 token 延遲、吞吐、KV 傳輸時間、重試與節點故障。若只報平均吞吐，容易掩蓋某些請求在跨節點搬運時出現的 P95／P99 惡化；真正的服務設計要對尾端體驗負責。