前言
面對「請設計一個類似 ChatGPT 的系統」面試題，千萬別一直把重點放在資料庫怎麼存對話紀錄。
在 LLM 推論系統中，真正的挑戰是吞吐量（Throughput）與延遲（Latency）的極限拉扯。
本篇文章透過五維度分析法，帶你拆解大模型背後的 KV Cache 管理、批次處理（Batching）與 GPU 平行運算（Parallelism）策略。
這篇你可以帶走什麼
- 為什麼 TTFT 與 TPOT 必須分開優化
- KV Cache 與 Continuous Batching 的核心價值
- 超長 Prompt 為何會拖垮整批請求
- 何時該做 Prefill-Decode 分離（PD 分離）
- 量化與張量平行如何突破顯存瓶頸
維度一、可直接觀察的事實：系統邊界與硬體極限
LLM 推論服務和傳統 Web 服務有本質差異。
- Token-by-Token 生成：模型每次只能預測下一個 Token（自迴歸，Autoregressive）。
- 極度消耗 VRAM：以 7B 模型的 FP16 為例，光模型權重約需 14GB；若是 70B 模型，約需 140GB，單張 80GB GPU 無法承載。
- 推論分兩階段：
- Prefill：讀入長 Prompt 並建立上下文，偏運算密集（Compute-bound），主要影響首字延遲（TTFT, Time To First Token）。
- Decode：逐 Token 生成，反覆讀取歷史狀態，偏記憶體頻寬密集（Memory-bound），主要影響每個 Token 的生成延遲（TPOT, Time Per Output Token）。
重點：LLM 推論瓶頸不只在算力，更在顯存與記憶體頻寬管理。
維度二、條件檢查：效能最佳解與它的邊界
一般情況下的最佳解（KV Cache + Continuous Batching）
為避免 Decode 階段重複計算前文，業界標準做法是 KV Cache：把每層 Transformer 計算過的 Key/Value 暫存在 VRAM，後續只計算新 Token 的注意力。
為提升 GPU 利用率，排程通常採 Continuous Batching：
- 只要 GPU 有空隙，就動態塞入新請求
- 不必等整批最慢任務結束才收下一批
- 在多租戶流量下可顯著提升吞吐
邊界條件（超長文本導致資源阻塞）
若 Continuous Batching 直接混排長短請求，遇到 100K Token 超長 Prompt 時，Prefill 階段會算非常久。這會導致同一個 Batch 內的其他短任務全卡在 GPU 裡乾等，造成整體延遲瞬間飆高。
重點：Continuous Batching 很強，但需要長短請求隔離策略，否則會被極端長文本反噬。
維度三、反證檢查：跳脫直覺的排程與架構盲點
盲點一：既然 Prefill 會拖慢 Decode，那就混在一起算到底？
反直覺解法是 Prefill-Decode Disaggregation（PD 分離）：
- 一群 GPU 專做 Prefill（大運算量）
- 另一群 GPU 專做 Decode
- 中間用高速網路（RDMA / RoCE v2）傳遞 KV Cache
優點是能分別優化硬體利用率；代價是跨節點傳輸成本與系統複雜度上升。
盲點二：KV Cache 就乖乖放 VRAM，滿了就降並發(Concurrency)？
作業系統早就告訴我們記憶體碎片化怎麼解！借鑒 OS 的虛擬記憶體概念，引入 PagedAttention（如 vLLM 框架的核心）。把 KV Cache 切成一個個固定大小的 Block（分頁），不連續儲存。甚至可以把暫時用不到的 KV Cache「換頁（Swapping）」到 CPU 記憶體，等需要時再拉回 GPU，這能讓伺服器承載的並發人數直接翻倍。
維度四、不確定性分析：模型縮小與平行化策略
觀察事實：硬體 VRAM 是固定資源（例如 A100 就是 80GB）。
因此當模型大於單卡容量，除了加機器，必須做軟體層「縮骨功」：
- 量化（Quantization）：將原本 16-bit 浮點數（FP16）的模型權重與 KV Cache，強制壓縮成 8-bit（FP8）甚至 4-bit。這能在微幅犧牲精準度的情況下，將 VRAM 需求砍半。
- 張量平行（Tensor Parallelism, TP）：對於 70B 這種巨獸，單卡放不下，必須把神經網路的巨大矩陣「切開」，分給多張 GPU 同時算，算完再透過 NVLink 交換結果。這極度依賴 GPU 之間的超高頻寬。
這兩種策略通常需要組合使用，才能在成本與品質之間取得可營運平衡。
維度五、最終結論與行動建議
可落地的架構藍圖可拆成三層：
- API Gateway & Session Manager：負責認證、限流、會話狀態與上下文讀取（如 Redis / DynamoDB）。
- Scheduler：實作 Continuous Batching；對超長 Prompt 使用 Chunked Prefill，避免卡死短任務。
- Inference Engine：使用 vLLM 等高效引擎，啟用 PagedAttention、KV Cache 管理與 Tensor Parallelism。
破關路線圖（信心度 90%）
- 初期階段：先聚焦 Session 管理與調用開源框架（如 vLLM），落地 Continuous Batching + PagedAttention，避免 OOM(Out of Memory)。
- 進階階段：導入 Chunked Prefill、長短請求隔離與更細粒度排程策略。
- 高階挑戰：研究 PD 分離、KV Cache 跨節點傳輸優化，以及 GQA / MQA 對 KV 體積的進一步壓縮。
脆弱點提示
若系統場景從一般聊天機器人轉為 Coding Assistant，會出現大量相似 Prefix（如 import、共用模板、重複註解）。
若沒有 Prefix Caching，系統會反覆 Prefill 相同上下文，造成算力與延遲雙重浪費。此時必須引入前綴快取，重用共享 KV Cache。
一句話總結
設計 LLM 推論系統，本質是一場對抗 GPU VRAM 極限的資源保衛戰：誰能更好管理 KV Cache、批次排程與平行化，誰就能在高流量下活下來。