AI Engineer onepage/ LLM inference at scale
Harshul Jain, Audible · Tanmay Sah · 1:28:12
這支影片在講：LLM 推論要擴大，先管理會持續長大的 KV cache
這是一堂從 attention、GPU 記憶體與流量型態出發的推論工作坊。它把「為何 prompt 一長、併發一高就壞掉」拆成可計算的容量問題，再對應到模型與 serving 兩條優化路徑。
Published: 2026-09-08AI Engineer約 4,703 views（feed）
01 / 問題
GPU 不是只放模型
模型 weights 是固定成本；KV cache 會隨 context 與同時在跑的 request 增長，兩者共同決定卡能承受多少流量。
02 / 反轉
Prefill 與 decode 不同
長 prompt 會拉長 time-to-first-token；生成階段則更偏 memory-bound。把兩者混成一個 latency 問題，會做錯優化。
03 / 解法
模型與 serving 一起調
量化與 attention 變體降低每 token 成本；paged attention、continuous batching、prefix cache 則提高可服務的有效併發。
Capacity signals
先用四個訊號判斷瓶頸在哪裡
KV cache
131 KB
Mistral 7B 的單一 token KV cache 成本；看似小，會隨 context 與併發相乘。
Example load
42 GB
16,000 token × 80 位使用者時，光 cache 就需要約 42 GB；24 GB GPU 會先撞牆。
Serving split
2 phases
Prefill 重算力與首 token；decode 更受記憶體頻寬限制，排程不能一體適用。
Agentic branch
3–4×
講者實測：一般工作負載 vLLM 與 SGLang 差異不顯著，但 agent 分支下可拉開 3–4 倍。
Core story
推論會失速的三個根因
01
只看 weights，忽略會成長的狀態
容量規劃若只問「模型能不能塞進 GPU」，就漏掉 KV cache。context 變長、同時 request 變多時，cache 是最先膨脹並造成 OOM 的部分。
02
把首 token 延遲與生成吞吐混為一談
Prefill 要讀完整 prompt 並建立 cache；decode 每次只產一個 token，卻反覆讀取大量 state。兩個階段的資源輪廓與排程策略不同。
03
讓 request 逐一排隊
naive server 一個 request 做完才處理下一個，GPU 會閒置、尾延遲惡化。要以可用 cache page 與 token step 為單位，持續把工作填進去。
Decision map
優化不是清單，而是兩條互補路徑
模型端：先減少每個 token 的負擔量化降低 weights／cache 壓力；multi-query、grouped-query、latent attention 降低 KV 量；FlashAttention 與 tiling 改善 attention 的資料搬運。
Serving 端：把零碎資源變成可排程容量Paged attention 借鏡 OS paging 管理 KV block；continuous batching 不等一批 request 同步完成；prefix caching 重用共同 prompt。
容量端：以工作負載決定 GPU先帶入模型、context 長度、併發數與 latency target，建立 capacity calculator。不要用「模型參數量」單獨選卡。
引擎端：用你的 request shape 做 benchmark講者在標準負載下看不到 vLLM 與 SGLang 的統計顯著差異；agent branching 則可能改寫結果。benchmark 要保留真實分支與 prefix 重用。
Practical checklist
要把 LLM inference 帶進 production，先問這五題
你的 P50／P99 context 與同時活躍 request 是多少？以 token×併發估 KV cache，而不是只記模型的 VRAM footprint。
TTFT 與 token/s 是否分開量？將 prefill、decode、queueing 拆開，才知道是 prompt 太長、memory bandwidth，還是排程造成尾延遲。
共同 system prompt 或 RAG prefix 有沒有被重用？有高重複前綴時，prefix caching 往往是比單純加卡更直接的成本槓桿。
你的 batch 是否隨 token step 持續補入？若仍採 request-by-request 或 rigid batch，先評估 continuous batching 與 paged KV 管理。
引擎 benchmark 是否包含 agent 分支？把工具呼叫、分支、取消與長短 prompt 混合進測試；只有這樣的測試才能支持 production engine 決策。
Source video
原影片與延伸來源
AI Engineer：Deep dive on LLM Inference at Scale（影片、章節與數字來源）
Harshul Jain · Tanmay Sah（講者資料）