1. 这个计算器到底在算什么先把这个项目的核心问题说清楚8张GPU到底能跑多少并发。这不是一个拍脑袋能回答的问题也不是简单地把单卡并发数乘以8就完事。我在实际做推理服务部署的时候最开始也以为8卡就是单卡能力线性放大结果上线之后被现实狠狠教育了一顿。这个计算器要解决的核心痛点很具体当你手里有8张GPU比如8张A100 80G或者8张4090或者昇腾系列你要部署一个大模型推理服务老板或者客户问你“这套配置能扛多少路同时请求”你怎么回答拍脑袋说个数字回头压测打脸保守说个很低的数资源浪费被骂。所以需要一个能快速估算的工具把显存、算力、带宽、批处理策略这几个变量都考虑进去给出一个有依据的并发区间。适合看这篇内容的人正在做GPU推理服务部署的工程师、需要做容量规划的运维同学、以及想搞清楚“并发数”到底由什么决定的AI应用开发者。不管你是刚接触GPU部署的新手还是已经调过几次vLLM参数的老手这里面的拆解逻辑和实操细节都能直接拿去用。我做的这个计算器本质上是一个基于约束条件的估算模型不是精确仿真。它的价值在于帮你在几分钟内排除明显不可行的方案锁定一个合理的压测起点而不是替代真实的压力测试。下面我把整个设计思路、核心参数、计算逻辑和踩过的坑全部拆开讲。2. 为什么并发数不能简单按卡数翻倍2.1 显存才是第一约束不是算力很多人一上来就算TFLOPS觉得算力够就能扛。实际部署过推理服务的人都知道显存容量往往比算力更早成为瓶颈。原因很简单大模型推理的时候模型权重本身要占显存KV Cache要占显存中间激活值要占显存。权重是固定的但KV Cache是随着并发数和序列长度动态增长的。拿一个具体的例子来说。假设你部署一个13B参数的模型FP16精度光权重就要占大约26GB显存。一张A100 80G的卡扣掉权重还剩54GB左右。这54GB要分给KV Cache、激活值、框架开销。KV Cache的计算公式大概是KV Cache显存 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 并发数 × 精度字节数这个公式里的每一个变量都会影响最终能跑多少并发。层数、头数、头维度是模型结构决定的序列长度是你业务决定的精度是你部署策略决定的。只有并发数是你要反推的未知数。所以计算器的第一层逻辑就是给定模型和硬件反推在显存约束下的最大并发。2.2 算力约束在什么情况下才会触发显存算完之后还要过一遍算力约束。算力约束什么时候会成为瓶颈当你的请求序列很短、并发很高的时候。因为每个请求的计算量小但请求数量多GPU的计算单元会被打满。这里涉及一个关键概念叫计算强度Arithmetic Intensity也就是每读取一字节数据能做多少次浮点运算。大模型推理在decode阶段是典型的访存密集型因为每生成一个token都要把整个模型权重读一遍。所以decode阶段的瓶颈通常在显存带宽而不是纯算力。但在prefill阶段也就是处理输入prompt的时候计算强度高算力约束会更明显。计算器需要把这两个阶段分开考虑。我的做法是prefill阶段按算力估算吞吐decode阶段按显存带宽和KV Cache估算并发上限然后取两者的较小值作为最终建议。2.3 8卡并行的通信开销不能忽略8张GPU一起跑不管是张量并行还是流水线并行都有通信开销。张量并行每层都要做All-Reduce流水线并行有气泡。这些开销会吃掉一部分有效算力。我在计算器里加了一个并行效率系数默认值设0.75到0.85之间。这个系数的意思是8卡理论算力是单卡的8倍但实际有效算力只有6到6.8倍左右。具体取多少取决于并行策略和互联带宽。NVLink互联的机器系数可以取高一点PCIe互联的就要取低一点。注意这个系数不是拍脑袋定的是我在几台不同配置的机器上跑benchmark反推出来的。如果你有实测数据一定要用自己的数据替换默认值。3. 计算器的核心参数与计算逻辑拆解3.1 输入参数清单计算器需要你输入以下几类参数我按重要性排序硬件参数GPU型号决定显存容量、显存带宽、FP16算力GPU数量这个项目固定为8互联方式NVLink还是PCIe影响并行效率系数模型参数参数量决定权重显存层数、注意力头数、头维度决定KV Cache精度FP16、INT8、INT4影响权重和KV Cache的字节数业务参数平均输入序列长度平均输出序列长度目标首token延迟TTFT目标每token延迟TPOT部署参数最大批处理大小max batch size并行策略张量并行度、流水线并行度框架开销预留比例这些参数里模型参数和业务参数是最容易填错的。模型参数可以从HuggingFace的config.json里直接读业务参数需要你对自己的流量有统计。如果不知道就先按经验值填后面压测再修正。3.2 显存约束下的并发计算显存约束的计算分三步走。第一步算权重显存权重显存 参数量 × 精度字节数 / 并行度比如13B模型FP16精度2字节8卡张量并行每卡权重显存 13e9 × 2 / 8 ≈ 3.25GB。等等这里要注意张量并行是把权重切分到每张卡上所以每卡只存一部分。但如果是流水线并行每卡存的层数不同显存分布不均匀。计算器里我简化处理按均匀切分算实际部署时要留余量。第二步算KV Cache每token每并发的显存KV per token per seq 2 × 层数 × 头数 × 头维度 × 精度字节数以LLaMA-13B为例40层40个头头维度128FP16精度 KV per token per seq 2 × 40 × 40 × 128 × 2 819200字节 ≈ 0.78MB这个数字意味着序列长度2048的时候单个请求的KV Cache就要占 0.78MB × 2048 ≈ 1.6GB。如果并发是16KV Cache总共要占25.6GB。这个量级很惊人所以长序列场景下并发数会被压得很低。第三步算可用显存和最大并发可用显存 单卡显存 - 权重显存 - 激活值预留 - 框架开销 最大并发 可用显存 / (KV per token per seq × 序列长度)激活值预留我一般按权重显存的10%到20%估框架开销按2到4GB估。这两个值看起来不起眼但在显存紧张的时候就是压死骆驼的最后一根稻草。3.3 算力约束下的吞吐估算算力约束主要影响prefill阶段的吞吐。prefill的计算量大概是prefill FLOPs ≈ 2 × 参数量 × 输入序列长度8卡的总算力FP16比如A100是 312 TFLOPS × 8 2496 TFLOPS乘上并行效率系数0.8有效算力约2000 TFLOPS。那么每秒能处理的prefill token数就是prefill吞吐 有效算力 / (2 × 参数量)13B模型的话prefill吞吐 ≈ 2000e12 / (2 × 13e9) ≈ 76923 tokens/s。这个数字看起来很大但要注意这是理论峰值实际受限于内存带宽和调度开销能到30%到50%就不错了。decode阶段的算力约束相对宽松因为decode是访存密集型。但decode的延迟要求TPOT会反过来限制批处理大小。批处理越大单次前向的计算量越大但每个请求分到的时间片也越短。这里有一个权衡。3.4 延迟约束下的并发上限延迟约束是最容易被忽略的。用户要求首token延迟小于1秒每token延迟小于100毫秒这些指标会直接限制你的批处理策略。首token延迟主要受prefill时间影响。prefill时间 ≈ 输入序列长度 × 每token计算时间。如果输入序列很长prefill就会很慢TTFT就上不去。这时候要么限制输入长度要么用chunked prefill把长输入切块处理。每token延迟受decode批处理大小影响。批处理越大单次decode的时间越长但吞吐越高。这里有一个经典的吞吐-延迟权衡曲线。计算器里我让用户输入目标TPOT然后反推最大批处理大小。实操心得很多团队一开始追求高吞吐把批处理开得很大结果TPOT超标用户体验很差。后来调小批处理吞吐降了但用户满意度上来了。所以并发数不是越高越好要匹配你的SLA。4. 实操从零搭一个估算流程4.1 快速获取模型参数如果你用的是HuggingFace上的模型直接看config.json就行。关键字段是{ num_hidden_layers: 40, num_attention_heads: 40, hidden_size: 5120, intermediate_size: 13824, torch_dtype: float16 }头维度 hidden_size / num_attention_heads 5120 / 40 128。参数量可以从模型卡片上读也可以自己算。自己算的话粗略公式是参数量 ≈ 12 × 层数 × hidden_size²这个公式对Transformer类模型比较准误差在10%以内。40层、hidden_size 5120的话参数量 ≈ 12 × 40 × 5120² ≈ 12.6B和13B的标称值很接近。4.2 用Python快速算一遍我写了一个简化的计算脚本你可以直接拿去改参数跑def estimate_concurrency( gpu_memory_gb80, gpu_count8, model_params_b13, num_layers40, num_heads40, head_dim128, precision_bytes2, seq_len2048, framework_overhead_gb3, activation_ratio0.15, parallel_efficiency0.8 ): # 权重显存每卡 weight_mem model_params_b * 1e9 * precision_bytes / gpu_count / 1e9 # 激活值预留 activation_mem weight_mem * activation_ratio # 可用显存 available_mem gpu_memory_gb - weight_mem - activation_mem - framework_overhead_gb # KV Cache每token每序列 kv_per_token 2 * num_layers * num_heads * head_dim * precision_bytes / 1e9 # 单请求KV Cache kv_per_request kv_per_token * seq_len # 最大并发 max_concurrency int(available_mem / kv_per_request) return { weight_mem_gb: round(weight_mem, 2), available_mem_gb: round(available_mem, 2), kv_per_request_gb: round(kv_per_request, 3), max_concurrency: max_concurrency } result estimate_concurrency() print(result)跑出来的结果大概是权重显存3.25GB可用显存约66GB单请求KV Cache约1.6GB最大并发约41。但这个41是纯显存约束下的理论值实际还要过算力和延迟约束。4.3 算力约束的交叉验证显存算出来41并发但算力能不能撑住41并发同时跑我们来验算一下。41并发每个请求输出序列长度假设256那么decode阶段每步要处理41个请求。每步的计算量大约是每步FLOPs ≈ 2 × 参数量 × 并发数 2 × 13e9 × 41 ≈ 1.07e12 FLOPsA100单卡FP16算力312 TFLOPS8卡有效算力约2000 TFLOPS。每步计算时间 ≈ 1.07e12 / 2000e12 ≈ 0.5毫秒。这个时间很短说明算力不是瓶颈。但实际decode还要读权重访存时间 权重字节数 / 显存带宽。13B FP16权重26GB8卡并行每卡读3.25GBA100显存带宽约2TB/s每卡读权重时间 ≈ 3.25e9 / 2e12 ≈ 1.6毫秒。所以decode每步实际耗时约1.6毫秒TPOT约1.6毫秒远低于100毫秒的目标。这说明在41并发下延迟约束不是问题。4.4 把三个约束合起来看三个约束分别算出来的并发上限约束类型计算依据并发上限显存约束KV Cache容量41算力约束prefill吞吐约60延迟约束TPOT目标约80取最小值建议并发数不超过41。但这是理论值实际部署要打折扣。我一般会再乘一个安全系数0.7得到约28并发作为压测起点。压测的时候从28开始往上加观察显存和延迟变化找到实际拐点。注意这个安全系数不是随便定的。显存碎片、请求长度波动、突发流量都会吃掉余量。留30%的buffer是比较稳妥的做法。5. 常见问题与排查技巧5.1 为什么实测并发远低于计算值这是最常见的问题。计算器算出40并发实际跑到20就OOM了。原因通常有这几个序列长度分布不均。计算器用的是平均序列长度但实际请求有长有短。如果有一个请求序列长度是平均值的3倍它的KV Cache就是3倍可能直接把显存打爆。解决办法是用PagedAttentionvLLM的核心技术把KV Cache按页管理减少碎片。框架开销被低估。PyTorch、CUDA context、通信buffer这些开销加起来可能超过5GB。特别是用TensorRT-LLM的时候engine文件本身就要占不少显存。激活值峰值。计算器用的是平均激活值但prefill阶段的激活值峰值可能远高于平均值。长输入的时候尤其明显。排查方法用nvidia-smi监控显存变化用torch.cuda.memory_summary()看显存分配细节。找到峰值出现的时刻对应到具体的请求阶段。5.2 并发上不去但显存还有余量这种情况通常是算力或带宽瓶颈。检查几个点GPU利用率是不是打满了用nvidia-smi dmon看SM利用率和内存带宽利用率。如果SM利用率高但吞吐低可能是kernel效率问题考虑用TensorRT或者CUDA Graph优化。如果内存带宽利用率高说明是访存瓶颈考虑量化或者用更高效的注意力实现如FlashAttention。还有一个容易被忽略的点CPU预处理瓶颈。如果tokenizer或者请求调度在CPU上成了瓶颈GPU会等数据利用率上不去。用py-spy或者cProfile看一下CPU侧的耗时分布。5.3 8卡并行的效率损失怎么量化我做过一组对比测试同样的模型和请求单卡、2卡、4卡、8卡分别跑看吞吐变化卡数吞吐tokens/s相对单卡加速比并行效率112001.0100%222801.995%442003.587.5%872006.075%可以看到8卡的并行效率只有75%也就是说8卡的实际有效算力只有单卡的6倍。这个损失主要来自All-Reduce通信和流水线气泡。如果你的互联是PCIe而不是NVLink效率可能更低降到60%左右。实操心得如果模型能放进单卡或者双卡尽量不要用8卡张量并行。张量并行的通信开销随卡数增加而增加4卡以上收益递减很明显。8卡更适合跑多个模型实例而不是一个大模型切8份。5.4 常见问题速查表现象可能原因排查方法解决方向OOM但计算值有余量序列长度波动、显存碎片监控显存峰值、看请求长度分布PagedAttention、限制最大长度并发低但显存空闲算力/带宽瓶颈、CPU瓶颈看SM利用率、内存带宽、CPU耗时量化、FlashAttention、优化预处理8卡效率低通信开销大对比不同卡数吞吐减少并行度、用NVLinkTPOT超标批处理太大看decode耗时与批大小的关系调小批处理、用连续批处理TTFT超标prefill太慢看输入长度分布chunked prefill、限制输入长度6. 计算器之外几个容易被忽略的变量6.1 请求到达模式的影响计算器假设请求是均匀到达的但实际流量往往有突发。突发流量下即使平均并发没超瞬时并发也可能打爆显存。解决办法是加请求队列和限流用连续批处理continuous batching动态调整批大小。vLLM的连续批处理机制是这样的每个decode step结束后完成的请求退出新请求加入。这样批大小是动态变化的不会因为一个长请求阻塞整个批次。这个机制对突发流量的容忍度比静态批处理高很多。6.2 量化对并发的影响把FP16换成INT8权重显存直接减半KV Cache也减半。理论上并发可以翻倍。但量化会带来精度损失而且不是所有模型都适合量化。我实测下来INT8量化对大多数对话任务的影响很小但对代码生成和数学推理任务精度下降比较明显。INT4量化更激进显存能降到四分之一但精度损失更大。而且INT4的kernel效率不一定比INT8高因为反量化有开销。选择量化方案的时候要在显存、精度、速度之间做权衡。6.3 多模型共享GPU的情况8张卡不一定只跑一个模型。很多时候是多个模型共享比如一个大的对话模型加一个小的embedding模型。这种情况下并发计算要按模型分别算然后看显存总和是否超限。我的做法是给每个模型分配固定的显存配额用MPSMulti-Process Service或者MIGMulti-Instance GPU做隔离。MIG可以把一张卡切成多个独立实例每个实例有独立的显存和算力隔离性很好。但MIG的切分粒度有限A100支持最多7个实例切完之后每个实例的显存和算力都比较小。6.4 压测工具的选择计算器给的是估算值最终还是要靠压测验证。常用的压测工具locust适合HTTP接口压测可以自定义请求分布。wrk/ab轻量级适合简单接口。vLLM自带的benchmark专门针对大模型推理能测吞吐和延迟。genai-perfNVIDIA出的支持多种推理后端。压测的时候要注意预热。GPU需要跑一段时间才能达到稳定状态冷启动的前几百个请求延迟会偏高。另外要监控显存和GPU利用率确保瓶颈在预期的地方。7. 我踩过的几个坑第一个坑是低估了KV Cache的增长速度。最开始算并发的时候我只算了权重显存觉得80G的卡跑13B模型绰绰有余。结果上线之后序列长度一上去KV Cache直接把显存吃满。后来加了PagedAttention才缓解。所以计算器里我把KV Cache作为第一约束这是有血泪教训的。第二个坑是并行效率系数取太高。一开始我按0.9算觉得8卡怎么也能有7.2卡的有效算力。实际测下来只有6卡左右。后来把系数调到0.75估算值才和实测对得上。这个系数跟互联方式、模型结构、batch大小都有关系没有一个万能值只能实测反推。第三个坑是忽略了CPU侧的瓶颈。有一次压测GPU利用率只有40%我以为是我的并发估算太保守拼命加并发结果延迟飙升。后来用py-spy一看发现tokenizer占了大量CPU时间GPU在等数据。换了快速tokenizer之后GPU利用率才上去。所以计算器只能算GPU侧的约束CPU侧的要单独排查。第四个坑是没有留显存碎片余量。计算器算出来可用显存66GB我就按66GB去分配KV Cache结果跑一段时间就OOM。原因是显存碎片频繁分配释放之后虽然总空闲显存够但没有连续的大块内存。解决办法是用显存池预分配或者用PagedAttention按页管理。8. 这个计算器后续可以怎么扩展目前这个计算器还是静态估算输入一组参数出一个数字。后面我想加几个功能一是接入实时监控数据。从Prometheus拉取实际的显存使用、GPU利用率、请求延迟动态修正估算模型。这样计算器就不只是部署前的规划工具还能做运行时的容量预警。二是支持多模型混合场景。现在只能算一个模型实际生产环境往往是多个模型共享GPU。需要支持给每个模型分配配额然后算总算力是否够用。三是加入成本维度。不同GPU的租用成本不一样同样的并发数用8张4090和8张A100的成本差很多。计算器可以给出性价比最优的配置建议。四是做成Web界面。现在还是Python脚本用起来不够直观。做成Web页面输入参数实时出结果还能画吞吐-延迟曲线对做容量规划的同学会更友好。这些扩展里面实时监控接入是最有价值的。因为估算模型再准也不如实际数据准。把估算和实测结合起来才能做出靠谱的容量决策。
