大模型到底能同时多少人用？一篇看懂并发、排队与容量估算
部署一个大模型后，经常会遇到一个很实际的问题：
这套模型到底能让多少人同时使用？
是 5 个人、20 个人，还是 100 个人？
很多人第一反应是看 GPU：
“我有两张显卡，是不是就能支持几十个人？”
实际上没这么简单。
大模型并发不是由某一个参数直接决定的，而是模型、GPU、显存、上下文长度、生成速度、推理框架以及你能接受的响应时间共同决定的。
一、先搞清楚：100 个用户，不等于 100 并发
这是最容易混淆的地方。
假设一个系统有：
100 个注册用户
但真正同一秒向模型发送请求的可能只有：
5~10 个人
那么真正对模型产生压力的是这 5~10 个请求。
所以我们通常说的模型并发，更准确地说是：
同一时间正在被模型处理的请求数量。
例如：
公司有 500 人使用系统
某一时刻：
张三正在生成答案
李四正在生成答案
王五正在生成答案
赵六正在生成答案
实际并发 ≈ 4
因此，评估模型容量不能简单问：
能支持多少用户？
更应该问：
高峰期预计会有多少人同时请求模型？
二、模型并发到底由什么决定？
可以先记住一个简单关系：
模型并发能力
= 模型大小
+ GPU 性能
+ GPU 显存
+ 上下文长度
+ 输出长度
+ 推理框架
+ 用户能接受的响应速度
其中最重要的可以分成两类。
第一类：显存能不能装得下
模型运行时，显存不只需要存放模型本身，还需要保存每个请求产生的 KV Cache。
可以把 KV Cache 简单理解成：
模型为每个正在聊天的请求保存的一份临时记忆。
假设同时有：
用户 A
用户 B
用户 C
用户 D
模型就需要同时保存多份运行中的上下文。
而且：
上下文越长
↓
KV Cache 越大
↓
单个请求占用显存越多
↓
能同时运行的请求越少
所以同一个模型：
每人输入 2K Token
和：
每人输入 100K Token
能够支撑的并发数量可能差很多。
第二类：GPU 算不算得过来
即使显存还能放得下，也不代表并发可以无限增加。
因为 GPU 的计算能力是有限的。
例如一套模型整体生成能力假设是：
800 Token/s
如果希望每个用户至少还能保持：
20 Token/s
那么可以做一个非常粗略的估算：
800 ÷ 20 = 40
也就是说：
从纯生成吞吐角度看，理论上大约能够同时服务 40 个正在生成答案的请求。
但注意：
这只是理论估算，不代表实际就能稳定跑 40 并发。
因为系统还要处理：
- Prompt 输入
- Prefill
- 长上下文
- 请求长短不一
- GPU 调度
- 网络传输
- 突发流量
所以生产环境最终还是需要压测。
三、并发其实同时受“显存”和“算力”限制
可以把它想象成一家餐厅。
GPU 显存像：
餐厅有多少张桌子。
GPU 算力像：
厨房一分钟能做多少道菜。
即使餐厅有 100 张桌子：
桌子很多
但厨房只有一个厨师：
做菜很慢
照样会排队。
反过来也一样。
厨房非常强，但是餐厅只有 10 张桌子，也不能同时接待 100 桌客人。
所以真正的模型并发大致可以理解成：
显存允许的并发
↓
实际并发 ≈ 取最小值 ← GPU算力允许的并发
↑
系统配置的并发上限
哪个先到瓶颈，哪个决定最终容量。
四、能不能提前算出“到底支持多少并发”？
可以估算，但很难只靠配置精确算出来。
可以先做两次估算。
1. 看显存
大致判断：
GPU总显存
-
模型自身占用
-
系统预留显存
=
可以留给 KV Cache 的显存
KV Cache 越多，理论上能够同时保持的活跃请求越多。
2. 看吞吐量
可以用一个非常实用的简单思路：
可接受并发
≈
模型整体 Token 吞吐量
÷
希望每个用户获得的 Token 速度
例如实际测试得到：
模型整体吞吐：1000 Token/s
希望用户使用时至少达到：
25 Token/s
那么：
1000 ÷ 25 = 40
理论上大约是 40 个生成中的请求。
但真正上线时不能直接按照理论极限设计。
更合理的做法是：
根据真实业务的输入长度、输出长度和并发模式进行压力测试，再确定安全并发值。
五、为什么“最大并发”其实没有一个固定答案？
因为你必须先定义：
多慢才算不能用了？
例如同一套服务器：
10 并发
首字 1 秒
生成 50 Token/s
体验很好
到了：
30 并发
首字 3 秒
生成 30 Token/s
还能接受
再到：
80 并发
首字 15 秒
生成 8 Token/s
从技术上看：
80 个请求可能仍然在运行。
但是从产品角度看：
这个系统其实已经“扛不住”了。
所以企业真正需要定义的不是：
GPU 最大能塞多少请求？
而是：
在保证用户体验的情况下，最多能够稳定支持多少并发？
这叫有效并发，比单纯追求最大数字更有意义。
六、如果并发满了，后面的用户怎么办？
这里就涉及排队。
假设服务器现在最多允许同时处理：
20 个请求
此时已经有：
1 ~ 20 号用户
正在运行
第 21 个用户来了以后，通常不是直接让 GPU 硬塞进去。
而是：
第21个请求
↓
等待队列
↓
前面的请求完成
↓
释放资源
↓
进入运行状态
整体可以理解成：
用户请求
↓
请求队列
↓
调度器
↓
GPU 当前有资源？
│
┌─┴─┐
有 没有
│ │
运行 等待
│ │
└──释放资源后继续──┘
这其实和银行取号非常像。
窗口忙的时候，并不是让所有人同时挤到窗口，而是先排队。
七、是谁负责排队？
通常是推理框架的调度器。
例如现在常见的：
vLLM
SGLang
都会负责把大量用户请求合理地交给 GPU。
以当前 vLLM 为例，它有专门的 Scheduler，可以限制一次调度的序列数量；默认支持先来先服务（FCFS），也支持优先级调度。当前版本还可以限制等待与运行中的请求总量，超过配置容量后可以拒绝新请求，让上层系统进行重试或转发到其他实例。
所以一个真正的大模型服务，并不是：
用户
↓
直接访问 GPU
而更像：
大量用户
↓
API 服务
↓
请求队列
↓
Scheduler 调度器
↓
批量组织请求
↓
GPU
↓
模型生成
这也是 vLLM 这类推理框架很重要的原因。
八、并发太高，除了排队还能怎么办？
如果业务量继续增加，单纯排队并不是最终解决方案。
假设：
一套模型实例
稳定支撑 30 并发
现在业务需要：
100 并发
那就可以部署多个模型实例：
用户请求
↓
负载均衡
↓
┌──────────┼──────────┐
↓ ↓ ↓
模型实例 A 模型实例 B 模型实例 C
30并发 30并发 30并发
这就从：
单机性能优化
进入了：
集群扩容。
实际企业的大规模 AI 服务，通常都会逐渐走到这一步。
九、企业到底应该怎么测模型并发？
真正上线之前，我认为至少应该关注四个指标：
| 指标 | 关注什么 |
|---|---|
| 并发数 | 同时有多少请求 |
| TTFT | 用户多久看到第一个字 |
| Tokens/s | 回答过程中生成多快 |
| GPU 显存 | 是否快达到显存上限 |
然后逐步压测：
1 并发
↓
5 并发
↓
10 并发
↓
20 并发
↓
50 并发
观察什么时候开始出现：
TTFT明显增加
Tokens/s明显下降
显存接近极限
请求大量排队
请求超时
这个位置附近，才是真正需要关注的容量边界。
十、最后总结
大模型能支持多少人同时使用，没有一个只看“模型多少B、几张GPU”就能直接得出的数字。
真正决定并发能力的是：
模型大小
+
GPU算力
+
GPU显存
+
上下文长度
+
KV Cache
+
Token生成速度
+
推理框架
+
允许的响应延迟
如果只记住三句话，可以记住：
第一，系统有 1000 个用户，不代表就是 1000 并发，真正要看同一时间有多少人在请求模型。
第二，并发可以提前估算，但最终一定要通过真实业务压测确定。
第三，超过并发能力以后，不一定马上报错，可以先进入队列等待；流量再大，就需要限流、拒绝请求或者增加模型实例。
所以企业部署大模型时，真正需要回答的问题从来不是：
“这个模型最多能跑多少并发？”
而应该是：
“在用户体验还能接受的情况下，这套硬件能够稳定支撑多少并发？”
这才是一个真正有意义的“大模型并发指标”。
浙公网安备 33010602011771号