推理服务上线后最常见的矛盾，是吞吐与延迟总要牺牲一个。静态批处理等一批请求凑齐再一起算，吞吐上去了，单个请求的等待时间却被拖长。连续批处理的做法是打破这种整齐划一的节奏：正在解码的序列不必等同一批的同伴结束，某个序列一完成，调度器立刻把新请求补进空位，让算力始终处于饱和状态。

理解这套机制要先区分两个阶段。预填充阶段把提示词一次性算完，计算密集，适合大批量并行；解码阶段每次只产一个词元，访存密集，批量越大边际收益越小。好的调度器会把两者拆开排队：预填充用分块方式插进解码间隙，既不让新请求久等，也不让正在输出的请求被大块计算饿死。分块大小就是第一个可调旋钮，块越大首词延迟越低，解码的每词延迟波动也越大。

第二个旋钮是单批词元上限与并发上限。词元上限决定了一步计算的规模，直接影响显存占用和延迟；并发上限则受键值缓存容量制约。缓存满了怎么办，是直接拒绝还是排队等待，这决定了服务在高峰时的表现形态。排队会推高尾延迟，拒绝则把压力推给客户端重试，两种策略要在容量规划时就定好，而不是等到线上报警才临时改。

分级服务是更进一步的权衡手段。对延迟敏感的交互请求走高优先级队列，批量离线任务走低优先级，利用空闲算力填充。优先级不能是摆设，需要配合抢占与恢复机制：低优先级任务被抢占后，其中间状态要能保留或快速重算，否则一次抢占造成的浪费可能抵消全部收益。

落地时建议盯住四组指标：每秒词元数、首词延迟、每词延迟以及排队时长分布。只看平均值会掩盖问题，尾延迟的分布才是用户真实体感。压测要模拟真实流量混合比例，纯长文本与纯短对话的压测结论往往互相误导。调度策略没有银弹，关键是让每个旋钮的代价都可观测，再按业务的延迟预算反推参数。