首Token延迟是什么指标，通义千问Turbo的320ms算快吗？

首Token延迟（TTFT）指从客户端发出请求到收到模型第一个输出token所经过的时间，通义千问Turbo的320ms说的就是这一段；它衡量「多久开始回答」，不衡量「回答得多快」，因此不能拿来判断一篇长回复的总耗时，也不适用于离线批处理这类不关心首字响应的场景。 首Token延迟和端到端延迟是两个指标，混用会直接导致选型判断出错。端到端延迟等于首token时间加上后续全部token的生成时间，只有TTFT覆盖输入处理和第一次解码；交互式对话、语音助手、代码补全这类对「首字响应」敏感的场景看TTFT，报告生成、批量摘要这类吞吐优先的场景看总时长更合理。 320ms这个数值通常由五段构成：客户端到服务端的网络往返、网关鉴权与限流、请求排队调度、prefill预填充计算、首个token采样与回传。五段里任何一段变慢都会推高TTFT，所以单看一个320ms没有意义，必须先问清它是在什么网络位置、多长输入、多大并发下测出来的。 prefill预填充是TTFT中最容易变化的一段，因为它随输入长度近似线性增长。同一个模型，提问只有二十来个token，和把数千token的文档一起塞进上下文，首token延迟可能拉开一个数量级；320ms通常对应较短输入、较低并发与同区域网络的组合条件。 排队与调度是第二大变数，在共享算力上尤其明显。并发突增时，请求先进入队列等GPU空闲，这段等待全部计入TTFT，却与模型本身快慢无关；这就解释了为什么同一个模型在不同时间测出的首token延迟能差好几倍，跨厂商比较TTFT必须确认是否在同一并发压力下测量。 多快算好没有统一数字，应按人机交互的感知经验分层判断。100～300毫秒的TTFT会让流式对话接近「即时」；300～800毫秒仍算流畅，用户大多察觉不到停顿；超过1秒开始出现可感知的等待；超过2秒且没有打字机效果或占位提示时，用户会怀疑服务卡住。 320ms处在「接近即时」区间的上沿，对纯文本对话、客服问答、知识检索总结都够用，但它的适用边界也很清楚。如果应用是实时语音通话，链路里还要叠加语音识别与语音合成，这时单看模型的320ms不足以下结论，端到端往返要把识别、合成和额外网络时间一并算上。 只看首Token延迟会漏掉输出速度问题，这是最常见的评估误区。首token 320ms、但每输出一个token要几十毫秒、回复长达数百字，用户的总等待依然可观；衡量生成阶段要看每输出token时间（TPOT）或每秒输出token数，两个指标一起看，才能识别「开头快、中间拖」的体验断点。 不同场景对TTFT的容忍度差别很大，用同一把尺子会做出错误取舍。代码补全、搜索联想、语音打断对首字延迟最敏感，通常要求在几百毫秒以内；而文档生成、数据清洗、批量摘要属于吞吐优先，TTFT高一些不影响结果，优化目标应改成总时长和单位成本。 自己测TTFT时要固定三个变量：输入长度、并发数、测量位置。常见误测是把浏览器首屏渲染完成的时间当成TTFT，那里面混进了前端渲染和网络抖动；正确做法是在服务端记录请求发出到收到第一个流式chunk的时间，并分别统计P50、P95、P99，而不是只报一个平均值。 平均值会掩盖长尾，选型和服务承诺应以P95或P99为准。一个服务平均320ms、P99却到3秒，高峰期就会出现肉眼可见的卡顿；把指标写成「P95首token延迟不超过某个毫秒数」比写「平均响应快」更可验证，也更容易在压测中复现和追责。 降低TTFT的常用手段是缩短输入、开启流式输出、复用KV cache、设置并发上限和预热实例，但每个手段都有代价。截断输入可能丢失上下文，量化和推测解码可能影响输出质量，所以正确顺序是先确认指标口径和场景阈值，再决定牺牲哪一部分；对通义千问Turbo这类给出320ms首token指标的模型，短输入、低并发、同区域网络下可满足即时交互要求，换成超长上下文或高并发共享实例，这个数字不能直接外推。