https://yennj12.js.org/yennj12_blog_V4/tags/inference/Recent content in Inference on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSun, 21 Jun 2026 19:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-16-ttft-throughput-optimization-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-16-ttft-throughput-optimization-zh/核心定義：LLM 推理服務存在兩個永遠相互拉扯的指標——TTFT（首字延遲，決定用戶感知流暢度）與 Throughput（每秒 Token 數，決定 GPU 成本與容量）；所有推理優化技術本質上都是在這兩者之間移動作業點。 一、為什麼面試官問這個 面試官問 TTFT / Throughput 優化，真正測試的是三件事： 你是否理解 LLM 推理的計算瓶頸 — Prefill 受限於 FLOPS（矩陣乘法），Decode 受限於 Memory Bandwidth（KV Cache 讀取）。能分清楚這兩個瓶頸才是起點。 你是否能從業務 SLA 倒推系統設計 — 互動式聊天 TTFT < 500ms 優先；批次摘要任務 Throughput 最大化優先。混淆兩者設計方向是初階錯誤。 你是否知道業界標準工具 — vLLM、TGI、GPTQ、AWQ、Flash Attention 不是加分項，是基本盤。沒提過這些工具，面試官會直接降級評分。 弱答案長什麼樣：「可以用更快的 GPU」、「換成更小的模型」——這種回答顯示你沒有系統化思考，只是在說廢話。 強答案長什麼樣： 先拆解 Prefill vs Decode 的不同瓶頸，再針對每個瓶頸選對應工具，最後說明在給定 SLA 下如何調整 Batch Size 在 TTFT 與 Throughput 間取得平衡，並給出具體數字。 二、核心原理與技術深度 2.1 Prefill vs Decode：兩個截然不同的計算瓶頸 LLM 推理分為兩個階段，具有完全不同的計算特性： ┌──────────────────────────────────────────────────────────────────┐ │ PREFILL 階段（Compute-Bound，計算密集） │ │ │ │ 輸入 Prompt：N 個 Token │ │ ┌────────────────────────────────────────────────────────────┐ │ │ │ 步驟 1：Q, K, V 投影 │ │ │ │ N × d_model → 三個 N × d_head 矩陣 │ │ │ │ 步驟 2：Attention Score 計算 │ │ │ │ Score = QK^T / sqrt(d_k) ← NxN 矩陣乘法 │ │ │ │ FLOPS = O(N² × d_model) │ │ │ │ 步驟 3：Softmax + 加權 V │ │ │ │ 所有 N 個 Token 並行處理 → GPU 利用率高 │ │ │ └────────────────────────────────────────────────────────────┘ │ │ │ │ 瓶頸：FLOPS（輸入越長，計算量平方增長） │ │ 輸出：第一個 Output Token ← 這就是 TTFT 的終點 │ └──────────────────────────────────────────────────────────────────┘ ┌──────────────────────────────────────────────────────────────────┐ │ DECODE 階段（Memory-Bound，記憶體頻寬密集） │ │ │ │ 每一步只生成 1 個新 Token（Auto-regressive） │ │ ┌────────────────────────────────────────────────────────────┐ │ │ │ 步驟 1：從 KV Cache 讀取所有歷史 K, V │ │ │ │ HBM → SRAM（記憶體頻寬瓶頸在此） │ │ │ │ 步驟 2：計算新 Token 對所有歷史 Token 的 Attention │ │ │ │ FLOPS 極低（只有 1 × N 而非 N × N） │ │ │ │ 步驟 3：寫回新 K, V 到 KV Cache │ │ │ └────────────────────────────────────────────────────────────┘ │ │ │ │ 瓶頸：Memory Bandwidth（每步都要讀寫整個 KV Cache） │ │ 公式：Tokens/sec ≈ HBM Bandwidth / KV Cache Size per Token │ └──────────────────────────────────────────────────────────────────┘ 具體數字（LLaMA-2 70B，A100 80GB SXM）：https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase11-part1-inference-serving-zh/Sun, 21 Jun 2026 19:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase11-part1-inference-serving-zh/大多數人把 LLM 推論想成「載入模型，呼叫 generate()，等結果」。 實際上，每個 token 都在搶 GPU HBM 頻寬，記憶體碎片化讓吞吐量砍半， 一個設計不良的 batch 策略讓 A100 的使用率停在 12%。 真正的推論工程是記憶體管理、排程策略、精度取捨三件事同時做對。 面試情境：「你的團隊剛把一個 70B 參數的對話模型從研究環境搬到生產，目前 p99 延遲 18 秒、GPU 使用率 15%、每千 token 成本 $0.04。CTO 要求三個月內把成本降到 $0.008、p99 降到 4 秒。你的架構計畫是什麼？」 一、核心問題：LLM 推論為什麼貴又慢 LLM 推論和傳統深度學習推論有本質上的差異。ResNet 做影像分類，輸入固定大小，一次 forward pass，批次容易排。LLM 是自回歸生成（autoregressive generation）：每個 token 依賴前面所有 token，必須一步一步產生。 三個根本瓶頸： 瓶頸一：記憶體頻寬牆（Memory Bandwidth Wall） 70B 模型 FP16 佔 140 GB。A100-80GB 只能塞下半個模型，必須 tensor parallel。每生成一個 token，模型的所有 140 GB 權重都要從 HBM 讀一次。A100 HBM 頻寬 2 TB/s，讀 140 GB 需要 70 ms——這就是單 token 延遲的硬下限，和計算無關。