交互工具 · 对比

批处理调度对照

同一张卡，Ollama 排队、vLLM 高一个量级——差的不只是显存管理，更是发车方式。左边班车：凑满 8 个才发车，最长的没生成完谁都别想下车；右边地铁：每生成一步就有人到站下车、有人上车补位。同一串请求喂给两种引擎，看延迟和吞吐怎么被「发车规则」拉开，再把节奏拧到悠闲看红利消失。

纯前端确定性离散事件模拟：同种子（seed=42）生成同一串请求（48 个；短档 4–12 / 长档 24–96 token 的混合长度与指数到达节奏为演示口径，页面明示），班车「凑满 B 发车 + 末班车」、地铁「步边界下车 → 补位」均为真实调度推演；文章口径「vLLM 吞吐 2～4 倍」用作量级校验锚（默认口径 2.1~2.5× 落带内，长度分布不同倍率不同）。零 API、零延迟、同种子完全可复现。

同一张卡伺候一串请求，发车规则决定吞吐与延迟：老式引擎像班车——凑满一整车才走、整批陪到最晚的落地； vLLM 像地铁——随到随上、到站即下。同一串请求（同种子，48 个）喂给两种引擎，看差距怎么被拉开。

seed=42 · 可复现

批大小 B（凑满几人发车）8B 越大拼车越省、但先完成者陪得越久——两头都是账长短混跑（长请求占比）40%长度越参差，整批 max 与均值差越远，班车亏得越狠（短档 4–12 / 长档 24–96）

静态批处理 · 班车

总耗时 509 步 · 6 班车

#10

#11

#12

#13

#14

#15

#16

#17

#18

#19

#20

#21

#22

#23

#24

#25

#26

#27

#28

#29

#30

#31

#32

#33

#34

#35

#36

#37

#38

#39

#40

#41

#42

#43

#44

#45

#46

#47

#48

等待发车生成中陪跑（已完成占车）

连续批处理 · 地铁

总耗时 215 步 · 无车可等

#10

#11

#12

#13

#14

#15

#16

#17

#18

#19

#20

#21

#22

#23

#24

#25

#26

#27

#28

#29

#30

#31

#32

#33

#34

#35

#36

#37

#38

#39

#40

#41

#42

#43

#44

#45

#46

#47

#48

等待发车生成中

班车（静态）

总耗时

509 步

吞吐 9.4 个/百步

平均总延迟

282.4

其中等待 198.3

陪跑浪费

2780

token·步 · 已完成占车

发车空窗

4 步

GPU 无活干

地铁（连续）

总耗时

215 步

吞吐 22.3 个/百步

平均总延迟

76.5

其中等待 50.3

陪跑浪费

到站即下 · 无占车

发车空窗

1 步

仅整条流真空时

2.37×连续 / 静态吞吐比文章口径：PagedAttention + 连续批处理吞吐 2~4 倍（本页只演发车规则一项，倍率随长度分布落带）

到达间隔约 0.7 步/个，队列排起来：静态班车凑满 8 个才发车，先完成的请求陪着整车跑到最晚的落地（琥珀段共 2780 token·步），批与批之间还有发车空窗；连续地铁随到随上、到站即下，一个 token 步的边界就完成一次换员。同一串请求，总耗时 509 → 215 步（2.37×，落在文章「吞吐 2~4 倍」口径带内），平均延迟 282.4 → 76.5 步。

和其他工具是什么关系

「显存碎片与分页」工具演的是装得下（PagedAttention 把 48.7% 的碎片压到 0.7%）；本页演的是跑得开（连续批处理把 GPU 的空转缝隙填上）——vLLM 的两件核心装备，各演一半。

「量化显存与并发账」算的是静态容量上限（一张卡扛几路）；本页解释为什么同样的显存，调度规则能让实际并发差一个量级。

请求长度两档混合（短 4–12 / 长 24–96）与到达节奏为演示口径（页面明示）；发车规则本身是真实调度推演：班车凑满 B 发车 + 末班车规则，地铁每个 token 步边界先下车再补位。零 API、同种子完全可复现。