大模型部署如何评估并发能力？从 GPU 数量到 TTFT、吞吐量与压测实践

一、背景：为什么 GPU 数量不能直接决定并发能力？

在企业部署大语言模型时，经常会遇到这样的问题：

“如果系统有 400 个用户，高峰期可能有 50 个并发请求，那么使用 4 张 GPU 是否足够？还是必须配置 8 张 GPU？”

这个问题看似简单，但实际上无法只根据 GPU 数量给出准确答案。

因为大模型推理的并发能力受到多个因素影响：

• 模型参数规模与量化方式
• GPU 显存容量和计算性能
• 用户输入文本长度
• 模型生成内容长度
• 推理框架与调度策略
• 用户可以接受的响应时间

因此，评价大模型推理服务时，不能只关注能否同时接收 50 个请求，更应该关注：

在 50 个并发请求下，系统是否仍能满足响应速度、稳定性和吞吐量要求。

二、并发数、QPS 和吞吐量有什么区别？

这三个指标经常被混淆。

1. 并发数（Concurrency）

并发数表示某个时刻同时处于处理过程中的请求数量。

例如，50 并发意味着系统在某个时间点有 50 个尚未完成的请求。

但这不代表系统每秒能够完成 50 次请求。

2. QPS（每秒请求数）

QPS 表示系统每秒处理的请求数量，通常需要明确统计的是接收请求还是完成请求。

例如，系统每秒完成 5 个请求，则完成吞吐率为 5 QPS。

在稳定负载下，可以使用 Little 定律建立近似关系：

平均并发请求数 = 平均请求到达率 × 平均请求耗时

例如，平均请求耗时为 10 秒、每秒有 5 个新请求进入系统，那么平均在途请求数约为 50。

需要注意，这个关系需要系统处于相对稳定的运行状态。

3. Token 吞吐量

大模型不同于传统 Web 接口。

一次请求可能只生成几十个 Token，也可能生成几千个 Token。

因此，Token 吞吐量往往比单纯的 QPS 更能够反映模型推理能力。

常用指标包括：

• 输入 Token 吞吐量
• 输出 Token 吞吐量
• 总 Token 吞吐量

对生成式大模型而言，输出 Token 吞吐量尤其值得关注。

三、为什么要关注 TTFT 和 TPOT？

用户感受到的模型速度，通常可以拆分为两个阶段。

1. TTFT：首 Token 延迟

TTFT（Time To First Token）表示从发送请求到接收到第一个输出 Token 所需要的时间。

它通常包含：

• 请求排队
• 输入文本预处理
• Prefill 计算
• 首 Token 生成
• 网络传输

如果 TTFT 很高，用户就会觉得模型一直没有响应。

2. TPOT：平均输出 Token 时间

TPOT（Time Per Output Token）表示生成阶段平均每个输出 Token 所需要的时间，通常不包含首 Token。

例如，模型已经开始回答，但后续文字输出非常缓慢，就可能是 TPOT 较高。

对于一次生成多个 Token 的请求，可以使用以下公式：

TPOT =（端到端耗时 - TTFT）/（输出 Token 数量 - 1）

需要注意，不同压测工具的统计方式可能有所区别，实际比较时应统一口径。

3. 为什么两个指标要结合分析？

假设有两套推理服务：

• 系统 A：首 Token 很快，但后续输出缓慢。
• 系统 B：首 Token 稍慢，但后续生成速度较快。

如果应用是交互式 AI 助手，用户可能更关注首 Token 延迟。

如果应用是长文档分析、报告生成，端到端完成时间可能更加重要。

因此，应根据实际业务场景分配性能指标的优先级。

四、4 张 GPU 和 8 张 GPU 的差距有多大？

很多人会认为：

“8 卡的性能一定是 4 卡的两倍。”

实际上，这种理解并不准确。

1. 显存容量

部署大模型首先要考虑模型权重和运行时状态能否放入 GPU 显存。

显存除了保存模型权重，还需要容纳 KV Cache、运行时缓冲区等数据。

当模型参数规模较大时，可以通过张量并行将模型分布到多张 GPU 上。

但张量并行也会引入额外的通信开销。

2. 多卡不一定线性加速

例如：

方案 A：使用 4 卡部署一个模型实例。

方案 B：使用 8 卡部署一个模型实例。

方案 C：使用 8 卡部署两个独立的 4 卡实例。

这三种方案的性能特点可能完全不同。

对于能够在 4 卡上运行的模型，方案 C 可能在部分负载下具有更好的请求吞吐能力。

但方案 B 可能更适合对单个模型实例有较大显存需求的场景。

最终应该通过压测决定，而不是简单按照 GPU 数量推算。

3. KV Cache 是重要限制因素

大模型在生成过程中，需要保存历史 Token 的 Key、Value 状态，通常称为 KV Cache。

输入内容越长、并发序列越多，KV Cache 的内存需求通常越高。

因此，同一套硬件：

• 50 个短文本请求可能能够正常处理。
• 50 个超长文档请求却可能出现显存压力、排队或延迟增加。

这也是为什么必须按照真实业务输入长度进行压力测试。

五、如何设计一套合理的大模型压测方案？

建议采用逐级增加并发的方式，而不是直接测试最高并发。

1. 设计测试矩阵

以上仅为示例测试配置，并非真实压测数据。

正式测试时，还需要加入更长输入、不同输出长度和真实用户请求分布。

2. 使用 vLLM 进行测试

vLLM 是常见的大模型推理框架，提供了服务端 Benchmark 工具。

在模型服务已经启动的情况下，可以使用类似命令：

vllm bench serve \
  --backend openai \
  --endpoint /v1/completions \
  --model your-model-name \
  --dataset-name random \
  --random-input-len 1024 \
  --random-output-len 256 \
  --num-prompts 200 \
  --max-concurrency 50 \
  --save-result

其中需要将 your-model-name 替换为实际部署的模型名称，并根据服务地址与接口类型调整参数。

该命令可用于测试并发上限为 50 时的性能表现，但不代表始终维持 50 个活跃推理请求，也不能替代按照真实到达速率设计的业务压测。

3. 重点采集哪些指标？

尤其建议关注 P95，而不是只看平均响应时间。

因为平均值可能掩盖高峰负载下部分请求的长时间等待问题。

六、如何判断 50 并发是否达标？

建议在压测前先定义业务服务等级目标（SLO）。

例如，某个交互式 AI 问答应用，可以设定以下示例目标：

• 请求成功率不低于 99%
• TTFT P95 不超过 5 秒
• 端到端响应时间 P95 不超过 30 秒
• 持续运行期间无严重显存溢出
• 在目标负载下排队时间保持可控

这些只是用于说明的业务目标，不是所有大模型应用都必须满足的行业标准。

如果某套 4 卡方案能够稳定满足这些要求，就没有必要仅仅因为用户数较多而直接升级至 8 卡。

相反，如果虽然能够承接 50 个请求，但 P95 延迟达到数分钟，显然也不能认为系统具备良好的 50 并发服务能力。

七、从产品角度，如何做好容量规划？

对于企业级 AI 产品，建议从三个层次评估部署方案。

第一层：业务负载

明确用户数量、峰值请求量、典型输入长度、输出长度和实际使用时间分布。

第二层：技术性能

通过压测确定不同并发下的响应时间、吞吐量和资源利用率。

第三层：成本与扩展性

比较不同 GPU 配置的资源成本、可用性、扩容方式和单位有效吞吐成本。

需要注意，压测不能只验证系统能否完成短时间请求。

还应该开展持续负载测试，观察长时间运行过程中的显存使用、错误率和尾部延迟变化。

八、总结

大模型部署的容量评估，本质上不是一道简单的 GPU 数量计算题。

真正需要回答的问题是：

在既定模型、输入输出规模和业务响应要求下，系统能够稳定支持多大的请求负载？

因此，建议遵循以下原则：

1. 不用 GPU 数量直接推断并发能力。
2. 不将用户数、并发数和 QPS 混为一谈。
3. 同时评价 TTFT、TPOT、吞吐量和端到端耗时。
4. 使用真实业务流量进行分级压测。
5. 结合性能和成本选择最终部署方案。

对于企业 AI 应用而言，最合理的部署方案不一定是 GPU 数量最多的方案，而是能够以合理成本持续满足实际业务服务要求的方案。