企业官网建设流程全解析

大模型"说话"快慢的玄机：聊天、coding场景的token速率到底怎么一回事

声明：本文作为笔者个人备忘的文章，不喜勿喷。本文由 AI 辅助生成，仅供个人记录与交流，不代表任何专业结论。

经常用 AI 的人应该都有一个体感：同样一个模型，你跟它"聊天"它蹦字就慢慢悠悠，让它"写代码"就噼里啪啦飞快。我最早也没太当回事，后来一琢磨，发现这里面的门道还挺有意思。这篇文章就当我自己的一次备忘，把"大模型生成速率和不同应用之间的关系"这件事梳理清楚。

先搞清楚两个词：token 和生成速率

很多人以为 token 就是"一个字"，其实不完全对。token 是模型切文本的最小单位，可以是一个字、一个词，也可能是一个标点或者一小段符号。中文里头，大致可以理解成"半个到一个字"的样子。

生成速率就很好懂了——模型每秒钟能"吐"出多少个 token，单位是 tokens/s（也叫 TPS），你可以理解成它的"打字速度"。

但这里有个特别容易混淆的点，也是整篇文章的钥匙：

• 模型底层跑得出来的速度（API 的极限吞吐），动不动几百上千 t/s；
• 你作为用户实际感受到的速度（产品层给你的那个"节奏"），很多时候只有十几个 t/s。

这两个"速度"不是一回事，而不同应用场景需要的"节奏"，就是我想说的重点。

先把人当尺子：阅读速度是"体验及格线"

聊到速度，最直观的参照系不是机器，而是人。

普通人读中文的速度大概是每分钟 300～500 字，换算成每秒也就 5～8 个 token；再宽松一点看，中文阅读大约每秒 15～20 字。业内普遍把"人能一边读一边跟得上"的速度，定在每秒 10～20 个 token左右——这个数字就是"聊天对话"这种场景的体验及格线。

为啥是这个基准？想想你刷聊天框的体验就懂了：如果 AI 蹦字比你读还慢，你会有"卡""等它"的烦躁；如果它快到刷屏，你根本来不及看前面的字。所以聊天场景里，把输出速度"压"到和人阅读差不多的节奏，反而最舒服——无等待感。

不同应用的"速率等级"：聊天慢、编码快，还有更特殊的

如果把"产品层该给用户多快的输出节奏"按场景分个等级，大致可以这么排（这是我自己的归纳，仅供参考）：

等等，这里要声明一下：上面说的是"产品层想要的节奏等级"，跟"模型底层能跑多快"是两码事。底层那些模型，其实快得吓人。

底层到底多快？一串让人吃惊的实测数字

虽然聊天时你只看到每秒十几个 token，但模型 API 的真实吞吐是另一个量级。我搜集了一些公开实测数据：

• 智谱 GLM 的 highspeed 版：约 400 tokens/s，相当于人类阅读速度的 50～80 倍，"你才开始读，它已经把整篇文档写完了"；
• OpenAI GPT-5.6 Sol 标准模式约53 tokens/s，而 Ultrafast 超高速模式最高750 tokens/s（加速约 14 倍）；
• 谷歌 Gemini 3.5 Flash 泄露实测里，写码场景最快能到900+ tps，极端时冲到 1100 多；
• 编程模型普遍很快：Kimi K2.7 Code 常规约 180、短上下文 260 tokens/s；Cursor 自研模型约 250 tokens/s；
• 纯推理模型（慢思考那类）输出速度中位数约108 tokens/s；
• 业内有个"工业达标"的说法：约150 tokens/s是工业级应用的合格线，低于 80 会让用户体验明显变差。

这就很有意思了——底层能跑到几百上千，产品层却只给你十几个。说明"用户感受到的快慢"其实是被应用层有意识地"控制"出来的，不是模型跑不动。

为什么会有这些差异？扒开底层的三个原因

原因一：模型天生是"一个词一个词往外蹦"的（串行）大模型是"自回归生成"，它每吐一个 token，都要基于前面已经吐出来的内容再算一次，像打字员边想边写。所以它天然是"串行"的，快慢主要受解码阶段（Decode）限制。

原因二：不同的任务，"该不该等"不一样聊天这类，用户要的是"回应感"，首几个字快点出来比什么都重要；深度推理则需要模型在幕后"想很久"（所谓 Test-Time Compute），这时候快反而牺牲准确；编码则要"密度"——代码是给机器和开发者看的，信息又密又讲究立即验证，所以消费节奏快，供给就得跟得上。

原因三：人的"消化能力"是天花板再快的喷涌，人读不过来也白搭。所以产品层会主动把输出节奏调到"人跟得上"的水平，这解释了为什么聊天只有十几个 t/s——不是不能更快，是没必要更快。

这些值是怎么"想到"的？

说白了，核心不是"模型能多快"，而是"应用场景需要多快、以及用户能承受等多久"。设计者做的基本是一条"反推"逻辑：

1. 先量出"人的消费速率"——比如阅读速度（10～20 t/s 就是聊天场景锚定的来源）；
2. 再按任务特性给场景定"延迟预算"——聊天要首包快一点（几百毫秒），长文要稳、要不断流，深度推理允许你等几十秒；
3. 最后拿"体感阈值"校准——什么速度下用户不流失、不烦躁，定成及格线（150 t/s 达标、80 t/s 以下流失，这类数字就这么来的）。

所以你看，网上那些"10 还是 20 还是 150"不是凭空拍脑袋，而是从"人"出发、再结合成本与实测反推出来的刻度。

这背后到底解决什么问题？

一句话：解决"等待"和"够不够用"这两个矛盾。

• 等太久，人就跑了（用户流失、留存下降）；
• 跑太快、资源堆太多，成本爆炸（每提升 10 t/s，部署成本大约能降 15%，但反之也成立——盲目堆速度是烧钱）；
• 不同场景对"等"的容忍度不同，一刀切要么浪费要么卡死。

所以核心课题是：在"够快"和"不浪费"之间，给每个场景找到那个刚刚好的速度。

那到底怎么解决？

技术手段基本围绕"省计算、省等待、压成本"三件事：

1. KV Cache / 缓存：已经聊过的内容缓存下来，不再重算，是提速最狠的一招；
2. 量化压缩：INT8 / FP8 / 剪枝 / 蒸馏，把模型"减肥"，算得快、显存省；
3. 调度与批处理：动态批处理、请求合并，把 GPU 空闲填满，高并发也不排队；
4. 流式输出 + 首 token 优化：不等整篇算完，先吐第一段给你，"感觉快很多"（首 token 时延和生成吞吐是两个指标，别混）；
5. 推理引擎与硬件：针对模型架构重写推理路径、多专家并行、专用芯片（Groq 这类甚至到每秒 500+ token）；
6. 架构变革：扩散式模型能"一把生成 256 个 token"，突破逐字串行的天花板。

把这几招组合起来，就能做到"该快的时候快，该省的时候省"。

一个有意思的演进：从"快慢二选一"到"又快又聪明"

回顾这几年（这就是我理解的"时期"）：

• 2023 年左右：ChatGPT 一字一字往外蹦，像"老牛拉破车"，但大家图新鲜，能忍；
• 2024 年：Groq 靠专用芯片做到每秒 500+ token，把"等"这件事第一次做成卖点；
• 2025—2026 年：Ultrafast（750）、GLM highspeed（400）、Gemini 3.5 Flash（1100+）……各大厂开始"速度军备竞赛"。

过去有个不成文的死规矩：想要快，就得用小的笨模型；想要聪明，就得忍受慢。现在这个取舍正在被打破——"又快又聪明"成了新方向，哪怕这背后烧的是真金白银。

小结

所以回到开头的问题：为什么聊天大概十几个 token、编码要更快？

因为——快慢不是模型的属性，是"人"和"应用"一起决定的刻度。聊天跟着人阅读的节奏走（约 10 t/s），编码要顶住高密度的消费节奏（30 t/s 往上），深度推理则用"慢"来换"准"。模型底层其实能跑几百上千，但产品最终呈现给你的速度，是"刚刚好人跟得上又不浪费"的那个值。

想通这一点，再看各种"XXX 达到每秒 XXX token"的新闻，就会多一层味道：数字大不大是一回事，放到具体场景里合不合适，才是关键。

——本文为个人备忘，AI 辅助生成，不喜勿喷。仅供交流记录。