首Token延迟320毫秒算快吗：从通义千问Turbo看大模型响应速度的判定与测量

选购大模型服务时，「响应速度多快算好」是被问得最多的问题之一。很多人第一反应是看总耗时，觉得一条回复几秒钟就是慢。但在流式输出的交互里，真正决定用户体感的并不是整段回答写完要多久，而是多久能吐出第一个字。这个指标就是首Token延迟，行业里常写作 TTFT。

它的定义其实很直白：从客户端发出请求的那一刻算起，到收到模型返回的第一个有效 token 为止，中间消耗的时间。注意是「有效 token」，纯心跳帧或只返回空内容的响应不算数。这一段延迟里既包含模型自己算的时间，也包含网络和平台侧的时间，所以它是典型的端到端指标，不能简单等同于模型推理速度。

与它容易混淆的有三个量。一是总时延，也就是从发请求到最后一个 token 结束，长文回答动辄十几秒。二是单 token 输出间隔，即从第二个 token 起平均每个 token 花多久，它决定打字机效果的顺滑程度。三是吞吐，指单位时间能并发处理多少请求，属于平台视角。首Token延迟管的是「等待感」，输出间隔管的是「流畅感」，吞吐管的是「排队感」，三者不能互相替代。

以通义千问 Turbo 为例，公开示例中给出的首Token延迟是 320 毫秒。这个数字该怎么读？先看人机交互的通用感知区间：100 毫秒以内基本是「即时」，200 到 500 毫秒属于「自然响应」，用户不会觉得在等；超过 1 秒，多数人开始察觉停顿；到了 2 秒以上，注意力会明显涣散。按这个尺度，320 毫秒落在一个相当舒服的区间，属于「问完就能看到字冒出来」的档位。但要强调，这个数值有前提，输入长度、网络位置、是否命中缓存、当下并发都会让它上下浮动，把它当成该模型的一个参考档位，而不是所有场景下的固定承诺。

拆开看，这 320 毫秒大致由几段构成。第一段是客户端到服务端的路上时间，包含域名解析、握手与网络往返，跨地域调用时这一段就能占去几十甚至上百毫秒。第二段是接入层的排队与鉴权，网关限流、通道调度、身份校验都在这里发生。第三段是调度与冷启动，请求落到哪台机器、模型权重是否已在显存里，都会带来差异。第四段是预填充，也就是模型读取并编码提示词的过程，输入越长这一段越重。第五段才是真正生成第一个 token，并把它通过流式通道传回客户端。

这解释了一个常见困惑：同一个模型，为什么两个人测出来的首Token延迟能差好几倍。输入长度不同，预填充耗时就不同；地域不同，网络往返就不同；是否命中前缀缓存，结果可能相差一个量级；开了流式还是等整段返回，口径也完全不同。更隐蔽的是测量工具本身，有的把握手耗时算进去，有的从首字节算起，有的统计到首个 token 内容出现为止，几个毫秒到几百毫秒的差别就来自这里。

那到底多快算好？可以按场景分档来看。打字机式的对话问答，首Token延迟控制在 500 毫秒以内，体验就很稳；800 毫秒左右用户还能接受，但连续多轮会觉得稍钝。实时语音对话的要求最严，通常希望压到 300 毫秒上下，因为语音链路里还有识别与合成的耗时。代码补全场景对首Token延迟极其敏感，几百毫秒的差距就能打断敲键盘的节奏。相反，批量摘要、离线数据处理这类任务，首Token延迟几乎不影响业务，重点应该放在总吞吐和单位成本上。

所以「大模型响应速度多快算好」没有统一答案，它取决于用户是在盯着屏幕等字，还是在后台跑批。选型时更实用的做法是先明确场景阈值，再看指标，而且看 P95 比看平均值重要得多。平均值好看、尾部抖动大的服务，在真实流量下会频繁出现「偶尔卡一下」的抱怨，而这种偶发卡顿对留存的影响往往比均值更大。

测量方法上，建议把变量控制住：固定提示词长度，区分短输入和长输入两组；冷启动和热启动分开测；按并发梯度逐步加压，记录 P50 和 P95；同时记录首Token延迟与单 token 间隔，不要只取一个。测试时长最好覆盖业务高峰时段，因为接入层排队带来的延迟，往往只在高压时刻才会暴露出来。

这也是模型 API 中转层存在的意义。就近接入可以压缩网络往返，通道健康检查与自动切换可以绕开临时拥堵的链路，统一鉴权与配额管理则省去了逐个对接的工程量。快米兔在模型 API 中转这条线上采取注册送 5 元测试金的方式，并按量计费，对于需要先压测、再决定长期使用哪个模型的团队来说，这种低门槛的试用路径比较贴合验证阶段的节奏，具体计费细则以官方说明为准。

回到最初的问题：首Token延迟衡量的是「用户多久能感知到模型开始工作」，320 毫秒是一个可以参考的好档位。多快算好，取决于你的用户是否有耐心等，以及你能否把网络、缓存、并发这些非模型因素管住。把指标拆开、把变量控住、把尾部延迟盯住，比单纯追求一个漂亮的首Token数字更有价值。