一句话定义
分块预填充（Chunked Prefill）是一种大模型推理调度技术：把一条超长输入（prompt）的预填充计算切成若干小块，分多个推理步逐步完成，每一步都和其他请求的解码（decode）步骤拼成同一个批次一起计算。
为什么需要它
大模型推理分两个阶段。第一阶段叫预填充（prefill）：把用户输入的整段 prompt 一次性读进去，算出每个 token 的注意力键值缓存（KV cache），这是算力密集型的活，并行度很高。第二阶段叫解码（decode）：拿着缓存一个一个往外蹦字，每一步只算一个 token，瓶颈在显存带宽而不是算力，GPU 的计算单元其实相当闲。
问题就出在长 prompt 上。如果一条 prompt 有几万 token，预填充这一步会长时间霸占显卡，期间其他正在解码的请求只能干等——用户看到的现象就是"别人发了个长文档，我的回复突然卡住了"。反过来，如果为了不被阻塞而把长短请求分开跑，显卡的解码阶段又因为算力闲置而浪费。
分块预填充的思路是：别一口吃成胖子。把长 prompt 切成固定大小的块，这一步算一块，下一步再算一块，每步都能顺带捎上其他请求的解码任务。整条流水线不再出现"某一步特别长"的尖峰。
打个比方
超市只有一个收银台。前面的人买了 500 件商品，如果一次性扫完，后面每个人都得干等五分钟；改成每扫 50 件就轮到下一位扫几件，所有人都能稳定地往前走，队伍整体的通过速度反而更快。商品一件没少（不丢上下文），只是节奏换了。
和相邻概念的区别
| 概念 | 解决的问题 | 与分块预填充的关系 |
|---|---|---|
| 预填充 / 解码 | 推理的两个天然阶段 | 分块预填充只是在预填充内部再切分 |
| AI 词典：连续批处理">连续批处理（Continuous Batching） | 请求级别调度，随时把新请求塞进批次 | 是上层调度框架，分块预填充是它的具体策略之一 |
| KV 缓存分页（PagedAttention 等） | 显存碎片与利用率 | 正交的显存管理问题，常配合使用 |
| 投机解码（Speculative Decoding） | 加速解码阶段 | 优化的是另一半流程 |
| 截断 prompt | 减少输入长度 | 会丢信息，分块预填充不丢 |
要付的代价
块切得越小，调度越平滑，但每步的有效计算量变少，预填充本身的高并行优势被摊薄，内核启动和缓存管理的固定开销占比上升；块切得太大，又退回原来的阻塞问题。所以实际部署里块大小是个需要根据流量特征调的参数，主流推理框架一般都有对应配置项，默认值和取值范围以官方文档为准。
对你的意义
对做工程的：长上下文场景（RAG 拼接文档、代码仓库问答、多轮长对话）下，首 token 延迟（TTFT）和 token 间延迟（ITL）的尾部指标往往比平均值更影响体验，分块预填充是压这两个尾部毛刺的常用手段。
对普通用户：你在用的聊天产品如果同时服务很多人，别人灌进去一份几万字的合同，不会再把你的回复卡成幻灯片——这就是它在后台干的事。