首Token延迟320ms算快吗：拆解大模型响应速度的指标口径与分档

很多团队在问「大模型响应速度多快算好」，得到的回答往往是「看情况」。这个答案并不敷衍——真正决定体感的，不是整段回复花了多久，而是用户从按下回车到屏幕上冒出第一个字之间的那段空白。衡量这段空白的指标，就是首Token延迟，英文缩写 TTFT。

TTFT 指的是从客户端发出请求，到接收到第一个流式分片所经过的完整时间。它和「总响应时间」是两个口径：后者还包含后续所有 token 的生成与传输。一个模型可能 TTFT 只有 300 毫秒，但输出很长，整体要十几秒；也可能 TTFT 接近 2 秒，之后吐字飞快。在对话、补全、问答这类交互产品里，TTFT 的权重通常远高于总耗时。

把 320 毫秒拆开看，它由几段串联的时间组成。第一段是网络往返，请求从客户端到接入点、再落到推理集群；第二段是排队与调度，请求在多实例、多批次之间等待分配；第三段是 prefill，模型读完整个输入 prompt 并建立 KV 缓存的阶段，输入越长这一段越贵；第四段是首个 token 的采样与解码；第五段是流式首包回传。任何一段出现抖动，都会直接体现在 TTFT 上。

以通义千问Turbo首Token延迟320ms为例，这个数字在公开可查的口径里属于比较靠前的一档。它反映的不是单点运气，而是 prefill 计算效率、批处理调度策略与首包传输链路综合作用的结果。需要留意的是，320ms 是特定输入长度、特定并发条件下的测量值，并非恒定值；把同样的问题换成几万字的上下文，TTFT 大概率会明显上升。

那么「多快算好」？业内常用的经验分档大致是：300 毫秒以内接近即时，用户几乎察觉不到等待；300 到 500 毫秒属于优秀区间，多数对话产品在这个范围内体验顺滑；500 毫秒到 1 秒仍然可用，但开始有可感知的停顿；1 到 2 秒等待感明显，需要靠打字机动画、加载提示来过渡；超过 2 秒，用户就会开始怀疑「是不是卡了」。

不过分档只是参考，真正该看的是分位数而不是平均值。平均值会被大量短请求拉低，从而掩盖长尾。工程上更该盯 P95 和 P99：如果 P95 的 TTFT 在 800 毫秒、P99 冲到 3 秒，说明有一部分用户的体验相当差。压测时应固定输入长度与并发梯度，分段记录，否则前后两组数字之间没有可比性。

影响 TTFT 最直接的自变量是输入长度。prefill 的计算量与 prompt 的 token 数近似线性增长，十万级上下文的请求，即便模型本身很快，TTFT 也很难维持在几百毫秒。这也是为什么许多场景要把常用前缀做缓存：把系统提示词、知识库固定段落缓存成 KV，只在后面追加变化的部分，可以大幅削减重复 prefill 的开销。

并发同样是关键变量。同一张卡上跑批处理能提升吞吐，但排队的请求会推高 TTFT。更合理的做法是区分优先级：把交互式请求与离线批处理分流，对前者保留低延迟通道，对后者允许较长的队列。只看吞吐不看 TTFT，线上体验与压测报告就会出现严重脱节。

接入层往往被忽略，却直接决定第一段网络耗时。请求如果绕远路、反复建连、经过层层转发，几十毫秒就这样被吃掉。模型 API 中转服务在这里的价值，是把路由、连接复用、失败重试与限流收拢到一处，让上游探测到的 TTFT 更接近真实链路水平。快米兔的模型 API 中转面向国产合规模型，注册送 5 元测试金、按量计费，比较适合团队先跑一轮自己的 TTFT 基线，再决定长期用量。

测量 TTFT 本身也有方法上的讲究。客户端计时要点在「收到首个分片」，而不是「连接建立完成」，两者可能差出数百毫秒；服务端计时则不含公网往返。做跨区域测试时，最好同时记录网络 RTT，才能判断慢是慢在模型，还是慢在链路。

回到开头的问题：大模型响应速度多快算好，并没有统一标准，但可以用场景反推。代码补全、输入联想这类场景要求 TTFT 越低越好，最好压在 300 毫秒以内；客服问答、检索增强问答可以放宽到 500 至 800 毫秒；长文写作、报告生成对首字快慢相对宽容，用户更在意后续输出是否稳定。选型时先明确业务属于哪一档，再拿同输入长度、同并发下的 P95 去比较，比只看宣传页上的单点最优值靠谱得多。

对多数团队来说，落地路径是：先定场景阈值，再用统一口径压测，最后才谈成本与用量。按量计费的接入方式便于在早期控制预算，把测试金花在基线测量上，等阈值与成本曲线都清楚了，再扩大调用规模，会是更稳妥的节奏。