长 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 budget<=0: 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] left=budget-len(decode_ids) while prefills and left: request,remaining=prefills.popleft() if remaining<=0: raise ValueError("positive prompt remainder") take=min(left,remaining) chosen.append(("prefill",request,take));left-=take if take<remaining: prefills.appendleft((request,remaining-take)) return chosen q=deque([("long",9)]) a=schedule(["d1","d2"],q,6) assert a==[("decode","d1",1),("decode","d2",1),("prefill","long",4)] assert list(q)==[("long",5)] b=schedule([],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 请求通常贡献本轮需要处理的新 token，prefill 请求贡献本轮选中的 prompt token；不能在一个字段里混用请求数与 token 数。多模态输入还可能引入不同的展开或计算成本，简单 token 预算不应被当成完备成本模型。调度器可以逐步增加更准确的估计，但每次增加规则，都应保留预算不超限、请求不重复调度和取消后不再提交等基本检查。明确这些不变量，才能让性能参数调整具有稳定边界。
调度记录应同时保存请求身份与有效 token 数，才能复查一次请求是否被遗漏、重复或过早移出队列。
2026 年 10 月的 SGLang TPU 后端说明还介绍了按形状 bucket 缓存编译程序。预算、padding 与编译形状会相互影响，不能只把 chunk 大小调得越小越好。本文没有测 GPU、TPU 或服务延迟，输出只证明示例中的预算守恒。
