每秒1.4万token，大模型推理速度的工程解密

你上一次因为模型回答太慢在演示现场翻车是什么时候这不是段子。很多技术团队在选大模型时把注意力全放在参数量、上下文长度和跑分上结果真正上线之后最先被用户骂的往往是同一个问题太慢了。模型效果差一点还能接受回答要等十秒二十秒产品基本没法用。所以当 Taalas 这个项目把推理速度做到每秒 1.4 万 token 的消息传出来时圈内人的反应很分化有人觉得是营销数字有人当成未来方向也有不少人根本不知道这个数字意味着什么。这篇文章不打算复述新闻稿而是想从工程视角拆清楚三件事第一每秒 1.4 万 token 到底是什么水平第二推理速度为什么是比参数量更值得关注的生产指标第三开发者如何自己动手测量推理速度避免被一个漂亮数字牵着走。1. 关于“每秒 1.4 万 token”的正确打开方式首先要明确一个口径问题。大模型领域的推理速度至少有三种常见含义单条请求的生成速度也就是解码速度单条请求端到端的每秒 token 数包含处理输入的时间N 个并发请求的聚合吞吐看整个服务单位时间能输出多少 token。这三种口径算出来的数字可以差出几十倍。如果 Taalas 的 1.4 万 token/s 是单条请求的生成速度那是一个相当夸张的量级因为当前主流消费级 GPU 上单流解码速度通常只有每秒几十到几百 token数据中心显卡叠加各种优化后单流也很难破千。如果它指的是并发聚合吞吐那同样是高水平说明系统能把一批用户请求压进显存通过连续批处理、显存管理等手段把 GPU 利用率拉满。当前公开信息里我倾向于先不把“单流还是聚合”这个口径定死而是把这个数字放进一个参照系里看场景大致量级普通用户对“流畅打字机”的感知每秒 10-20 token单张消费级显卡本地推理每秒 20-80 tokenA100/H100 上生产级推理框架的聚合吞吐每秒几千 token1.4 万 token/s无论哪个口径都已远超“够用”这个数字最值得在意的不是“谁家更快”而是它传递了一个信号当模型本身的效果不再成为瓶颈推理速度会直接决定一个 AI 产品能承载多大的用户量、多长的上下文、多复杂的 Agent 任务链。这才是开发者在 2025 年应该重新审视推理性能的原因。2. token 到底是什么为什么它决定推理成本2.1 token 是模型眼中的“最小文字单元”大模型并不是按字符理解文本的而是先通过 tokenizer 把文本切成一个个 token。英文里一个常见单词可能是一个 token中文里一个字、一个常用词、一个标点符号都可能占一到两个 token。举个例子在多数中英文 tokenizer 下from transformers import AutoTokenizer tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-7B-Instruct) text 大模型推理速度为什么重要 tokens tokenizer.encode(text) print(切分结果, tokens) print(token 数量, len(tokens))输出 token 数量大致在 8 到 12 之间具体取决于 tokenizer 词表。这不是一个需要背下来的数字但你要形成一个直觉用户看到的一句话在模型内部会被放大成若干 token而每个 token 都对应一次计算。2.2 token 数量约等于算力成本和等待时间大模型生成回答时每个 token 都要经过一次前向计算同时还需要读取已有的 KV cache 和完整的模型参数。所以 token 数量越多耗时越长账单越高。API 厂商按 token 计费本质上就是在按“模型算力消耗”计费。这也是为什么热词里会出现“2500 credits 相当于多少 token”“token 消耗计算方式”这类搜索。很多开发者在实际项目里遇到的第一道坎不是模型不会回答问题而是预算和延迟都跟 token 量挂钩。理解 token才算真正理解大模型服务的成本模型。2.3 不要和登录鉴权的 token 混为一谈还有一个常见误区值得单独说。很多人在配置 API 登录、Git 仓库、第三方平台时看到 “token exchange failed”“access token could not be refreshed” 这类报错会误以为跟模型计费的 token 有关。其实完全不是一回事类型AI 计费 token鉴权 token含义文本被 tokenizer 切分后的最小单元访问受保护资源用的凭证典型形态一个词、一个字、一个片段一串加密字符串、JWT、OAuth Token常见报错context length exceeded、output token limittoken exchange failed、401 Unauthorized跟钱的关系按数量计费直接决定成本通常不按量计费只控制访问权限很多工程师排查半天最后发现是把两种 token 概念混在一起了。大模型布道和实际开发中这是一个非常高频的混淆点。3. 衡量推理速度不能只看一个数字3.1 三个指标分别回答了不同问题如果只用一个“每秒 token 数”去衡量所有项目很容易做出错误判断。生产环境中至少要看三个指标TTFT指从发出请求到收到第一个 token 的耗时。对应的是用户“点一下发送多久开始出现第一个字”直接影响对话产品的主观体验。生成阶段的 token/s指模型进入稳定输出后的速度。它决定了整段回复要等多久。聚合吞吐指服务在并发请求下单位时间输出的总 token 数。它决定了这套服务能支撑多少用户、多少任务。用餐厅来类比TTFT 是“下单到第一道菜上桌”的时间生成速度是“后续上菜快不快”聚合吞吐是“这家店同时能服务多少桌”。如果只宣传“每秒出菜量很高”那可能是几十桌加起来的结果单独一桌照样等得着急。3.2 不同业务场景要优先优化不同指标指标回答的问题典型应用TTFT反应快不快实时对话、Agent 工具调用、搜索引擎摘要生成 token/s一段回复要等多久长文本生成、文章续写、代码补全聚合吞吐服务能支撑多少并发B 端 API 服务、批量离线任务、内容批量生成做聊天机器人TTFT 差可能比生成速度差更致命做离线批处理单流速度就不重要聚合吞吐才是核心做 Agent 链路每次工具调用都可能产生多轮请求TTFT、生成速度、吞吐三者都要看。如果 Taalas 的 1.4 万 token/s 是聚合吞吐那背后的关键能力其实是调度和显存管理而不是单次生成变快了多少。4. 1.4 万 token/s 背后的技术优化路线由于 Taalas 的具体架构信息有限这里不展开断言它的实现方式但从大模型推理优化的通用路线已经能看出“每秒万级 token”是怎么实现的。这些东西也直接回答了“如何提高 Ollama/vLLM 等框架的推理生成速度”这个灵魂问题。4.1 Prefill 和 Decoding两个阶段分开优化大模型生成分两个阶段。第一个阶段叫 Prefill把用户输入的 token 一次并行计算生成 KV cache。这个阶段计算密集输入越长耗时越长直接决定了 TTFT。第二个阶段叫 Decoding逐个 token 输出。每个 token 的计算量不大但需要反复读取模型参数和 KV cache因此通常受显存带宽限制而不是算力限制。很多框架的优化核心就是让 Decoding 阶段尽量少读数据、多批量计算。4.2 KV Cache 与显存换速度KV Cache 的本质是缓存历史 token 的 Key 和 Value 向量避免每生成一个新 token 就重算整段历史。缓存命中后生成速度会明显提升缓存失效或超长上下文时显存占用和计算量都会指数上涨。这也是“服务器内存和推理卡之间的影响”这类问题的核心KV cache 用量大的时候如果显存不足有些实现会把缓存换到内存中速度会断崖式下跌。推理卡的显存容量和带宽往往比算力更能决定实际体验。4.3 量化把参数从 16 位压到 8 位或 4 位把 FP16 模型量化成 INT8 或 INT4参数的显存占用和读取量都会下降Decoding 速度可以大幅提升。代价是精度损失对某些任务可能不明显对代码生成、数学推理等任务则可能造成明显回退。所以量化不是无脑开启通常要在自己的评测集上跑一遍对比。4.4 投机采样 / 推测解码用小模型加速大模型这是目前把单流生成速度推到几千 token/s 以上的主流技术路线之一。思路是先让一个小模型快速生成 D 个候选 token再把这个候选序列交给大模型一次性验证。如果候选正确一次前向计算就能产出多个 token如果失败再用正确 token 重新继续。由于小模型速度快整体效果大多数时候接近大模型收益却非常可观。Taalas 如果真的做到单流每秒 1.4 万 token推测解码大概率是核心手段之一。4.5 连续批处理与推理框架传统做法是等一批请求全部结束后再进入下一批遇到慢请求整个 batch 都要等。Continuous Batching 则让每个请求在每一轮都独立决定继续生成还是结束GPU 空闲位置立即被新请求填满聚合吞吐因此大幅提升。vLLM 的 PagedAttention、NVIDIA TensorRT-LLM、Ollama 的后端优化都在这个方向上做文章。如果想把推理框架作为学习路线的一部分优先理解 Continuous Batching、KV Cache、量化、投机采样四条线就够了。5. 完整示例用代码亲手测量推理速度看再多的概念都不如把测速脚本跑一遍来得直观。下面假设你已经有一个 OpenAI 兼容的本地推理服务。5.1 准备一个 OpenAI 兼容的推理服务如果是 vLLM一条命令就能启动vllm serve Qwen/Qwen2.5-7B-Instruct --served-model-name my-model如果用的是 Ollama也可以用ollama run qwen2.5:7b本文以下的脚本假设服务监听在http://localhost:8000协议为 OpenAI 兼容格式使用的是/v1/completions接口。不同推理框架的兼容层可能有细微差异具体以实际启动日志为准。5.2 单请求延迟与生成速度测试# 文件measure_latency.py import json import time import requests from transformers import AutoTokenizer BASE_URL http://localhost:8000/v1/completions MODEL my-model # 这里请替换成与服务端模型相近的 tokenizer如果无法联网可以改为本地模型路径 tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-7B-Instruct) def run_measure(prompt: str, max_tokens: int 200): payload { model: MODEL, prompt: prompt, max_tokens: max_tokens, stream: True, temperature: 0.0, } t0 time.time() first_token_time None output_text with requests.post(BASE_URL, jsonpayload, streamTrue, timeout120) as resp: resp.raise_for_status() for line in resp.iter_lines(): if not line: continue line line.decode(utf-8, errorsignore) if not line.startswith(data: ): continue data line[6:] if data.strip() [DONE]: break try: obj json.loads(data) except json.JSONDecodeError: continue # /v1/completions 使用 choices[0].text # 如果是 /v1/chat/completions需要改为 choices[0].delta[content] delta_text obj.get(choices, [{}])[0].get(text, ) if delta_text: if first_token_time is None: first_token_time time.time() output_text delta_text total_time time.time() - t0 output_tokens len(tokenizer.encode(output_text)) if output_text else 0 ttft first_token_time - t0 if first_token_time else None decode_time max(total_time - ttft, 1e-6) return { ttft_s: ttft, total_time_s: total_time, output_tokens: output_tokens, decode_tokens_per_s: output_tokens / decode_time, } if __name__ __main__: result run_measure(请用一段话介绍大模型推理优化的主要手段。) print(result)这段脚本做了三件事以流式方式接收输出记录第一个 token 到达的时刻从而算出 TTFT拼接全部输出文本然后用 tokenizer 统计真实的输出 token 数避免“按逗号或空格估算”带来的误差用输出 token 数除以生成阶段耗时得到解码速度。如果服务使用的是/v1/chat/completions只需要把响应体里的choices[0].text换成choices[0][delta][content]其他逻辑完全一致。5.3 并发吞吐测试# 文件throughput_test.py import time from concurrent.futures import ThreadPoolExecutor import requests BASE_URL http://localhost:8000/v1/completions MODEL my-model PROMPT 请用一段话介绍大模型推理优化的主要手段。 MAX_TOKENS 128 CONCURRENCY 8 REQUESTS 16 def single_request(_): payload { model: MODEL, prompt: PROMPT, max_tokens: MAX_TOKENS, stream: False, temperature: 0.0, } start time.time() resp requests.post(BASE_URL, jsonpayload, timeout120) resp.raise_for_status() data resp.json() text data[choices][0][text] # 为保持脚本简短这里用空格粗略估算 token 数。 # 更准确的统计请使用 AutoTokenizer 对 text 重新编码。 token_count len(text.split()) return token_count, time.time() - start if __name__ __main__: t0 time.time() with ThreadPoolExecutor(max_workersCONCURRENCY) as pool: results list(pool.map(single_request, range(REQUESTS))) total_time time.time() - t0 total_tokens sum(r[0] for r in results) print(f请求数: {REQUESTS}) print(f总耗时: {total_time:.2f}s) print(f聚合吞吐: {total_tokens / total_time:.2f} tokens/s)注意并发压测会给推理服务带来真实负载建议只在测试环境或自己可控的服务上运行不要直接压在线上核心服务上。5.4 运行结果与验证上面脚本可能的输出请求数: 16 总耗时: 4.52s 聚合吞吐: 453.10 tokens/s这个数字是示例不是标准答案。你更应关注的是结果是否稳定如果多次运行聚合吞吐忽高忽低说明服务端存在排队或显存抖动如果 TTFT 一直偏高说明 prefill 阶段或网络链路有瓶颈。6. 常见问题与排查思路问题现象可能原因排查方式解决方案自测速度远低于宣传值统计口径不一致网络开销未扣除区分 TTFT 与生成阶段 token/s本机压测统一指标后再对比不要拿单流速度和聚合吞吐比TTFT 偏高输入 prompt 过长prefill 阶段耗时大打印服务端耗时观察输入 token 数缩短上下文使用 prompt cache / prefix cache并发一提升单请求明显变慢GPU 显存饱和或请求排队观察显存利用率、P50/P95 延迟限制并发降低 max_tokens必要时水平扩容服务端数字正常但用户觉得卡客户端没有使用流式输出或网络链路慢抓包看首字节时间开启 stream 流式返回缩短网络路径输出被截断max_tokens 设置过小或结果提前中断查看 finish_reason 是否为 length调大 max_tokens优化生成策略鉴权 token 报错把模型计费 token 与 API 访问凭证混淆检查 API key、endpoint、权限配置使用正确的访问凭证查看服务端鉴权日志显存 OOM并发太高KV cache 超限nvidia-smi 查看显存降低并发、启用量化、限制 max_model_len7. 工程选型与性能优化最佳实践7.1 先明确业务场景再定性能指标不要上来就追求“每秒多少 token”。如果是智能客服TTFT 比生成速度更重要如果是批量生成文案聚合吞吐才是关键如果是代码补全端到端延迟直接决定用户是否愿意用。先把指标优先级列出来再看对应的优化手段顺序不能反。7.2 建立一份可重复的基准测试脚本性能优化最怕“感觉变快了”。建议把前文的测速脚本固化到仓库里按周或按月跑一次记录 TTFT、生成速度、聚合吞吐、P50/P95 延迟等数据。这样每次换框架、调量化、加并发都能用数据说话。7.3 流式输出是性价比最高的优化在客户端开启流式接收首字到达时间不变但用户体感会明显好很多。很多团队在服务端优化很久最后发现把 stream 打开就已经解决了一半体验问题。7.4 量化与缓存要放在评测之后INT4 能显著提高推理速度但也可能让模型在专业任务上变笨。正确的做法是准备好评测集分别跑 FP16、INT8、INT4 三个版本比较效果和延迟之后再决定是否上线。对于长对话场景prefix cache 和 KV cache 复用往往能省下大量 prefill 时间收益比单纯换加速框架更明显。7.5 不要只盯着每秒 token 数还要算成本大模型选型最终要看“单位成本能产出多少可用 token”。同样 1.4 万 token/s跑在 4 卡还是 8 卡单位成本完全不同。把 credits、API 价格、算力租赁成本都换算成“每百万 token 多少钱”比单纯比较峰值速度可靠得多。7.6 注意显存带宽比算力更重要解码阶段主要瓶颈不是算力而是从显存读取参数的速度。这也是为什么服务器内存会影响推理卡效果如果 KV cache 被换到普通内存速度会断崖式下降。选型时显卡的显存带宽、显存容量比峰值算力更值得关注。8. 总结与下一步回到开头的问题当推理速度达到每秒 1.4 万 token它改变的不只是响应时间而是产品可以承载的交互密度。以前一个 Agent 任务链要跑几分钟现在可能几十秒完成以前批量处理上千篇文章要等很久现在等待时间被压缩到可以放进实时流程。1.4 万 token/s 本身是别人的成绩但把这套判断、测量、优化方法迁移到自己的项目里才是工程师能真正落地的收获。下一步建议做三件事第一搭一个本地推理服务跑一遍上文的三份脚本先把“快慢”变成数字第二在团队里统一 TTFT、生成速度、吞吐三个指标的口径再做框架选型第三重点关注量化、推测解码、KV Cache 和连续批处理这几个方向它们才是把 token/s 从几百推向几千上万的关键技术。当“模型会回答”已经不再是核心竞争力“回答得足够快、足够便宜”才是 AI 产品进入生产环境的分水岭。