为什么大模型性能测试不能只看“并发数”和 Token/s？

最近在做大模型和企业办公智能体性能测试时，我越来越明显地感觉到一个问题：

我们很容易把传统性能测试里的「并发数」，再加上一个大模型特有的「Token/s」，就当成了大模型性能测试。

于是经常能看到这样的测试结论：40 并发运行正常，平均生成速度 XX Token/s，系统性能满足要求。

这个结论不能说错，但它能说明的事情其实非常有限。

因为对于一个真正给用户使用的大模型系统来说，用户关心的并不是 GPU 一秒钟吐出了多少 Token，而是：

• 我点击发送以后，要等多久它才开始回答？
• 开始回答以后，是不是流畅？
• 人多以后，会不会一直排队？
• 一个完整任务到底多久才能做完？

如果再往企业级智能体走一步，问题会更加复杂。

用户表面上只问了一句话，后台可能经历了意图识别、知识库检索、模型推理、工具调用、再次推理、结果整理等多个环节。一次用户请求，实际上可能被放大成三次、五次甚至更多次模型调用。

所以，大模型性能测试真正需要回答的，并不是「这套机器能跑多少并发？」，而应该是：

在什么业务场景、什么上下文长度、什么响应体验要求下，这套资源能够稳定支撑多少真实用户？

一、为什么「40 并发」本身几乎没有意义？

传统 Web 系统里，我们习惯说：100 并发、500 并发、1000 并发。

因为大多数传统交易的资源消耗相对稳定，一个查询请求和另一个查询请求虽然不完全一样，但差异通常不会达到几个数量级。

大模型不是这样。

同样一个请求，可以是「输入 500 Token / 输出 200 Token」，也可以是「输入 100,000 Token / 输出 4,000 Token」。这两个请求如果都叫「1 个并发」，显然不是同一种负载。

尤其是长上下文场景，输入 Token 数量会直接影响 Prefill 阶段的计算量和 KV Cache 占用；输出长度又会影响后续 Decode 阶段持续占用计算资源的时间。

所以：40 个短问答并发 ≠ 40 个长文档分析并发。

甚至同样都是「40 并发」，如果一个场景平均 30 秒结束，一个场景平均 5 分钟结束，它们对应的系统压力和能够支撑的真实用户规模也完全不同。

这也是为什么我现在更倾向于把「并发数」理解成测试施加了多少压力，而不是系统性能有多好。

图 1 · 同样叫「40 并发」，短问答、文档总结、长文档分析的算力消耗完全不同

二、Token/s 也没有我们想象得那么简单

第二个特别容易被误用的指标，就是 Token/s。

比如有人告诉你：这个模型能够达到 100 Token/s。第一反应通常是：挺快。

但这里首先需要问一句：到底是谁的 100 Token/s？

至少存在两种完全不同的口径：

• 单请求生成速度：某个用户的回答开始生成以后，模型平均每秒给这个用户输出 100 个 Token。
• 整个推理服务的总 Token 吞吐量：8 张卡同时处理几十个请求，一秒钟总共生成 5000 个 Token。

这两个指标完全不是一回事。

随着并发提高，经常会出现一种情况：系统总体 Token 吞吐量越来越高，但单个用户的 Token 生成速度越来越慢。

从 GPU 利用率来看，这可能是一件好事。从用户体验来看，却未必。

假设 10 并发时单用户 80 Token/s，40 并发时单用户 40 Token/s，80 并发时单用户 20 Token/s —— 与此同时，系统总吞吐量可能还在持续增长。

如果只看总 Token/s，会觉得资源利用得越来越充分。但如果站在用户角度看，则可能已经变成：系统越来越卡。

所以大模型性能测试里，一个非常重要的原则就是：吞吐能力和用户体验必须同时观察。不能为了追求最高 Token 吞吐，把系统压到用户已经无法接受的状态。

图 2 · 并发增加后：系统总吞吐持续上升，但单用户生成速度持续下降，拐点出现在 40 并发附近

三、真正影响用户第一感受的是 TTFT

如果让我从大模型性能指标里只挑一个最容易被用户感知的指标，我会优先看 TTFT（Time To First Token）。

它表示：用户发送请求以后，到收到第一个输出 Token 之间等待了多久。

例如用户 10:00:00 点击发送，10:00:03 开始出现第一个字，那么 TTFT 大约就是 3 秒。

TTFT 实际上非常重要，因为用户并不知道 GPU 利用率是多少，也不知道系统当前跑了多少 Token/s。他首先感受到的是：「为什么还没开始回答？」

在客户端测量口径下，TTFT 通常不仅包含模型计算本身，还可能包含网络传输、请求排队、Prompt 处理以及生成首个输出等阶段。NVIDIA AIPerf 和 vLLM 目前也都把 TTFT 作为独立指标统计。

尤其长上下文场景，这个指标会变得更加明显。500 Token 的问题和 128K 上下文的问题，即使最终输出都是 500 Token，TTFT 也可能存在非常大的差异。

因为模型在真正开始生成答案以前，需要先完成输入上下文的 Prefill。所以测试 128K、200K 这类长上下文模型时，如果只统计「最终生成速度」，其实会漏掉非常关键的一部分体验。

四、开始回答以后快不快，要看 TPOT

TTFT 解决的是：多久开始回答。接下来还要回答：开始以后，回答得顺不顺。

这里就涉及另一个指标：TPOT（Time Per Output Token）。

简单理解就是：第一个 Token 出来以后，后面的每个 Token 平均需要多长时间。

vLLM 当前采用的请求级 TPOT 计算方式可以简化理解为：

TPOT = （端到端响应时间 − TTFT）÷ （输出 Token 数 − 1）

TPOT 越低，意味着后续 Token 生成越快。例如：

• 20 ms / Token ≈ 50 Token/s
• 50 ms / Token ≈ 20 Token/s
• 100 ms / Token ≈ 10 Token/s

所以从用户体验来看：TTFT 决定「什么时候开始说话」，TPOT 决定「说话的时候是不是流畅」。

这两个指标必须拆开看。因为完全可能出现 TTFT 只有 2 秒，但是开始回答以后非常慢；也可能出现 TTFT 需要 20 秒，但是一旦开始输出，后面非常快。

如果最终只给出一个「平均响应时间 35 秒」，实际上你根本不知道问题发生在哪。

图 3 · 一次大模型请求到底慢在哪里：把「总响应时间」拆开，才能判断问题出在网络、排队、Prefill 还是 Decode

五、高并发情况下，我反而特别关注 Queue Time

实际做算力测试时，有一个现象非常值得观察。

假设 20 并发正常，30 并发正常，40 并发开始出现等待，50 并发以后等待越来越明显。这个时候系统不一定报错，GPU 甚至可能一直保持高利用率。

如果只看「请求成功率」，很可能还会得到：100% 成功。

但系统其实已经进入了另外一种状态：算力供给速度赶不上请求进入速度。请求开始在 Scheduler 前面排队。这就是 Queue Time。

vLLM 的生产监控指标中就单独提供了 request_queue_time_seconds，同时还能观察运行中请求和等待中请求数量。

我觉得这个指标对于做容量判断尤其重要。因为：系统真正的性能拐点，很多时候不是从「报错」开始的，而是从「排队」开始的。

例如原来 TTFT = 3 秒，随着并发提高变成 5 秒、10 秒、20 秒、40 秒。如果继续往下拆，会发现模型本身 Prefill 可能没有慢这么多，真正增加的是 Queue Time。

这说明问题已经从「模型算得慢」变成了：算力不够用了。

图 4 · 并发增加后 TTFT 为什么突然恶化：低负载时 Queue 接近 0，进入拐点后 Queue Time 快速膨胀并推高整体耗时

六、最终还是要回到端到端响应时间

TTFT、TPOT、Queue Time 都很重要。但做企业级系统性能测试，最终不能只停留在这些模型指标。

因为用户真正完成的是一个任务。比如：「帮我分析这份 30 页的制度文件。」

用户不会关心模型 Prefill 用了 8 秒、Decode 用了 20 秒。他只知道：我从点击发送到拿到完整结果，一共等了多久。

所以还需要一个最基本的指标：End-to-End Latency，端到端响应时间。

对于单模型聊天，它大致就是：请求发送 → 排队 → Prefill → TTFT → 持续生成 → Last Token。

但是到了 Agent 场景以后，事情会复杂很多。

七、到了 Agent，单次模型调用性能已经不够用了

假设用户问智能体：「帮我分析这份制度文件，找出其中涉及性能测试的要求，并结合现有规范给出修改建议。」

后台可能不是调用一次大模型就结束。实际过程可能类似：

用户请求 → 意图识别 → LLM #1 → 知识库检索 → LLM #2 → 读取附件 → 工具调用 → LLM #3 → 再次检索 → LLM #4 → 结果整理 → 用户收到最终答案。

用户只发起了 1 次请求，但模型后台实际上执行了 4 次推理。

这就是我认为企业智能体性能测试中特别需要关注的一个概念：Agent 调用放大。可以定义一个非常简单的指标：

模型调用放大倍数 = 模型实际调用次数 ÷ 用户任务数量

例如 100 个用户任务，后台总共调用了 380 次模型，调用放大倍数 = 3.8。这时候 100 个业务请求 ≠ 100 个模型请求，而是 100 个业务请求 → 380 个模型推理请求。

如果还有重试、反思、自我纠错、规划或者多 Agent 协作，放大倍数可能还会继续增加。这对容量规划的影响非常大。

图 5 · Agent 调用放大：一次用户任务在后台被拆成多次模型调用、知识库检索和工具执行

八、多轮会话还会带来第二层「放大」

Agent 是一种调用次数上的放大。还有一个经常被忽略的问题：多轮会话会带来上下文长度上的放大。

比如第一轮用户输入 300 Token、上下文为 0；第二轮请求时，系统可能会把「第一轮问题 + 第一轮回答 + 第二轮问题」一起送给模型。

随着会话继续，上下文可能从第 1 轮的 2K，涨到第 3 轮的 8K、第 5 轮的 20K、第 10 轮的 50K。即使用户每次只输入几百个 Token，真正送进模型的 Prompt 也可能越来越长。

所以一个办公智能体的真实性能测试，不应该永远都是「新建会话 → 发一个问题 → 得到答案 → 结束」。

现实用户会继续追问、要求修改、补充附件、引用上一轮内容、要求基于之前结果继续生成。因此需要增加：多轮会话性能测试。

否则测出来的可能只是第一轮性能，而不是真实办公过程中的性能。

图 6 · 多轮会话：用户每轮输入变化不大，但历史上下文不断累积，Prefill 压力持续增加，TTFT 随之上升

九、所以我现在更愿意把指标分成三层

经过一段时间的大模型性能测试实践，我觉得企业级 AI 性能指标至少应该分成三个层面来看。

第一层：模型推理层

回答的是：模型本身跑得怎么样？

重点看：TTFT、TPOT / ITL、Input Token/s、Output Token/s、Prefill Time、Decode Time、KV Cache 使用情况。

其中 vLLM 目前的生产指标已经将 TTFT、TPOT、ITL、Prefill、Decode 以及 KV Cache 等指标分别暴露出来。

第二层：服务容量层

回答的是：人多以后还能不能保持这个体验？

重点看：并发请求数、Running Request、Waiting Request、Queue Time、Request/s、Input Token Throughput、Output Token Throughput、失败率、超时率、P95 / P99。

这里最重要的不是找到「系统最多能塞进去多少请求」，而是找到：在目标响应指标不被突破的前提下，最多能够稳定处理多少请求。这两个容量完全不同。

第三层：业务体验层

也是企业智能体最容易漏掉的一层。回答的是：用户完成一个真实任务到底需要多久？

例如文档生成耗时、PPT 生成耗时、知识问答完成时间、数据分析完成时间、代码生成完成时间、多轮任务完成时间、Agent End-to-End Duration。

对于 Agentic AI，MLCommons 目前也已经把完整 Agent 任务的 End-to-End Duration 作为独立性能指标，统计范围覆盖多轮模型推理和工具执行，而不只是某一次模型调用。

这其实和企业真正关心的问题更加接近。

图 7 · 三层指标体系：底层解释「为什么慢」→ 中层判断「能支撑多少」→ 上层验证「用户能不能接受」

十、一个真正有意义的性能结论应该怎么写？

所以，如果以后再看到这样的结论：4 台服务器部署 XX 模型，测试 40 并发，Token 生成速度 XX Token/s，测试通过。

我觉得至少还缺一半的信息。更加完整的描述应该是：

在 XX 业务场景下，平均输入长度 XX K Token、平均输出长度 XX K Token，持续 XX 并发运行；P95 TTFT 为 XX 秒，P95 TPOT 为 XX ms，单请求平均生成速度 XX Token/s，系统总输出吞吐 XX Token/s。40 并发以内请求基本无排队；达到 XX 并发后 Queue Time 明显增加，并进一步推高 TTFT。按照目标 TTFT ≤ XX 秒、端到端 P95 ≤ XX 秒的体验要求，当前资源下建议稳定运行负载控制在 XX 范围。在 Agent 场景下，平均每个业务任务触发 XX 次模型调用、XX 次知识库 / 工具调用，完整任务 P95 耗时 XX 秒。

这样，我们才能真正回答：这套资源到底能支撑什么。而不仅仅是：这套机器最多能压到多少并发。

十一、真正应该寻找的是「可用容量」，而不是「极限容量」

我觉得这是大模型性能测试和传统容量测试里非常容易混淆的一件事情。

假设测试结果是：60 并发没有报错，80 并发没有报错，100 并发也没有报错。是不是意味着系统可以支撑 100 并发？

不一定。如果 100 并发情况下 TTFT 已经达到 45 秒、请求平均排队 30 秒、单用户生成速度降到 8 Token/s、完整任务需要 5 分钟 —— 虽然系统没挂，但用户可能已经不愿意用了。

因此真正需要寻找的不是「最大能压到多少」，而是：在目标用户体验约束下，最大能够稳定支撑多少。

可以把这个概念叫做：有效容量 / 可用容量，也就是满足「TTFT SLO + TPOT SLO + E2E SLO + 错误率 SLO」条件下的最大稳定业务负载。

我认为，这才是企业做大模型算力规划时真正有价值的数据。

图 8 · 极限容量 ≠ 可用容量：系统在 80 并发时仍能成功处理请求，但体验指标早已突破目标；真正有价值的是满足 SLO 前提下的「可用容量」

十二、最后

大模型性能测试真正难的地方，其实不是多增加几个监控指标，而是测试对象发生了变化。

以前我们测试的是：请求 → 应用 → 数据库 → 响应。

现在测试的可能是：用户任务 → Agent → RAG → Model → Tool → Model → Search → Model → 最终结果。

所以单纯讨论「多少并发？」已经不够，单纯比较「谁的 Token/s 更高？」也不够。

我现在更关注的是一条完整的性能链路：

并发用户 → 实际请求量 → Agent 调用放大 → 模型排队 → TTFT → TPOT → Token 吞吐 → 多轮上下文增长 → 完整任务响应时间

最终再把这些指标收敛成一个企业真正需要回答的问题：

在我们的真实业务场景下，在用户能够接受的响应体验范围内，一套确定的算力资源究竟能够稳定服务多少人？

这个问题回答清楚了，性能测试的数据才真正能够支撑后面的容量评估和算力规划。否则，40 并发也好，100 Token/s 也好，都只是一个孤立的数字。