什么是首字时间？TTFT 这个指标

向大模型提问后，从按下发送到屏幕出现第一个字，中间隔着的时间叫首字时间，圈内人常用 TTFT 这个缩写称呼它。这个指标衡量的是 AI 产品“反应快不快”的第一印象：字还没开始蹦，用户已经在心里打了第一分。首字时间的构成不复杂，主要是预填充通读输入的那段时间，加上调度和网络传输的零头。

第一个字出现前发生了什么

拆开看，首字时间花在三个地方。最大头是预填充：模型要把你发出去的整段输入通读一遍，输入越长这段越久。其次是排队，请求到达服务端后不一定立刻被处理，高峰期要在队列里等一等。最后是零头，包括网络往返和把第一个字送到你屏幕上的时间。

这也解释了一个常见困惑：为什么同样的问题，有时秒回，有时要转圈。问题本身没变，但服务端的负载变了，排队时长跟着变，首字时间就出现了波动。把它理解成“答题前的准备时长”，比单纯当成网速问题更准确。顺带一提，服务端往往还会做缓存复用，结构相似的热门请求可能命中已有结果，首字几乎瞬间弹出；完全没见过的长输入，才最能看出一个产品的真实通读速度。这也是为什么测速度要用自己业务里的真实文本，别用“你好”之类的短句自我安慰。

像在餐厅等第一道菜

理解首字时间，可以类比在餐厅等第一道菜上桌。落座点单后，厨房要看完所有单子、备料、开火，这段时间客人面前是空的。第一道菜上桌，意味着厨房真正消化完了订单，后面出菜就顺理成章。首字时间就是 AI 的“第一道菜”，它出现之前，厨房一直在忙。

等菜类比还能解释另一个现象：为什么复杂的订单等更久。你点一碗白米饭和点一桌席，厨房的备料量完全不同。模型面对一句“你好”和一篇三千字文档，预填充的负担也完全不是一个量级。

等菜类比不成立的两点

这个类比有两处对不上。其一，餐厅的备料是物理动作，有上限；模型的通读是计算，输入更长时耗时增长虽明显，但服务端可以靠扩容和调度把峰值压下来。其二，第一道菜上桌后厨房就翻篇了，首字出现后模型却还在继续写，两个阶段的成本结构并不一样。

还有一点要澄清：首字时间短不等于答案好。它只说明起步快，答案质量要看后面的逐字生成写得怎么样；起步快、后程软的产品同样让人着急，每秒 token 数要一起看才公道。

TTFT 多少算正常

参考标准随场景浮动。日常短对话，几百毫秒到两秒以内都算跟手；长文档总结，首字等到五六秒也不罕见，毕竟通读量大。真正该警惕的是同等输入下某个产品长期比别人慢一大截，那通常是服务端调度或容量的问题。

腾讯元宝和文心一言在短对话场景下的首字速度口碑都不错，拿同一段问题横向对比，比看宣传数字直观，对比时记得固定输入长度，不然量不出真差距。带走一个判断：首字时间拆成“通读输入、排队等候、网络零头”三笔账，慢在哪一笔，就从哪一笔优化。

速查表：TTFT=按下发送到第一个字；三笔账=预填充通读+排队+网络；类比等第一道菜；字短不等于答得好；长文档等更久属正常。

关于首字时间再多问三句

• 首字时间和网速有关系吗？有，但只占零头，主要成本在服务端的通读和排队。
• 为什么高峰期首字明显变慢？排队时长被同时涌入的请求拉长，服务端再扩容也有上限。
• 首字快是不是说明模型更强？不是，它只反映起步速度，答案质量要看完整生成的结果。