做 AI 应用的开发者应该都遇到过这种尴尬模型能力明明很强产品体验却总差一口气。用户问一个 50 字的问题界面要悬停 1 秒多才开始吐字生成一篇 1000 字的文章前 300 字像挤牙膏一样一个字一个字蹦出来。很多团队把问题归结为“模型选错了”于是换更大的模型、加更复杂的提示词结果速度更慢。方向其实从一开始就偏了真正卡住体验的不是一个抽象的词“速度”而是一个可以被精确测量的数——token/秒。最近一个值得留意的趋势判断是Tibo 在谈 AI 未来时提出750 token/秒 将很快成为常态。这个数字如果真正落地意味着 AI 生成内容的速度会超过绝大多数人的阅读速度过去那种“盯着光标等 AI 打字”的体验会从很多产品里彻底消失。本文不打算做情绪化的未来预言而是从 token 的基本原理、推理优化的技术路径、以及开发者的工程实践三个层面把“750 token/秒”这件事拆开讲清楚它为什么重要、靠什么实现、现在做应用层的人应该提前做哪些准备。先说结论token/秒 不是模型能力的注脚而是 AI 应用能否进入“实时交互”时代的入场券。如果你正在做聊天机器人、Agent、写作助手或者任何需要流式输出的大模型应用这篇文章大概率能帮你少走几个月的弯路。1. 真正要解决的问题AI 应用的“实时感”从哪里来很多产品经理喜欢说“AI 要有实时感”但“实时感”不是一个目标函数而是一组可以被量化拆解的指标。拆到最后两个数决定了用户的体感第一个是首 token 延迟用户发出请求后到看见第一个字的时间第二个是生成速度也就是单位时间内模型能输出多少个 token。这两者常常被混为一谈其实对应的是两个完全不同的性能瓶颈。首 token 延迟高问题往往出在预填充阶段也就是系统把整段输入 prompt 计算成 KV Cache 的过程输入越长第一次等待越久。生成速度慢问题则出在自回归解码的每一个单步推理上每一步只能生成一个 token循环几百次才是一篇文章。很多做 AI 应用的团队把精力全部放在 prompt 优化和模型选型上却忘了这两个最底层的数字。这里要强调一个容易被忽视的事实同一个模型在不同推理框架、不同并发参数、不同量化级别下生成的 token/秒 可能差出好几倍。模型能力是“天花板”但开发者真正能影响的是“离天花板有多远”。所以理解 token/秒不是大模型算法工程师的专利而是所有调用 API、部署模型、设计交互的开发者都应该补上的基本功。2. token 是什么从开发视角理解这个计量单位2.1 通俗解释模型阅读文本的最小块token 是模型处理文本的最小基本单位可以理解成“切分后的碎片”。英文里“Hello”可能是一个 token也可能被切得更细“人工智能”在中文分词器下可能是一个或几个 token。不同模型使用不同的 tokenizer所以同样一句话在不同模型下的 token 数量会有差异。这个机制很像真实世界的语言习惯人类读书是按词理解模型读文本是靠这些碎片建立概率关系。token 越多模型要计算的关系就越复杂延迟和成本也随之上升。2.2 token 的三个角色对开发来说token 至少同时承担三个角色第一个角色是上下文窗口的计量单位。模型的 context length 是 32K 还是 128K说的就是它能容纳的 token 数量。第二个角色是 API 的计费单位。绝大多数大模型 API 按输入 token 和输出 token 分别计费服务端的 usage 字段会返回 prompt_tokens、completion_tokens 和 total_tokens。第三个角色是性能指标的分母。token/秒 的快慢直接决定了应用的等待时间。理解这三个角色就能解释很多开发中的困惑为什么长对话越来越慢因为输入侧的历史消息堆高了 prompt token预填充阶段要处理的内容变多。为什么一次请求比想象中贵因为一次检索增强生成可能同时消耗数千个输入 token而 token 计数是双向的。2.3 别把认证 token 和大模型 token 混为一谈这里必须单独提醒一个高频混乱点在登录鉴权、API 网关场景中也有一个 token比如 JWT、access token。它和本文讨论的大模型推理 token 完全是两回事。社区里经常看到两类截然不同的问题。一类是调用 API 时报 “token exchange failed” 或 401错误发生在身份认证阶段常见原因是 JWT 过期、权限配置不正确、请求头 Authorization 没有传对跟模型快慢无关。另一类是“token 用量怎么算”“为什么一次对话消耗这么多 token”这才是模型输入输出的计量问题。写代码时最忌讳把这两类 token 放在同一个变量、同一个缓存、同一套过期策略里管理。认证 token 的核心是安全过期与续签大模型 token 的核心是计费与速度统计。把两者分开建模后续排障会清爽很多。3. 750 token/秒为什么值得关注3.1 超过人类阅读速度意味着什么先给出一个直观参照。成年人正常阅读英文的速度大约是每分钟 200 到 300 词中文约每分钟 300 到 500 字。粗略估算一下1 个 token 约等于 0.75 个英文单词中文场景下一个汉字可能对应 0.6 到 1.5 个 token。750 token/秒 意味着 AI 每秒能生成数百个英文单词或者一眨眼生成几十个汉字这个速度远远超过了人类的自然阅读速度。换句话说当生成速度高于阅读速度时用户等 AI 输出的体感会发生质变。以前是“AI 在写我在等”以后会变成“我在读AI 永远跟得上”。这个转变看起来只是数值变化但它直接影响产品可以做什么能不能做逐字实时字幕、能不能做毫秒级响应的语音对话、能不能在几秒内批量产出几十篇摘要。3.2 从“等待生成”到“实时生成”所有流式 AI 产品都在跟一个隐含约束做斗争用户耐心有限。如果生成一篇 500 token 的回复在 50 token/秒 的模型下要等 10 秒在 750 token/秒 的模型下只需要 0.7 秒左右。这个差别的意义不只是“快一点”而是交互模式的改变。10 秒的等待必须做 loading 动画、中途打断、流式渲染甚至要想办法把长任务拆成多个短任务用状态机管理进度。0.7 秒的延迟则接近传统 API 请求的体感产品可以把 AI 能力嵌入到几乎任何流程里而不用专门设计“AI 正在思考”的用户提示。3.3 趋势判断不等于今天所有模型都达标需要保持清醒的是“750 token/秒 成为常态”更接近方向判断而不是当下所有模型都能达成的事实。不同规模的模型、不同的硬件条件、不同的量化方案实际 token/秒 差异非常大。参数量更大的模型往往更慢跑在消费级显卡上的模型和跑在高端推理集群上的模型也不在一个数量级。但从行业信号看速度竞赛已经是 AI 基础设施层最明确的方向之一。推理框架在优化吞吐和延迟芯片厂商在提升显存带宽模型架构也在向稀疏化和更高效的注意力机制演进。对应用开发者来说与其纠结“750 到底是多少天才到”不如先把自己的项目测清楚当前模型在什么速度下运行瓶颈在哪儿换一种部署方式或推理引擎能提升多少。4. 把速度推上去的几条技术路径4.1 模型架构优化大模型生成速度的瓶颈本质上集中在两个地方自回归的串行解码以及每生成一个新 token 都要读取和更新 KV Cache 带来的显存带宽压力。针对这些瓶颈模型架构层面出现了几个重要趋势。第一是 MLA 这类低秩压缩方法通过对 KV Cache 做压缩来减少显存占用支撑更大并发和更长上下文。第二是 MoE 架构它只激活全部参数的一小部分计算量比同参数的稠密模型小得多可以在不爆炸计算成本的前提下扩大模型规模。第三是各类注意力机制优化目标是减少长序列下的计算复杂度。4.2 推理引擎与调度优化同一份模型权重放到不同推理引擎里运行token/秒 表现有明显差别。这背后是调度策略的差异。最有代表性的思路是 continuous batching。传统部署方式等一个请求完整生成完再处理下一个请求continuous batching 则把多个请求的动态生成过程混合在一起调度谁先产出 token 谁先返回因为大模型每次生成的 token 长度不同这种动态拼车策略能大幅提升 GPU 利用率。另一个典型方向是 speculative decoding用一个小模型先草拟几段再由大模型一次性验证验证通过的部分相当于一步生成了多个 token有效突破自回归解码的步数限制。4.3 量化与硬件配合量化是另一个直接提升速度的手段。把模型从 FP16 压缩到 INT8 或 INT4显存占用变少单位时间内能计算的数据量变大单卡并发能力也会提升。代价是输出质量可能出现轻微下降尤其是小模型在复杂推理任务上会更敏感。硬件层面GPU 的显存带宽HBM bandwidth对 token/秒 影响极大因为自回归解码过程严重依赖高频读取权重和 KV Cache。这也是为什么高性能推理卡和消费级显卡的差异几乎无法只靠软件抹平。对大多数团队来说更实际的选择是先用开源推理框架和量化方案在现有卡上跑出最大吞吐再评估是否值得增加硬件投入。4.4 本地推理与云上推理的分化速度提升之后推理市场正在分化成两条路线。一条是云上高并发推理追求单卡吞吐最大化适合面向大量用户的产品另一条是端侧或私有化部署追求低延迟和数据不出域适合对隐私敏感的场景。端侧部署是否也能达到 750 token/秒 的级别取决于模型规模和硬件条件。小参数模型经过量化在部分高端设备上可以接近这个量级大模型仍然依赖云端。从材料看现阶段更稳妥的判断是750 token/秒 的常态会先在云端推理集群出现再逐步向下渗透。5. 高吞吐会重构哪些应用场景5.1 AI 写作与翻译当生成速度超过阅读速度写作助手的交互逻辑会完全改变。现在的产品为了减少等待会把长文拆成段落逐段生成甚至用“先生成标题再展开内容”的策略降低用户焦虑。速度上去以后产品可以一次性生成较长篇幅用户不再需要为生成过程设计太多进度反馈。翻译场景同理越快越接近同传而不是逐句转写。5.2 Agent 与多工具调用Agent 类应用对速度的敏感程度比普通对话更高。一个 Agent 执行复杂任务时可能要完成多次推理、工具调用、结果检查每次推理都是一次生成过程。如果单次生成要等 5 秒一个三步任务就要让用户等很久如果单次生成只要几百毫秒用户会觉得这个 Agent 是“顺手就把事办了”。从这个角度看750 token/秒 的意义不是让 AI 回答问题更快而是让 AI 有更充足的时间和算力去做更长的推理链。多步工具调用、自我修正、多候选方案对比这些特性只有在延迟足够低的时候才真正可用。5.3 实时语音与字幕语音交互对延迟极其敏感。传统的“语音转文字 → 大模型生成 → 文字转语音”如果每个环节都慢对话就变成了对讲机。生成速度提升后语音助手可以实现更低延迟的对话体验实时字幕和会议纪要也可以从“会后生成”变成“边说边出”。这类场景不仅要求 token/秒 高还要求首 token 延迟尤其低因为用户的耳朵等不了太久。做这类产品的团队建议把 TTFT首 token 延迟和 token/秒 两个指标都列入线上监控。5.4 批量离线处理批量处理场景里速度的收益直接体现在成本和时间上。比如一次性为几万条数据打标签、生成摘要或翻译模型吞吐越高完成时间越短单位时间能处理的请求越多。很多团队在跑离线任务时会专门用高吞吐推理引擎来降低单 token 成本因为离线任务对延迟不敏感但对总吞吐和资源利用率非常敏感。6. 不能只盯着 token/秒性能指标的四个侧面6.1 TTFT 与 TPS 都要看token/秒 衡量的是生成阶段的平均速度但用户感知到的延迟是首 token 延迟和生成速度的组合。一个简单估算公式是# estimate_wait_time.py def estimate_wait_time(output_tokens, tps, ttft0.3): return ttft output_tokens / tps # 在 50 token/s 下生成 300 token print(estimate_wait_time(300, 50)) # 6.3 秒 # 在 750 token/s 下生成 300 token print(estimate_wait_time(300, 750)) # 0.7 秒如果 TTFT 高到 2 秒即使模型生成速度到了 500 token/秒用户体感依然是“卡顿”。调优时把两个指标分开记录才能知道瓶颈是在预填充阶段还是解码阶段。6.2 单流速度与系统吞吐要区分单个请求的 token/秒 高不代表服务整体的吞吐高。一个推理服务同时处理 20 个请求时单请求速度可能下降但系统总吞吐所有请求的 token 数相加可能是单请求模式下的十几倍。面向用户的产品优先关心单个请求的延迟面向离线任务优先关心系统总吞吐面向复杂业务两者都要关注。测试时不要只看一个数字建议同时记录 P50、P95 单请求延迟和系统总吞吐。6.3 输出质量不能被速度绑架速度提升如果建立在过度量化或过度裁剪上输出质量会下滑。用户能接受慢一点得到一个准确答案但很难接受又快又胡说的结果。做技术选型时建议用固定的评测 prompt 集对比不同部署方案的生成质量不要只跑一个“你好”的演示。6.4 成本与配额token/秒 提升之后成本结构也在变化。同样的算力能支撑更多请求但用户也可能在更短时间内消耗更多 token。做应用层时需要在产品侧设计 token 配额、单用户限流和成本告警避免体验优化之后账单跟着失控。7. 工程实践测出并优化你项目的 token/秒7.1 先定义测速方法测速之前要定好变量固定一个输入 prompt固定输出的期望长度固定并发数跑多次取平均值。不要一边测速度一边调整提示词否则数据没有可比性。下面用一个 OpenAI 兼容接口的流式请求示例演示如何在实际项目中统计 TTFT 和生成速度。脚本里的关键点是通过 resp.iter_lines 逐行读取 SSE 数据遇到 content 字段就累加计数。# speed_check.py import json import time import requests API_URL https://your-endpoint/v1/chat/completions API_KEY your-api-key MODEL your-model-name payload { model: MODEL, messages: [ {role: user, content: 请用 500 字介绍分布式系统的基本概念。} ], stream: True, max_tokens: 800, } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } def main(): first_token_time None token_count 0 start time.time() with requests.post(API_URL, jsonpayload, headersheaders, streamTrue) as resp: if resp.status_code ! 200: print(请求失败:, resp.status_code, resp.text) return for line in resp.iter_lines(decode_unicodeTrue): if not line or not line.startswith(data:): continue data line[len(data:):].strip() if data [DONE]: break try: chunk json.loads(data) except json.JSONDecodeError: continue choices chunk.get(choices) or [] if not choices: continue delta choices[0].get(delta) or {} content delta.get(content) if not content: continue if first_token_time is None: first_token_time time.time() # 注意这是按流式返回的 chunk 数近似统计实际 token 数以服务端 usage 字段为准 token_count 1 end time.time() elapsed end - start ttft (first_token_time - start) if first_token_time else 0 generation_time end - first_token_time if first_token_time else elapsed print(f总耗时: {elapsed:.2f}s) print(f首 token 时间(TTFT): {ttft:.2f}s) print(f生成 token 数近似值: {token_count}) if generation_time 0: print(f生成速度: {token_count / generation_time:.2f} token/s) if __name__ __main__: main()运行方式python speed_check.py脚本输出的总耗时、TTFT 和 token/秒 就是当前 API 的体感基线。如果首 token 时间很长说明服务端预填充耗时高如果生成速度低于预期需要查看服务端推理引擎的部署参数。7.2 并发场景下看系统吞吐单请求速度只反映单路体验。生产环境通常要同时服务多个用户所以还需要看并发下的系统吞吐。下面是一个简化版并发测试脚本用 ThreadPoolExecutor 启动多个并发请求统计总耗时和系统级 token/秒。# concurrent_speed_test.py import concurrent.futures import time import requests API_URL https://your-endpoint/v1/chat/completions API_KEY your-api-key MODEL your-model-name PROMPT 用三句话解释什么是缓存。 HEADERS { Authorization: fBearer {API_KEY}, Content-Type: application/json, } def one_request(_): payload { model: MODEL, messages: [{role: user, content: PROMPT}], stream: False, max_tokens: 128, } t0 time.time() resp requests.post(API_URL, jsonpayload, headersHEADERS, timeout30) dt time.time() - t0 if resp.status_code ! 200: return {error: resp.status_code, elapsed: dt} data resp.json() token_count data.get(usage, {}).get(completion_tokens, 0) return {tokens: token_count, elapsed: dt} def main(): concurrency 5 total_requests 20 start time.time() with concurrent.futures.ThreadPoolExecutor(max_workersconcurrency) as pool: results list(pool.map(one_request, range(total_requests))) total_time time.time() - start completed [r for r in results if error not in r] failed total_requests - len(completed) total_tokens sum(r.get(tokens, 0) for r in completed) print(f并发数: {concurrency}, 请求数: {total_requests}) print(f成功: {len(completed)}, 失败: {failed}, 总耗时: {total_time:.2f}s) print(f总生成 token 数: {total_tokens}) if total_time 0: print(f系统吞吐: {total_tokens / total_time:.2f} token/s) if completed: avg_elapsed sum(r[elapsed] for r in completed) / len(completed) print(f单请求平均耗时: {avg_elapsed:.2f}s) if __name__ __main__: main()运行方式python concurrent_speed_test.py如果单请求速度高但并发后系统吞吐上不去优先检查服务端是否启用了 continuous batching、max_num_seqs 是否过小、显存是否足够。7.3 推理引擎部署参数调整如果你使用的是开源推理引擎比如 vLLM 风格的服务部署参数直接影响 token/秒 和系统吞吐。以下命令仅为示意具体参数名和版本有关请以你所用引擎的官方文档为准# 以 vLLM 风格示意的本地/内网部署参数 vllm serve your-model-name \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 32 \ --enable-prefix-caching \ --tensor-parallel-size 1几个关键参数的含义--max-model-len控制最大上下文长度。设得过大会占用大量显存压缩并发能力设得过小长输入会被截断。--max-num-seqs控制同时处理的序列数这是并发吞吐的核心参数。调大可能提高系统吞吐但也会增加单请求延迟。--enable-prefix-caching开启前缀缓存。对于多轮对话、固定系统提示词的场景可以减少重复预填充计算。--tensor-parallel-size控制多卡并行。单卡能容纳模型时可以先从 1 开始避免不必要的通信开销。7.4 如何判断瓶颈在服务端还是客户端如果速度不达标先做隔离判断。用命令行 curl 直接请求 API 并计时如果命令行请求也慢基本可以排除前端渲染和网络代理问题重点排查服务端推理引擎。如果命令行快、前端慢再检查流式解析、WebSocket 转发和中间层是否有额外缓冲。更推荐的方式是在服务端记录日志每个请求记录 TTFT、生成耗时、总 token 数、排队时间。排队时间一上来说明算力已经打满需要扩容或限流TTFT 高但排队时间低说明预填充阶段有性能瓶颈生成阶段慢则需要看显存带宽和解码优化配置。8. 常见问题与排查方法问题现象可能原因排查方式解决方案流式请求后第一个字要等很久输入 prompt 过长预填充耗时长服务端未开启前缀缓存查看 TTFT 指标对比短 prompt 和长 prompt 的差异开启 prefix caching精简历史消息或降低 max_model_len长文本生成越往后越慢KV Cache 持续增长显存带宽压力变大监控显存占用和每百 token 耗时变化控制 max_tokens分段生成或升级显存带宽更高的设备并发一上来单请求延迟暴涨服务端算力打满请求排队或 max_num_seqs 配置过大导致抢占查看服务端排队时间和 GPU 利用率扩容副本调整 max_num_seqs或对用户侧限流调用 API 报 token exchange failed / 401认证 token 过期、权限配置错误或把认证 token 与大模型 token 混淆检查请求头 Authorization、响应状态码和错误信息刷新认证 tokenJWT 场景实现续签机制不同 token 分开管理计费 token 与本地统计不一致tokenizer 差异或流式 chunk 数不等于真实 token 数使用模型对应 tokenizer 重新统计以服务端返回的 usage 字段为准本地值仅做参考输出质量下降量化过度或小模型能力不足用固定评测集对比不同部署方案降低量化级别或在不敏感场景使用小模型兜底9. 最佳实践与工程建议流式输出优先。几乎所有面向用户的大模型应用都应该设计为流式返回而不是等整个响应生成完再展示。即使模型速度已经很快流式输出也能降低用户的感知延迟并在长文本场景下提供更好的交互体验。性能测试要标准化。不要用一两个随便写的 prompt 判断“快不快”。建议准备一组固定 prompt覆盖短问答、中等长度列表、长文生成三类场景设置相同的 max_tokens每次跑 5 次取中位数。把测速脚本放进项目的 scripts 目录方便后续做回归对比。监控指标要分层。别只看一个 token/秒建议同时记录 TTFT、生成中位数延迟、P95 延迟、排队时间、GPU 利用率和系统总吞吐。单独一个数字很容易掩盖真正的瓶颈。成本控制要做在功能上线之前。速度提升后用户消耗 token 的速度也会变快。产品侧设置单用户配额、单请求 max_tokens 上限、成本告警。尤其要注意AI 应用在高峰期可能出现 token 消耗量突然上涨没有配额机制很容易失控。安全边界要守住。API Key 绝不能放在前端代码里一定要通过后端代理或转发服务调用大模型 API。服务端调用时注意认证 token 的管理JWT 场景做好续签与过期刷新避免因为认证失败导致用户侧看到 401 或 token exchange failed 这类错误。多模型回退策略值得提前设计。大模型擅长复杂推理但速度慢小模型速度快但质量一般。建议在应用中设置两个档位默认场景用速度更快的模型保证体验复杂任务自动切换大模型并提示用户需要稍等。这样既照顾实时感也保留质量上限。10. 总结与后续学习方向750 token/秒 成为常态本质上不是一个关于“AI 会有多聪明”的叙事而是一个关于“AI 能多快地出现在日常软件里”的工程叙事。它意味着模型能力不再只是被 benchmark 衡量而是被部署效率、推理成本和实时体验共同衡量。对应用开发者来说与其等待这个趋势自己到来不如现在就先把自己项目的 token/秒 基线测出来跑一次流式测速脚本统计一次并发吞吐看一眼服务端监控把 TTFT 和生成速度分开记录。这些动作做完你已经比很多只盯着模型排行榜的团队领先一步。后续值得继续深入的方向有几个一是推理引擎原理尤其是 continuous batching 和 PagedAttention 这类调度和显存优化机制二是模型量化理解 INT8、INT4 以及各类量化方法对质量和速度的影响三是流式协议与前端渲染的衔接思考在低延迟下如何重新设计交互四是成本治理把 token 计量、配额、告警做成一套工程能力。速度是 AI 应用最容易被感知的硬指标。希望这篇文章能帮你把 token 这个概念从“计费单位”升级为“产品设计工具”。如果你也在做 AI 应用建议把文中的测速脚本放到项目里跑一次用数据说话再决定下一步优化哪里。
750 token/秒：AI应用实时交互的入场券
做 AI 应用的开发者应该都遇到过这种尴尬模型能力明明很强产品体验却总差一口气。用户问一个 50 字的问题界面要悬停 1 秒多才开始吐字生成一篇 1000 字的文章前 300 字像挤牙膏一样一个字一个字蹦出来。很多团队把问题归结为“模型选错了”于是换更大的模型、加更复杂的提示词结果速度更慢。方向其实从一开始就偏了真正卡住体验的不是一个抽象的词“速度”而是一个可以被精确测量的数——token/秒。最近一个值得留意的趋势判断是Tibo 在谈 AI 未来时提出750 token/秒 将很快成为常态。这个数字如果真正落地意味着 AI 生成内容的速度会超过绝大多数人的阅读速度过去那种“盯着光标等 AI 打字”的体验会从很多产品里彻底消失。本文不打算做情绪化的未来预言而是从 token 的基本原理、推理优化的技术路径、以及开发者的工程实践三个层面把“750 token/秒”这件事拆开讲清楚它为什么重要、靠什么实现、现在做应用层的人应该提前做哪些准备。先说结论token/秒 不是模型能力的注脚而是 AI 应用能否进入“实时交互”时代的入场券。如果你正在做聊天机器人、Agent、写作助手或者任何需要流式输出的大模型应用这篇文章大概率能帮你少走几个月的弯路。1. 真正要解决的问题AI 应用的“实时感”从哪里来很多产品经理喜欢说“AI 要有实时感”但“实时感”不是一个目标函数而是一组可以被量化拆解的指标。拆到最后两个数决定了用户的体感第一个是首 token 延迟用户发出请求后到看见第一个字的时间第二个是生成速度也就是单位时间内模型能输出多少个 token。这两者常常被混为一谈其实对应的是两个完全不同的性能瓶颈。首 token 延迟高问题往往出在预填充阶段也就是系统把整段输入 prompt 计算成 KV Cache 的过程输入越长第一次等待越久。生成速度慢问题则出在自回归解码的每一个单步推理上每一步只能生成一个 token循环几百次才是一篇文章。很多做 AI 应用的团队把精力全部放在 prompt 优化和模型选型上却忘了这两个最底层的数字。这里要强调一个容易被忽视的事实同一个模型在不同推理框架、不同并发参数、不同量化级别下生成的 token/秒 可能差出好几倍。模型能力是“天花板”但开发者真正能影响的是“离天花板有多远”。所以理解 token/秒不是大模型算法工程师的专利而是所有调用 API、部署模型、设计交互的开发者都应该补上的基本功。2. token 是什么从开发视角理解这个计量单位2.1 通俗解释模型阅读文本的最小块token 是模型处理文本的最小基本单位可以理解成“切分后的碎片”。英文里“Hello”可能是一个 token也可能被切得更细“人工智能”在中文分词器下可能是一个或几个 token。不同模型使用不同的 tokenizer所以同样一句话在不同模型下的 token 数量会有差异。这个机制很像真实世界的语言习惯人类读书是按词理解模型读文本是靠这些碎片建立概率关系。token 越多模型要计算的关系就越复杂延迟和成本也随之上升。2.2 token 的三个角色对开发来说token 至少同时承担三个角色第一个角色是上下文窗口的计量单位。模型的 context length 是 32K 还是 128K说的就是它能容纳的 token 数量。第二个角色是 API 的计费单位。绝大多数大模型 API 按输入 token 和输出 token 分别计费服务端的 usage 字段会返回 prompt_tokens、completion_tokens 和 total_tokens。第三个角色是性能指标的分母。token/秒 的快慢直接决定了应用的等待时间。理解这三个角色就能解释很多开发中的困惑为什么长对话越来越慢因为输入侧的历史消息堆高了 prompt token预填充阶段要处理的内容变多。为什么一次请求比想象中贵因为一次检索增强生成可能同时消耗数千个输入 token而 token 计数是双向的。2.3 别把认证 token 和大模型 token 混为一谈这里必须单独提醒一个高频混乱点在登录鉴权、API 网关场景中也有一个 token比如 JWT、access token。它和本文讨论的大模型推理 token 完全是两回事。社区里经常看到两类截然不同的问题。一类是调用 API 时报 “token exchange failed” 或 401错误发生在身份认证阶段常见原因是 JWT 过期、权限配置不正确、请求头 Authorization 没有传对跟模型快慢无关。另一类是“token 用量怎么算”“为什么一次对话消耗这么多 token”这才是模型输入输出的计量问题。写代码时最忌讳把这两类 token 放在同一个变量、同一个缓存、同一套过期策略里管理。认证 token 的核心是安全过期与续签大模型 token 的核心是计费与速度统计。把两者分开建模后续排障会清爽很多。3. 750 token/秒为什么值得关注3.1 超过人类阅读速度意味着什么先给出一个直观参照。成年人正常阅读英文的速度大约是每分钟 200 到 300 词中文约每分钟 300 到 500 字。粗略估算一下1 个 token 约等于 0.75 个英文单词中文场景下一个汉字可能对应 0.6 到 1.5 个 token。750 token/秒 意味着 AI 每秒能生成数百个英文单词或者一眨眼生成几十个汉字这个速度远远超过了人类的自然阅读速度。换句话说当生成速度高于阅读速度时用户等 AI 输出的体感会发生质变。以前是“AI 在写我在等”以后会变成“我在读AI 永远跟得上”。这个转变看起来只是数值变化但它直接影响产品可以做什么能不能做逐字实时字幕、能不能做毫秒级响应的语音对话、能不能在几秒内批量产出几十篇摘要。3.2 从“等待生成”到“实时生成”所有流式 AI 产品都在跟一个隐含约束做斗争用户耐心有限。如果生成一篇 500 token 的回复在 50 token/秒 的模型下要等 10 秒在 750 token/秒 的模型下只需要 0.7 秒左右。这个差别的意义不只是“快一点”而是交互模式的改变。10 秒的等待必须做 loading 动画、中途打断、流式渲染甚至要想办法把长任务拆成多个短任务用状态机管理进度。0.7 秒的延迟则接近传统 API 请求的体感产品可以把 AI 能力嵌入到几乎任何流程里而不用专门设计“AI 正在思考”的用户提示。3.3 趋势判断不等于今天所有模型都达标需要保持清醒的是“750 token/秒 成为常态”更接近方向判断而不是当下所有模型都能达成的事实。不同规模的模型、不同的硬件条件、不同的量化方案实际 token/秒 差异非常大。参数量更大的模型往往更慢跑在消费级显卡上的模型和跑在高端推理集群上的模型也不在一个数量级。但从行业信号看速度竞赛已经是 AI 基础设施层最明确的方向之一。推理框架在优化吞吐和延迟芯片厂商在提升显存带宽模型架构也在向稀疏化和更高效的注意力机制演进。对应用开发者来说与其纠结“750 到底是多少天才到”不如先把自己的项目测清楚当前模型在什么速度下运行瓶颈在哪儿换一种部署方式或推理引擎能提升多少。4. 把速度推上去的几条技术路径4.1 模型架构优化大模型生成速度的瓶颈本质上集中在两个地方自回归的串行解码以及每生成一个新 token 都要读取和更新 KV Cache 带来的显存带宽压力。针对这些瓶颈模型架构层面出现了几个重要趋势。第一是 MLA 这类低秩压缩方法通过对 KV Cache 做压缩来减少显存占用支撑更大并发和更长上下文。第二是 MoE 架构它只激活全部参数的一小部分计算量比同参数的稠密模型小得多可以在不爆炸计算成本的前提下扩大模型规模。第三是各类注意力机制优化目标是减少长序列下的计算复杂度。4.2 推理引擎与调度优化同一份模型权重放到不同推理引擎里运行token/秒 表现有明显差别。这背后是调度策略的差异。最有代表性的思路是 continuous batching。传统部署方式等一个请求完整生成完再处理下一个请求continuous batching 则把多个请求的动态生成过程混合在一起调度谁先产出 token 谁先返回因为大模型每次生成的 token 长度不同这种动态拼车策略能大幅提升 GPU 利用率。另一个典型方向是 speculative decoding用一个小模型先草拟几段再由大模型一次性验证验证通过的部分相当于一步生成了多个 token有效突破自回归解码的步数限制。4.3 量化与硬件配合量化是另一个直接提升速度的手段。把模型从 FP16 压缩到 INT8 或 INT4显存占用变少单位时间内能计算的数据量变大单卡并发能力也会提升。代价是输出质量可能出现轻微下降尤其是小模型在复杂推理任务上会更敏感。硬件层面GPU 的显存带宽HBM bandwidth对 token/秒 影响极大因为自回归解码过程严重依赖高频读取权重和 KV Cache。这也是为什么高性能推理卡和消费级显卡的差异几乎无法只靠软件抹平。对大多数团队来说更实际的选择是先用开源推理框架和量化方案在现有卡上跑出最大吞吐再评估是否值得增加硬件投入。4.4 本地推理与云上推理的分化速度提升之后推理市场正在分化成两条路线。一条是云上高并发推理追求单卡吞吐最大化适合面向大量用户的产品另一条是端侧或私有化部署追求低延迟和数据不出域适合对隐私敏感的场景。端侧部署是否也能达到 750 token/秒 的级别取决于模型规模和硬件条件。小参数模型经过量化在部分高端设备上可以接近这个量级大模型仍然依赖云端。从材料看现阶段更稳妥的判断是750 token/秒 的常态会先在云端推理集群出现再逐步向下渗透。5. 高吞吐会重构哪些应用场景5.1 AI 写作与翻译当生成速度超过阅读速度写作助手的交互逻辑会完全改变。现在的产品为了减少等待会把长文拆成段落逐段生成甚至用“先生成标题再展开内容”的策略降低用户焦虑。速度上去以后产品可以一次性生成较长篇幅用户不再需要为生成过程设计太多进度反馈。翻译场景同理越快越接近同传而不是逐句转写。5.2 Agent 与多工具调用Agent 类应用对速度的敏感程度比普通对话更高。一个 Agent 执行复杂任务时可能要完成多次推理、工具调用、结果检查每次推理都是一次生成过程。如果单次生成要等 5 秒一个三步任务就要让用户等很久如果单次生成只要几百毫秒用户会觉得这个 Agent 是“顺手就把事办了”。从这个角度看750 token/秒 的意义不是让 AI 回答问题更快而是让 AI 有更充足的时间和算力去做更长的推理链。多步工具调用、自我修正、多候选方案对比这些特性只有在延迟足够低的时候才真正可用。5.3 实时语音与字幕语音交互对延迟极其敏感。传统的“语音转文字 → 大模型生成 → 文字转语音”如果每个环节都慢对话就变成了对讲机。生成速度提升后语音助手可以实现更低延迟的对话体验实时字幕和会议纪要也可以从“会后生成”变成“边说边出”。这类场景不仅要求 token/秒 高还要求首 token 延迟尤其低因为用户的耳朵等不了太久。做这类产品的团队建议把 TTFT首 token 延迟和 token/秒 两个指标都列入线上监控。5.4 批量离线处理批量处理场景里速度的收益直接体现在成本和时间上。比如一次性为几万条数据打标签、生成摘要或翻译模型吞吐越高完成时间越短单位时间能处理的请求越多。很多团队在跑离线任务时会专门用高吞吐推理引擎来降低单 token 成本因为离线任务对延迟不敏感但对总吞吐和资源利用率非常敏感。6. 不能只盯着 token/秒性能指标的四个侧面6.1 TTFT 与 TPS 都要看token/秒 衡量的是生成阶段的平均速度但用户感知到的延迟是首 token 延迟和生成速度的组合。一个简单估算公式是# estimate_wait_time.py def estimate_wait_time(output_tokens, tps, ttft0.3): return ttft output_tokens / tps # 在 50 token/s 下生成 300 token print(estimate_wait_time(300, 50)) # 6.3 秒 # 在 750 token/s 下生成 300 token print(estimate_wait_time(300, 750)) # 0.7 秒如果 TTFT 高到 2 秒即使模型生成速度到了 500 token/秒用户体感依然是“卡顿”。调优时把两个指标分开记录才能知道瓶颈是在预填充阶段还是解码阶段。6.2 单流速度与系统吞吐要区分单个请求的 token/秒 高不代表服务整体的吞吐高。一个推理服务同时处理 20 个请求时单请求速度可能下降但系统总吞吐所有请求的 token 数相加可能是单请求模式下的十几倍。面向用户的产品优先关心单个请求的延迟面向离线任务优先关心系统总吞吐面向复杂业务两者都要关注。测试时不要只看一个数字建议同时记录 P50、P95 单请求延迟和系统总吞吐。6.3 输出质量不能被速度绑架速度提升如果建立在过度量化或过度裁剪上输出质量会下滑。用户能接受慢一点得到一个准确答案但很难接受又快又胡说的结果。做技术选型时建议用固定的评测 prompt 集对比不同部署方案的生成质量不要只跑一个“你好”的演示。6.4 成本与配额token/秒 提升之后成本结构也在变化。同样的算力能支撑更多请求但用户也可能在更短时间内消耗更多 token。做应用层时需要在产品侧设计 token 配额、单用户限流和成本告警避免体验优化之后账单跟着失控。7. 工程实践测出并优化你项目的 token/秒7.1 先定义测速方法测速之前要定好变量固定一个输入 prompt固定输出的期望长度固定并发数跑多次取平均值。不要一边测速度一边调整提示词否则数据没有可比性。下面用一个 OpenAI 兼容接口的流式请求示例演示如何在实际项目中统计 TTFT 和生成速度。脚本里的关键点是通过 resp.iter_lines 逐行读取 SSE 数据遇到 content 字段就累加计数。# speed_check.py import json import time import requests API_URL https://your-endpoint/v1/chat/completions API_KEY your-api-key MODEL your-model-name payload { model: MODEL, messages: [ {role: user, content: 请用 500 字介绍分布式系统的基本概念。} ], stream: True, max_tokens: 800, } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } def main(): first_token_time None token_count 0 start time.time() with requests.post(API_URL, jsonpayload, headersheaders, streamTrue) as resp: if resp.status_code ! 200: print(请求失败:, resp.status_code, resp.text) return for line in resp.iter_lines(decode_unicodeTrue): if not line or not line.startswith(data:): continue data line[len(data:):].strip() if data [DONE]: break try: chunk json.loads(data) except json.JSONDecodeError: continue choices chunk.get(choices) or [] if not choices: continue delta choices[0].get(delta) or {} content delta.get(content) if not content: continue if first_token_time is None: first_token_time time.time() # 注意这是按流式返回的 chunk 数近似统计实际 token 数以服务端 usage 字段为准 token_count 1 end time.time() elapsed end - start ttft (first_token_time - start) if first_token_time else 0 generation_time end - first_token_time if first_token_time else elapsed print(f总耗时: {elapsed:.2f}s) print(f首 token 时间(TTFT): {ttft:.2f}s) print(f生成 token 数近似值: {token_count}) if generation_time 0: print(f生成速度: {token_count / generation_time:.2f} token/s) if __name__ __main__: main()运行方式python speed_check.py脚本输出的总耗时、TTFT 和 token/秒 就是当前 API 的体感基线。如果首 token 时间很长说明服务端预填充耗时高如果生成速度低于预期需要查看服务端推理引擎的部署参数。7.2 并发场景下看系统吞吐单请求速度只反映单路体验。生产环境通常要同时服务多个用户所以还需要看并发下的系统吞吐。下面是一个简化版并发测试脚本用 ThreadPoolExecutor 启动多个并发请求统计总耗时和系统级 token/秒。# concurrent_speed_test.py import concurrent.futures import time import requests API_URL https://your-endpoint/v1/chat/completions API_KEY your-api-key MODEL your-model-name PROMPT 用三句话解释什么是缓存。 HEADERS { Authorization: fBearer {API_KEY}, Content-Type: application/json, } def one_request(_): payload { model: MODEL, messages: [{role: user, content: PROMPT}], stream: False, max_tokens: 128, } t0 time.time() resp requests.post(API_URL, jsonpayload, headersHEADERS, timeout30) dt time.time() - t0 if resp.status_code ! 200: return {error: resp.status_code, elapsed: dt} data resp.json() token_count data.get(usage, {}).get(completion_tokens, 0) return {tokens: token_count, elapsed: dt} def main(): concurrency 5 total_requests 20 start time.time() with concurrent.futures.ThreadPoolExecutor(max_workersconcurrency) as pool: results list(pool.map(one_request, range(total_requests))) total_time time.time() - start completed [r for r in results if error not in r] failed total_requests - len(completed) total_tokens sum(r.get(tokens, 0) for r in completed) print(f并发数: {concurrency}, 请求数: {total_requests}) print(f成功: {len(completed)}, 失败: {failed}, 总耗时: {total_time:.2f}s) print(f总生成 token 数: {total_tokens}) if total_time 0: print(f系统吞吐: {total_tokens / total_time:.2f} token/s) if completed: avg_elapsed sum(r[elapsed] for r in completed) / len(completed) print(f单请求平均耗时: {avg_elapsed:.2f}s) if __name__ __main__: main()运行方式python concurrent_speed_test.py如果单请求速度高但并发后系统吞吐上不去优先检查服务端是否启用了 continuous batching、max_num_seqs 是否过小、显存是否足够。7.3 推理引擎部署参数调整如果你使用的是开源推理引擎比如 vLLM 风格的服务部署参数直接影响 token/秒 和系统吞吐。以下命令仅为示意具体参数名和版本有关请以你所用引擎的官方文档为准# 以 vLLM 风格示意的本地/内网部署参数 vllm serve your-model-name \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 32 \ --enable-prefix-caching \ --tensor-parallel-size 1几个关键参数的含义--max-model-len控制最大上下文长度。设得过大会占用大量显存压缩并发能力设得过小长输入会被截断。--max-num-seqs控制同时处理的序列数这是并发吞吐的核心参数。调大可能提高系统吞吐但也会增加单请求延迟。--enable-prefix-caching开启前缀缓存。对于多轮对话、固定系统提示词的场景可以减少重复预填充计算。--tensor-parallel-size控制多卡并行。单卡能容纳模型时可以先从 1 开始避免不必要的通信开销。7.4 如何判断瓶颈在服务端还是客户端如果速度不达标先做隔离判断。用命令行 curl 直接请求 API 并计时如果命令行请求也慢基本可以排除前端渲染和网络代理问题重点排查服务端推理引擎。如果命令行快、前端慢再检查流式解析、WebSocket 转发和中间层是否有额外缓冲。更推荐的方式是在服务端记录日志每个请求记录 TTFT、生成耗时、总 token 数、排队时间。排队时间一上来说明算力已经打满需要扩容或限流TTFT 高但排队时间低说明预填充阶段有性能瓶颈生成阶段慢则需要看显存带宽和解码优化配置。8. 常见问题与排查方法问题现象可能原因排查方式解决方案流式请求后第一个字要等很久输入 prompt 过长预填充耗时长服务端未开启前缀缓存查看 TTFT 指标对比短 prompt 和长 prompt 的差异开启 prefix caching精简历史消息或降低 max_model_len长文本生成越往后越慢KV Cache 持续增长显存带宽压力变大监控显存占用和每百 token 耗时变化控制 max_tokens分段生成或升级显存带宽更高的设备并发一上来单请求延迟暴涨服务端算力打满请求排队或 max_num_seqs 配置过大导致抢占查看服务端排队时间和 GPU 利用率扩容副本调整 max_num_seqs或对用户侧限流调用 API 报 token exchange failed / 401认证 token 过期、权限配置错误或把认证 token 与大模型 token 混淆检查请求头 Authorization、响应状态码和错误信息刷新认证 tokenJWT 场景实现续签机制不同 token 分开管理计费 token 与本地统计不一致tokenizer 差异或流式 chunk 数不等于真实 token 数使用模型对应 tokenizer 重新统计以服务端返回的 usage 字段为准本地值仅做参考输出质量下降量化过度或小模型能力不足用固定评测集对比不同部署方案降低量化级别或在不敏感场景使用小模型兜底9. 最佳实践与工程建议流式输出优先。几乎所有面向用户的大模型应用都应该设计为流式返回而不是等整个响应生成完再展示。即使模型速度已经很快流式输出也能降低用户的感知延迟并在长文本场景下提供更好的交互体验。性能测试要标准化。不要用一两个随便写的 prompt 判断“快不快”。建议准备一组固定 prompt覆盖短问答、中等长度列表、长文生成三类场景设置相同的 max_tokens每次跑 5 次取中位数。把测速脚本放进项目的 scripts 目录方便后续做回归对比。监控指标要分层。别只看一个 token/秒建议同时记录 TTFT、生成中位数延迟、P95 延迟、排队时间、GPU 利用率和系统总吞吐。单独一个数字很容易掩盖真正的瓶颈。成本控制要做在功能上线之前。速度提升后用户消耗 token 的速度也会变快。产品侧设置单用户配额、单请求 max_tokens 上限、成本告警。尤其要注意AI 应用在高峰期可能出现 token 消耗量突然上涨没有配额机制很容易失控。安全边界要守住。API Key 绝不能放在前端代码里一定要通过后端代理或转发服务调用大模型 API。服务端调用时注意认证 token 的管理JWT 场景做好续签与过期刷新避免因为认证失败导致用户侧看到 401 或 token exchange failed 这类错误。多模型回退策略值得提前设计。大模型擅长复杂推理但速度慢小模型速度快但质量一般。建议在应用中设置两个档位默认场景用速度更快的模型保证体验复杂任务自动切换大模型并提示用户需要稍等。这样既照顾实时感也保留质量上限。10. 总结与后续学习方向750 token/秒 成为常态本质上不是一个关于“AI 会有多聪明”的叙事而是一个关于“AI 能多快地出现在日常软件里”的工程叙事。它意味着模型能力不再只是被 benchmark 衡量而是被部署效率、推理成本和实时体验共同衡量。对应用开发者来说与其等待这个趋势自己到来不如现在就先把自己项目的 token/秒 基线测出来跑一次流式测速脚本统计一次并发吞吐看一眼服务端监控把 TTFT 和生成速度分开记录。这些动作做完你已经比很多只盯着模型排行榜的团队领先一步。后续值得继续深入的方向有几个一是推理引擎原理尤其是 continuous batching 和 PagedAttention 这类调度和显存优化机制二是模型量化理解 INT8、INT4 以及各类量化方法对质量和速度的影响三是流式协议与前端渲染的衔接思考在低延迟下如何重新设计交互四是成本治理把 token 计量、配额、告警做成一套工程能力。速度是 AI 应用最容易被感知的硬指标。希望这篇文章能帮你把 token 这个概念从“计费单位”升级为“产品设计工具”。如果你也在做 AI 应用建议把文中的测速脚本放到项目里跑一次用数据说话再决定下一步优化哪里。
