什么是并发？一个服务同时接待多少人

同一个 AI 服务，同一时刻能接待多少用户同时提问，这个规模就是并发。大模型的算力是稀缺资源，一个请求从读题到写完答案要占用计算资源好一会儿，服务端能同时扛多少路这样的请求，直接决定了高峰期你是秒回，还是对着转圈图标发呆。

同时接待多少人怎么算

并发通常指活跃请求数：某一刻正在被处理、还没交出完整答案的请求总量。它和注册用户数、日活都不同——一百万注册用户里，同一秒涌进来的可能只有几百个，服务真正要扛的是这几百。超过扛得住的量，后来的请求就得排队，或者被限流。

这个规模受两层约束。一层是显存和算力，模型本身占着资源，每个进行中的请求还要额外占用一份上下文空间；另一层是调度能力，请求怎么分组、怎么穿插处理，决定了同样的硬件能榨出多少并发。这也是为什么同样规模的卡，不同团队的接待能力能差出一截。

接待名额具体被什么吃掉，三类占用分开看。

像商场收银台

理解并发，可以类比商场的收银台。营业时间是固定的，收银台数量决定了同时能结账的人数；人多台少，队就越排越长。AI 服务也一样：算力是收银台，请求是顾客，台子越多、每个顾客结得越快，同时招待的人数就越多。

收银台类比还解释了高峰期的策略选择。商场可以开应急通道、引导自助结账；服务端则可以限制单次输出长度、优先保障短请求，把有限的接待名额留给更多人。本质上都是在总量不够时做取舍。

收银台类比失灵处

这个类比有两处对不上。其一，收银员结完一单就彻底翻篇，模型的请求在输出过程中要持续占用资源，写得越久占得越久，不是“结完就走”。其二，收银台之间互不干扰，模型的多个请求却共享同一套权重和缓存，请求之间会互相挤占，这也是连续批处理调度要解决的核心难题。

还有一点：并发不是越高越好。接待人数加上去，每个人的速度被摊薄，首字时间和输出节奏都会受影响。服务方要在“多招呼人”和“每人招呼好”之间找平衡点。

并发高≠体验好

判断一个产品的接待能力，别只看宣传的并发数字，要结合负载看体验。同一时段提问的人少，再大的并发也显不出来；真到高峰期，首字时间和输出速度的变化才见真章。豆包和海螺AI在大促、热点事件时的稳定性常被用户拿出来讨论，靠的就是并发调度和兜底机制。还有一类隐形的名额消耗值得注意：长文档问答。上传一份几百页的材料，模型通读和检索都要占资源，一个这样的请求顶得上几十个短对话。高峰期你觉得“没几个人在提问却依然慢”，往往就是这类重请求在幕后占着名额，把它们错开到闲时，体验会立刻好转。

带走一个判断：并发是服务端的总接待规模，用户感知的却是分到自己头上的那份速度。两个数字一起看，才知道高峰期你我是被照顾的那个，还是被挤到队尾的那个，真被挤到了，换个时段再来，比干等聪明，错峰这招，比反复刷新按钮管用得多，也更能等出好体验。

速查表：并发=同时处理的活跃请求数；受算力和调度双重约束；类比商场收银台；失效在请求持续占资源且互相挤占；要看负载下的真实速度。

关于并发，问得最多的三个

• 并发和在线人数是一回事吗？不是，在线的人不一定在提问，并发只数正在处理的请求。
• 为什么有时明明人不多还是慢？可能存在少量超长请求长期占着资源，把接待名额吃掉了。
• 并发扩容是不是加卡就行？加卡解决算力上限，调度不改进，新增的容量未必用得上去。