分離預填充與解碼

預填充與解碼分離（prefill-decode disaggregation）把提示處理與 token 生成分給不同的工作池，再把每個請求的 KV 狀態在兩者之間傳遞。這種拆分能讓解碼免受長提示預填充的干擾，也讓兩個工作池各自擴縮。兩個工作池仍須載入相容的模型權重；相較於共置（aggregated）基準，權重的總複製份數是否增加，取決於部署配置。分離架構還會增加路由與 KV 傳輸，帶來新的故障模式；若工作負載或網路條件不足以讓這項設計划算，延遲或容量反而可能變差。

本篇把分離架構視為需要實測的工程取捨，而不是預設的升級。你將估算單次 KV 傳輸量、比較各種拓撲的預算、定義共置與分離架構的基準測試，最後否決短提示案例：遠端預填充在那裡只增加成本，沒有修復任何 SLO 問題。

正確界定兩個階段

在僅解碼器（decoder-only）Transformer 中，預填充會平行處理大量已知的提示位置，算術強度（arithmetic intensity）通常較高；低批次解碼則是每條活躍序列只處理一個新位置，算術強度通常較低，因此權重與 KV 的記憶體流量可能成為主要開銷。提示長度、批次大小、注意力變體、量化方式、運算核心（kernel）的選擇與硬體，都可能改變兩個階段各自的瓶頸型態。

營運上的問題在於跨階段干擾：大型預填充若與活躍的解碼排在一起，或排在它們前面，就可能拉長使用者看到的串流 token 間隔。分塊預填充是在共用的工作節點上限制這段中斷；分離架構則把兩個階段隔離到各自的工作池。

階段隔離也有代價。每個工作池都需要相容的模型權重與執行期容量，每筆預填充結果都必須送達解碼節點，請求也多了幾個可能失敗的環節：路由、KV 緩衝區配置、傳輸、交接與解碼准入（admission）。

架構與請求流程

1. 前端將請求分詞（tokenize）並執行准入控制。

2. 預填充路由器依據未命中快取的提示 token 數、佇列深度與前綴快取局部性，挑選相容的預填充節點。

3. 預填充節點計算提示的 KV 狀態與交接中繼資料，包含可能已先取樣出的第一個輸出 token。

4. 若採直接傳輸，須先選定相容的解碼節點並預留其接收緩衝區；共用儲存設計則可能先發布 KV 區塊，之後再指派讀取端。

5. 選定的傳輸機制搬移所需的 KV 區塊，並在交接時驗證身分、區塊布局、token 序列、就緒狀態與緩衝區擁有權。

6. 解碼節點接手後續的 token 生成。請記錄第一個 token 是在交接前還是交接後串流送出，因為這個選擇決定傳輸延遲會落在 TTFT，還是落在前段的 ITL 分布。

NVIDIA Dynamo 現行文件對預填充與解碼採取不同的路由方式：解碼階段的路由器會停用前綴重疊評分，因為解碼路由不應追逐前綴重用；除非後端真的能對傳輸過來的區塊去除重複（deduplicate），否則不假設 KV 可以重用；也不再計入預填充 token，讓解碼端負載只反映解碼工作。若啟用拓撲感知的 KV 傳輸，還可以把解碼路由限制在或偏向所選預填充節點的傳輸網域（Dynamo 分離式路由指南）。

現行實作成熟度很關鍵

截至 2026-11-02 查核時，vLLM 將預填充分離標為 experimental（實驗性），並直接說明這項功能不會提升吞吐量。文件列出的理由是分開調校 TTFT 與 ITL，以及控制尾端 ITL。分塊預填充只要分塊大小合適，也能達到相同的尾端 ITL 目標，但文件指出實務上很難找出正確的大小，因此稱預填充分離是控制尾端 ITL 可靠得多的做法（vLLM Disaggregated Prefilling）。

這項範圍說明與研究系統並不矛盾：研究系統可以透過階段專屬的部署配置與硬體佈建，提高符合 SLO 條件的容量。這段說明只是避免讀者把已發表的研究結果，當成某項現行功能的承諾。

可重現的 KV 傳輸公式

針對標準 GQA KV 張量：

KV_bytes = 2 × layers × kv_heads × head_dim × bytes_per_element × prompt_tokens

bandwidth_floor_ms = KV_bytes / (effective_GB_per_second × 10^9) × 1000

handoff_floor_ms = setup_ms + bandwidth_floor_ms

這裡的 effective_GB_per_second 是持續的酬載頻寬，不含另外建模的準備時間項；若實測速率已包含準備時間，就不要再加一次 setup_ms。此公式假設完整的邏輯 KV 酬載經過單一等效連結。分片平行傳輸則需要逐 rank 計算位元組數、檢查共用連結的競爭，並分析關鍵路徑。連結的峰值規格不等於應用程式實測到的頻寬。

固定傳輸計算範例的條件

以下採用假設的模型架構與提示條件：

KV 大小計算：

KV bytes/token = 2 × 80 × 8 × 128 × 2
               = 327,680 bytes

KV bytes       = 327,680 × 2,000
               = 655,360,000 bytes
               = 625 MiB

完整範例：比較三種傳輸連結

20 ms 交接預算是本教學設定的限制，並非通用 SLO。通過這個簡化下限，只代表 100 GB/s 連結還留在候選名單中；排隊、緩衝區配置與同步仍可能讓實際交接時間超過 20 ms。

DistServe 對總頻寬做過概算：依論文採用的單位，一筆 512 個 token 的 OPT-66B 請求約有 1.13 GB 的 KV，每秒十筆請求約需 90 Gbps。這個數字估算的是網路流量，並不保證單筆請求的延遲看不出傳輸時間。DistServe 的評估以 vLLM 與 DeepSpeed-MII 為對照，回報在超過 90% 請求同時達成 TTFT 與 TPOT 目標的條件下，每 GPU 請求率最高可達 7.4×；7.4× 這個最大值是相對於 DeepSpeed-MII 測得（Zhong et al., OSDI 2024）。這是 DistServe 在其評估環境下的實測結果，與本篇表格中的假設數值是兩回事。

若要以明確的單位估算：OPT-66B 公開的模型設定為 64 層、隱藏維度 9,216。假設 K/V 採完整多頭注意力並以 FP16 儲存，快取 512 個 token 需要 2 × 64 × 9,216 × 2 × 512 = 1,207,959,552 bytes，也就是 1.125 GiB ≈ 1.208 GB；每秒十份這樣的酬載，未計協定開銷就約為 96.64 Gbit/s。請使用這種單位明確的算式，不要把論文四捨五入後的 90 Gbps 範例當成網路佈建數字（OPT-66B 模型設定）。

傳輸策略

序列式點對點交接

預填充完成後傳送完整的 KV 狀態，再把生成工作交給解碼端。若第一個輸出 token 在交接前就已串流送出，這段傳輸延遲會直接落在第一個與第二個可見 token 之間。

逐層非同步傳輸

Splitwise 在後續層繼續預填充的同時，以非同步方式傳送每一層的 KV 狀態，把部分傳輸時間藏在進行中的運算背後。對較短的提示而言，細部重疊的開銷大於收益，因此 Splitwise 改用序列式傳輸（Patel et al., ISCA 2024）。第一個 token 在交接前或交接後送出，取決於執行環境，必須在用戶端觀察確認。

共用或分層 KV 儲存

預填充節點把 KV 區塊寫入分散式快取或記憶體階層，解碼節點再依需要讀取。Mooncake 的長上下文 LLM 服務架構，以分散式 KV 儲存與 KV 感知排程為核心（Qin et al., 2024）。維運團隊要管理的不再是單一的點對點交接，而是階層命中率、區塊配置位置、讀寫總頻寬、驅逐（eviction）與中繼資料一致性。

建立傳輸模型

將以下程式存為 model_pd_transfer.py，並執行 python model_pd_transfer.py > pd-transfer-model.json：

import json

LAYERS = 80
KV_HEADS = 8
HEAD_DIM = 128
BYTES_PER_ELEMENT = 2
PROMPT_TOKENS = 2000
SETUP_MS = 1.0
HANDOFF_BUDGET_MS = 20.0
LINKS_GB_S = [100, 25, 10]

bytes_per_token = 2 * LAYERS * KV_HEADS * HEAD_DIM * BYTES_PER_ELEMENT
kv_bytes = bytes_per_token * PROMPT_TOKENS

links = []
for bandwidth in LINKS_GB_S:
    bandwidth_floor_ms = kv_bytes / (bandwidth * 1e9) * 1000
    handoff_floor_ms = SETUP_MS + bandwidth_floor_ms
    links.append({
        "effective_bandwidth_gb_s": bandwidth,
        "bandwidth_floor_ms": bandwidth_floor_ms,
        "handoff_floor_ms": handoff_floor_ms,
        "floor_within_20ms_budget": handoff_floor_ms <= HANDOFF_BUDGET_MS,
    })

short_prompt_tokens = 300
short_kv_bytes = bytes_per_token * short_prompt_tokens
short_handoff_10gb_s_ms = SETUP_MS + short_kv_bytes / (10 * 1e9) * 1000

artifact = {
    "scope": "hypothetical GQA transfer model",
    "bytes_per_token": bytes_per_token,
    "prompt_tokens": PROMPT_TOKENS,
    "kv_bytes": kv_bytes,
    "kv_mib": kv_bytes / 2**20,
    "links": links,
    "broken_short_prompt_case": {
        "prompt_tokens": short_prompt_tokens,
        "effective_bandwidth_gb_s": 10,
        "handoff_floor_ms": short_handoff_10gb_s_ms,
    },
}
print(json.dumps(artifact, indent=2))

預期核心數值（浮點數四捨五入至小數點後四位）：

bytes_per_token = 327680
kv_bytes = 655360000
kv_mib = 625
100 GB/s handoff floor = 7.5536 ms, floor_within_20ms_budget=true
25 GB/s handoff floor = 27.2144 ms, floor_within_20ms_budget=false
10 GB/s handoff floor = 66.5360 ms, floor_within_20ms_budget=false
300-token/10 GB/s handoff floor = 10.8304 ms

選擇部署架構前的基準測試入門

先用 I-06 的部署配置表，核對兩種設計實際使用的 GPU 數。TP8 代表八個張量平行 rank 共同執行一個模型副本。兩組共置的 TP8 副本使用 16 張 GPU；一組 TP8 預填充池加上一組 TP8 解碼池，同樣使用 16 張 GPU。相同的 GPU 數只是比較時的限制條件，不代表成本或效能會相同。

請分清以下四個基準測試指標：

• 送入速率（Offered rate）：用戶端每秒排定送出的請求數，與伺服器何時完成無關。請檢查實際的發送延遲，以免用戶端的背壓掩蓋伺服器超載。

• 吞吐量（Throughput）：在宣告的量測區間內，每秒成功完成的請求數；失敗的請求仍留在可靠性的分母中。

• 延遲與達標率（Latency and attainment）：TTFT 量測到第一個輸出 token 的時間，TPOT 則是後續輸出 token 的平均時間。一筆請求必須通過每一項要求的門檻，才算聯合達標（joint pass）；平均延遲既不是尾端百分位數，也不是聯合達標率。

• 符合 SLO 的容量（SLO-compliant capacity）：在固定工作負載下，滿足所宣告的達標率、錯誤率與佇列穩定門檻的最高已測送入速率。光憑傳輸下限很低，永遠無法確立容量。

以合成的 100 筆請求群組為例：95 筆成功，其中 90 筆同時符合兩項延遲門檻。錯誤率為 5%，成功請求中的聯合達標率為 90/95（約 94.7%），以全部嘗試為分母的聯合達標率則是 90%。比較不同部署前，務必先宣告分母；依本篇「全部嘗試至少 95% 達標」的門檻，這個合成測試點不合格。

變更部署配置時，請固定請求排程、模型版本、序列長度、快取策略、硬體與量測邊界。用戶端指標慣例依循 vLLM 基準測試指南。這份入門已足以解讀下面的傳輸實驗；完整的 SLO 分析器、樣本數與不確定性政策、容量餘裕計算與故障測試，會在 I-07 展開。

建立等預算基準測試計畫

建立 pd-benchmark-plan.yaml：

comparison:
  model_revision: "<same immutable revision>"
  engine_version: "<same pinned version>"
  total_gpus: 16
  gpu_type: "<same pinned SKU>"
  network_and_host_budget: "<declare and match>"
  warmup_requests: 100
  offered_rates_rps: [1, 2, 4, 8]
  output_tokens_minimum_for_tpot: 2
  request_deadline_seconds: 120
  precision: bf16
  workload_trace: "<same timestamped input/output/prefix distribution>"
  cache_state: [cold, warm]
  duration_seconds: 600
deployments:
  aggregated:
    description: "same workers perform prefill and decode"
    replicas: 2
    tensor_parallel: 8
    pipeline_parallel: 1
  disaggregated:
    prefill_replicas: 1
    decode_replicas: 1
    tensor_parallel_per_replica: 8
    pipeline_parallel_per_replica: 1
    kv_transport: "<declared backend and topology>"
metrics:
  client: [ttft, tpot, itl, e2e, errors, goodput]
  scheduler: [prefill_queue, decode_queue, running, rejected]
  kv_transfer: [bytes, setup_ms, transfer_ms, failures]
acceptance:
  ttft_max_ms: 2000
  tpot_max_ms: 50
  max_itl_per_request_ms: 200
  numerator: successful_requests_meeting_all_three_latency_conditions
  denominator: all_offered_requests_after_warmup_including_rejections_and_timeouts
  slo_attainment_min: 0.95
  error_rate_max: 0.01
  require_no_sustained_queue_growth: true

請在相同 GPU 數與相同的開迴路（open-loop）工作負載下比較兩種架構。報告可以列出原始吞吐量，但選擇架構時應依據同時滿足 TTFT 與 TPOT／ITL 目標的最高到達速率。更動 GPU 數、加速器型號、電力或網路預算，或是提示集合，都會混淆階段配置的比較。跨硬體或 GPU 數不同的設計，仍可用明確正規化後的成本或容量來比較，但它們回答的是另一個問題。

刻意破壞的案例：慢速連結上的短提示

假設另一組獨立的合成基準條件：

• 300 個 token 的短提示；

• 共置部署的 P95 ITL 為 35 ms，目標為 50 ms；

• 本機預填充的干擾區間為 2 ms；以及

• 遠端連結有效頻寬為 10 GB/s，另加 1 ms 交接準備時間。

交接下限為 10.8304 ms。在序列式交接、且沒有排隊或運算收益可以抵銷的前提下，把 2 ms 的本機預填充干擾換成遠端傳輸，受影響的路徑至少多出 8.8304 ms。這個單筆請求的下限並不能證明分離架構會突破 50 ms 的 P95 ITL 目標，因為單點的交接下限不是尾端百分位數，而且共置基準本來就已達成 50 ms 的 SLO，還有 15 ms 的餘裕。在端對端速率掃描得出不同結果之前，工程判定是「現有證據不足以支持採用」。

保留共置服務作為基準，先調校分塊預填充，再評估只把長且未命中快取的提示交給遠端預填充。唯有實測的 SLO 條件容量或成本足以證明值得，才採用較複雜的設計。把「全部分離」當成預設規則，就會得到這個錯誤設定。

動手實作

1. 對 300、2,000 與 8,192 個 token 三種提示長度執行傳輸模型。

2. 加入 FP8 KV 作為理想化的敏感度分析案例，再列出實務上需要的縮放因子、對齊與準確度要求。

3. 在目標拓撲上，以至少兩種訊息大小量測實際的有效頻寬。

4. 在同樣 16 張 GPU 的預算下，分別執行共置與分離部署的速率掃描。

5. 回報 P50／P95／P99 的 TTFT 與 TPOT／ITL、聯合 SLO 達標率、錯誤率、佇列趨勢與 KV 傳輸延遲分布。

6. 注入一次失敗的傳輸，驗證執行環境會乾淨地讓請求失敗，或最多重試一次，且不會向用戶端送出重複的 token，也不會洩漏 KV 緩衝區（重試可能重算預填充，因此這不是「運算恰好執行一次」的保證）。

7. 測試選擇性路由策略：讓短提示或前綴已在快取中的預填充留在本機執行。

可量測的完成標準

符合以下條件時，本教學才算通過：

• 明確指出階段瓶頸會隨工作負載與硬體而變；

• KV 位元組數由層數、KV 注意力頭數、頭維度、資料型別與提示長度推導得出；

• 2,000 個 token 的計算範例精確算出 625 MiB；

• 每條連結的結果都把頻寬下限與交接準備、執行期開銷分開列出；

• 載明 vLLM 現行功能的實驗性質，以及不提升吞吐量的範圍說明；

• 引用 DistServe 的 7.4× 結果時，保留對照基準與「超過 90% 請求同時達成 TTFT／TPOT 目標」的條件；

• 假設值皆有標示，並與已發表的論文實測結果分開；

• 共置與分離測試使用相同資源與相同的工作負載軌跡；

• 短提示的採用提案以證據不足為由否決，且不宣稱未經量測的 SLO 違規；以及

• 傳輸失敗、防止重複輸出與復原都經過測試。

提取練習

1. 在現行 vLLM 文件中，預填充／解碼分離主要解決什麼問題？

2. 為什麼互連的峰值頻寬不足以建立傳輸模型？

3. 在分離式設計中，前綴局部性通常應該影響哪一段路由？

4. 逐層傳輸試圖隱藏什麼？

5. 為什麼不能只看原始吞吐量來挑選部署架構？

6. 為什麼 300 個 token 的短提示反例應該維持共置部署？

解答

1. 分開調校 TTFT／ITL，以及控制尾端 ITL；vLLM 文件明確表示這項功能不會提升吞吐量。

2. 有效頻寬取決於拓撲、訊息大小、傳輸協定、連結競爭、記憶體註冊與同步。

3. 主要在挑選預填充節點或共用快取時；挑選解碼節點時，通常優先考量相容的傳輸拓撲與當下的解碼負載。

4. KV 傳輸時間，藏在後續模型層正在進行的預填充運算背後。

5. 部署可能在拉高原始吞吐量的同時，違反 TTFT 或 TPOT／ITL 門檻；符合 SLO 條件的容量必須同時通過延遲、錯誤與佇列穩定門檻。

6. 在序列式、無重疊的設定下，10.8304 ms 的交接下限超過它所取代的 2 ms 本機干擾，而共置基準本來就達成 50 ms 的 P95 ITL 目標，因此無法證明有任何端對端效益。若要確定實際的 SLO 與成本結果，仍需要端對端速率掃描。

本文不涵蓋的內容

本篇不指定特定的 KV 連接器或叢集拓撲。I-06 涵蓋密集模型的平行化與集體通訊配置；I-07 則涵蓋正式環境選型所需的完整容量、SLO 與可觀測性流程。

來源與延伸閱讀

• Zhong, Y., Liu, S., Chen, J., et al. "DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving." OSDI, 2024。預填充／解碼分離、SLO 條件下的有效吞吐量、部署配置與 KV 傳輸量估算的第一手來源。usenix.org

• Patel, P., Choukse, E., Zhang, C., et al. "Splitwise: Efficient Generative LLM Inference Using Phase Splitting." ISCA, 2024。階段專屬工作池與逐層非同步 KV 傳輸的第一手來源。microsoft.com

• vLLM Project. "Disaggregated Prefilling (Experimental)." 現行文件，查閱日期 2026-11-02。功能成熟度、TTFT／ITL 設計理由、連接器與「不提升吞吐量」聲明的官方第一手說明。docs.vllm.ai

• NVIDIA Dynamo. "Disaggregated Serving." 現行文件，查閱日期 2026-11-02。預填充／解碼路由與拓撲行為的官方第一手說明。docs.nvidia.com

• Qin, R., Li, Z., He, W., et al. "Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving." arXiv, 2024。會議版本以 "Mooncake: Trading More Storage for Less Computation" 為題發表於 FAST 2025。分散式 KV 儲存與長上下文服務的第一手來源。arxiv.org/abs/2407.00079