长 prompt 会占用一次较大的 prefill 工作交互请求的 decode 则更在意连续输出间隔。Chunked Prefill 的目标是把长 prefill 分成可调度的小块与 decode 共享批次预算。它没有允许不同 query 沿用同一个 Softmax 归一化状态。vLLM 的优化文档说明 V1 在可用时启用 chunked prefill并优先安排 decode剩余 token 预算再填 prefill。预算大小影响 TTFT、ITL 与吞吐具体折中仍需按工作负载测量。decode 优先使用预算长 prefill 通过后续批次逐段继续。from collections import deque def schedule(decode_ids,prefills,budget): if budget0: raise ValueError(positive budget required) if len(decode_ids)budget: raise ValueError(toy policy requires decodes to fit) chosen[(decode,x,1) for x in decode_ids] leftbudget-len(decode_ids) while prefills and left: request,remainingprefills.popleft() if remaining0: raise ValueError(positive prompt remainder) takemin(left,remaining) chosen.append((prefill,request,take));left-take if takeremaining: prefills.appendleft((request,remaining-take)) return chosen qdeque([(long,9)]) aschedule([d1,d2],q,6) assert a[(decode,d1,1),(decode,d2,1),(prefill,long,4)] assert list(q)[(long,5)] bschedule([],q,6) assert b[(prefill,long,5)] and not q print(token-budget accounting and prompt continuation passed)这段调度模型只扣 token 预算没做 Attention也未建模设备耗时。它把 decode 必须先全部装下作为简化前提真实系统还要处理 decode 过载、公平性与准入不能让等待 prompt 永远饥饿。一个 query 的 KV 分块和多 query 分块不是一回事在线 Softmax 可以合并同一 query 面对不同 KV 块的统计量。下一个 query 的分数变了最大值与分母也要重新计算。把上一个 query 的状态带过去得到的已经不是标准 Attention。切分 prefill 时因果位置、前序 KV 可见性和块边界都要保留。缓存分配可能在块间增长取消请求还需清理尚未执行的部分。调度计数正确只是第一步。预算守恒之外还有请求进展示例先安排两个 decode再从长 prompt 取四个 token因此剩余 prompt 从九变成五。下一轮没有 decode 时五个 token 全部进入 prefill。这个过程检查的是已经调度量与剩余量相加仍等于原始需求不涉及设备一轮能多快完成。若把 token 数直接乘一个固定耗时便额外引入了未经测量的性能模型。真实调度器还要检查每个请求是否在前进。持续有 decode 到来时prefill 可能一直得不到预算持续有长 prompt 时已有 decode 的输出间隔又可能变差。可以采用准入、等待时间或其他公平性策略但需要明确目标并在负载变化时检查不存在一个适用于所有服务的固定预算。请求取消会影响队列里的剩余量。某个 prefill 已被切出但尚未提交时取消可以直接移除已经提交后则需要等待实际完成或按设备能力处理。不能把剩余计数清零就假定相应 KV 与工作区已经空闲。调度状态和执行完成是两份不同信息。形状 bucket 又会引入额外工作。一个批次的有效 token 数与实际填充后的执行形状未必相等调度日志最好同时记录这两者便于解释小批次为什么没有按预期降低成本。调预算之前先观察真实分布通常比凭一个平均 prompt 长度选择参数更可靠。预算单位必须统一。decode 请求通常贡献本轮需要处理的新 tokenprefill 请求贡献本轮选中的 prompt token不能在一个字段里混用请求数与 token 数。多模态输入还可能引入不同的展开或计算成本简单 token 预算不应被当成完备成本模型。调度器可以逐步增加更准确的估计但每次增加规则都应保留预算不超限、请求不重复调度和取消后不再提交等基本检查。明确这些不变量才能让性能参数调整具有稳定边界。调度记录应同时保存请求身份与有效 token 数才能复查一次请求是否被遗漏、重复或过早移出队列。2026 年 10 月的 SGLang TPU 后端说明还介绍了按形状 bucket 缓存编译程序。预算、padding 与编译形状会相互影响不能只把 chunk 大小调得越小越好。本文没有测 GPU、TPU 或服务延迟输出只证明示例中的预算守恒。
