大模型推理速度怎么测？从每秒 token 数到用户实际等待时间

大模型推理速度：每秒 token 数衡量的是什么？

输出速度（tokens per second），也就是每秒输出的 token 数，衡量的是收到首个 token 后，LLM 继续交付所生成 token 的速度。 大语言模型（LLM）以 token 为单位处理文本：一个 token 可能是一个词、词的一部分，也可能是标点。token 数不能统一换算成词数。Cerebras 的定义 明确区分了这两个概念。

可以想象去图书馆取一批书：等开门是一段时间，开门后拿到每本书的速度又是另一回事，两者共同决定你什么时候能拿齐书离开。递书再快，也抵消不了之前在门外的漫长等待。

评估应用时，应把以下指标分开记录：

这些计时边界沿用了 Artificial Analysis 的指标定义。首个推理 token 可能早于首个答案 token 到达，因此这两种计时必须分别命名。

应用的端到端延迟，从用户发起操作开始，到获得有用的结果结束。对语音助手来说，这个终点可能是用户听到语音；对智能体来说，则可能是操作完成。检索、工具执行、语音合成和界面更新，都可能发生在模型请求的计时范围之外。这个更完整的过程，也需要埋点测量。

底层过程分为 prefill（预填充） 和 decode（解码）：前者处理提示词，后者生成后续内容。LLM 推理详解 介绍了这两项工作在模型服务系统中的执行过程。

为什么只看一个速度数字容易误判？

速度测量描述的是某个服务端点处理特定负载时的表现，并不是模型在任何条件下都成立的固有属性。任务或服务条件一变，比较的基础也就变了。

提示词长度与上下文缓存

客服对话只带一个简短问题，和带上冗长历史记录、检索出的政策文档，处理起来并不一样。输入增加，给出答案前的计算工作也会变化。Groq 在延迟优化指南中，将输入规模列为影响 TTFT 的因素。

测试记录中应保留提示词长度和缓存状态。KV cache 详解 介绍了生成过程中保存的注意力状态，以及提示词复用与缓存的关系。不能把反复使用、已经预热的提示词，悄悄当作一段全新客户对话的代表。

答案出来前，还有推理过程

推理模型可能先生成中间推理 token，再交付答案。token 生成速度快，并不能说明它会推理多久。阅读速度数据时，要确认它是否包含这段推理输出，以及首 token 计时停在推理文本出现时，还是答案文本出现时。

对预订助手来说，有用的节点是给出可用的回复，或发起工具调用。界面显示“思考中”可以让用户知道请求已收到，却不代表预订已经完成。

批处理负载与并发

批处理把多个请求放在一起执行，以提高硬件利用率。总吞吐量统计的是多个请求合计产生的输出；单用户速度描述的则是某个请求实际收到的流。Cerebras 指出，批处理可以提高吞吐量，同时也可能增加等待时间。来源：Cerebras 对吞吐量的说明。

运维人员需要确认：其他对话涌入时，每段对话还能持续输出吗？测试应覆盖具有代表性的并发流量，并计入失败请求和重试。服务端点几乎空闲时测出的好成绩，回答不了这个问题。

部署区域与传输链路

应用和服务端点的位置会影响网络延迟。Groq 在网络分析指南中，区分了服务端计时和客户端实际感受到的延迟。

应在后端实际部署的区域测量。如果应用会把流式响应代理转发到浏览器，还要增加浏览器端测量：中间环节的缓冲可能让上游平稳的响应，在页面上变成一阵一阵地出现。修复这条链路，有时比换模型更有效。

不同 GPU 的每秒 token 数能直接比较吗？

GPU 是执行推理的加速器。脱离模型和负载，单独给它标一个每秒 token 数，并没有明确意义。比较硬件时，速度结果旁应同时列明模型、数值精度、上下文、服务配置和并发负载。

量化通过降低数值精度来节省内存；速度和质量之间如何取舍，取决于具体实现。Cerebras 在模型压缩说明中解释了这一点。比较压缩后的部署方案时，可以参考 LLM 量化指南，并在测量耗时的同时保留答案质量检查。

厂商公布的速度，应该怎么看？

看待公开速度数据时，应明确它出自哪家厂商、对应哪个模型，以及核实日期。以下厂商页面已于 2026 年 10 月 24 日核实。这些数字来自厂商，并非本文自行实测。

Cerebras：公布速度时，也要看部署限制

推理服务商 Cerebras 在 Developer 表格中，将 OpenAI GPT-OSS 120B 的速度列为 “~3000 tokens/s”。同一页面也说明，性能因模型和配置而异，Developer 访问面向评估用途，而非生产环境。来源：Cerebras 定价页面。

真正需要确认的是：你能购买的部署方案，在处理你的负载时，能否达到所需的响应速度和容量。仅凭这张表，无法得出答案。

Groq 的每秒 token 数：看清对应的模型行

推理服务商 Groq 在支持的模型列表中，将 OpenAI GPT-OSS 120B 的 “SPEED (T/SEC)” 一栏列为 “500”。这是 Groq 针对该模型行公布的数据。来源：Groq 支持的模型列表。

这些表格不足以确定两家服务商在实际应用中的速度比例。要作出这种判断，仍需对齐提示词、推理设置、token 统计口径、负载和计时边界。

权衡速度与成本时，可以结合 Cerebras 定价指南和 Groq 定价指南，比较成功完成一次任务的成本，以及所需容量。

独立测速数据去哪里看？

独立基准测试服务 Artificial Analysis 可以作为比较模型和推理服务商的起点。打开它的服务商排行榜后，还要查看每项结果对应的端点和测试负载。

其性能测试方法目前规定：

• 默认负载约为 10,000 个输入 token，以及至少 1,500 个答案 token。
• 常规负载的结果取过去 72 小时的中位数。
• 主测试服务器位于 Google Cloud 的 us-central1-a 可用区。
• 性能统计统一使用 o200k_base，而不是各模型原生的 tokenizer。

这提供了统一的比较基准，但不代表你的应用也能达到同样表现。比较结果前，应检查提示词规模、端点、推理模式和日期。提示词变长，可能同时改变首 token 延迟和输出速度。

对于隐藏部分推理 token 的推理模型，Artificial Analysis 会根据最后 80% 的答案文本块计算输出速度。下面的简单脚本既不复现这种算法，也不复现完整的基准测试负载；它测量的是你实际观察到的文本流。

如何实测自己的流式输出？

在接收响应的客户端计时，统计文本 token，而不是流式事件数量。一个事件可能没有文本，也可能包含一整块文本；如果数事件，得到的就是每秒文本块数。

下面的 Python 示例使用 Groq 流式 API 和文本分词器 tiktoken。它会报告首个文本块延迟、从请求发出到最后文本到达的耗时、流式响应完成时间，以及按统一分词口径估算的每秒输出 token 数。

安装依赖：

python3 -m pip install groq tiktoken

在环境变量中设置 GROQ_API_KEY。将 GROQ_MODEL 设为 Groq 支持的模型列表中、你的账户可用的非推理文本模型，并在 prompt.txt 中放入一条能代表实际应用的提示词。将以下代码保存为 measure_stream.py，然后运行 python3 measure_stream.py。

import os
from pathlib import Path
from time import perf_counter

import tiktoken
from groq import Groq

encoder = tiktoken.get_encoding("o200k_base")
prompt = Path("prompt.txt").read_text(encoding="utf-8")
model = os.environ["GROQ_MODEL"]
parts = []
first = last = None

with Groq(max_retries=0) as client:
    start = perf_counter()
    stream = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        stream=True,
    )
    for event in stream:
        now = perf_counter()
        if not event.choices:
            continue
        text = event.choices[0].delta.content or ""
        if not text:
            continue
        if first is None:
            first = now
        last = now
        parts.append(text)
    end = perf_counter()

if first is None:
    raise SystemExit("No text received; no text-speed measurement.")

# Tokenize after timing; never count events as tokens.
count = lambda text: len(encoder.encode(text, disallowed_special=()))
total_tokens = count("".join(parts))
post_first_tokens = total_tokens - count(parts[0])
span = last - first

print(f"First text chunk / TTFT estimate (s): {first - start:.3f}")
print(f"Request to last text (s): {last - start:.3f}")
print(f"Stream complete (s): {end - start:.3f}")
print(f"Normalized output tokens: {total_tokens}")
if span > 0 and post_first_tokens > 0:
    print(f"Post-first output tok/s (estimate): {post_first_tokens / span:.1f}")
else:
    print("Output tok/s unavailable: insufficient text delivery intervals.")

Groq SDK 支持关闭自动重试。示例关闭了这项功能，避免把重试等待悄悄算进一个看似成功的样本；请求失败，就应记录为失败。

计算速度时，token 数和交付时间都不包含首个文本块。 这里采用了 Artificial Analysis 指标定义中基于文本块的公式；确定最后一段文本的到达时间时，也会忽略流末尾的元数据。

这个示例适用于纯文本。推理流、工具调用参数或音频，需要分别处理各自的事件类型，并明确什么才算有用的首次输出。做比较时，应保留提示词和设置，记录输出长度，并在实际部署区域、具有代表性的负载下重复测量。既保留典型结果，也保留慢请求；不要把最快的一个样本当成性能保证。

计算器和模拟器能告诉你什么？

规划工具可以演示某个计时假设，却无法替你测出实际端点的延迟。

每秒 token 数模拟器该怎么用？

可以用模拟器讨论聊天界面应该边收到边显示文本，还是等完整对象生成后再展示。随后，要用真实观察到的流式响应验证设计。恒定的模拟速度，无法判断实际响应是否会停顿、分批涌出，或卡在工具调用上。

对于已经完成的文本响应，时间关系很明确：从发出请求到最后文本到达的耗时，等于初始等待时间，加上首个与最后一个文本块之间的时间。 脚本直接测量这两段时间，而不是从宣传速度倒推。

每秒多少 token 才算够用？

合理的目标，来自任务中真正让人等待的环节。先回答与你所构建的体验有关的问题，再设定指标。

**开发语音应用时：**用户说完一句话后，要等多久才能听到有用的回复？能否在完整答案生成前就开始播报？音频缓冲会不会耗尽？用户能否打断？如果沉默发生在文本开始输出之前，提高解码速度可能解决不了主要问题。

**开发聊天应用时：**用户等的是第一句有用的话、完整解释，还是一个有效的结构化结果？界面能否显示部分输出？客服回答和可导出的报告，完成节点并不相同。应测量界面真正需要的那个节点。

**运营智能体时：**任务有多少时间花在模型生成上，又有多少花在工具执行上？响应更快后，工具参数还能保持正确，任务还能成功完成吗？下一步是否必须等全部输出结束？如果优化错了时间段，整个工作流的完成时间可能几乎不变。

**采购推理服务时：**拟采用的部署方案，能否在你的区域、你的流量和提示词条件下，维持所需的体验？引用的成绩能否代表该部署的典型表现？请求失败或容量繁忙时，又会怎样？

当追踪数据表明用户在等待生成过程或第一个有用答案时，就该着手优化。尚未定位主要延迟之前，先别急着迁移服务商。如果后台任务已经能按时完成，更高的宣传速度通常不会带来多大影响，除非吞吐量或成功完成任务的成本改变了取舍。

LLM 速度有哪些被夸大的说法？

最常见的夸大，是把输出速度最高等同于应用最该选择的服务端点。速度证明不了答案质量、输出有效性，也证明不了工具能被成功调用。

再快的端点，最终也会受周围应用环节的限制。文本生成更快，修不好缓慢的数据库调用，消不掉不必要的冗长推理，也救不了无法通过校验的响应。同样，漂亮的首 token 成绩，也可能掩盖后续流式输出停滞、用户迟迟拿不到有用内容的问题。

评估时要保留速度指标，但终点应是正确、可用的结果。

常见问题

下一轮开发，先测哪个环节？

下一次迭代时，选一轮有代表性的语音交互、一条聊天提示词，或一项智能体任务，先定义什么状态才算结果可用。为这个节点埋点，同时记录首次输出和流式响应完成时间。让候选端点处理同一任务，检查失败情况，再优化真正让用户等待的那段时间。

想获取构建实用 AI 应用的操作指南，可以订阅邮件通讯。