看到 Taalas 展示的每秒 1.4 万 token 推理速度后不少开发者开始重新审视大模型推理性能的边界。这个数字乍看不太直观但稍微换算一下如果按英文文本约 1 个 token 对应 0.75 个单词估算一秒钟就能生成接近一万个英文单词相当于 20 页左右的英文文档如果按中文约 1 个 token 对应 0.6 到 0.7 个汉字估算一秒钟也在 8000 汉字以上。放在过去“一个字一个字往外蹦”的生成式大模型上这几乎是科幻级别。不过比“跑得快”更值得讨论的是这个速度是怎么测出来的token 到底是什么为什么大家都用 token 而不是字数来评价推理性能我们自己的模型服务离这个量级还有多远中间卡在哪些环节这篇文章围绕这几个问题展开会从 token 基础概念讲起拆解推理速度指标再结合 vLLM、Ollama 等主流推理框架给出可复现的测速与优化方法最后整理高频报错和工程建议。适合正在做模型部署、推理优化或者刚开始接触大模型应用开发的读者。1. 为什么推理速度成了大模型落地的关键指标1.1 训练快不如推理稳很多刚接触大模型的同学会把注意力放在“模型参数量有多大”“训练用了多少张卡”上但在实际业务场景中推理阶段的性能往往才是决定项目能不能上线的关键。训练是离线任务跑几小时甚至几天都可以接受推理却是实时任务用户在对话界面等回复接口在压测下要保证不超时批量任务在有限算力下要尽快跑完。同一个 7B 模型用不同框架部署、不同量化精度、不同并发配置延迟和吞吐可能差出好几倍。推理速度直接影响用户体验、服务器成本和可支撑的业务规模。1.2 每秒 1.4 万 token 是什么概念以 1.4 万 token/s 为例对这个数字建立一个直觉很重要。如果生成一篇 1000 token 的短文耗时不到 0.1 秒。如果处理一本 10 万字的小说约 8 万到 12 万 token大约 6 到 10 秒可以完成全文生成。在流式输出场景中用户几乎感觉不到“逐字输出”的等待体验接近搜索响应的即时性。这也是为什么像 Taalas 这类推理加速方案公布速度数据时会引起关注。它代表的不只是一个框架的优化成绩而是说明大模型推理在特定硬件和工程组合下已经可以逼近过去专用模型才有的处理速度。1.3 推理速度不是单一指标这里要先打一个预防针不要看到“每秒 1.4 万 token”就直接和某个框架或某张显卡画等号。推理速度受批量大小、输入长度、输出长度、量化方式、硬件型号、并发策略影响非常大。同一套系统在 batch size 为 1 的流式对话场景和 batch size 为 32 的离线批量生成场景里测出来的单用户 token 吞吐完全不同。所以理解这个数字时要同时问清楚测的是单请求延迟还是服务端总吞吐是短文本还是长文本2. 先搞懂 token大模型计算的基本单位2.1 token 是什么token 是大模型处理文本的最小单位。你可以把它理解成模型眼中的“词元”或“片段”。比如英文单词unbelievable模型不一定会把它当作一个整体而可能拆成un、believ、able三个 token。中文“深度学习”可能被拆成“深”、“度”、“学”、“习”四个 token也可能被拆成“深度”、“学习”两个 token具体取决于分词器。专业一点说token 是分词器Tokenizer对原始文本进行切分后的结果。大模型在训练和推理时看到的不是字符串而是一串 token id。模型本质上是在预测“下一个 token 是什么”而不是“下一个字/单词是什么”。2.2 为什么要用 token 而不是字数主要有三个原因。第一模型的计算量和上下文长度都以 token 为计量单位。Transformer 的自注意力机制复杂度与序列长度的平方相关这里的序列长度就是 token 数。第二不同语言、不同写法下token 和字符的换算比例不稳定。英文一个单词平均约 1.3 个 token中文一个汉字约 0.6 到 1 个 token同一个句子在不同分词器下 token 数也可能不同。直接用字数统计会失真。第三模型服务的计费、限流、上下文窗口限制都以 token 为基准。在调用 OpenAI、智谱等平台的 API 时费用按 token 计算在本地部署时显存占用也和上下文 token 数直接相关。2.3 用代码计算 token 数量在实际开发中我们需要在发送请求前估算 token 用量避免超出上下文限制。最准确的方式是使用模型对应的 tokenizer。下面以 HuggingFace 的 transformers 库为例# requirements: transformers4.40 # 文件路径count_tokens.py from transformers import AutoTokenizer # 这里以 Qwen2.5 7B 为例实际使用时换成你部署的模型 model_name Qwen/Qwen2.5-7B-Instruct tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) text 大模型推理速度是落地的关键指标token 是计算的基本单位。 tokens tokenizer.tokenize(text) token_ids tokenizer.encode(text) print(f原始文本: {text}) print(fToken 列表: {tokens}) print(fToken ID: {token_ids}) print(fToken 数量: {len(token_ids)})运行后可以看到中文文本并不是每个字固定对应一个 token而是由分词器根据词表决定。这个结果在不同模型之间会有差异所以不要用“一个汉字等于一个 token”这种粗略规则做精确预算而是直接用 tokenizer 算。2.4 token 与字符数、API credit 的换算关系不少平台在控制台里同时展示 token 和 credit积分但换算关系并不统一。有的平台 1 credit 等于 1 token有的平台按照模型等级设置不同倍率还有的会用固定字符数折算。遇到“2500 credits 相当于多少 token”这类问题时最可靠的做法是查看对应平台的计费文档而不是套用某个固定公式。在自建服务中我们也不应该根据字符数预估显存和上下文而应该用 tokenizer 在你选定的 prompt 模板上跑一遍完整文本。3. 推理速度指标token/s 是怎么算出来的3.1 首 token 延迟与生成速度衡量大模型推理性能最常用的两个指标是TTFTTime To First Token从发起请求到收到第一个 token 的时间。TPSTokens Per Second稳定生成阶段每秒产生的 token 数也叫生成速度。TTFT 影响“用户多久看到第一个字”TPS 影响“整段回答多久完整结束”。在流式输出场景中用户最先感受到的是 TTFT在离线批量生成中TPS 更关键。3.2 预填充阶段与解码阶段大模型推理在时间上分为两个阶段。预填充阶段Prefill用户输入的 prompt 一次性进入模型并行计算所有输入 token 的注意力结果。这个阶段对算力要求高但可以被并行加速。解码阶段Decode模型逐个生成新 token每生成一个 token 就依赖前面所有 token 的计算结果串行程度高。这也是大家常说生成式推理“慢”的主要原因——不是一个一个并发出词而是生成序列本身是逐步展开的。衡量“每秒 1.4 万 token”时需要明确它覆盖了哪个阶段。如果只是预填充阶段的吞吐和完整生成全过程的体验差异会非常大如果是完整生成阶段摊平后的速度参考价值更高。3.3 用 Python 写一个简易测速脚本下面这段脚本调用一个兼容 OpenAI API 的本地推理服务并统计生成速度和 token 数# 文件路径benchmark.py # 依赖pip install openai transformers import time from openai import OpenAI from transformers import AutoTokenizer # 修改为你的服务地址与模型名 BASE_URL http://localhost:8000/v1 MODEL_NAME Qwen/Qwen2.5-7B-Instruct API_KEY EMPTY client OpenAI(base_urlBASE_URL, api_keyAPI_KEY) tokenizer AutoTokenizer.from_pretrained(MODEL_NAME, trust_remote_codeTrue) prompt 请用 500 字左右介绍大模型推理加速的基本思路。 messages [{role: user, content: prompt}] start time.time() response client.chat.completions.create( modelMODEL_NAME, messagesmessages, streamTrue, max_tokens1024, ) output_text for chunk in response: delta chunk.choices[0].delta.content if delta: output_text delta elapsed time.time() - start output_tokens len(tokenizer.encode(output_text)) print(f耗时: {elapsed:.2f}s) print(f生成 token 数: {output_tokens}) print(f平均生成速度: {output_tokens / elapsed:.2f} token/s)注意这个脚本实测的是“从请求开始到输出结束”的全流程平均速度包含网络传输和首 token 延迟。服务端日志通常会另外给出 Prefill 和 Decode 阶段的细分指标生产环境建议以服务端指标为准。3.4 为什么要区分“速率”和“吞吐”单用户测速得到的 token/s 是单请求速率服务端同时处理多个请求时整体吞吐可能更高但单个用户感受到的速度不一定提升。例如一颗显卡在 batch 为 1 时单请求可能是 60 token/s把 batch 提高到 16总吞吐可能到 600 token/s但单个请求因为排队和显存分配反而可能降到 50 token/s。所以在优化推理性能前必须先明确业务目标是降低单用户延迟还是提升整体吞吐。这两个目标对应的优化手段不同。4. Taalas 与主流推理框架对比4.1 Taalas 每秒 1.4 万 token 的技术含义根据公开宣传信息Taalas 在推理任务中展示了约每秒 1.4 万 token 的速度。目前公开技术细节有限我们不展开猜测其内部实现但可以从工程角度分析这个数字的参考意义。要达到这个量级的解码速度通常需要几个条件同时满足高带宽显存或高速内存、高效的算子融合、较大的批量吞吐以及针对目标模型和硬件深度定制的内核。单一环节优化很难达到万级 token/s这也是为什么它引发讨论——说明推理加速还有很大的工程空间。对普通开发者来说重点不是盲目追逐这个数字而是理解同样的模型在优化前后测速结果可能天差地别。自己部署时最好先记录下当前基线再逐项优化。4.2 主流推理框架盘点目前工业界和开源社区常见的推理框架有vLLM基于 PagedAttention 和连续批处理Continuous Batching适合高并发场景兼容 OpenAI API是当前部署服务的主流选择之一。Ollama适合本地开发和体验安装简单支持量化模型适合个人笔记本或单机部署。TensorRT-LLMNVIDIA 生态的推理引擎对 Tensor Core 优化深入适合对延迟要求极高的生产环境。llama.cpp纯 C/C 实现支持 CPU 推理和 GPU 加速在资源受限环境很受欢迎。HuggingFace TGIText Generation Inference官方维护的推理服务与 transformers 生态集成好。4.3 不同框架的适用场景框架优势适合场景vLLM吞吐高、并发友好、支持 OpenAI 协议线上 API 服务、多用户并发Ollama部署简单、模型管理方便本地开发、个人学习、原型验证TensorRT-LLMGPU 优化极致、延迟低生产环境、GPU 资源充足llama.cpp跨平台、可 CPU 推理边缘设备、低配机器TGI生态统一、功能完整已深度使用 HuggingFace 的团队选择框架时不要只看宣传的峰值速度要结合自己的硬件、并发模型、编程语言和运维能力。如果只是本地体验从 Ollama 入手最合适如果要做高并发 APIvLLM 是更稳妥的起点。4.4 推理框架学习路线如果你刚接触推理部署可以按这个顺序学习用 transformers 加载模型做一次普通推理理解模型输入输出。用 Ollama 部署一个开源模型体验命令行调用和 API 调用。用 vLLM 部署同一个模型对比吞吐和延迟。学习量化概念AWQ、GPTQ、GGUF 的区别。学习连续批处理和 KV Cache 的基本原理。再深入了解 TensorRT-LLM 这类硬件级优化引擎。这条路线从“跑通”到“跑快”每一步都能积累可量化的经验。5. 影响推理速度的关键因素5.1 推理卡与显存带宽模型推理时权重和 KV Cache 都要在显存中反复读写。GPU 的显存带宽越高单位时间内能处理的 token 就越多。这也是为什么很多高性能推理引擎强调使用了 HBM 高带宽显存。显存容量决定你能放多大的模型、开多大的上下文。显存不足时模型会被换到内存或磁盘推理速度会急剧下降。所以选择推理卡时不仅要看算力还要看显存容量和带宽。5.2 服务器内存与推理卡的关系很多部署新手会把目光全放在 GPU 上忽略了服务器内存的影响。模型加载时权重首先从磁盘读入内存再从内存拷贝到显存。如果内存带宽低、磁盘 IO 慢加载时间会很长。另外当并发请求增多、KV Cache 超过显存容量时部分实现会进行调度频繁在 CPU 内存和 GPU 显存之间搬运数据这时候内存带宽和 PCIe 带宽都会成为瓶颈。所以在采购或配置服务器时要同时考虑内存容量不小于模型权重的 2 到 3 倍PCIe 通道数足够磁盘最好是 NVMe SSD避免模型加载和量化权重交换时成为瓶颈。5.3 批量大小、KV Cache 与量化连续批处理是提升吞吐的有效手段。它让计算单元在同一时刻处理多个请求而不是等一个请求全部生成完再处理下一个。KV Cache 是推理过程中缓存历史 token 的键值对避免每生成一个新 token 都重新计算全部历史。KV Cache 很占显存但它是提升解码速度的关键。很多框架提供了gpu_memory_utilization、max_model_len等参数来管理 KV Cache 容量。量化则是把模型权重从 FP16 降到 INT8、INT4 等更低精度减少显存占用和内存带宽压力从而提升速度。代价是可能出现轻微精度下降。5.4 框架调度策略不同框架的最大差异之一是请求调度策略。vLLM 的连续批处理能够在当前请求生成间隙插入其他请求GPU 利用率更高简单批处理框架则必须凑满一个 batch 才开始计算空闲率大。TensorRT-LLM 则在算子融合、内核自动调优上做了大量工作。这些策略层面的差异比“谁家的模型加载更快”更能解释实际性能差距。6. 实战搭建一个高性能推理服务6.1 搭建前的环境准备下面以一个常见的 7B 模型为例演示从零搭建一个 OpenAI 兼容的推理服务并完成测速。本文不锁定具体硬件版本只给出通用思路。实际环境可能是操作系统Ubuntu 20.04/22.04或 Windows WSL2GPUNVIDIA 显卡建议显存不小于 16GPython3.10 或更高版本CUDA根据显卡驱动安装对应版本建议 12.x推理框架vLLM 或 Ollama如果没有 GPUvLLM 的演示可以跳过改用 CPU 版本的 Ollama 体验概念部分但测速结果会差别很大。6.2 vLLM 启动服务安装 vLLMpip install vllm启动 OpenAI 兼容服务python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --port 8000参数解释--model指定 HuggingFace 模型名称或本地模型目录。--gpu-memory-utilization允许使用的显存比例避免一次性占满导致后续任务失败。--max-model-len最大上下文长度受模型本身和显存双重限制。--port服务端口。启动成功后可以在另一个终端运行curl http://localhost:8000/v1/models能返回模型列表说明服务已就绪。6.3 调用服务并测速回到 3.3 节的benchmark.py把BASE_URL改为http://localhost:8000/v1模型名改为你实际部署的模型 ID然后运行python benchmark.py预期输出结构大致如下耗时: 18.35s 生成 token 数: 1024 平均生成速度: 55.80 token/s注意如果你的显卡是消费级单卡55 token/s这个量级是正常的不要和 1.4 万 token/s 直接比较因为批量策略、硬件规格、上下文长度完全不同。6.4 用 Ollama 做轻量替代如果只是想快速验证量化模型在本地的速度可以用 Ollamaollama pull qwen2.5:7b ollama run qwen2.5:7bOllama 默认会使用适合本地硬件的量化版本。运行后输入一句话模型会流式输出。调用 API 时默认地址为http://localhost:11434使用api/chat接口很多 HTTP 客户端工具都直接支持。7. 常见问题与排查思路7.1 输出 token 上限导致回答被截断现象长内容生成到一半突然停止响应提示“已达到输出 token 上限”。可能原因max_tokens设置过小或者服务端存在硬限制。解决思路调大max_tokens。检查框架配置中max_model_len是否足够。对超长生成任务用流式输出配合分段续写而不是一次拉到上限。7.2 测速结果与预期相差过大现象官方宣传或他人教程中显示 60 token/s自己测只有 20 token/s。排查步骤确认是否使用了相同模型和量化方式。确认是否相同上下文长度。确认是否有并发请求干扰。检查 GPU 使用率是否打满nvidia-smi查看功耗是否达到上限。检查是否是 CPU 推理或 GPU 未开启。这类差异大多源于环境不同而不是框架“不行”。7.3 登录或接口返回 token 相关报错在开发中“token”还有另一层含义认证令牌例如 JWT、OAuth Token、GitLab Token 等。很多同学遇到sign-in could not be completed token exchange failed、token endpoint returned status 403 forbidden这类错误时会困惑我调用的是模型 API怎么跟认证 token 有什么关系这类报错通常出现在连接第三方平台时Access Token 或 API Key 过期。服务端配置了地区或网络策略导致令牌端点返回 403。时区不同步导致 token 验证失败。排查思路检查当前 token 是否过期尝试重新登录生成新 token。检查服务器时间和本地时间是否一致。检查代理或网关配置是否正确。JWT 场景下检查密钥和签名算法是否一致。这里要特别提醒认证 token 和模型 token 是两个不同概念。看到“token 失效”相关报错时先别急着优化模型推理先确认是哪一层 token。7.4 显存不足服务启动失败现象vLLM 启动时报 CUDA out of memory。排查与解决降低gpu-memory-utilization。调低max-model-len。关闭其他占用显存的进程。尝试更低比特的量化版本例如 AWQ 或 GGUF。7.5 服务器内存和推理卡之间相互影响现象模型加载慢推理过程中偶尔出现明显卡顿。可能原因内存带宽不足、PCIe 带宽受限、系统 Swap 频繁。解决思路模型加载前关闭不必要的进程。使用 NVMe 固态硬盘存放模型文件。合理设置页缓存避免反复从磁盘读权重。如果使用 CPU Offload 策略确认内存容量足够。8. 工程最佳实践8.1 先测基线再优化不要凭感觉调参数。无论用什么框架第一步都先记录一份基线数据模型名、量化方式、batch 大小、并发数、上下文长度、单请求平均速度、服务端吞吐。后续每做一项改动都对照基线评估收益。这样能避免“优化了一圈结果更慢”的情况。8.2 按场景选择量化精度对话体验类场景优先考虑 FP16/BF16保持输出质量。高并发离线场景可尝试 INT8 或 AWQ。边缘设备或低配机器考虑 GGUF 的 Q4/Q5 版本。量化后的模型一定要做效果抽测不能只看速度。部分任务在 INT4 下会出现明显质量下降。8.3 管理好 token 用量预算在 API 调用场景中token 用量直接关联费用。常用做法在发请求前用 tokenizer 预估 prompt 的 token 数。对用户输入做长度限制超长内容先截断或总结。控制max_tokens避免模型自由发挥过长。日志中记录每次请求的 prompt token 和 completion token方便成本分析。8.4 监控不是可选项生产环境部署推理服务至少要监控GPU 显存占用、利用率、功耗。平均 TTFT 和 TPS。请求排队长度和超时率。token 吞吐总量和成本估算。这些指标可以接入 Prometheus 和 Grafana也可以在应用层做日志统计。只有数据足够才能判断是否需要扩容或调整策略。8.5 给自己留一条“降级方案”在真实业务中推理服务可能会有高峰期或模型故障。建议提前准备一个更小、更快的模型作为后备。一段缓存常用回答的 Redis 服务。预设超时和重试策略避免用户长时间等待。当主模型明显变慢或不可用时自动降级优先保证服务可用性。9. 总结与学习路线这篇文章从 Taalas 每秒 1.4 万 token 的公开数据切入梳理了大模型推理中几个最基本也最容易混淆的知识点token 到底是什么推理速度怎么测量预填充和解码阶段有何区别以及为什么不能拿一个孤立的 token/s 数字直接比较不同框架。同时给出了两个可以直接上手的实战路径用 vLLM 部署 OpenAI 兼容的推理服务或者用 Ollama 在本地快速体验以及配套的 token 计算脚本和测速脚本方便你在自己的机器上建立基线数据。如果接下来想继续深入建议按这个顺序推进重点理解 KV Cache 和连续批处理原理这是当前推理引擎拉开性能差距的核心。学习量化技术在同一模型上对比 FP16、AWQ、GGUF 的延迟、吞吐和输出质量。动手做一次压测使用 Locust 或 wrk 模拟多用户并发观察吞吐与延迟的平衡点。再往后可以了解 TensorRT-LLM 的引擎构建流程以及分布式推理中的张量并行、流水线并行等概念。在实际项目中永远要把“业务目标”放在“峰值指标”前面。你要做的不是盲目追求每秒 1.4 万 token而是找到你的硬件、模型、并发模型和成本约束下最合适的配置。先让服务稳定跑起来再逐步优化这一步一步对比出来的数据比任何宣传数字都更有说服力。
看到 Taalas 展示的每秒 1.4 万 token 推理速度后不少开发者开始重新审视大模型推理性能的边界。这个数字乍看不太直观但稍微换算一下如果按英文文本约 1 个 token 对应 0.75 个单词估算一秒钟就能生成接近一万个英文单词相当于 20 页左右的英文文档如果按中文约 1 个 token 对应 0.6 到 0.7 个汉字估算一秒钟也在 8000 汉字以上。放在过去“一个字一个字往外蹦”的生成式大模型上这几乎是科幻级别。不过比“跑得快”更值得讨论的是这个速度是怎么测出来的token 到底是什么为什么大家都用 token 而不是字数来评价推理性能我们自己的模型服务离这个量级还有多远中间卡在哪些环节这篇文章围绕这几个问题展开会从 token 基础概念讲起拆解推理速度指标再结合 vLLM、Ollama 等主流推理框架给出可复现的测速与优化方法最后整理高频报错和工程建议。适合正在做模型部署、推理优化或者刚开始接触大模型应用开发的读者。1. 为什么推理速度成了大模型落地的关键指标1.1 训练快不如推理稳很多刚接触大模型的同学会把注意力放在“模型参数量有多大”“训练用了多少张卡”上但在实际业务场景中推理阶段的性能往往才是决定项目能不能上线的关键。训练是离线任务跑几小时甚至几天都可以接受推理却是实时任务用户在对话界面等回复接口在压测下要保证不超时批量任务在有限算力下要尽快跑完。同一个 7B 模型用不同框架部署、不同量化精度、不同并发配置延迟和吞吐可能差出好几倍。推理速度直接影响用户体验、服务器成本和可支撑的业务规模。1.2 每秒 1.4 万 token 是什么概念以 1.4 万 token/s 为例对这个数字建立一个直觉很重要。如果生成一篇 1000 token 的短文耗时不到 0.1 秒。如果处理一本 10 万字的小说约 8 万到 12 万 token大约 6 到 10 秒可以完成全文生成。在流式输出场景中用户几乎感觉不到“逐字输出”的等待体验接近搜索响应的即时性。这也是为什么像 Taalas 这类推理加速方案公布速度数据时会引起关注。它代表的不只是一个框架的优化成绩而是说明大模型推理在特定硬件和工程组合下已经可以逼近过去专用模型才有的处理速度。1.3 推理速度不是单一指标这里要先打一个预防针不要看到“每秒 1.4 万 token”就直接和某个框架或某张显卡画等号。推理速度受批量大小、输入长度、输出长度、量化方式、硬件型号、并发策略影响非常大。同一套系统在 batch size 为 1 的流式对话场景和 batch size 为 32 的离线批量生成场景里测出来的单用户 token 吞吐完全不同。所以理解这个数字时要同时问清楚测的是单请求延迟还是服务端总吞吐是短文本还是长文本2. 先搞懂 token大模型计算的基本单位2.1 token 是什么token 是大模型处理文本的最小单位。你可以把它理解成模型眼中的“词元”或“片段”。比如英文单词unbelievable模型不一定会把它当作一个整体而可能拆成un、believ、able三个 token。中文“深度学习”可能被拆成“深”、“度”、“学”、“习”四个 token也可能被拆成“深度”、“学习”两个 token具体取决于分词器。专业一点说token 是分词器Tokenizer对原始文本进行切分后的结果。大模型在训练和推理时看到的不是字符串而是一串 token id。模型本质上是在预测“下一个 token 是什么”而不是“下一个字/单词是什么”。2.2 为什么要用 token 而不是字数主要有三个原因。第一模型的计算量和上下文长度都以 token 为计量单位。Transformer 的自注意力机制复杂度与序列长度的平方相关这里的序列长度就是 token 数。第二不同语言、不同写法下token 和字符的换算比例不稳定。英文一个单词平均约 1.3 个 token中文一个汉字约 0.6 到 1 个 token同一个句子在不同分词器下 token 数也可能不同。直接用字数统计会失真。第三模型服务的计费、限流、上下文窗口限制都以 token 为基准。在调用 OpenAI、智谱等平台的 API 时费用按 token 计算在本地部署时显存占用也和上下文 token 数直接相关。2.3 用代码计算 token 数量在实际开发中我们需要在发送请求前估算 token 用量避免超出上下文限制。最准确的方式是使用模型对应的 tokenizer。下面以 HuggingFace 的 transformers 库为例# requirements: transformers4.40 # 文件路径count_tokens.py from transformers import AutoTokenizer # 这里以 Qwen2.5 7B 为例实际使用时换成你部署的模型 model_name Qwen/Qwen2.5-7B-Instruct tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) text 大模型推理速度是落地的关键指标token 是计算的基本单位。 tokens tokenizer.tokenize(text) token_ids tokenizer.encode(text) print(f原始文本: {text}) print(fToken 列表: {tokens}) print(fToken ID: {token_ids}) print(fToken 数量: {len(token_ids)})运行后可以看到中文文本并不是每个字固定对应一个 token而是由分词器根据词表决定。这个结果在不同模型之间会有差异所以不要用“一个汉字等于一个 token”这种粗略规则做精确预算而是直接用 tokenizer 算。2.4 token 与字符数、API credit 的换算关系不少平台在控制台里同时展示 token 和 credit积分但换算关系并不统一。有的平台 1 credit 等于 1 token有的平台按照模型等级设置不同倍率还有的会用固定字符数折算。遇到“2500 credits 相当于多少 token”这类问题时最可靠的做法是查看对应平台的计费文档而不是套用某个固定公式。在自建服务中我们也不应该根据字符数预估显存和上下文而应该用 tokenizer 在你选定的 prompt 模板上跑一遍完整文本。3. 推理速度指标token/s 是怎么算出来的3.1 首 token 延迟与生成速度衡量大模型推理性能最常用的两个指标是TTFTTime To First Token从发起请求到收到第一个 token 的时间。TPSTokens Per Second稳定生成阶段每秒产生的 token 数也叫生成速度。TTFT 影响“用户多久看到第一个字”TPS 影响“整段回答多久完整结束”。在流式输出场景中用户最先感受到的是 TTFT在离线批量生成中TPS 更关键。3.2 预填充阶段与解码阶段大模型推理在时间上分为两个阶段。预填充阶段Prefill用户输入的 prompt 一次性进入模型并行计算所有输入 token 的注意力结果。这个阶段对算力要求高但可以被并行加速。解码阶段Decode模型逐个生成新 token每生成一个 token 就依赖前面所有 token 的计算结果串行程度高。这也是大家常说生成式推理“慢”的主要原因——不是一个一个并发出词而是生成序列本身是逐步展开的。衡量“每秒 1.4 万 token”时需要明确它覆盖了哪个阶段。如果只是预填充阶段的吞吐和完整生成全过程的体验差异会非常大如果是完整生成阶段摊平后的速度参考价值更高。3.3 用 Python 写一个简易测速脚本下面这段脚本调用一个兼容 OpenAI API 的本地推理服务并统计生成速度和 token 数# 文件路径benchmark.py # 依赖pip install openai transformers import time from openai import OpenAI from transformers import AutoTokenizer # 修改为你的服务地址与模型名 BASE_URL http://localhost:8000/v1 MODEL_NAME Qwen/Qwen2.5-7B-Instruct API_KEY EMPTY client OpenAI(base_urlBASE_URL, api_keyAPI_KEY) tokenizer AutoTokenizer.from_pretrained(MODEL_NAME, trust_remote_codeTrue) prompt 请用 500 字左右介绍大模型推理加速的基本思路。 messages [{role: user, content: prompt}] start time.time() response client.chat.completions.create( modelMODEL_NAME, messagesmessages, streamTrue, max_tokens1024, ) output_text for chunk in response: delta chunk.choices[0].delta.content if delta: output_text delta elapsed time.time() - start output_tokens len(tokenizer.encode(output_text)) print(f耗时: {elapsed:.2f}s) print(f生成 token 数: {output_tokens}) print(f平均生成速度: {output_tokens / elapsed:.2f} token/s)注意这个脚本实测的是“从请求开始到输出结束”的全流程平均速度包含网络传输和首 token 延迟。服务端日志通常会另外给出 Prefill 和 Decode 阶段的细分指标生产环境建议以服务端指标为准。3.4 为什么要区分“速率”和“吞吐”单用户测速得到的 token/s 是单请求速率服务端同时处理多个请求时整体吞吐可能更高但单个用户感受到的速度不一定提升。例如一颗显卡在 batch 为 1 时单请求可能是 60 token/s把 batch 提高到 16总吞吐可能到 600 token/s但单个请求因为排队和显存分配反而可能降到 50 token/s。所以在优化推理性能前必须先明确业务目标是降低单用户延迟还是提升整体吞吐。这两个目标对应的优化手段不同。4. Taalas 与主流推理框架对比4.1 Taalas 每秒 1.4 万 token 的技术含义根据公开宣传信息Taalas 在推理任务中展示了约每秒 1.4 万 token 的速度。目前公开技术细节有限我们不展开猜测其内部实现但可以从工程角度分析这个数字的参考意义。要达到这个量级的解码速度通常需要几个条件同时满足高带宽显存或高速内存、高效的算子融合、较大的批量吞吐以及针对目标模型和硬件深度定制的内核。单一环节优化很难达到万级 token/s这也是为什么它引发讨论——说明推理加速还有很大的工程空间。对普通开发者来说重点不是盲目追逐这个数字而是理解同样的模型在优化前后测速结果可能天差地别。自己部署时最好先记录下当前基线再逐项优化。4.2 主流推理框架盘点目前工业界和开源社区常见的推理框架有vLLM基于 PagedAttention 和连续批处理Continuous Batching适合高并发场景兼容 OpenAI API是当前部署服务的主流选择之一。Ollama适合本地开发和体验安装简单支持量化模型适合个人笔记本或单机部署。TensorRT-LLMNVIDIA 生态的推理引擎对 Tensor Core 优化深入适合对延迟要求极高的生产环境。llama.cpp纯 C/C 实现支持 CPU 推理和 GPU 加速在资源受限环境很受欢迎。HuggingFace TGIText Generation Inference官方维护的推理服务与 transformers 生态集成好。4.3 不同框架的适用场景框架优势适合场景vLLM吞吐高、并发友好、支持 OpenAI 协议线上 API 服务、多用户并发Ollama部署简单、模型管理方便本地开发、个人学习、原型验证TensorRT-LLMGPU 优化极致、延迟低生产环境、GPU 资源充足llama.cpp跨平台、可 CPU 推理边缘设备、低配机器TGI生态统一、功能完整已深度使用 HuggingFace 的团队选择框架时不要只看宣传的峰值速度要结合自己的硬件、并发模型、编程语言和运维能力。如果只是本地体验从 Ollama 入手最合适如果要做高并发 APIvLLM 是更稳妥的起点。4.4 推理框架学习路线如果你刚接触推理部署可以按这个顺序学习用 transformers 加载模型做一次普通推理理解模型输入输出。用 Ollama 部署一个开源模型体验命令行调用和 API 调用。用 vLLM 部署同一个模型对比吞吐和延迟。学习量化概念AWQ、GPTQ、GGUF 的区别。学习连续批处理和 KV Cache 的基本原理。再深入了解 TensorRT-LLM 这类硬件级优化引擎。这条路线从“跑通”到“跑快”每一步都能积累可量化的经验。5. 影响推理速度的关键因素5.1 推理卡与显存带宽模型推理时权重和 KV Cache 都要在显存中反复读写。GPU 的显存带宽越高单位时间内能处理的 token 就越多。这也是为什么很多高性能推理引擎强调使用了 HBM 高带宽显存。显存容量决定你能放多大的模型、开多大的上下文。显存不足时模型会被换到内存或磁盘推理速度会急剧下降。所以选择推理卡时不仅要看算力还要看显存容量和带宽。5.2 服务器内存与推理卡的关系很多部署新手会把目光全放在 GPU 上忽略了服务器内存的影响。模型加载时权重首先从磁盘读入内存再从内存拷贝到显存。如果内存带宽低、磁盘 IO 慢加载时间会很长。另外当并发请求增多、KV Cache 超过显存容量时部分实现会进行调度频繁在 CPU 内存和 GPU 显存之间搬运数据这时候内存带宽和 PCIe 带宽都会成为瓶颈。所以在采购或配置服务器时要同时考虑内存容量不小于模型权重的 2 到 3 倍PCIe 通道数足够磁盘最好是 NVMe SSD避免模型加载和量化权重交换时成为瓶颈。5.3 批量大小、KV Cache 与量化连续批处理是提升吞吐的有效手段。它让计算单元在同一时刻处理多个请求而不是等一个请求全部生成完再处理下一个。KV Cache 是推理过程中缓存历史 token 的键值对避免每生成一个新 token 都重新计算全部历史。KV Cache 很占显存但它是提升解码速度的关键。很多框架提供了gpu_memory_utilization、max_model_len等参数来管理 KV Cache 容量。量化则是把模型权重从 FP16 降到 INT8、INT4 等更低精度减少显存占用和内存带宽压力从而提升速度。代价是可能出现轻微精度下降。5.4 框架调度策略不同框架的最大差异之一是请求调度策略。vLLM 的连续批处理能够在当前请求生成间隙插入其他请求GPU 利用率更高简单批处理框架则必须凑满一个 batch 才开始计算空闲率大。TensorRT-LLM 则在算子融合、内核自动调优上做了大量工作。这些策略层面的差异比“谁家的模型加载更快”更能解释实际性能差距。6. 实战搭建一个高性能推理服务6.1 搭建前的环境准备下面以一个常见的 7B 模型为例演示从零搭建一个 OpenAI 兼容的推理服务并完成测速。本文不锁定具体硬件版本只给出通用思路。实际环境可能是操作系统Ubuntu 20.04/22.04或 Windows WSL2GPUNVIDIA 显卡建议显存不小于 16GPython3.10 或更高版本CUDA根据显卡驱动安装对应版本建议 12.x推理框架vLLM 或 Ollama如果没有 GPUvLLM 的演示可以跳过改用 CPU 版本的 Ollama 体验概念部分但测速结果会差别很大。6.2 vLLM 启动服务安装 vLLMpip install vllm启动 OpenAI 兼容服务python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --port 8000参数解释--model指定 HuggingFace 模型名称或本地模型目录。--gpu-memory-utilization允许使用的显存比例避免一次性占满导致后续任务失败。--max-model-len最大上下文长度受模型本身和显存双重限制。--port服务端口。启动成功后可以在另一个终端运行curl http://localhost:8000/v1/models能返回模型列表说明服务已就绪。6.3 调用服务并测速回到 3.3 节的benchmark.py把BASE_URL改为http://localhost:8000/v1模型名改为你实际部署的模型 ID然后运行python benchmark.py预期输出结构大致如下耗时: 18.35s 生成 token 数: 1024 平均生成速度: 55.80 token/s注意如果你的显卡是消费级单卡55 token/s这个量级是正常的不要和 1.4 万 token/s 直接比较因为批量策略、硬件规格、上下文长度完全不同。6.4 用 Ollama 做轻量替代如果只是想快速验证量化模型在本地的速度可以用 Ollamaollama pull qwen2.5:7b ollama run qwen2.5:7bOllama 默认会使用适合本地硬件的量化版本。运行后输入一句话模型会流式输出。调用 API 时默认地址为http://localhost:11434使用api/chat接口很多 HTTP 客户端工具都直接支持。7. 常见问题与排查思路7.1 输出 token 上限导致回答被截断现象长内容生成到一半突然停止响应提示“已达到输出 token 上限”。可能原因max_tokens设置过小或者服务端存在硬限制。解决思路调大max_tokens。检查框架配置中max_model_len是否足够。对超长生成任务用流式输出配合分段续写而不是一次拉到上限。7.2 测速结果与预期相差过大现象官方宣传或他人教程中显示 60 token/s自己测只有 20 token/s。排查步骤确认是否使用了相同模型和量化方式。确认是否相同上下文长度。确认是否有并发请求干扰。检查 GPU 使用率是否打满nvidia-smi查看功耗是否达到上限。检查是否是 CPU 推理或 GPU 未开启。这类差异大多源于环境不同而不是框架“不行”。7.3 登录或接口返回 token 相关报错在开发中“token”还有另一层含义认证令牌例如 JWT、OAuth Token、GitLab Token 等。很多同学遇到sign-in could not be completed token exchange failed、token endpoint returned status 403 forbidden这类错误时会困惑我调用的是模型 API怎么跟认证 token 有什么关系这类报错通常出现在连接第三方平台时Access Token 或 API Key 过期。服务端配置了地区或网络策略导致令牌端点返回 403。时区不同步导致 token 验证失败。排查思路检查当前 token 是否过期尝试重新登录生成新 token。检查服务器时间和本地时间是否一致。检查代理或网关配置是否正确。JWT 场景下检查密钥和签名算法是否一致。这里要特别提醒认证 token 和模型 token 是两个不同概念。看到“token 失效”相关报错时先别急着优化模型推理先确认是哪一层 token。7.4 显存不足服务启动失败现象vLLM 启动时报 CUDA out of memory。排查与解决降低gpu-memory-utilization。调低max-model-len。关闭其他占用显存的进程。尝试更低比特的量化版本例如 AWQ 或 GGUF。7.5 服务器内存和推理卡之间相互影响现象模型加载慢推理过程中偶尔出现明显卡顿。可能原因内存带宽不足、PCIe 带宽受限、系统 Swap 频繁。解决思路模型加载前关闭不必要的进程。使用 NVMe 固态硬盘存放模型文件。合理设置页缓存避免反复从磁盘读权重。如果使用 CPU Offload 策略确认内存容量足够。8. 工程最佳实践8.1 先测基线再优化不要凭感觉调参数。无论用什么框架第一步都先记录一份基线数据模型名、量化方式、batch 大小、并发数、上下文长度、单请求平均速度、服务端吞吐。后续每做一项改动都对照基线评估收益。这样能避免“优化了一圈结果更慢”的情况。8.2 按场景选择量化精度对话体验类场景优先考虑 FP16/BF16保持输出质量。高并发离线场景可尝试 INT8 或 AWQ。边缘设备或低配机器考虑 GGUF 的 Q4/Q5 版本。量化后的模型一定要做效果抽测不能只看速度。部分任务在 INT4 下会出现明显质量下降。8.3 管理好 token 用量预算在 API 调用场景中token 用量直接关联费用。常用做法在发请求前用 tokenizer 预估 prompt 的 token 数。对用户输入做长度限制超长内容先截断或总结。控制max_tokens避免模型自由发挥过长。日志中记录每次请求的 prompt token 和 completion token方便成本分析。8.4 监控不是可选项生产环境部署推理服务至少要监控GPU 显存占用、利用率、功耗。平均 TTFT 和 TPS。请求排队长度和超时率。token 吞吐总量和成本估算。这些指标可以接入 Prometheus 和 Grafana也可以在应用层做日志统计。只有数据足够才能判断是否需要扩容或调整策略。8.5 给自己留一条“降级方案”在真实业务中推理服务可能会有高峰期或模型故障。建议提前准备一个更小、更快的模型作为后备。一段缓存常用回答的 Redis 服务。预设超时和重试策略避免用户长时间等待。当主模型明显变慢或不可用时自动降级优先保证服务可用性。9. 总结与学习路线这篇文章从 Taalas 每秒 1.4 万 token 的公开数据切入梳理了大模型推理中几个最基本也最容易混淆的知识点token 到底是什么推理速度怎么测量预填充和解码阶段有何区别以及为什么不能拿一个孤立的 token/s 数字直接比较不同框架。同时给出了两个可以直接上手的实战路径用 vLLM 部署 OpenAI 兼容的推理服务或者用 Ollama 在本地快速体验以及配套的 token 计算脚本和测速脚本方便你在自己的机器上建立基线数据。如果接下来想继续深入建议按这个顺序推进重点理解 KV Cache 和连续批处理原理这是当前推理引擎拉开性能差距的核心。学习量化技术在同一模型上对比 FP16、AWQ、GGUF 的延迟、吞吐和输出质量。动手做一次压测使用 Locust 或 wrk 模拟多用户并发观察吞吐与延迟的平衡点。再往后可以了解 TensorRT-LLM 的引擎构建流程以及分布式推理中的张量并行、流水线并行等概念。在实际项目中永远要把“业务目标”放在“峰值指标”前面。你要做的不是盲目追求每秒 1.4 万 token而是找到你的硬件、模型、并发模型和成本约束下最合适的配置。先让服务稳定跑起来再逐步优化这一步一步对比出来的数据比任何宣传数字都更有说服力。
