过去两年AI 圈讨论最多的是“模型能不能答对”而最近风向正在变化——越来越多的人开始追问“模型答得有多快”。如果你同时关注过大模型 API 的定价页面、Agent 项目的评测报告或者自己搭过开源模型的推理服务应该已经注意到一个高频数字750 token/秒。这个速度正在从“实验室跑分”走向“真实可用的部署指标”。这篇文章不打算只讲“token 是什么”这种基础概念而是想讲清楚一个更关键的问题当生成速度达到 750 token/秒之后AI 应用的形态会怎么变开发者的工作方式又会怎么变。同时我会给出可落地的测速方法、服务端优化方向以及在做 AI 应用时如何围绕 token 预算做工程决策。如果你是正在做 AI 应用、本地部署大模型或者在调研 Agent 方案的开发者这篇文章应该能帮你建立一个更完整的判断框架。1. 为什么“750 token/秒”值得关注先说结论750 token/秒 不是某一个模型的普通输出速度而是推理引擎、硬件调度和模型压缩共同作用后逐步逼近的行业常态。它的意义不在于“数字好看”而在于它把大模型从“可用的助手”推向了“可交互的基础设施”。我们做一个直观换算。750 token/秒 意味着一篇 1500 token 的技术博客初稿大约 2 秒内可以完整生成一段 2000 token 的代码文件流式输出时几乎感觉不到等待在 Agent 场景里模型每产生一轮思考或工具调用等待时间从“几十秒”压缩到“一两秒”。这个变化的影响面非常大。过去我们设计 AI 应用时默认模型输出是“慢操作”所以要加 loading、要设计异步任务、要把长文本生成做成后台任务。但当吞吐量达到 750 token/秒 后很多交互可以回归“同步操作”产品设计逻辑会随之改变。另一个被低估的点是成本结构。大模型 API 的计费单位是 token同样的硬件、同样的模型如果每秒生成的 token 数提升 3 倍意味着在相同预算下能服务的请求量也提升 3 倍。这也是为什么云厂商、开源社区、推理初创团队都在死磕“每 token 的延迟”和“单位时间的吞吐量”。不过要注意750 token/秒 是一个趋势判断不是一个保证值。真实能跑多快取决于模型大小、量化方式、GPU 型号、并发设置以及你是用流式输出还是非流式输出。后面文章会展开这些变量。2. token 是什么先厘清三个容易混淆的“token”在进入实操之前必须先把 token 这个概念讲透。因为如果你在网上搜索“token 失效”“token 授权失败”看到的绝大部分内容是 Web 登录场景里的 token那和大模型语境下的 token 完全是两回事。2.1 大模型 token文本切分的最小单位在大模型语境里token 是文本被模型处理的最小单元。它可以是一个单词的一部分、一个完整的单词也可以是中文里的一个汉字或一个词组。不同模型用不同的分词器Tokenizer所以同一段中文文本在不同模型里对应的 token 数量不一定相同。举个简单例子英文 “Hello world” 通常会被切成 2 到 3 个 token中文 “你好世界” 在不同分词器下可能是 4 到 8 个 token代码文本的 token 密度通常比自然语言更高因为符号、缩进、关键字都会占用 token。理解这一点很重要因为 token 数量直接决定了两件事API 费用和模型上下文窗口的使用量。你在设计提示词时写得越啰嗦消耗的 token 就越多输出越长等待时间也越长。2.2 别把 JWT、Access Token 和大模型 token 混为一谈网上大量出现“token exchange failed”“token 续签”“token 授权失败”等技术问题这些属于 API 认证、OAuth、JWT 的范畴它们和大模型生成文本时说的 token 只是同名没有直接关系。JWT / Access Token用于身份认证和权限控制是一段有结构、有有效期的字符串API Token / Secret Key用于调用开放平台接口时的身份凭证大模型 Token模型输入和输出的文本计量单位。如果你在开发 AI 应用时同时遇到两类问题比如“调用大模型 API 返回 401”和“生成速度慢”需要分别排查前者看认证凭证是否过期、地区限制、请求头是否正确后者看模型部署、显存、并发策略。这篇文章讨论的是后者也就是大模型的生成吞吐量。2.3 token 用量为什么是 AI 应用的关键指标从工程角度看token 用量是 AI 应用的“元指标”。它的意义类似传统后端里的 QPS、响应时间、数据库连接数但它更贴近业务成本每个请求消耗的 token 数 输入 token 输出 token输出 token 数越多用户等待时间越长成本越高上下文越长KV Cache 占用越多服务端并发能力越差。很多团队做 AI 应用的第一版时只关注“效果好不好”直到账单出来才开始复盘 token 消耗。但更成熟的团队会在设计阶段就引入 token 预算把它当成和内存、CPU 一样需要规划的资源。3. 推理速度为什么是 AI 应用的下一个分水岭可能有人会觉得“模型质量才最重要速度快一点慢一点有什么关系”但真实场景里推理速度会直接影响用户对模型能力的感知甚至会决定产品能不能做出来。3.1 从“模型能不能用”到“体验像不像人”在聊天场景中用户对延迟的容忍度其实很低。如果模型每句话都要思考 10 秒才回复即使内容质量很高用户也会觉得“卡”“笨”“不智能”。反过来当响应速度接近人类阅读速度时用户会下意识地把模型当成一个“正在思考的对话者”而不是一台“正在计算的机器”。750 token/秒 这个量级对于短回复场景意味着几乎无感延迟。假设用户问了一个问题模型需要输出 200 token 的回答按 750 token/秒计算生成时间不到 0.3 秒加上网络和首 token 延迟整体也就 1 秒左右。这种体验已经接近传统接口请求的感知。3.2 Agent 场景速度就是可用性Agent 类应用比聊天更依赖速度。一个复杂 Agent 任务通常要经历“规划 — 调用工具 — 观察结果 — 再规划”的多轮循环每一轮都要消耗几百到几千 token。如果模型输出速度只有 50 token/秒一个 5000 token 的任务会耗时 100 秒用户基本不可能盯着页面等但如果输出速度到 750 token/秒同样的任务耗时不到 7 秒虽然还没到“完全无感”但已经进入可接受范围。所以你会发现Agent 从原型到可用的过程很大一部分是在解决速度问题。这也是为什么开源社区和云厂商都在优化推理吞吐而不只是追求模型精度。3.3 流式输出与首 token 延迟除了总吞吐量还有两个指标也非常重要TTFTTime To First Token首 token 延迟和 ITLInter-Token Latency相邻 token 间隔。在实际用户体验中用户感受到的“快”更多来自首 token 延迟足够低。哪怕后文生成需要时间只要第一段文本快速出现用户的耐心就会大幅提升。流式输出Streaming正是基于这个心理机制设计的。当我们在讨论 750 token/秒 时通常指的是稳定输出阶段的吞吐量也就是 ITL 约等于 1.33 毫秒/token。这个阶段越快整体体验越好但首 token 的优化则更多依赖预处理、模型推理启动速度、显存读取效率。4. 吞吐量从哪里来硬件、推理引擎、模型优化不要以为 750 token/秒 是“白来的”。这个数字背后是整个推理栈的集体优化。4.1 硬件与批量调度GPU 不只是大还要用得满GPU 的算力很强但如果每次只处理一个请求大部分算力都在空转。推理引擎通过 Continuous Batching连续批处理技术把一个 GPU 上多个请求的 token 级别操作动态拼接到一起让 GPU 始终处于高利用率状态。这类优化直接带来的效果是在并发请求较多时总吞吐量可以接近线性提升。这也是为什么同一个模型用 vLLM、TensorRT-LLM 这类引擎部署吞吐量会比原生 PyTorch 高出一大截。4.2 模型侧优化更小的模型更快的速度模型参数量越大单次前向传播需要的计算量越高速度自然越慢。所以实践中经常通过以下方式提升生成速度量化将 FP16 权重压缩为 INT8 或 INT4减少显存占用和计算量蒸馏用大模型生成训练数据训练一个更小但能力接近的模型稀疏化与剪枝移除不重要的参数或计算路径投机采样用小模型先草拟多个 token再用大模型一次性验证节省大量推理时间。这些优化都可能让模型在相同硬件下的吞吐量翻倍甚至提升数倍。但同时也要注意量化可能会轻微影响输出质量具体需要结合评测集验证。4.3 部署侧优化从单卡到分布式单张 GPU 能承载的上下文长度和并发数有限。为了达到更高的吞吐量生产环境通常需要多卡推理、张量并行Tensor Parallelism、KV Cache 管理等技术。另外Prompt Cache提示词缓存也是一个容易被忽视的手段。如果大量请求的前缀提示词相同系统可以直接缓存对应的 KV Cache避免重复计算首 token 延迟和整体吞吐都会大幅改善。5. 开发者如何测出真实的 token/秒说了这么多真正动手的时候你需要一个可复现的测速方法。下面给出一个基于 OpenAI 兼容 API 的测速脚本适用于本地部署的 vLLM、FastLLM、或其他兼容 OpenAI 格式的服务。5.1 环境准备Python 3.9 以上OpenAI SDK 或 requests 库一个已部署好的 OpenAI 兼容 API 地址例如http://localhost:8000/v1。建议在虚拟环境中安装依赖python -m venv .venv source .venv/bin/activate # Windows 下为 .venv\Scripts\activate pip install openai5.2 最小测速脚本创建一个文件benchmark_speed.pyimport time import json from openai import OpenAI # 请根据你的实际服务地址和 API Key 修改 client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY, # 本地部署时常用占位符 ) prompt 请用 500 字介绍大模型推理优化的主要技术方向。 def measure_non_stream(): start time.time() response client.chat.completions.create( modelyour-model-name, messages[ {role: user, content: prompt} ], max_tokens1024, temperature0.7, streamFalse, ) elapsed time.time() - start content response.choices[0].message.content # 这里用字符数做粗略估算更准确的做法是调用 tokenizer print(f非流式模式总耗时: {elapsed:.2f}s) print(f输出字符数: {len(content)}) print(f预计每秒输出 token 数字符/4 粗略估算: {len(content) / 4 / elapsed:.2f}) if __name__ __main__: measure_non_stream()运行python benchmark_speed.py这里有一个常见误区如果使用len(content) / 4估算 token 数只有英文字符比较接近中文的 token 密度更高实际 token 数通常少于字符数除以 4。想得到精确 token 数需要使用模型对应的 Tokenizer。5.3 更准确的 token 数统计方式如果不方便直接调用 Tokenizer也可以让模型自己在回复中输出 token 消耗统计。更常见的做法是检查 API 返回的usage字段print(response.usage)在 OpenAI 兼容接口里usage通常包含prompt_tokens、completion_tokens、total_tokens。你需要统计的是completion_tokens。改成更精确的版本def measure_non_stream_precise(): start time.time() response client.chat.completions.create( modelyour-model-name, messages[{role: user, content: prompt}], max_tokens1024, temperature0.7, streamFalse, ) elapsed time.time() - start completion_tokens response.usage.completion_tokens print(f非流式模式总耗时: {elapsed:.2f}s) print(f生成 token 数: {completion_tokens}) print(f平均每秒 token 数: {completion_tokens / elapsed:.2f})这段代码依赖response.usage大部分 OpenAI 兼容服务都会返回该字段。如果服务端关闭了 usage 统计可能需要改服务端配置。5.4 流式输出测速流式输出会影响整体的 token/秒 数据因为客户端收到的是增量内容。测速脚本要单独记录总耗时和累计 token 数def measure_stream(): start time.time() stream client.chat.completions.create( modelyour-model-name, messages[{role: user, content: prompt}], max_tokens1024, temperature0.7, streamTrue, ) collected_chunks [] for chunk in stream: if chunk.choices[0].delta.content: collected_chunks.append(chunk.choices[0].delta.content) elapsed time.time() - start output_text .join(collected_chunks) # 用字符数做粗略估算 print(f流式输出总耗时: {elapsed:.2f}s) print(f输出字符数: {len(output_text)}) print(f预计每秒输出 token 数: {len(output_text) / 4 / elapsed:.2f})流式模式下response.usage在最终 chunk 里可能会返回但不同服务的实现差异较大建议以字符估算或使用 Tokenizer 为准。5.5 如何判断测速结果拿到实际的 token/秒 数字后建议和以下基准对比50–150 token/秒常规在线推理适合原型验证但长对话和 Agent 场景体验偏慢300–500 token/秒说明已经做了推理优化、量化或使用了高性能引擎体验明显提升750 token/秒 以上已经接近当前工程优化的第一梯队可以支撑实时交互和较高并发。如果你的速度远低于预期建议优先检查显存是否足够、请求是否串行、模型是否未开启批处理、量化精度是否过高、上下文长度是否过长。6. 如果把吞吐做到 750 token/秒 以上工程优化路径测出当前速度后下一步是优化。下面几条路径按投入产出比排序适合从“能跑”升级到“跑得快”。6.1 换用高性能推理引擎如果你还在用 Transformers 库直接调用模型生成吞吐大概率在几十到一百多 token/秒。换成 vLLM 或 TensorRT-LLM 后连续批处理和 PagedAttention 机制可以明显提升吞吐量。以 vLLM 为例一条启动命令大致长这样python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9这里需要提醒不同版本 vLLM 的参数可能略有变化请以官方文档为准。gpu-memory-utilization调得越高KV Cache 可用空间越大能支持的并发数和吞吐量越高但要预留系统显存余量避免 OOM。6.2 量化模型INT8 与 INT4量化是把模型权重从 FP16 降到 INT8 或 INT4代价是输出质量可能轻微下降。如果你对质量不是极度敏感量化通常能带来显著的速度提升。实际操作中可以先用 AWQ 或 GPTQ 量化后的模型权重再配合 vLLM 加载。例如python -m vllm.entrypoints.openai.api_server \ --model /path/to/awq-model \ --quantization awq \ --max-model-len 4096不同量化方案对模型效果影响不同建议在实际任务集上做质量对比不要只看速度指标。6.3 引入 Prompt Cache 与语义缓存如果应用有大量公共提示词前缀比如系统提示词特别长或者大量请求共享同一段背景材料务必确认推理服务是否支持 Prompt Cache 或 Prefix Caching。服务端 Prompt CachevLLM 等引擎会自动缓存相同前缀的 KV Cache应用层语义缓存对重复的问题直接返回上一次结果减少模型调用次数。这不仅能降低 token 消耗还能显著降低首 token 延迟对整体吞吐量的提升非常直接。6.4 控制输出长度与并发最后也是最容易被忽略的一点输出长度越长每请求耗时越高单位时间能处理的请求数越低。在实际产品里建议通过max_tokens限制输出长度并通过提示词让模型“简洁回答”而不是让模型自由发挥。同时生产环境要配置合理的并发数。并发过低会让 GPU 利用率不足并发过高会导致显存溢出和性能抖动。建议压测后找到最佳并发区间。# 用 curl 简单模拟一次请求观察响应时间 curl -N http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: your-model-name, messages: [{role: user, content: 你好}], max_tokens: 100, stream: true }-N参数代表禁用 curl 缓冲适合观察流式输出的实时效果。7. 常见问题与排查思路在测速和部署过程中以下几个问题出现频率最高。问题现象可能原因排查方式解决方案token/秒 远低于预期未使用高性能推理引擎或用纯 PyTorch 逐请求推理检查请求日志和 GPU 利用率改用 vLLM、TensorRT-LLM 等引擎显存不足CUDA OOM并发数过高、KV Cache 占用过多查看nvidia-smi显存使用情况降低gpu-memory-utilization调低并发或换用更小模型流式首 token 很慢上下文过长、Prompt Cache 未生效观察 TTFT 指标开启 Prefix Caching精简系统提示词usage 字段没有返回 token 数服务端关闭了 usage 统计查看服务端日志和配置开启 usage 统计或改用 Tokenizer 本地统计相同模型在不同环境速度差异大GPU 型号、显存带宽、引擎版本不同记录环境和版本信息同环境对比保留部署配置量化后输出质量下降明显量化精度低或量化感知训练不足做人工评测和 BLEU/ROUGE 对比换用更高精度量化或仅为部分层量化值得单独说明的是网络热词里反复出现“token exchange failed”、invalid token、token 授权失败等关键词。这些都是认证 token 或 OAuth token的问题通常和本文讨论的大模型生成 token 无关。如果你遇到token endpoint returned status 403 forbidden需要检查地区限制、API Key 权限、网络出口等因素和模型的 token/秒 没有关系。在设计文章时别把这两类问题混入同一个排查链路。8. 最佳实践AI 应用中的 token 预算与体验设计当推理速度提升后新的工程问题也随之而来你要怎么用这 750 token/秒8.1 提前设计 token 预算在开发 AI 应用时建议在需求文档里就写清楚单次请求的 token 消耗范围。可以把提示词模板、系统提示词、历史消息长度都纳入预算范围。例如一个常见的设计{ system_prompt: 你是智能客服助手请用简洁中文回答用户问题。, max_input_tokens: 2048, max_output_tokens: 512, temperature: 0.3, history_limit: 10 }这样设计的好处是每个请求都能估算成本也能预判最差延迟。8.2 流式输出是默认方案不是加分项现在很多成熟 AI 产品都默认开启流式输出因为用户的耐心比想象中更差。即使吞吐量足够高流式输出依然能避免“用户盯着光标转圈”的焦虑感。流式输出在设计上有几个注意点前端要处理增量文本而不是等全部返回后再渲染后端要支持断开连接时终止生成避免浪费 token要记录首 token 耗时作为性能监控指标。8.3 并发控制与降级策略当吞吐量提升后业务层容易忽略并发控制。真实的生成场景比普通 API 更容易被打爆因为单个请求占用的时间和显存远超普通接口。建议在 AI 应用前增加一层限流比如令牌桶或信号量控制。当服务端负载过高时可以让模型回答更短、返回缓存结果或者提示用户稍后再试。不要等到 GPU 被打满才处理。8.4 日志与监控关键指标一个都不能少生产环境中除了常规的 QPS、错误率AI 应用还需要监控以下指标平均输出 token/秒首 token 延迟TTFT平均请求耗时token 总消耗量按事件或流程维度的成本分布。这些指标能帮你快速定位问题比如某个 Agent 工作流突然变慢可能是因为某轮对话引入了大量上下文导致 KV Cache 压力增大、吞吐下降。8.5 模型与业务解耦最后一条建议偏架构尽量通过 OpenAI 兼容接口接入模型服务让业务层不感知底层模型切换。这样当更快的模型或更好的推理引擎出现时你可以随时替换而不需要变更业务代码。这也是当前众多开源推理服务选择兼容 OpenAI API 格式的原因。对于开发团队来说用一个标准的base_urlapi_key模式接入所有模型服务能省掉大量适配成本。9. 总结与后续学习方向回到文章开头的问题750 token/秒 会常态化的判断背后其实是推理栈的整体进步。它意味着大模型生成不再是一个“慢操作”而更像是普通后端接口的性能指标。当这个前提成立后AI 应用的产品设计、成本模型和系统架构都会发生连锁变化。对开发者来说值得做的三件事很明确第一学会测速。写一个 token/秒 的基准脚本跑通自己的模型知道自己当前的真实吞吐量。没有这个数字后续所有优化都无从谈起。第二关注推理引擎和模型压缩技术。vLLM、TensorRT-LLM、AWQ、投机采样这些工具实际带来的速度提升远超想象。但不要盲目追求“最顶尖方案”要结合自己的硬件、模型和业务场景做取舍。第三把 token 当成一种资源来管理。无论是成本预算、限流策略、日志监控还是 Prompt 设计每个环节都应该有 token 消耗的视角。下一步你可以从本地部署一个小参数模型开始用文章里的脚本跑一遍再尝试换更高效的推理引擎观察 token/秒 的变化。也可以在自己正在做的应用中引入流式输出和 token 预算设计一步步把“模型能跑”升级为“服务能用”。如果这篇文章对你有帮助建议收藏备用等实际部署时再看一遍。