📺 本文題目與架構參考自 s09g 的影片《AI System Design - MultiModel inference》，內容以我自己的話重組，並補上「面試官追問」的角度。
傳統系統設計考「設計推薦系統 / Feed」，但 2026 年的 ML/AI 面試越來越愛考一道更硬的題目——怎麼把一個大型多模態 LLM 真正撐起來上線。這題考的不是你會不會調模型，而是 GPU 成本、推理排程、串流、安全與監控的系統工程。
這篇是我前一篇 ML System Design 八步框架 的進階實戰：先 clarify、再估算、然後分層設計。
📋 題目
為一個 AI 助理設計後端系統，支撐 100 萬日活躍用戶（1M DAU） 的即時對話。需支援多模態輸入（文字、圖片、音訊）與多模態輸出（文字串流、語音、圖像生成），並維持多輪對話上下文。要求：可靠、低延遲、可擴展、可觀測。
這題大到不可能一次講完，所以分層拆解，每層都先講「為什麼」再講「怎麼做」。
一、需求分析與成本估算（先算清楚要燒多少卡）
面試一開口就估算規模，是這題最大的加分點——因為它直接決定架構。
QPS 推導：
- 總請求/日 =
1,000,000 用戶 × 3 對話 × 5 輪 = 1,500 萬請求 - 流量集中在每天約 8 小時 → 平均
15,000,000 / (8 × 3600) ≈ 520 QPS - 線上流量會突發，預留 3 倍 buffer → 系統要扛 ~1,500 QPS
Token 吞吐與卡數（以 H20 為例）：
- 單請求 ≈ 2000 input（含歷史 + RAG）+ 500 output = 2500 tokens
- 每秒總吞吐 =
520 × 2500 ≈ 1.3M tokens/s - 單卡線上實測吞吐 ≈ 4000 tokens/s（受 KV Cache、Prefill 延遲限制，遠低於理論值）
- 均值卡數 =
1.3M / 4000 ≈ 325 張；峰值 ×3 ≈ 1000 張 GPU
成本：1000 張卡全天候 1000 × $3/hr × 24 × 30 ≈ $2.16M/月。靠 Auto-scaling（非高峰縮容）可壓到 $300K–400K/月，省近 80%。
🎤 追問：「為什麼用 8 小時而不是 24？」「單卡 4000 tokens/s 怎麼來的（為何不是理論值）？」「peak buffer 為什麼抓 3 倍？」
二、多模態請求編排（Pipeline）
不同模態要在進大模型前先各自處理，最後組裝成一個完整 Query。
音訊（Audio）
- 輸入用 Batch ASR，不用 Streaming ASR：用 VAD 斷句後，整段音訊一次轉文字。Batch 服務無狀態（stateless）、易橫向擴容、準確率高；Streaming 要維護複雜的長連接狀態。
- 輸出 TTS 串流：不等全部文字生成完，每湊到 10–20 字（依標點）就丟給 TTS 非同步合成，以音訊流回傳。
圖像（Vision）
- Vision Preprocessor：下載、解碼、調整尺寸、切成 patches → 產生 pixel tensor。
Prompt 組裝（Prompt Assembly）
把這些拼成完整 Query：
- System Prompt（角色設定）
- User Profile + RAG 檢索內容
- Chat History（多輪上下文）
- 圖片佔位符
<image_0> - 當前用戶提問
Embedding 注入：原生多模態 vs 級聯
- 級聯（Cascading）：單獨一台機器跑 Vision Encoder（如 CLIP），算完 embedding 再透過網路傳給 LLM 機器。多一跳網路延遲，且兩者沒聯合訓練、對齊差。
- 原生多模態（Native VLM）✅：Encoder 與 Decoder 在同一模型、同一進程，端到端聯合訓練，圖文對齊更好，且 embedding 直接在 GPU 顯存內注入、延遲更低。
🎤 追問：「ASR 為什麼用 batch 不用 streaming？」「TTS 為什麼不等生成完？」「原生多模態比級聯好，那它的代價是什麼？」（→ 帶到第三段）
三、資源爭搶與優化（原生 VLM 的硬核痛點）
原生架構的代價：Encoder 和 Decoder 擠在同一張 GPU。一張圖的計算量可能等同幾百個 token，圖片進來瞬間霸佔 CUDA cores，讓正在串流輸出文字的請求（Decode 階段）卡頓、KV Cache 空間被壓縮、並發下降。三種優化：
| 策略 | 機制 | 優點 | 代價 |
|---|---|---|---|
| Encoder Cache | 快取相同圖片的 embedding，二次命中跳過前向計算 | 大幅降低重複圖計算 | 佔顯存；需配額與淘汰策略，否則被惡意流量污染 |
| Compute Budget | 類似 Chunked Prefill，限制每輪最多處理幾張圖，大請求拆多輪 | 避免大圖請求堵死隊列（head-of-line blocking） | 大請求的 TTFT 變長 |
| Encoder Disaggregation | Encoder 獨立部署，用 NVLink/RDMA 傳 embedding | 徹底解爭搶、可獨立擴容 | 工藝極難、有傳輸延遲；通常處理影片才用 |
🎤 追問：「Encoder Cache 會被惡意流量打爆嗎？」（→ quota + 淘汰策略）「一個帶 5 張圖的請求怎麼不讓它堵住整個 GPU 隊列？」（→ Compute Budget）
四、路由調度與動態擴容
大模型不能用 Round Robin——請求權重差異極大（Prefill 重、Decode 輕），且有 KV Cache 狀態。需要兩層路由：
- 語義層路由（Semantic Router）：前端用極小分類模型/規則判斷意圖。簡單對話 → 小模型（7B/8B）；要深度推理（寫程式、數學）→ thinking model；同時決定是否觸發 RAG。
- 推理引擎層路由（LLM Router）：深入感知後端 vLLM/TensorRT-LLM 叢集狀態——各 Pod 的 KV Cache 剩餘量、Batch Size、隊列深度、是否在跑大 Prefill——精準打分轉發，常用 EPP（Endpoint Predictor） 代理模式。
擴容：用 Kubernetes HPA + 自訂指標（並發數、KV Cache 使用率），或引入專門的 LLM 調度器。要處理 Prefill/Decode 開銷不均、KV Cache 狀態與冷啟動。
🎤 追問：「為什麼不能用 round-robin / 標準 Nginx LB？」「擴容時冷啟動（載模型權重要幾十秒）怎麼辦？」
五、串流輸出與安全審查（Guardrails）
串流（Streaming）輸出時，安全審查用雙軌制：
- 增量輕量檢查：每約 50 個 token 送進一個幾百 M 的快速分類器；一旦發現違規，立即中斷 Stream、前端改顯示罐頭回覆（「抱歉，我無法回答」）。
- 全量深度檢查（非同步）：不擋串流，後台把完整回答丟給大型 Guard 模型（如 Llama-Guard）做全量打分，用於標記、黑名單與告警。
🎤 追問：「串流到一半才發現違規，用戶不是已經看到了嗎？」（→ 增量檢查的截斷窗口 vs 全量的事後審計，兩者互補）
六、4D 監控指標體系
線上維運大模型，要從四個維度監控：
| 層次 | 關鍵指標 |
|---|---|
| 基礎設施層 | GPU/CPU 利用率、顯存水位、KV Cache 使用率、NVLink 頻寬、掉卡率 |
| 應用架構層 | TTFT（首字延遲）、ITL（字間延遲）、端到端延遲、吞吐量、Batch Size、KV Cache 命中率、上下文溢出率 |
| 模型質量層 | 點讚/點踩率、重新生成率、代碼採納率、幻覺率/放棄率、安全濾網觸發次數 |
| 商業業務層 | DAU/MAU、留存率、Token 成本/營收比、免費轉付費率 |
🔑 TTFT（Time To First Token）決定體感「反應快不快」；ITL（Inter-Token Latency）太高用戶會覺得 AI 在「結巴」。這兩個是 LLM serving 最核心的延遲指標。
🎤 追問：「TTFT 和 ITL 差在哪？哪個受 Prefill 影響、哪個受 Decode 影響？」
七、數據飛輪與持續疊代
上線只是開始。建立閉環讓系統越來越好，且不必每次都重訓底層權重：
- 收集：採完整 Trace + 用戶反饋 + 線上指標，對 Bad Case 分類歸因。
- 五大測試集：
- Golden Set：核心基礎能力
- Fix Set：線上剛爆的新問題
- Red Team Set：越獄/對抗安全測試
- Multimodal Set：圖文交織、帶雜音語音等
- Regression Set：歷史修好的 bug,每次改版必測
- 雙軌改進：
- 淺層修復（小時級）：改 Prompt、優化 RAG rerank、調解碼參數
- 深層修復（週級）：挖數據做 Fine-tuning 或 DPO/RLHF
- 評估上線：離線評估（Replay + Scoring）→ 過質量門禁（Quality Gate）→ 線上灰度 A/B → 形成新循環。
🎤 追問：「不重訓模型的前提下，怎麼最快修掉 80% 的線上問題？」（→ 淺層修復:Prompt/RAG/解碼參數）
一張圖記住整套架構
輸入(文字/圖/音) → [預處理: ASR / Vision Preprocessor]
→ [Prompt 組裝 + Embedding 注入(原生 VLM)]
→ [語義路由 → 推理引擎路由(看 KV Cache/隊列)]
→ [GPU 叢集推理: Encoder Cache / Compute Budget 防爭搶]
→ [串流輸出 + 增量安全檢查] → 用戶
↘ [全量安全審計 / Trace 收集] → 數據飛輪 → 持續改進
全程: 4D 監控(基礎設施/應用/質量/業務)
答題口訣
- 先估算：QPS → token 吞吐 → 卡數 → 成本。展現你懂「LLM 是燒 GPU 的」。
- 分模態 pipeline：Batch ASR、串流 TTS、原生 VLM 注入。
- 講資源爭搶：這是原生多模態的關鍵痛點 + 三種解法。
- 兩層路由：語義路由 + KV-Cache-aware 推理路由（不是 round robin）。
- 串流安全雙軌 + 4D 監控 + 數據飛輪收尾。
能把「估算 → pipeline → 爭搶 → 路由 → 安全 → 監控 → 飛輪」這條線講完整，你就答出了一道頂尖大廠等級的 AI 基礎設施題。