Tokens per Second：大模型推理速度的测量与优化全解析

看到 Celeris-1 以 2158 tokens/s 的生成速度登顶 AI 推理速度排行榜时，很多开发者的第一反应是：这个数字到底意味着什么？在真实项目中能不能复现？我自己部署模型之后，怎样测量并优化这个指标？

本篇文章不打算只停留在“谁跑得快”这个新闻层面，而是围绕 tokens per second 这个核心指标，从概念理解、评测方法、本地实测、影响因子、优化手段、常见误区与最佳实践几个维度展开。内容偏向工程落地，适合正在做模型推理部署、性能调优、技术选型的开发同学阅读。如果你只是刚接触大模型，也不要紧，我会从最基础的概念讲起。

1. 什么是 tokens per second，为什么 AI 速度排行榜都在用它

1.1 先理解 Token 的概念

要理解 tokens per second，首先要弄清楚 Token 是什么。大语言模型并不是按“字”或“单词”来理解文本的，而是把文本切分成更小的单元，这个单元就叫 Token。Tokenizer（分词器）会把一句话拆成若干个 Token，再把 Token 映射成数字 ID 输入给模型。

Token 的切分规则和语言、分词器训练方式有关。英文场景下，一个常见单词可能对应 1 到 2 个 Token，生僻词可能被拆成多个子词。中文场景下，一个汉字在不少 Tokenizer 中会对应 1 到 2 个 Token。所以题目里说的 2158 tokens/s，如果你换算成“每秒输出多少汉字”，并不是直接等于 2158 个字，需要结合具体 Tokenizer 的切分比例来估算。

1.2 tokens per second 指标的具体含义

tokens per second 描述的是模型每秒生成的 Token 数量，单位写作 tokens/s。它衡量的是模型的生成速度。生成速度越快，用户在对话中的等待时间就越短，批量处理任务的吞吐也会越高。

不过在性能评测里，还需要区分两个概念：

• 单请求生成速度：一个请求从开始生成到结束，模型每秒生成的 Token 数。
• 系统吞吐量：在并发场景下，所有请求合计每秒生成的 Token 数。

排行榜中的数字，既可能是单请求的速度，也可能是并发压力下的吞吐，要看评测方的定义。比如当 batch size 为 1 时，模型每秒生成的 Token 数就是单请求速度；当 batch size 很大时，系统每秒生成的总 Token 数会远高于单个请求的速度，因为 GPU 在同时处理多个请求。

1.3 为什么速度排行榜都在用这个指标

原因很简单：大模型生成文本是逐个 Token 输出的，Tokens per second 直接反映了“模型产出文本的速度”。无论是聊天机器人、内容生成、代码补全，还是文档总结，最终用户体验都和这个数字强相关。

另外，它也能反映推理系统的整体效率。同样的模型，在不同的推理框架、不同的 GPU、不同精度下，tokens/s 可能相差数倍。排行榜的意义在于给开发者一个横向参考：当前硬件和优化技术下，模型推理速度能够达到什么水平。

但这里要提醒一句：单一数字无法体现延迟分布、显存占用、成本、并发稳定性等因素。排行榜更多是“上限参考”，不是“生产环境保证值”。

2. 2158 tokens/s 是怎么测出来的：推理性能基准的关键变量

2.1 单请求测试与并发测试

评测方法直接决定最终数字。

如果评测方式是单请求、batch size 为 1，那么测到的是模型在理想状态下的单流生成速度。这种方式实现简单，适合对比模型本身和单卡推理能力。但如果评测加入了并发请求，比如同时发送多个 prompt，并且推理框架支持 continuous batching（连续批处理），那么系统吞吐量会明显提升，因为 GPU 可以同时服务多条请求，把空闲算力利用起来。

因此，当看到“2158 tokens/s”这个数字时，应该先问自己几个问题：

• 是单流速度还是总吞吐？
• 并发数是多少？
• 输入 token 长度是多少？
• 输出 token 长度是多少？
• 使用的是什么 GPU、精度、推理框架？

这些变量只要改一个，数字就可能有明显变化。

2.2 硬件、精度与框架的影响

硬件差异是最直观的。高端 GPU 的显存带宽更高、算力更强，单 token 的计算速度更快。低端 GPU 或 CPU 推理时，tokens/s 可能只有个位数甚至更低。

精度设置同样重要。FP16/BF16 是常见的半精度推理格式，INT8/INT4 量化可以进一步减少显存占用和计算量，但也会带来一定的精度损失。评测时采用哪种精度，要写清楚，否则很难复现。

推理框架的影响也很大。同一个模型，用 Hugging Face Transformers 直接用比用 vLLM、TensorRT-LLM 等优化框架慢不少。这些框架通过算子融合、Continuous Batching、PagedAttention（vLLM 提出的显存管理技术）等手段提升了 GPU 利用率，吞吐量和延迟都会更好。

2.3 评测工具与评测口径

常见的评测方法有两种：

• 固定 prompt、固定生成长度，统计生成耗时。
• 用离线批量脚本发送一批请求，统计总体吞吐。

固定提示词可以排除输入长度差异带来的影响。固定生成长度可以避免模型提前结束导致 token 数不稳定。一次评测通常需要重复多轮，取稳定值或平均值，避免偶然波动。

如果你要做对比实验，建议把评测条件写成一个标准清单，由几个维度组成：模型名称与版本、量化精度、GPU 型号与数量、输入长度、输出长度、并发数、推理框架与版本、CUDA 版本、解码参数。这些信息一起记录，跑出来的数值才有参考价值。

3. 在本地环境测量模型的 tokens per second

3.1 环境准备

要在本地实测生成速度，首先准备 Python 环境，建议 Python 3.10 及以上。主要依赖包括 PyTorch、Transformers、vLLM 等。

依赖安装命令如下：

pip install torch transformers vllm

这里说明一下：具体安装命令和版本会随 PyTorch、CUDA 版本变化，需要根据你的机器实际情况调整。如果你的项目已经用到了 virtualenv 或 conda，建议在独立环境里安装，避免包冲突。

硬件方面，如果使用 GPU，推荐显存 16GB 以上的 NVIDIA GPU，可以流畅运行 7B 到 14B 级别的模型。如果是纯 CPU 环境，也能跑通流程，但速度会慢很多，更建议换小模型测试。

3.2 使用 Transformers 测量单请求生成速度

下面用 Hugging Face Transformers 写一个简单的脚本，测量单请求的生成速度。

# 文件路径：benchmark_transformers.py import time import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_path = "your-model-path" # 替换为实际模型路径，例如 Qwen/Qwen2.5-7B-Instruct tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained( model_path, torch_dtype=torch.float16, device_map="auto", trust_remote_code=True ) prompt = "请用三句话介绍人工智能的发展历史。" inputs = tokenizer(prompt, return_tensors="pt").to(model.device) max_new_tokens = 512 start = time.perf_counter() with torch.no_grad(): output = model.generate( **inputs, max_new_tokens=max_new_tokens, do_sample=False, use_cache=True ) end = time.perf_counter() generated_tokens = output[0][inputs["input_ids"].shape[1]:] generated_count = len(generated_tokens) elapsed = end - start print(f"生成 token 数: {generated_count}") print(f"耗时: {elapsed:.2f}s") print(f"生成速度: {generated_count / elapsed:.2f} tokens/s")

这段代码的思路是：

1. 加载模型和分词器。torch_dtype=torch.float16表示以半精度加载，能减少显存占用。
2. 构造 prompt，编码成 input_ids。
3. 计算生成前后时间差，时间差除以生成的新 token 数量，得到每秒生成 token 数。
4. output[0][inputs["input_ids"].shape[1]:]是切片出新增生成的 token，去掉输入的前缀部分。

运行结果类似这样：

生成 token 数: 512 耗时: 8.42s 生成速度: 60.81 tokens/s

如果你的机器性能不错，或者模型比较小，数字会更高；反之会更低。这个脚本反映的是“单请求、无并发、Transformers 原生推理”下的速度，通常不是最高性能的表现。

3.3 使用 vLLM 测量批量吞吐

vLLM 是目前比较主流的开源推理框架，它通过 Continuous Batching、PagedAttention 等机制显著提升吞吐量。我们用 vLLM 测一下并发场景下的吞吐。

# 文件路径：benchmark_vllm.py import time from vllm import LLM, SamplingParams model_path = "your-model-path" # 替换为实际模型路径 llm = LLM( model=model_path, dtype="float16", tensor_parallel_size=1, gpu_memory_utilization=0.9, trust_remote_code=True ) prompts = [ "请解释什么是大语言模型。", "请写一段 Python 代码实现冒泡排序。", "请总结一篇文章的核心观点。", "请列出三种常见的模型量化方法。", ] * 20 # 构造 80 个请求 sampling_params = SamplingParams( max_tokens=512, temperature=0.7, top_p=0.9 ) start = time.perf_counter() outputs = llm.generate(prompts, sampling_params) end = time.perf_counter() total_tokens = sum(len(output.outputs[0].token_ids) for output in outputs) elapsed = end - start print(f"并发请求数: {len(prompts)}") print(f"总生成 tokens: {total_tokens}") print(f"总耗时: {elapsed:.2f}s") print(f"平均吞吐: {total_tokens / elapsed:.2f} tokens/s")

这段脚本里，LLM负责加载模型，SamplingParams负责配置解码参数。llm.generate(prompts, sampling_params)会一次性处理多个 prompt，框架内部自己管理 batch。

注意，vLLM 不同版本的 API 可能会有差异。如果你的 vLLM 版本比较新，参数名或导入方式可能有变化，建议先查看对应版本的文档。

vLLM 的吞吐通常比原生 Transformers 高出很多，尤其在并发请求较多的情况下。这不是模型变强了，而是同一块 GPU 被更充分地利用了。

3.4 结果解读与对比

如果你在两套脚本里跑同一个模型，会发现 vLLM 的吞吐明显更高。这里要追问一句：哪个数字才是“真实性能”？

答案是：两个都真实，只是评测口径不同。

Transformers 脚本测的是最朴素的单请求生成能力，适合调试和理解模型行为。vLLM 脚本更接近生产环境，适合评估系统吞吐。实际做性能报告时，要注明测试条件，不要只说“我的模型每秒能生成多少 token”。

另外，生成的 token 数量统计需要以 tokenizer 的实际输出为准，而不是简单地用“输出字符数”来推算。有些 Tokenizer 会把标点、空格也切成独立 Token，直接数汉字会低估或高估结果。

4. 影响 tokens per second 的关键因素

4.1 模型参数量与精度

模型的参数量决定了单次前向计算的计算量。7B 模型和 70B 模型，在同样的 GPU 上，单位时间能生成的 token 数差距会很大。参数越多，每次生成一个 token 需要做的矩阵运算越多，耗时自然越长。

精度也会影响速度。FP16/BF16 是常见的半精度推理格式，比 FP32 计算更快、显存占用更少。INT8/INT4 量化虽然会带来一定精度损失，但显存占用进一步下降，部分硬件上计算速度也会提升。对于显存带宽受限的解码阶段，量化后的模型往往能跑出更高的 tokens/s。

4.2 硬件：算力与显存带宽

大模型生成 token 时，有一个很有意思的特点：解码阶段很多算子并不完全受计算峰值限制，而是受显存带宽限制。模型权重和 KV Cache 要从显存中反复读取，显存带宽越高，每秒能完成的 token 生成次数就越多。

这也是为什么高端 GPU 在推理任务中优势明显，不仅因为算力强，还因为显存带宽高。如果你的 GPU 显存带宽较低，即使算力数字看起来不错，解码速度也可能不理想。

4.3 Prefill 和 Decode 两个阶段要分开看

大模型推理通常分成两个阶段：

• Prefill（预填充）阶段：处理输入 prompt，生成 KV Cache，这个阶段计算量较大，耗时主要取决于输入长度。
• Decode（解码）阶段：逐 token 生成输出，每个 token 依赖前一个 token，无法完全并行，耗时主要取决于输出长度和显存带宽。

如果评测时把 Prefill 时间和 Decode 时间混在一起，最终 tokens/s 会被输入长度影响。比如两个请求输出长度相同，一个输入 100 token，一个输入 1000 token，后者的 Prefill 时间更长，整体速度数值就会更低。

更科学的做法是把两个阶段分开统计：

• TTFT（Time To First Token）：首 token 延迟，反映用户等待“第一个字”的时间。
• TPOT（Time Per Output Token）：每输出一个 token 的耗时，反映生成流畅度。

4.4 批量大小与 KV Cache

批量大小对吞吐影响非常大。单条请求时，GPU 的算力通常没有被完全使用。把多条请求组合成一个 batch 后，矩阵计算的规模更大，GPU 利用率上升，整体吞吐也上来了。

但批量变大不是没有代价。每条请求都有自己的 KV Cache，batch 越大，KV Cache 占用显存越多。显存装不下时，要么降低批量，要么用更小的模型，要么使用类似 PagedAttention 的技术按需分配显存。

4.5 解码策略的影响

解码策略也会影响速度。

• 贪心解码（do_sample=False）：每次选择概率最大的 token，速度快且结果确定。
• 随机采样（temperature、top_p）：需要做随机采样计算，速度略慢。
• Beam Search：同时维护多条候选路径，生成时要多次前向计算，速度明显下降。

性能测试时，应固定解码参数。否则不同参数下测出的 tokens/s 没有可比性。

4.6 推理框架的优化能力

同一个模型，在原生 Transformers、vLLM、TensorRT-LLM 等框架上测试，速度可能差数倍。

vLLM 的核心优化包括：

• Continuous Batching：请求到达后不等待当前 batch 全部结束，而是动态加入新的请求，持续让 GPU 保持高利用率。
• PagedAttention：把 KV Cache 按块管理，减少显存碎片，提高显存利用率。
• 算子融合：把多个小算子合并成一个大算子，减少 Kernel 启动开销。

TensorRT-LLM 则通过图优化、算子选择、模型编译等静态优化方式，在 NVIDIA GPU 上做到较高性能。这类框架是否适合你的项目，取决于部署环境、模型兼容性和工程成本。

5. 提升模型推理速度的常用优化手段

5.1 模型量化

量化是把模型权重从 FP16 压缩到 INT8、INT4 等低精度格式，从而减少显存占用和计算量。常用的量化方法有 GPTQ、AWQ、GGUF 等。

量化后，模型文件变小，KV Cache 释放出更多显存，因此可以支持更大的 batch。在显存带宽受限的场景下，低精度权重读取更快，tokens/s 往往会有提升。不过要注意量化带来的精度损失，尤其是代码生成、数学推理等对精度敏感的任务，需要先做评估再决定是否量化。

5.2 使用连续批处理

如果你是自建服务，而不是只用离线批量脚本，建议使用支持 Continuous Batching 的推理框架。传统批处理模式下，一个 batch 里的请求必须全部完成后再处理下一批，空闲时 GPU 算力被浪费。Continuous Batching 可以在生成间隙插入新请求，进一步提高 GPU 吞吐。

这个优化对在线推理服务效果最明显。如果一个请求已经生成完毕，新请求可以立刻补位，不需要等待整批结束。

5.3 投机解码

投机解码（Speculative Decoding）是一种“以小博大”的思路：先用一个更小、更快的草稿模型生成多个候选 token，再用大模型一次性验证这些 token 是否正确。如果草稿模型猜得准，大模型一次前向计算就能确认多个 token，从而提升单流生成速度。

投机解码对硬件和任务分布有一定要求，不是所有场景都能得到明显加速。但在某些模型和输入分布下，可以在不损失输出质量的前提下提升 tokens/s。

5.4 KV Cache 优化

解码阶段需要读取历史 token 的 KV Cache。如果 KV Cache 管理不当，会出现显存碎片、浪费、重复申请等问题。优化方向包括：

• 使用 PagedAttention 按块管理 KV Cache。
• 对 KV Cache 做低精度量化，减少显存占用。
• 合理设置 max_model_len，避免预留过大显存。

这些优化通常集成在 vLLM 等框架中，普通开发者不需要手动实现，但了解原理有助于定位显存不足和速度下降问题。

5.5 多卡并行与部署策略

当单卡显存放不下模型，或单卡算力不够时，可以使用多卡并行。常见并行方式包括：

• 张量并行（Tensor Parallelism）：把单个算子的计算拆分到多张卡上，适合单模型很大但需要低延迟的场景。
• 数据并行（Data Parallelism）：每张卡跑一个完整模型副本，适合吞吐优先的场景。
• 流水线并行（Pipeline Parallelism）：把模型按层拆成多段，适合超大模型。

并行方案会增加通信开销，需要根据模型规模和硬件环境权衡。小模型强行上多卡，反而可能因为通信开销导致速度下降。

5.6 权衡：速度不是唯一目标

优化 tokens/s 的时候，还要关注精度、显存、成本和稳定性。一个推理系统如果只追求峰值速度，可能导致显存占用过高、并发能力下降、生成质量受损。生产环境中的性能优化，本质是在多个约束条件下找平衡点。

6. 常见问题与排查思路

6.1 常见问题速查表

6.2 排查 checklist

如果你复现不出排行榜的数字，我建议按以下顺序排查：

1. 确认模型版本是否一致，Tokenizer 是否一致。
2. 确认输入 prompt 长度、输出长度是否一致。
3. 确认 batch size、并发数是否一致。
4. 确认推理框架和版本是否一致。
5. 确认 GPU 型号、显存、精度是否一致。
6. 确认是否使用了相同的解码参数。
7. 多次测试，取平均值或稳定值，不要用单次峰值来对比。

排行榜上的数字，通常在特定的软硬件组合下才能复现。你的目标不一定是追平它，而是理解自己的系统在什么条件下能达到最优性能。

7. 最佳实践：如何正确看待和复现速度排行榜

7.1 建立自己的评测基准

与其纠结排行榜的绝对数字，不如搭建一套适合自己业务的评测基准。

具体做法是：选择 10 到 20 条有代表性的 prompt，覆盖短文本、长文本、代码、中文、英文等场景；固定输出长度，比如 256、512、1024 token；固定并发数和 batch 策略；在同样的 GPU 和框架下重复运行多轮，记录平均速度和 P95 延迟。

这套基准可以用于：

• 对比不同模型的速度。
• 对比不同推理框架的速度。
• 对比不同量化方案的速度和精度。
• 在升级硬件时评估收益。

评测脚本最好纳入版本管理，和代码一起维护。这样每次优化后，都能快速得出可对比的数据。

7.2 关注延迟分布而不是只看平均值

平均 tokens/s 只能反映整体水平，不能反映请求之间的波动。一个系统可能平均速度不错，但部分请求因为显存不足、调度排队等原因出现明显卡顿。

生产环境更应该关注：

• P50 和 P95 的 TTFT。
• P50 和 P95 的 TPOT。
• 并发请求下的吞吐稳定性。
• OOM 和超时次数。

如果只优化平均值，可能把系统推向极端状态，损害大多数用户体验。

7.3 速度评测之外，还要关注模型合规与安全

部署模型时，除了性能指标，还需要确认模型的使用协议、数据隐私要求和内容安全策略。不要使用来源不明、许可不明的模型和权重。推理服务上线前，应做好输入输出的内容过滤和访问控制，避免生成内容给业务带来风险。涉及用户数据时，要遵守数据最小化原则，记录日志时避免保存敏感原文。

7.4 生产环境的调优顺序建议

从我做过的一些推理服务优化经验来看，推荐的调优顺序是：

1. 先选一个合适的推理框架，优先考虑 vLLM、TensorRT-LLM 等有批处理和显存优化的框架。
2. 再根据显存情况决定是否量化，优先尝试 AWQ 或 GPTQ。
3. 配置合理的并发和 batch 策略，观察吞吐和延迟变化。
4. 如果单卡性能不足，再考虑张量并行或多卡部署。
5. 最后用完整的评测基准验收，尤其关注尾延迟和错误率。

这套顺序可以避免一上来就做复杂优化，最后发现瓶颈根本不在模型推理，而在数据加载或网络传输上。

如果你也想复现类似 Celeris-1 这样的速度榜单结果，建议先搭好基准测试脚本，把硬件、框架、精度、prompt、并发这些变量固定下来，再从单卡、单请求开始逐步加压。这样跑出来的数据，无论是写技术报告还是做方案选型，都会更有说服力。

最后想说的是：2158 tokens/s 这个数字本身会随着榜单更新被打破，但“如何正确测速、如何分析瓶颈、如何优化吞吐”这套方法不会过时。手里有一套自己的基准脚本，比记住任何排行榜数字都更实用。