Prefill

一句话解释

Prefill 一次处理输入提示词，计算首个输出 token 所需状态并填充 KV Cache。

对比

• 相比 Decode，Prefill 通常具有更高的并行度。
• 与 Decode 的资源特征不同，因此出现 Prefill-Decode Disaggregation。

一次 prefill 的数据流

prompt [B,T]
→ embedding / position
→ 多位置 Q/K/V 与 causal attention
→ 写入每层 KV Cache [B,Hkv,T,Dh]
→ 最后位置 logits
→ 首 token / 进入 decode

prefill 的 Tq 较大，矩阵乘法并行度高，通常受 compute、临时显存和长 prompt 处理时间影响；Decode 每轮 Tq=1，更常受权重/KV 搬运和调度影响。短 prompt 大输出和长 prompt 短输出因此会呈现不同瓶颈。

调度冲突与验证

一次吞入很长的 prefill 可以提高 GPU 利用率，却会占住执行窗口，让正在 decode 的请求 TPOT 尾延迟上升；如果调度器永远优先 decode，新 prompt 又会排队，TTFT 恶化。chunked prefill 把长输入拆成片段，提供折衷旋钮，但增加了状态管理和调度边界。

TTFT 应拆成排队、tokenize、prefill kernel、首 token 采样四段；同时记录输入长度分布、padding/packing 浪费、GPU 利用率和 KV 峰值。它向上连接 Autoregressive Generation，向下依赖 Tensor Shape、Causal Mask 和 KV Cache。

长 prompt 为什么不只增加线性时间

prefill 中每个输入位置都参与 Q/K/V 和 causal attention，临时 activation、attention workspace 与 KV 写入也随输入长度增长；不同实现可能用 padding、packing、FlashAttention 或 chunked prefill，因而同样的 token 数会产生不同的 kernel shape 和显存峰值。若 batch 内混入极长 prompt，短 prompt 可能等待同一轮完成，TTFT P99 就会被长度尾部主导。

chunked prefill 将长输入切成多个片段，让 scheduler 在片段边界插入 decode 请求。chunk 太大，decode 仍会被阻塞；太小，kernel 利用率下降且需要维护中间状态。验证时按 prompt 长度分桶，记录每个 chunk 的 token 数、插入次数、decode 被打断时间、KV 增长和最终 TTFT/TPOT，而不是只看平均 prefill throughput。

prefix cache 命中可以减少需要重新执行的前缀，但未命中的后缀仍然需要 prefill，且命中缓存的管理/复制成本可能在短 prompt 上占比很高。因而“启用 prefix cache 后 TTFT 变快”必须同时报告命中 token 数、命中率、跨副本路由和 cold/warm cache 条件。