根据并发量推算推理算力需求，核心就一句话：用并发数除以平均单次推理耗时得到所需QPS，再对照单张显卡的实测吞吐反推卡数。
并发量和算力需求怎么算？先弄懂三个关键变量
很多人拿到并发数就直接查显卡参数,结果发现对不上，这里先给你一个行业共识：推理算力需求不是直接用并发数乘模型大小，而是通过QPS和单次耗时来换算。
并发数不等于每秒请求数（QPS）
并发数指的是同一时刻正在处理的请求数量,比如API网关显示当前有20个请求在排队或处理，而QPS是每秒完成的请求数，两者关系很简单：QPS ≈ 并发数 ÷ 平均单次处理耗时。
举个例子,如果平均每个请求推理要200毫秒，那么20并发下，每秒能完成的请求数是20÷0.2=100，这里有个容易踩的坑：如果请求耗时拉长到500毫秒，同样20并发，QPS就掉到40，所以先别急着定显卡，先把你线上真实的平均耗时抓出来。
单次推理耗时是核心分母
单次推理耗时取决于模型结构、输入长度、batch大小和硬件，业内专家指出，同一个模型在A100和4090上的耗时可能差好几倍，同时batch从1调到8，吞吐能翻好几倍，但单次延迟也会上升，所以你需要在你目标硬件上实测，而不是看官方理论算力。
建议用ONNX Runtime或TensorRT做一次基准测试，具体操作：
- 准备一批真实业务样本,至少100条
- 在目标GPU上跑多次推理,记录每次耗时
- 统计P50和P95耗时,取P95作为平均耗时的输入
注意要把预处理和后处理的时间也算进去,这部分同样占用CPU和显存，如果是流式输出的大语言模型，首token延迟和每个token的生成时间要分开记录，因为这类模型的并发估算方式跟普通分类模型很不一样。
算力需求的单位统一到TFLOPS或TOPS
显卡算力通常标称FP16 TFLOPS，但对推理来说，更常用的是TOPS（INT8）或者实际吞吐（requests/s），行业共识认为，把需求换算成QPS，再对比显卡的实测吞吐，是最靠谱的路径
，千万不要把显卡峰值算力直接当有效算力，通常利用率在30%到70%之间，所以估算公式要留出余量。
推理算力需求计算公式：从并发到显卡的实操路径
这里给一套能直接落到命令行的方法,按步骤走就能算出大致卡数。
第一步：确认业务峰值并发
不要取平均值,要取高峰期，比如早上10点用户集中点击，此时并发可能达到50，怎么得到这个数？有两条路：
- 从网关日志统计同一时刻在途请求数,以Nginx为例，可以写脚本匹配请求开始和结束时间，统计重叠数量
- 用压测工具（如wrk、Locust）按预期流量压出系统的并发上限
目标不是算平均并发,而是要找到最坏情况下的峰值并发，算力资源就是按这个值配置的。
第二步：测出单次推理耗时
在目标GPU上用你的模型跑真实数据,命令示例：
- TensorRT引擎：
trtexec --loadEngine=model.engine --warmup=100 --iterations=200 - Python脚本：循环推理N次，记录每次延迟，计算P50和P95
如果模型尚未部署,可以在单卡上先用batch=1测一遍，再用batch=4、8分别测，记录吞吐和延迟的变化曲线，这会直接影响后面的卡数判断。
第三步：用公式算QPS和总算力
核心公式：所需QPS = 峰值并发 ÷ 平均单次耗时。
假设峰值并发是40,平均耗时才120毫秒，那么QPS ≈ 40÷0.12 ≈ 333，这表示系统每秒要完成333次推理。
接着看单卡吞吐,假设实测单卡每秒能处理150个请求（batch=1），那么卡数 = 333÷150 ≈ 2.2，向上取整并留出40%冗余，所以需要4张卡，如果延迟要求更严，比如P95要小于200毫秒，batch大小就得调小，单卡吞吐会下降，卡数也要相应增加。
第四步：对照显卡性能选型
不同显卡的推理吞吐差异很大,下面给一组常见参考区间（基于公开benchmark和实际项目经验，具体以实测为准）：
| 显卡型号 | 常见用途 | 单卡参考吞吐（batch=1，INT8分类模型） |
|---|---|---|
| RTX 4090 | 中小服务、本地验证 | 80-150 req/s |
| L20 | 中大服务、性价比 | 100-180 req/s |
| A100 80G | 大模型高并发 | 200-400 req/s（取决于模型大小） |
| H20 | 大模型推理均衡 | 150-300 req/s |
需要注意,这只是分类模型的大致区间，像7B这样的大语言模型，A100生成1000个token的耗时可能要好几十秒，每秒请求数是单位数或两位数，所以大语言模型要按生成token数每秒来算，不能照搬分类模型的经验。
不同业务规模下的并发与算力估算对照表
结合前面的公式,给你一组更直观的估算场景。
假设一个OCR识别模型,单次推理耗时50毫秒：
- 并发10：QPS=200，单卡吞吐300 req/s，1张卡足够
- 并发50：QPS=1000，需要3-4张卡
- 并发200：QPS=4000，需要13-14张卡，这时要考虑多机负载均衡
再看一个7B大语言模型,每个请求生成300个token，生成总耗时约3秒：
- 并发10：QPS≈3.3，单卡能并发处理的请求数可能只有2-4个，需要3-5张卡
- 并发50：QPS≈16.7，需要10-15张卡
- 并发200：QPS≈66.7，需要30张以上
这组对比说明一个问题：大模型推理的算力需求比传统分类模型高一个数量级，做规划前，先确定业务类型，再套公式。
云端租卡还是自建机房？算力成本和地域怎么平衡
提到算力需求,一定会涉及价格和部署位置，这是很多团队纠结的地方。
中小业务：几十路并发怎么配
如果你只需要几十并发,优先考虑云端GPU实例，比如简米云或酷番云的按量付费GPU，低峰期可以释放资源，在这个规模下，自建机房完全不划算，以一张L20为例，按月租的价格大概几千元，而买一台双卡服务器要几万到十几万，还不算机房和带宽成本。
中大型业务：百路以上并发怎么规划
到了百路并发,月成本可能达到数万元，这时自建机房的优势才显现：静态成本可控、数据不出域、延迟更低，但前提是流量曲线稳定，如果流量波动大，建议混合部署：核心流量走自建，突发流量走云端扩容。
地域选择和数据合规
选GPU机房时,地域很重要，如果用户集中在华东，机房放上海或杭州会更近，延迟能低几十毫秒，如果涉及金融、政务数据，很多要求本地化部署，不能随便上公有云，做算力规划时，一定要一并考虑合规要求，别等卡不够了再搬家。
最后给你一个提醒：算力规划不是一次性动作，而是伴随业务增长的持续过程，上线后用监控工具持续追踪并发峰值和P95延迟，每季度重新估一次，就能避免算力浪费或突然过载。
常见问题：并发量上去了但算力不够会怎样
问题1：并发数只有20，但系统卡顿，是不是算力不够？
不一定,先看单次耗时长不长，如果模型推理只要30毫秒，20并发对应QPS约600，普通单卡就能扛住，卡顿可能是网关连接数不够、CPU预处理瓶颈、显存不足导致batch策略被迫调小，用压测工具分别测一下各环节耗时，再决定是否加卡。
问题2：推理算力需求公式里的并发数从哪里拿？
最准确的是业务压测结果,如果还在设计阶段，就按业务日活和高峰时段预估：假设日活1万，高峰集中在晚上8点到10点，两小时处理1万请求，平均每秒1.4个请求，再乘以峰值系数3到5，得到并发约5到7，这在初期足够做参考。
问题3：GPU利用率70%了，为什么还要加卡？
因为利用率高不代表延迟合格,如果P95延迟已经超过业务要求，比如用户明显感觉响应慢，那就必须加卡或优化模型，利用率70%只说明还有30%余量，但如果请求排队时间太长，P95会迅速恶化，判断算力够不够，主要看延迟SLA，而不是看利用率。