首Token延迟是什么指标，通义千问Turbo标称320ms算快吗，大模型响应速度多快才算好？

首Token延迟指从客户端发出请求到收到第一个输出token之间经过的时间，通义千问Turbo标称的320ms属于短提示、网络通畅、无排队条件下体验较快的一档；它只衡量用户等多久看到第一个字，不衡量整段回答写多久，也不适用于超长输入或高并发排队的真实场景，把它当成“响应速度”的全部会误判。 这个指标在工程上可以拆成四段：请求从客户端到服务端的网络往返、网关侧的排队与调度、模型对输入的预填充计算、以及第一个输出token的采样与解码。四段里任何一段变慢都会把数字推高，所以看到一个首Token延迟数值时，先要确认它是端到端测的，还是只在服务端内部统计的，两者可能差出几十到上百毫秒。 预填充通常占其中最大一块，因为模型必须先读完整个输入才能产出第一个字。输入token越多，预填充的计算量越大，320ms这类数字一般对应较短的提示词；把几万字的文档塞进上下文，同一套服务给出的首Token延迟会明显变长。这也是为什么拿短问句压测出来的结果，不能直接外推到长文档摘要场景。 首Token延迟与输出速度是两个不能互相替代的指标：前者决定用户等多久看到第一个字，后者决定这段回答多久能读完。只优化其中一个会带来割裂的体验，比如开头很快、后面一字一顿，或者首字慢半拍、一旦开始就飞快。描述一次问答的完整体感，至少要同时给出这两个数字。 多快算好要分场景看。交互式文本对话里，首Token延迟在几百毫秒以内体感流畅，接近一秒仍可接受，超过一两秒用户就会怀疑请求卡住；这是人机交互中的经验参考，不是硬性标准，真正的判据是用户在自己使用节奏里有没有感到停顿。同样一个数字，用在网页问答和用在输入补全里，结论可能完全相反。 对延迟最敏感的是实时语音与数字人对话，几百毫秒的差距会被直接听成“反应迟钝”，这类场景通常要把首Token延迟压到更低区间，并尽量稳住尾部波动。相反，离线批处理、夜间批量生成、后台数据标注这类任务里，首Token延迟几乎不影响总时长与总成本，为它牺牲吞吐或单价并不划算。 看首Token延迟必须看分位数而不是平均值。平均值320ms很可能意味着并发高峰时的尾延迟是它的数倍，而用户抱怨的恰恰是那几次最慢的请求。评估时至少取P95和P99，并标注采样当时的并发水平与输入长度，否则两个团队报出的“同一指标”根本没有可比性。 在流式返回的接口里，首Token延迟直接等于用户看到第一个字之前的那段空白。流式输出只是把后续token陆续推送出来，第一个token到达之前前端无内容可渲染，所以这段“开头停顿”完全由首Token延迟决定，与后面的分块大小、推送频率没有关系。 测量方法会显著影响数值。从客户端计时的端到端首Token延迟包含公网往返，通常高于服务端自报的数字；用真实业务的输入长度分布去压测，比用一句“你好”测出来的结果更有参考价值；采样次数太少，也容易被偶发的网络抖动或调度排队误导，得不出稳定结论。 降低首Token延迟的手段大多集中在输入端：做前缀缓存或提示缓存，精简系统提示词，减少不必要的上下文拼接，把请求路由到离用户更近的接入区域。此外复用长连接以省掉重复握手、控制并发峰值、设置合理的排队与超时策略，也能压住尾部的长尾等待，避免平均值好看、尖峰难看。 必须明确边界：首Token延迟不是质量指标，回答得对不对、准不准它一概不反映；它也不是吞吐指标，单位时间能处理多少请求要用并发数和每秒输出token数来衡量。对非流式的一次性返回接口，首token与整段内容几乎同时到达，这个指标的意义会弱化到接近总耗时。 选型时把首Token延迟与输出速度、P99稳定性、单位成本放进同一张对照表，单看任何一个都会误判。通义千问Turbo标称的320ms可以作为同类交互场景的一个参考锚点，说明短输入下“开始出字”已经进入几百毫秒区间；但落到自己的业务上，仍要用真实输入长度、真实并发和真实网络环境重新测一遍，再决定这个速度是否够用。