什么是预填充？首字延迟从哪来，新手版入门

大模型开口回答之前，有一段不出声的准备期，这段准备在技术上叫预填充。你按下发送后盯着空白屏幕等的那一两秒，主要就花在它身上：模型在把你的问题从头到尾读一遍，把每个字都消化成自己能处理的内部表示，读完了，才开始蹦第一个字。理解预填充，就理解了首字延迟从哪来。

预填充阶段在忙什么

可以把一次回答拆成两大段：先是读，后是写。预填充负责的是“读”——你发出去的整段文字，连同系统附带的指令，一次性进入模型。它的任务是把这些文字转换成内部的向量表示，相当于给每个字建立一份上下文档案，后面生成答案时随时调用。

这个阶段有个明显特点：读得越多，耗时越长。你问一句“你好”，预填充几乎瞬间完成；你贴上一篇三千字的文档让它总结，预填充就要实打实读上一阵。这也是为什么长文档场景下首字等待更久，慢的不是模型打字，是它看书。

这段准备期到底做什么、不做什么，逐条拆开。

像厨子看完整张订单再开火

理解预填充，可以类比厨师接单后的备料。客人点了一桌子菜，厨师先把订单从头看到尾，知道有哪些菜、什么口味、哪几道可以同炉，心里有数了才开火。模型也是这样：先把你的整段输入“看”完，建立整体理解，再决定第一句话说什么。

这个类比还解释了一个现象：为什么你补充背景信息后，模型答得更准。就像厨师提前知道有人忌口，做出来的菜才对得上胃口。预填充读到的信息越全，答案的针对性越强，那些看似多余的背景，其实都在这个阶段被消化。

类比在哪里对不上

备料类比有两处会失效。其一，厨师看订单是从头到尾顺序读，模型的预填充却是一次性处理整段输入，不存在“先读前半句再读后半句”的时间差。其二，厨师看完就忘了订单原文，靠的是理解；模型会把每个字的原始信息都以某种形式留在上下文里，后面写答案时可以反复回看。

还有一处容易混淆：预填充不是“想答案”。它只做阅读理解，不做创作。答案的第一个字，要等预填充收尾、进入逐字生成阶段才出现，这两个阶段的分工，可以顺着解码阶段的逐字生成继续了解。

首字等待慢时先看什么

日常使用中，等首字等得心慌，先排查两件事：输入是不是特别长，是不是一次贴了太多材料。如果两者都排除，再看首字时间 TTFT这个指标在不同产品上的表现差异。DeepSeek 和豆包在长输入场景下的首字速度都被用户讨论得比较多，选型时可以拿同一段长文本横向试。还有一个细节：预填充的耗时和你用什么产品也有关，不同服务端的推理框架、硬件配置不同，同一段输入的通读速度能差出两三倍，这也是横向对比时值得亲自试的原因。

带走一个判断：预填充是“先读后写”里读的那一半，首字延迟高，多半是读的负担重，而不是模型打字慢。想少等，就精简输入；想答得准，就值得等。这个权衡，用每秒 token 数衡量后半段的写字速度更合适。

速查表：预填充=完整读一遍输入再生成；耗时随输入长度增长；类比厨师看完整张订单备料；失效在模型一次性读取且保留原文；首字慢先查输入长度。

关于预填充的三个常问问题

• 预填充和打字速度是一回事吗？不是，前者是开口前的通读，后者是开口后的逐字输出，两段分开计量。
• 为什么长文档的首字等更久？因为要读的文字量更大，这段通读的耗时随输入长度明显增长。
• 提示词写得长会拖慢首字吗？会，提示词同样要过预填充，但交代清楚背景换来的准确度通常值这个等待。