https://yennj12.js.org/yennj12_blog_V4/tags/chunked-prefill/Recent content in Chunked Prefill on YennJ12 Engineering BlogHugo -- gohugo.ioen-usFri, 11 Sep 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/vllm-intro-part3-scheduler-continuous-batching-zh/Fri, 11 Sep 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/vllm-intro-part3-scheduler-continuous-batching-zh/大多數人調 LLM 推論效能的方式，是把 batch size 調大，看到吞吐上升就停手。 真正的答案是：在連續批次的世界裡「batch size」根本不是一個固定值——它是排程器每一輪重新決定的結果，而排程器真正在分配的不是「幾個請求」，是「這一輪的 token 預算怎麼切」。 看不懂那份預算表，你調的每一個參數都是在賭。 前言 Part 2 把 KV 記憶體管好了：分頁、共享、快取、量化。但記憶體只是配額。 這一篇處理的是分配：每一次 GPU forward 之前，有一個元件要回答「這一輪跑哪些請求、每個請求推進幾個 token」。它叫 Scheduler，住在 vllm/v1/core/sched/scheduler.py，是整個 vLLM 裡最短但最關鍵的一段程式碼——你所有的延遲數字都是它的輸出。 本篇的目標：讀完之後，你看到 P99 ITL 抖動能立刻猜出是哪個參數的問題，看到 GPU 利用率低能說出是 CPU bound 還是 batch 湊不起來，並且知道投機解碼在你的負載下是賺還是賠。 一、核心問題：靜態批次的氣泡 先看清楚被連續批次取代的東西。 1.1 靜態批次為什麼浪費 靜態批次（static batching）：湊滿 4 個請求一起跑，跑完整批才換下一批 時間 → t0 t1 t2 t3 t4 t5 t6 t7 t8 ┌─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┐ req A │ P │ D │ D │ END │░░░░░│░░░░░│░░░░░│░░░░░│░░░░░│ 3 個 token req B │ P │ D │ D │ D │ D │ D │ D │ D │ END │ 8 個 token req C │ P │ D │ END │░░░░░│░░░░░│░░░░░│░░░░░│░░░░░│░░░░░│ 2 個 token req D │ P │ D │ D │ D │ END │░░░░░│░░░░░│░░░░░│░░░░░│ 4 個 token └─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┘ ↑ ░░░ = 氣泡：GPU 在算 padding，純浪費 req E 在門外排隊，但要等 t8 之後才能進來 有效算力 = 17 / (4×9) = 47% 兩個獨立的損失：