为啥别人的 AI 秒回，你的还在转圈圈？

原创

ITPAPA
ITPAPA

ITPAPA

2026年10月20日 22:46
江苏

去阅读

同一个问题，为什么有的 AI 秒回，
有的要等 5–10 分钟？

——大模型响应延迟的六道闸门：一次把\"转圈\"这件事讲透

核心结论速览：同一场对话的等待时间由三段构成——首字延迟、吐字速度、总时长；而首字延迟被拉长到 5–10 分钟，通常是六道闸门共同作用的结果：思考预算、模型规模、输入长度、服务排队、智能体任务、产品呈现。慢不一定是卡了，更多时候是它在用时间换质量、换深度、或只是在排队。

引子：一个让全网用户抓狂的谜题

深夜十一点，你把同一道题分别发给两个 AI 助手。

左边那个，回车键还没松开，字就像流水一样淌了出来，三秒钟给你一篇像模像样的答案。右边那个，屏幕上只剩一行小字——\"正在深度思考中……\"，转圈、转圈、再转圈。五分钟后，它终于开口，给出的答案确实更周密、更有条理，可你的耐心早已在转圈中碎了一地。

问题来了：它们背后不都是\"大模型\"吗？差得也太多了。

是右边那个\"卡了\"？是它\"更笨所以算得慢\"？还是它偷偷干了什么别的活？

答案都不对。真正的原因是：从你敲下回车到第一个字蹦出来，中间要过六道闸门。有的模型六道全绿灯，一路畅行；有的模型在某一道闸门前规规矩矩排长队——那不是故障，而是它在用时间换别的东西。

这篇报告就把这六道闸门一道一道拆开看。读完你会拥有一张完整的\"延迟地图\"：再遇到转圈，你大致能判断出它卡在哪一道、值不值、以及怎么绕。

先把\"等待\"拆开：你等的是哪一段时间？

在拆闸门之前，先纠正一个大多数人都在犯的认知错误：\"AI 回答慢\"根本不是一个数字，而是三个。

首字延迟（TTFT）：从按下回车到第一个字出现的时间。这是你在聊天框里\"干瞪眼\"的那段死寂。吐字速度：第一个字出现之后，后续文字流淌出来的快慢，通常以\"每秒多少个词元（token）\"计量。端到端总时长：从提问到全文写完的总时间，约等于首字延迟加上\"全文长度 ÷ 吐字速度\"。

这三件事的瓶颈完全不同，就像点一份外卖：首字延迟像\"商家接单 + 后厨开火\"的时间，吐字速度像\"骑手在路上跑多快\"，总时长才是\"从下单到开饭\"。一家后厨慢但骑手飞快的店，和一家秒接单但骑手慢悠悠的店，给你的体验天差地别——尽管总时长可能一样。

对聊天用户来说，首字延迟几乎决定一切观感。界面研究的共识是：屏幕空白超过几秒，用户就开始怀疑\"它是不是死了\"；而一旦有字开始流动，哪怕整体要跑二十秒，用户也会觉得\"它在干活\"。所谓\"等 5–10 分钟才有内容输出\"，本质上是首字延迟被拉到了分钟级。后面六道闸门，每一道都可能贡献这段死寂。

图 1　同一个问题，两种模式下的时间都花在哪儿（时间为示意量级）

第一道闸门：模型\"想不想\"——推理模型的思考税

这是 5–10 分钟等待最大的单一来源，没有之一。

2024 年起，AI 圈出现了一个新物种：推理模型。普通模型接到问题后直接开写答案；推理模型却会先在内部\"打草稿\"——生成成百上千甚至上万个你看不见的思考词元：列步骤、试方案、发现走不通、推倒重来、自我检查……全部想完之后，才郑重写下给你的正式回答。

打个比方：普通模型像闭卷抢答的学霸，听到题目凭直觉张口就来；推理模型像同一位学霸但坚持打草稿——草稿越认真，答案越漂亮，可你就得在旁边多等一会儿。

这笔\"思考税\"有多重？一个简单到残酷的公式：

等待时间 ≈ 思考词元数 ÷ 每秒生成速度

如果模型\"心里\"写了 12,000 个词元的草稿，而它的吐字速度是每秒 40 个词元，那么光打草稿就要 300 秒——整整五分钟。同样 12,000 词元的草稿，放到每秒 300 词元的轻量模型上只要 40 秒。这就是为什么\"深度思考\"模式有的产品等一两分钟、有的要等十分钟：思考预算（它允许自己想多久）和底层速度，共同决定你的等待。

图 2　思考得越久，等得越久：思考预算 × 生成速度 → 等待时间（对数坐标）

那这笔税交得值吗？看任务。OpenAI 公开过一组著名数据：在难倒一片人的数学竞赛 AIME 上，普通模型 GPT-4o 的正确率只有 13%，而肯花时间打草稿的 o1 做到了 74%——翻了五倍多。但在\"今天天气怎么样\"这类问题上，深度思考除了让你多等之外毫无贡献。行业测算也显示，推理模式每次查询的算力成本是普通模式的 5–20 倍，换来的质量提升却高度集中在数学、代码、复杂分析这几类\"硬任务\"上。

第一个结论：你等的那 5–10 分钟，很可能大部分是模型按你（或产品默认设置）的要求，认真打草稿的时间。关掉深度思考，它立刻就快了——只是难题的正确率会掉下来。

表 1　深度思考模式的任务匹配指南

第二道闸门：模型\"多大\"——参数量与那道显存带宽之墙

第二道闸门在模型出厂之前就砌好了：模型本身有多大。

一个反直觉的事实是：大模型生成文字，慢的原因往往不是\"算不过来\"，而是\"搬不动\"。模型生成每一个词元，都要把全部参数从显存里完整读一遍——就像一个抄写员，每写一个字，都必须把整部百科全书从头到尾翻一遍。参数越多，这本书越厚，每个字就写得越慢。给一个量级感受：一个 700 亿参数的稠密模型，在现代显卡上仅\"翻书\"这一步的理论极限就是每秒约 40–50 个词元；一个 70 亿参数的小模型，轻松跑出数倍的速度。

于是工程师发明了一个聪明的招数：混合专家架构（MoE）。把一个巨型模型拆成许多位\"专家\"，每个词元只唤醒其中少数几位干活。DeepSeek 的旗舰模型总参数高达 6710 亿，但每个词元实际只激活约 370 亿——虽然这本书有 6710 亿页，但每个字只需要翻其中 37 亿页。这就是\"总参数 6710 亿的大模型反而比某些小得多的稠密模型跑得快\"的秘密：决定速度的是每个字要翻的页数（激活参数），不是书的总厚度（总参数）。

表 2　稠密模型与混合专家架构的速度逻辑对比

图 3　不同档位模型的输出速度区间（综合多家第三方公开测评，量级参考）

综合多家第三方测评的量级大致是：轻量高速档每秒数百词元，中端主力档一两百，旗舰直答档约 55–110，旗舰推理档（叠加思考税之后的有效速度）只有 25–80。同一个问题，两端的吐字速度可以差十倍——这还没算思考预算的差距。

第三道闸门：输入\"多长\"——提问之前的隐形长跑

很多人不知道：在你按下回车之后、模型开口之前，还有一段看不见的计算——预填充（Prefill）。模型必须把你输入的全部内容（问题 + 系统提示词 + 上传的文档 + 前面几十轮对话）从头到尾读一遍，才能写出第一个字。

这段计算最要命的特性是：输入翻倍，开销远不止翻倍。注意力机制的计算量随输入长度呈平方级增长——读 10 万字的合同摘要，开销不是 1000 字短问题的 100 倍，而是接近 10000 倍。所以给 AI 塞一整本书再提问，首字延迟从零点几秒飙到十几秒甚至更久，是物理规律，不是产品 Bug。

图 4　同一张显卡上，读输入卡在算力墙、写输出卡在带宽墙

用工程师的\"屋顶线\"视角看，AI 推理其实卡在两堵不同的墙上：读输入（预填充）卡在算力墙上——大量矩阵乘法把 GPU 的计算单元吃得满满当当；写输出（逐字生成）卡在带宽墙上——瓶颈是数据搬运速度而非计算速度。这两堵墙的优化手段完全不同，也是为什么同一次回答里，\"出第一个字慢\"和\"出后面的字慢\"往往病因不一样。

顺带一提，这也是为什么各家都在推\"上下文缓存\"：多轮对话中，前面聊过的内容不必每次重算，命中缓存的部分几乎零开销——首字延迟能因此成倍下降。你在同一个会话里连续追问时越来越快，背后就是它在起作用。

第四道闸门：服务器\"忙不忙\"——排队、拼车与降速

前三种解释都假设模型\"随叫随到\"。但现实中，你的请求往往要先排队。

大模型服务有个经典的\"拼车\"设计：GPU 永远不能闲着，所以服务商会把许多用户的请求打包成一批发给同一张显卡。拼车让整个系统的运力大涨、成本骤降，但代价是——车越满，每个人等发车的时间越长，车上每个人的吐字节奏也越慢。凌晨三点人少，你的请求上车就走；下午三点高峰期，同一个人、同一个问题，首字延迟可能翻好几倍。

图 5　并发量攀升时，系统吞吐与单用户延迟的\"剪刀差\"（示意数据）

更极端的情况是过载。2026 年国内某头部模型多次因流量暴涨登上热搜：日活用户近乎翻倍，算力储备却只扩容了不到一成，结果工作日早高峰网页和接口集体转圈，官方只能靠限流\"削峰填谷\"。免费通道的用户在这种时刻往往优先被降速、排队——这就是为什么同一个产品，有时秒回，有时\"服务器繁忙请稍后再试\"。

判断方法也简单：如果连\"你好\"这种一句话问题都要转圈半天，大概率不是模型在思考，而是你在队伍里。换个时段、换个平台，或者升级到付费通道，往往立竿见影。

第五道闸门：它是不是\"跑出去干活了\"——Agent 与深度研究

如果等待发生在你明确开启了\"深度研究\"\"联网搜索\"\"智能体\"模式的场景下，那么 5–10 分钟不但正常，甚至算快的。

这类模式已经不是\"一个模型回答一个问题\"，而是一个团队在替你做研究。典型流程是三段式：先由一个\"规划者\"把你的问题拆成十几个子问题；然后几十个\"搜索员\"并发出动，各自检索、打开网页、交叉比对，几十轮往返下来读进几十万字资料；最后由一个\"撰写者\"把所有发现汇总成带引用的报告。行业里一次典型的深度研究运行：搜索调用 30–60 次、吞下 20 万–46 万词元、耗时 5–15 分钟——它不是在\"想\"，它是在真的跑图书馆。

打个比方：普通提问是\"问一个博学的人\"，深度研究是\"委托一家研究所\"。前者张口就来，后者得立项、查资料、开评审会、写结题报告。时间当然不在一个量级，但产出也不在一个量级——后者给你的是一份有出处、有交叉验证的报告，前者可能只是一段流畅的\"印象派\"作答。

看到这里可以做个小结：同是\"等 5 分钟\"，可能是模型在打草稿（第一道闸门），也可能是一群模型在跑图书馆（第五道闸门），还可能只是你在排队（第四道闸门）。三者的解法完全不同，所以下一节的归因树值得收好。

第六道闸门：产品\"让不让你看\"——流式输出与感知延迟

最后一道闸门最玄学：它不改变任何真实的计算时间，只改变你感觉等了多久。

现代 AI 产品几乎都用流式输出：文字像打字机一样一个词一个词往外蹦，而不是憋到最后\"啪\"地甩出全文。技术上，流式一行字的总时长一毫秒都没省——它只是把\"等到最后\"变成了\"边出边读\"。但用户体验的天壤之别就在这里：实测显示，流式能把感知等待时间压缩五到八成，因为从第一个字出现起，你的注意力就转移到\"读\"上了。

反过来，如果一款产品不开启流式、或者把思考过程完全藏起来只留一个转圈动画，那么哪怕它后台实际只跑了 60 秒，你也会觉得度日如年——沉默的等待最漫长。这就是为什么成熟的产品都学会了两件事：把模型的思考摘要展示出来（\"我正在比对这三份文档的差异……\"），以及在长任务里显示具体进度（\"正在检索第 8 个来源，已完成 12 个中的 5 个\"）。有字在动，人心就不慌。

把六道闸门装进一张图：遇到转圈怎么办

图 6　\"等了 5–10 分钟还没出字\"的归因决策树

对照这张归因树，日常自查只要三步：

第一步，看屏幕上有没有字在流动。有字在慢慢流 → 慢在\"吐字\"，瓶颈是吐字速度 × 输出长度：它在写长文、长代码就是正常现象；写一段短话也慢吞吞，则是模型档位偏低或服务器过载。一个字都没有 → 慢在\"起跑\"，进入第二步。

第二步，看是不是开了深度思考、推理或深度研究模式。开了 → 你等的主要是思考与检索，属\"付费上分\"，值不值取决于任务难度（见第一、五道闸门），急用就关掉或调低思考强度。没开还转圈 → 大概率是排队、限流或超长输入（见第三、四道闸门），换时段、精简输入、换平台试试。

第三步，永远记住那句口诀：先分清\"等第一个字\"还是\"等全部字\"——前者看思考与排队，后者看长度与速度。

实用建议：让 AI 快起来的七个技巧

给日常用户的四个

1．按难度选模式。买菜问题用普通模式，一道顶级的\"深度思考\"留给真正值得的难题。别让\"今天周几\"也思考五分钟。

2．输入做减法。别把整本书塞给模型。只贴相关章节、让产品自动检索（RAG），首字延迟立降。

3．错峰使用。工作日上午十点和下午三点是全国 AI 最堵的时段；深夜与清晨的体验通常好一个档次。

4．备好 Plan B。重要任务别押注单一平台，准备两个备选，卡住了立刻切换。

给开发者的三个

5．盯住两个指标而不是一个。首字延迟（TTFT）和每秒词元数分开测、分开优化——聊天产品优化前者，批处理管线优化后者；只看\"平均延迟\"基本等于什么都没看。

6．能缓存就缓存。固定的系统提示词与历史上下文开启前缀缓存，命中后预填充近乎免费，首字延迟和账单一起降。

7．路由而不是 all-in。八成的简单请求走轻量高速模型，两成的硬骨头才交给旗舰推理模型——质量几乎不损失，成本与延迟成倍下降。

结语：慢，有时是一种美德

回到开头那个深夜谜题。现在你知道了：那个转圈五分钟的模型，可能正在打一万两千词的草稿，可能派了几十个分身替你跑图书馆，也可能只是和你一起挤在了晚高峰的电梯里。

\"快\"与\"慢\"从来不是能力的标签，而是一组明码标价的交换：速度、质量、成本，构成了一个不可能三角——极致的快往往意味着放弃深思，极致的准则需要用时间和算力来换。真正聪明的做法不是追求最快，也不是忍受最慢，而是为每一类问题匹配恰当的思考预算：简单问题让它脱口而出，复杂问题允许它慢工出细活。

好消息是，这道交换的\"汇率\"正在快速变得友好。投机解码、多词元预测、专用推理芯片……工程界正把\"打草稿\"的成本一压再压。也许用不了几年，\"深度思考五分钟\"就会变成\"深度思考五秒钟\"——但无论快到什么程度，读懂这六道闸门的人，永远比只盯着转圈动画的人，更知道自己的每一秒等待究竟买到了什么。