Continuous Batching

上一章我们把单个请求的 decode 优化到了极致：KV cache 让每一步只算新 token。但线上服务从来不是一个请求，而是几十上百个请求同时进来，长度各不相同，随时开始随时结束。

这一章要回答的是：既然单请求已经喂不饱 GPU，把多个请求凑在一起算就好了，为什么真实系统还要为此专门设计一套调度机制？我们会看到朴素的批处理会浪费掉一半以上的算力，然后一步步引入 continuous batching、selective batching 和 chunked prefill，最后落到一个更根本的问题：吞吐和延迟不能同时最大化，到底该优化哪个。

一个请求喂不饱 GPU

多个请求一起算，听上去就是"把它们塞进同一个 batch"这么简单。但要理解后面为什么需要一整套调度机制，得先弄清楚：批处理到底省下了什么？

回到 decode 的一步。模型要为 1 个 token 做一次前向，为此它必须把整份模型权重从显存读进计算单元。这里的不对称非常极端：读的是整个模型，产出的是一个词。

打个比方，这就像开一辆大卡车去送一件快递。油钱（读权重）几乎全花在"把车开出去"上，和你车上装了 1 件还是 32 件货关系不大。既然如此，多装几件就是纯赚。这就是批处理的全部动机：把 32 个请求凑成一批，权重仍然只读一遍，却能同时产出 32 个 token。