大模型推理的预填充，指的是把一次输入的全部内容一次性处理完，算出每个位置对应的中间状态。可以把它理解为模型读题的阶段：读得完不完、快不快，直接决定用户要等多久才看到第一个字，也决定了后续生成的起点质量。
进来什么：一次输入的全部 token
预填充的输入是一整段上下文，可能是一个孤立的问题，也可能是问题加参考资料、加历史对话。这些内容被切分成 token 序列，一次性交给模型，不做任何分批。
这里的关键词是一次性。输入阶段的处理不依赖输出，整段文本可以同时进入计算，这为后面的并行打下了基础，也是它与生成阶段性格不同的根本原因。
长上下文场景里，预填充的耗时最容易被低估。贴一份几万字的文档提问，等待的大头在读题；同一个会话接着追问一句，因为上一轮的键值对还在缓存里，只需处理新增的一句话，等待立刻短下来。理解这一点，就能解释长文档首问慢、追问快的常见现象。
| 输入形态 | 预填充要读多少 | 首字等待 |
|---|---|---|
| 孤立短问题 | 一句话的 token | 短 |
| 长文档首问 | 几万字全文一次读完 | 等待的大头在读题 |
| 同会话追问 | 只处理新增的那一句话 | 明显短下来 |
发生什么：并行算出每个位置的中间表示
模型对输入序列做一次前向计算，为每个位置算出它该记住的中间表示，也就是注意力机制里要用的键值对。这些中间表示随后会被存起来，供生成阶段反复使用，不必再算。
由于输入之间没有依赖，这一步可以充分利用算力并行做，显卡吃得满。输入越长，这一步的计算量越大，这是长上下文首次等待偏长的根本原因，省不掉只能优化。优化方向也围绕输入展开：输入能精简就精简，重复资料做去重，系统提示词里去掉与本次无关的长段内容，读题量小了，等待自然短。
出去什么：一份可续的 KV 缓存
预填充的产出是每个位置的键值对，统一存进 KV 缓存。到了生成阶段，模型每写一个新字，都从这份缓存里取历史信息，不必把输入重读一遍，速度因此有了保障。
换句话说，预填充把读题的成果固化下来，让后面的逐字生成站在一个已经理解全文的起点上。这份缓存的质量，直接决定了生成阶段能不能用好上下文。所以评估一次调用的开销，要把读题和写答案分开看：读题按输入长度收费、耗时与输出无关，写答案逐字推进、时长随输出增长，两头混在一起算就容易误判。
与解码的差别：一次并行与逐字串行
预填充与解码是推理的两个阶段，性格完全相反。前者一次处理一整段，算力吃得满；后者一次只算一个位置，算力常常用不满。两者的耗时此消彼长，共同构成用户感知到的响应时间。两个阶段的耗时占比随场景变化，短问题读题占大头，长输出写答案占大头，优化前先弄清自己的场景偏哪一头。
在 DeepSeek、通义千问等模型的推理服务里，这两个阶段都是性能优化的重点对象。想了解生成阶段怎么走，可以读解码的循环、KV 缓存的复用和首字加速。
速查表：
- 进来什么？一次输入的全部 token
- 发生什么？并行算出每个位置的中间表示
- 出去什么？一份供生成阶段复用的 KV 缓存
- 耗时随什么涨？输入长度，与输出长度基本无关
换个问法再问预填充三句
- 为什么长文档的首次等待特别久？：输入长，预填充的计算量大，这一步省不掉，只能靠缓存、分片等工程手段优化。
- 预填充能跳过吗？：不能，它是生成的前提，但缓存命中时可以直接复用历史输入的处理成果，相当于变相跳过。
- 预填充的耗时和输出长度有关吗？：基本无关，它只由输入决定，输出长度影响的是后面的解码阶段，两段要分开评估。
