做容量规划时最常卡在一句话上：「一张卡到底能扛多少并发？」厂商说能跑，压测说跑不动，中间差的往往是上下文长度、量化和延迟目标这三个变量。这篇不给现成数字，而是给一套从显存扣减到并发数的推算顺序，以及哪些假设一变结论就作废，让你自己算得出属于你业务的那条线。
做容量规划最常卡在一句话上：「一张卡到底能扛多少并发？」厂商说能跑，你压测说跑不动，中间差的往往就是上下文长度、量化档位和延迟目标这三个变量。这篇不给现成数字，因为数字换一批流量就作废；给的是从显存扣减一路推到并发数的顺序，以及哪些假设一变结论就得重算。
先说个前提：并发数不是卡上的固有参数，是你业务场景下的一个结果。同一张卡，跑短 prompt 和跑长文档，能塞进去的请求数可能差好几倍。所以下面每一步都要带上你的真实参数，算出来才是你的线，不是别人的线。
先定义：你要的「并发」是哪种
很多争论其实是口径不同。销售说的并发、压测脚本里的并发、以及线上监控上的并发，经常指的不是同一个东西。坐下来算之前，先把口径对齐，否则后面每一步都在换尺子量。
- 同时在线的请求数
- 连接还挂着、但可能正在排队等算力，这个数可以很大，参考意义有限
- 同时在算的批大小
- 真正进入一轮前向计算的请求数，这个数直接决定吞吐和单请求速度
- 单位时间吞吐
- 每秒或每分钟完成的请求数，批量业务真正该看的指标
- 延迟目标
- 首 token 时间与单请求生成速度，聊天类业务先卡这个，再看别的
不同业务对「扛得住」的定义不一样。聊天类看首字多快出来，用户等两秒就皱眉；离线批量任务则完全不看单条快慢，只看整体吞吐，可以一路堆到显存上限。这两种思路算出来的并发数能差一个量级，别拿一套数去汇报两件事。
显存怎么扣：先扣固定项，再谈并发
并发数的上限就是显存能塞下多少条请求的中间状态。所以第一步是把显存一项一项扣掉，剩下多少才是能给并发用的。扣减顺序错了，特别容易高估。
- 扣权重按模型参数量乘以每参数字节数估，量化档位直接决定这一项的量级。具体某型号的占用，到 模型资料库（/models） 核对参数与量化说明。
- 扣 KV Cache和上下文长度、层数、注意力头数相关，长上下文场景下这项常常比权重还大，后面单独一节讲。
- 扣激活与框架开销推理框架本身要占一块，运行时的中间激活也要占，这部分和批大小相关，批越大涨得越明显。
- 扣碎片余量显存分配不是严丝合缝的，留出余量很重要。跑满会触发重算甚至直接 OOM，具体表现可以对照站内的显存排查内容看。
四项扣完，剩下那部分才是真正用于并发的额度。很多人只扣了权重就报数，结果现场一跑就炸，问题就出在后面三项被忽略了。
KV Cache：并发数真正的天花板
KV Cache 是每条请求在生成过程中必须保留的中间状态，长度随上下文线性增长。同一张卡，短上下文能塞的并发数可能是长上下文的好几倍，别拿短 prompt 的测试结果去汇报长文档业务。
| 场景 | KV 占用特征 | 对并发的影响 |
|---|---|---|
| 单轮短问答 | 每条占用小 | 并发上限高，瓶颈常在算力 |
| 长文档摘要 | 每条占用大 | 并发上限被显存压住 |
| 多轮对话 | 历史累积 | 轮次越多占用越大，需按最坏情况估 |
| 长短混合 | 按最长的算 | 批内被最长的请求拖累，整体下降 |
算出单条请求的 KV 占用后，用可用显存除以它，得到的是理论上限，不是可用值。常见折扣项有三个：框架预留、批内长短请求混排导致按最长的算、以及多轮对话历史的累积。实际可用的数通常明显低于理论值。
- 用真实 prompt 长度分布去算，取 P95 而不是平均值，平均值会骗人
- 多轮场景按最大历史轮数估，不要按当前几轮估
- 混合流量场景按最长的那类请求估，因为批是按最长的对齐
- 留出安全水位，别把理论上限当成线上容量
量化档位怎么改结论
量化主要压缩的是权重，对 KV Cache 的压缩效果要看具体方案，不能默认一切都等比缩小。这一点最容易让估算跑偏：权重降了，以为并发就能同步翻倍，结果 KV 那一项没怎么动。
低比特量化通常能换到更多并发余量，因为权重那块腾出了显存。代价是输出质量和兼容性风险要单独评估，尤其对格式敏感的业务。具体各档位的取舍，可以到 指南中心（/guides） 看当时的整理。
| 量化档 | 权重占用 | 对并发的作用 | 要注意的 |
|---|---|---|---|
| 高精度 | 大 | 余量小，并发受限 | 质量最稳，适合对输出严格的任务 |
| 中等 | 中 | 余量适中，常见折中 | 质量和兼容性需实测确认 |
| 低比特 | 小 | 余量最大，并发上限高 | KV 不一定同比例缩小，质量风险单独测 |
批处理与调度：不是所有并发都能同时算
连续批处理会把等待中的请求塞进同一轮计算，看起来并发数上去了，但算力还是要在它们之间分。批越大，单请求生成速度越慢，整体吞吐上去、单条体验下降。这是取舍，不是 bug。
并发数一旦超过算力，表现出来往往不是报错，而是排队：指标上看是首 token 延迟一路上升，请求还在跑，只是慢了。所以压测时不能只看有没有失败，要看曲线拐点。
- 同时记录三条曲线：并发数、首 token 延迟、单请求生成速度
- 找拐点而不是找最大值，拐点之后加并发只换来延迟
- 长短请求混排时单独看长请求那条线，它先崩
- 排队现象出现时优先降并发或限上下文，而不是加机器
实测顺序：从基线到拐点
前面都是估算，最终要用实测收口。实测的关键是有顺序，别一上来就压高并发，那样拿到的是一堆分不清原因的数字。
- 测单请求基线先用一条请求量清楚网络和推理各占多少，可以借助站内 接口测速（/tools/speed-test） 把链路上的干扰先排掉。
- 固定上下文加梯度固定上下文长度，按梯度往上加并发，每档记录三条曲线，直到延迟目标被击穿。
- 换成真实混合流量把长短混合、多轮历史的真实分布再跑一遍，对比和上一轮差多少，差得多说明前面的估算假设有问题。
- 留安全水位按拐点的七成左右做线上容量，剩下的留给突发和长尾；峰值场景提前写好降级方案。
如果压测结果和你估算差很远，先别急着改模型，回头检查显存扣减的哪一项漏了、上下文是不是用了平均值。这类偏差多半出在假设而不是硬件上。
单卡算完之后：多卡和多副本怎么接
单卡算完只是第一步。真到容量不够时，加卡有两条路：把模型切开装到多卡上，或者多开几个副本各装一份。这两条路对并发的影响完全不同，选错方向会白花钱。
张量并行能装下更大的模型，但不会让并发数线性翻倍，卡间通信会吃掉一部分收益。多副本更适合提并发，前提是单副本能装下整个模型——装不下就只剩切分这一条路。
- 第一分叉：模型能否单卡装下，这决定走副本还是走切分
- 显存充裕但算力受限时，瓶颈在计算不在显存，思路要换成算力估算
- 切分方案要算通信开销，别按卡数直接乘并发
- 副本方案要配好路由和会话粘性，多轮对话别乱跳
容量规划清单：报数前先自查
最后给一份自查清单。报容量数字之前逐条过一遍，能省掉后面大半的返工。这些不是流程装饰，每一条都对应一个真实会翻车的地方。
- 模型参数量与量化档位写清楚，权重占用单独列一行
- 上下文长度用真实分位数，不是文档里的最大值
- 延迟目标写明首 token 时间和生成速度，和业务方对齐验收口径
- KV Cache 按真实流量形态估算，长短混合按最长的那类算
- 留余量，并写明峰值场景的降级方案：缩短上下文、降并发、切小模型
- 把估算和实测的差距记下来，下次估得准一点
这套方法不承诺任何具体数字，因为数字取决于你的模型、你的流量、你的延迟要求。能承诺的是：按这个顺序算，你得到的是一条有依据的线，而不是一个拍出来的数。各家的实际报价和规格随时在变，到 价格追踪（/price-watch） 核对当时的数字。
下一步把你自己业务的参数填进这份清单，先算一遍再压一遍；模型规格和报价会变，去站内资料库和价格追踪核对当时的数字，比记在脑子里的旧结论靠谱。→常见问题
能不能直接给一个每张卡支持多少并发的参考值？
给不了通用值。并发数取决于模型大小、量化档位、上下文长度、延迟目标四个变量，任意一个变都会大幅改变结果。可行的做法是拿你自己的真实 prompt 长度分布去压测，找延迟被击穿的那个拐点，再按七成留水位。
为什么我加了卡，并发数没有成比例上涨？
常见原因是模型用了张量并行切分而不是多副本部署，卡间通信开销会吃掉一部分收益；也可能是瓶颈根本不在显存，而在算力或调度。先确认单副本能否装下模型，能装下就优先堆副本而不是切分。
长上下文业务是不是并发一定很低？
通常是的，因为 KV Cache 随上下文长度线性增长，它经常比权重还占显存。但也要看你的请求是否真的每次都用到最长上下文；把系统提示和检索内容做裁剪，往往比换卡更有效。
并发数是不是只要不超过最大值就不会出问题？
不是。并发超过算力后不会报错，而是表现为排队，首 token 延迟慢慢涨上去，用户体感变差但监控上看着一切正常。所以要盯延迟曲线，不是盯有没有报错。
离线批量任务也要按延迟目标算并发吗？
不用。离线任务可以忽略首 token 延迟，把显存和算力堆到上限换总吞吐，策略和在线服务完全不同。做容量规划时先把在线和离线两类流量分开算，别用同一套参数。
