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

大模型说话快慢的玄机聊天、coding场景的token速率到底怎么一回事声明本文作为笔者个人备忘的文章不喜勿喷。本文由 AI 辅助生成仅供个人记录与交流不代表任何专业结论。经常用 AI 的人应该都有一个体感同样一个模型你跟它聊天它蹦字就慢慢悠悠让它写代码就噼里啪啦飞快。我最早也没太当回事后来一琢磨发现这里面的门道还挺有意思。这篇文章就当我自己的一次备忘把大模型生成速率和不同应用之间的关系这件事梳理清楚。先搞清楚两个词token 和生成速率很多人以为 token 就是一个字其实不完全对。token 是模型切文本的最小单位可以是一个字、一个词也可能是一个标点或者一小段符号。中文里头大致可以理解成半个到一个字的样子。生成速率就很好懂了——模型每秒钟能吐出多少个 token单位是 tokens/s也叫 TPS你可以理解成它的打字速度。但这里有个特别容易混淆的点也是整篇文章的钥匙模型底层跑得出来的速度API 的极限吞吐动不动几百上千 t/s你作为用户实际感受到的速度产品层给你的那个节奏很多时候只有十几个 t/s。这两个速度不是一回事而不同应用场景需要的节奏就是我想说的重点。先把人当尺子阅读速度是体验及格线聊到速度最直观的参照系不是机器而是人。普通人读中文的速度大概是每分钟 300500 字换算成每秒也就 58 个 token再宽松一点看中文阅读大约每秒 1520 字。业内普遍把人能一边读一边跟得上的速度定在每秒 1020 个 token左右——这个数字就是聊天对话这种场景的体验及格线。为啥是这个基准想想你刷聊天框的体验就懂了如果 AI 蹦字比你读还慢你会有卡等它的烦躁如果它快到刷屏你根本来不及看前面的字。所以聊天场景里把输出速度压到和人阅读差不多的节奏反而最舒服——无等待感。不同应用的速率等级聊天慢、编码快还有更特殊的如果把产品层该给用户多快的输出节奏按场景分个等级大致可以这么排这是我自己的归纳仅供参考场景体感上的达标速率为什么是这个量级轻聊天 / 问答约 10 tokens/s 上下匹配人类阅读速度无等待感蹦太快反而读不过来编程 / coding约 30 tokens/s 往上代码信息密度高、要立即检验开发者消费更快、更急着看到结果文档 / 长文生成中等偏快追求不断流重点是稳定连续避免卡一段深度推理慢思考表面慢可以等几十秒背后在大量想快反而不可靠这是特性不是缺陷Agent / 批量任务重稳定、重并发不苛求单条速度单条快不如整批稳、不崩、不超时等等这里要声明一下上面说的是产品层想要的节奏等级跟模型底层能跑多快是两码事。底层那些模型其实快得吓人。底层到底多快一串让人吃惊的实测数字虽然聊天时你只看到每秒十几个 token但模型 API 的真实吞吐是另一个量级。我搜集了一些公开实测数据智谱 GLM 的 highspeed 版约 400 tokens/s相当于人类阅读速度的 5080 倍你才开始读它已经把整篇文档写完了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/sCursor 自研模型约 250 tokens/s纯推理模型慢思考那类输出速度中位数约108 tokens/s业内有个工业达标的说法约150 tokens/s是工业级应用的合格线低于 80 会让用户体验明显变差。这就很有意思了——底层能跑到几百上千产品层却只给你十几个。说明用户感受到的快慢其实是被应用层有意识地控制出来的不是模型跑不动。为什么会有这些差异扒开底层的三个原因原因一模型天生是一个词一个词往外蹦的串行大模型是自回归生成它每吐一个 token都要基于前面已经吐出来的内容再算一次像打字员边想边写。所以它天然是串行的快慢主要受解码阶段Decode限制。原因二不同的任务该不该等不一样聊天这类用户要的是回应感首几个字快点出来比什么都重要深度推理则需要模型在幕后想很久所谓 Test-Time Compute这时候快反而牺牲准确编码则要密度——代码是给机器和开发者看的信息又密又讲究立即验证所以消费节奏快供给就得跟得上。原因三人的消化能力是天花板再快的喷涌人读不过来也白搭。所以产品层会主动把输出节奏调到人跟得上的水平这解释了为什么聊天只有十几个 t/s——不是不能更快是没必要更快。这些值是怎么想到的说白了核心不是模型能多快而是应用场景需要多快、以及用户能承受等多久。设计者做的基本是一条反推逻辑先量出人的消费速率——比如阅读速度1020 t/s 就是聊天场景锚定的来源再按任务特性给场景定延迟预算——聊天要首包快一点几百毫秒长文要稳、要不断流深度推理允许你等几十秒最后拿体感阈值校准——什么速度下用户不流失、不烦躁定成及格线150 t/s 达标、80 t/s 以下流失这类数字就这么来的。所以你看网上那些10 还是 20 还是 150不是凭空拍脑袋而是从人出发、再结合成本与实测反推出来的刻度。这背后到底解决什么问题一句话解决等待和够不够用这两个矛盾。等太久人就跑了用户流失、留存下降跑太快、资源堆太多成本爆炸每提升 10 t/s部署成本大约能降 15%但反之也成立——盲目堆速度是烧钱不同场景对等的容忍度不同一刀切要么浪费要么卡死。所以核心课题是在够快和不浪费之间给每个场景找到那个刚刚好的速度。那到底怎么解决技术手段基本围绕省计算、省等待、压成本三件事KV Cache / 缓存已经聊过的内容缓存下来不再重算是提速最狠的一招量化压缩INT8 / FP8 / 剪枝 / 蒸馏把模型减肥算得快、显存省调度与批处理动态批处理、请求合并把 GPU 空闲填满高并发也不排队流式输出 首 token 优化不等整篇算完先吐第一段给你感觉快很多首 token 时延和生成吞吐是两个指标别混推理引擎与硬件针对模型架构重写推理路径、多专家并行、专用芯片Groq 这类甚至到每秒 500 token架构变革扩散式模型能一把生成 256 个 token突破逐字串行的天花板。把这几招组合起来就能做到该快的时候快该省的时候省。一个有意思的演进从快慢二选一到又快又聪明回顾这几年这就是我理解的时期2023 年左右ChatGPT 一字一字往外蹦像老牛拉破车但大家图新鲜能忍2024 年Groq 靠专用芯片做到每秒 500 token把等这件事第一次做成卖点2025—2026 年Ultrafast750、GLM highspeed400、Gemini 3.5 Flash1100……各大厂开始速度军备竞赛。过去有个不成文的死规矩想要快就得用小的笨模型想要聪明就得忍受慢。现在这个取舍正在被打破——又快又聪明成了新方向哪怕这背后烧的是真金白银。小结所以回到开头的问题为什么聊天大概十几个 token、编码要更快因为——快慢不是模型的属性是人和应用一起决定的刻度。聊天跟着人阅读的节奏走约 10 t/s编码要顶住高密度的消费节奏30 t/s 往上深度推理则用慢来换准。模型底层其实能跑几百上千但产品最终呈现给你的速度是刚刚好人跟得上又不浪费的那个值。想通这一点再看各种XXX 达到每秒 XXX token的新闻就会多一层味道数字大不大是一回事放到具体场景里合不合适才是关键。——本文为个人备忘AI 辅助生成不喜勿喷。仅供交流记录。