部署一个大模型后，经常会遇到一个很实际的问题：

这套模型到底能让多少人同时使用？

是 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 并发，真正要看同一时间有多少人在请求模型。

第二，并发可以提前估算，但最终一定要通过真实业务压测确定。

第三，超过并发能力以后，不一定马上报错，可以先进入队列等待；流量再大，就需要限流、拒绝请求或者增加模型实例。

所以企业部署大模型时，真正需要回答的问题从来不是：

“这个模型最多能跑多少并发？”

而应该是：

“在用户体验还能接受的情况下，这套硬件能够稳定支撑多少并发？”

这才是一个真正有意义的“大模型并发指标”。