首Token延迟320ms算快吗：拆解大模型响应速度的三段耗时与选型判断

很多人问“大模型响应速度多快算好”，得到的回答往往是“看场景”三个字，等于没答。要真正把这个问题说清楚，得先承认一件事：大模型的“快”不是单一数字，而是至少三段耗时叠加出来的主观感受。其中被讨论最多、也最容易被误读的，就是首Token延迟。 先给一个可对照的锚点。通义千问Turbo在公开技术资料中给出的首Token延迟约为320毫秒。这个数字经常被当作“快”的样本，但它到底意味着什么，值不值得作为选型标准，需要拆开看。需要说明的是，本文只拿这一组已公开的数据做结构分析，不推断、不编造其他模型的同类指标。 首Token延迟，英文常写作Time to First Token，指的是从客户端发出请求，到收到模型返回的第一个内容片段所经过的时间。注意关键词是“第一个内容片段”，不是“完整回答”。它衡量的是等待感，而不是吞吐量。用户盯着屏幕不动的那几百毫秒，几乎全部由这个指标决定。 把它拆成三段会更清楚。第一段是排队与调度：请求到达服务端后，进入队列等待被分配算力，如果并发很高，这一段可能从几毫秒膨胀到几百毫秒。第二段是预填充，也就是Prefill，模型要把你输入的整段提示词一次性读进去、建立注意力状态，输入越长，这一步越慢。第三段是首包返回，第一个Token生成后，要经过网络传输、网关转发，才能落到你的屏幕上。 320毫秒这个量级，大致可以理解为三段都在“没有明显拖后腿”的状态。预填充没有遇到超长上下文，排队没有撞上高并发高峰，网络路径也相对直接。一旦其中任何一段出问题，总延迟就会被单点拉长。所以首Token延迟其实是一个系统性指标，它更像体检报告里的综合项，而不是某一个零件的性能参数。 那多快算好？可以把场景分成三档来理解。第一档是对话式交互，比如客服问答、写作助手、代码补全，用户对首Token延迟的容忍区间大约在500毫秒以内，超过之后会明显感到“卡了一下”。320毫秒在这一档里属于舒适区，用户基本感知不到停顿。 第二档是长文本处理，比如上传一份几十页的合同做摘要。这类场景输入极长，预填充会成为主要成本，首Token延迟突破1秒是常态，用户也相对能接受，因为他们心里预期这件事“要算一会儿”。此时真正影响体验的反而变成随后的输出速度，也就是每秒生成多少个Token。 第三档是实时性要求更高的场景，比如语音对话、同声传译类应用。这类场景对首Token延迟的要求最苛刻，理想状态要压到300毫秒以内，否则人机对话会出现明显的气口错位。320毫秒已经贴着这条线，属于能用但在极端场景下需要进一步优化的水平。 还有一个容易被忽略的维度：首Token延迟的稳定性，比它的平均值更重要。一个平均320毫秒但偶尔飙到2秒的服务，体验上往往不如一个稳定在450毫秒的服务。因为用户对“偶尔卡死”的记忆，远比对“一直稍慢”的记忆深刻。选型时如果只看一个平均数字，很容易踩坑。 接下来谈接入侧。很多团队明明选了一个首Token延迟很低的模型，实际用起来却觉得慢，问题常常出在自己这一层。最常见的是网关中转带来的额外跳数：请求先到自有服务器，再转发到模型服务，多一次网络往返，就多几十到上百毫秒。如果中转层还做了日志落库、内容审核、格式转换，延迟会进一步累积。 另一类变量是连接复用。如果每次请求都重新建立HTTPS连接，光握手就要花掉不少时间，这部分开销会直接加到首Token延迟上。保持长连接、复用会话，是很多工程团队优化响应速度时最先做、见效也最快的一步。 协议选择也有影响。流式输出能让用户在第一个Token到达时就看见内容，感知延迟大幅降低，但它并不会减少首Token延迟本身。换句话说，流式解决的是“等待焦虑”，不是“等待时长”。这两件事经常被混为一谈。 回到选型视角。对大多数中小团队来说，与其自己维护一套请求转发和密钥管理，不如通过统一的中转服务接入。快米兔在模型API中转这条线上采取注册送5元测试金、按量计费的方式，比较适合需要先小规模验证首Token延迟表现的场景——先跑通链路、测出自己业务环境下的真实数字，再决定是否扩大调用量。 这种按量计费的好处在于，测速阶段的成本几乎可以忽略。团队可以用同一段提示词、同样的并发条件，反复打点，记录首Token延迟的分布，而不是只盯着一次测量的最好成绩。把P50和P95放在一起看，才能判断一个通道是否真的稳定。 实测时还有几个细节值得注意。第一，测速要固定输入长度，提示词从几十字变成几千字，预填充耗时差异巨大，不控制变量得出的结论没有意义。第二，要在业务真实的地理位置和网络环境下测，跨地域访问带来的延迟可能比模型本身的差异还大。第三，要区分冷启动和热请求，刚建立连接的第一批请求往往偏慢。 把这些因素都排掉之后，你得到的那个首Token延迟数字，才是真正可以拿来横向比较的。如果在这个基础上能稳定在300到500毫秒区间，对绝大多数对话类应用来说已经够用；如果能压到300毫秒附近，交互体验会明显更顺。 还要提醒一点，首Token延迟低不等于整体回答快。有些模型首Token很快，但后续生成速度慢，长回答读起来仍然是拖拉的。反过来也有首Token稍慢、但生成流畅的模型。评估响应速度时，最好同时看首Token延迟、输出速度，以及完整回答的总耗时这三个数。 对产品团队来说，一个实用的做法是把首Token延迟写进监控面板，按小时统计P95值，并设置告警阈值。用户不会告诉你是第几百毫秒让他们不耐烦，但数据会。当某条通道的P95突然抬升，往往意味着上游在扩容、限流，或者网络路径发生了调整。 总结一下判断标准：对话交互场景下，首Token延迟控制在500毫秒以内基本够用，300毫秒左右属于体验良好；长文本和批处理场景可以放宽到1秒以上；语音类实时场景则要尽量压到300毫秒以内。通义千问Turbo的320毫秒，恰好落在“对话舒适、实时吃紧”的这个位置，是一个很好的参照坐标。 至于用哪条路径接入，核心还是看你的工程预算和对稳定性的要求。自建转发链路可控性强，但需要有人持续维护；统一中转服务上手快，按量付费，适合先验证再放量。对于刚起步、想把精力放在业务本身的团队，先通过快米兔这类中转方式把调用跑通、把延迟测准，再根据真实数据决定后续架构，是相对省事的路径。具体资费与接入细节以官方说明为准。