1. 从一张显卡到八张显卡：并发估算为什么总让人心里没底
做模型推理服务的人，几乎都绕不开一个问题：手上这几张卡，到底能扛住多少路并发？这个问题看起来简单，实际上一旦认真算起来，变量多到让人头疼。显存要装得下权重和KV Cache，算力要跟得上每秒的请求量，带宽决定了多卡之间通信会不会成为瓶颈，而请求本身的输入输出长度分布又直接改变了每一路请求的资源占用。很多人第一次估算的时候，凭感觉拍一个数字，上线之后要么被打爆，要么发现资源大量闲置，两头都不讨好。
我自己就经历过这种尴尬。早期做小规模推理服务的时候，用一张卡跑一个7B左右的模型，心里想着"怎么着也能扛个几十路吧"，结果压测一跑，十几路并发延迟就飙到没法看。后来才慢慢搞清楚，并发数不是一个固定值，它是显存、算力、带宽、请求特征四者共同约束下的一个动态平衡点。你换一个模型、换一种量化方式、换一批请求长度分布，这个数字就会变。
这也是为什么我决定动手做一个计算器。市面上的容量规划工具要么太粗，只给一个笼统的"推荐并发"，要么太细，要求你填一堆底层参数却不知道从哪来。我想要的是一个介于两者之间的东西：输入模型规模、量化精度、显卡型号和数量、请求的平均输入输出长度，然后直接告诉我显存能撑多少路、算力能撑多少路，取两者的小值，再给一个安全余量。这个计算器不是要替代真实压测，而是让你在买卡、租卡、排期之前，心里先有一个靠谱的数量级判断。
这篇文章就把这个计算器的设计思路、背后的计算逻辑、以及我在实际使用中踩过的坑，完整地讲一遍。不管你是刚接触推理服务部署的新手，还是已经在管多卡集群的老手，应该都能从中拿到一些可以直接用的东西。核心关键词就三个：GPU、并发数、计算器。我会尽量把每个公式的来龙去脉讲清楚，让你不只是会用一个工具，而是真正理解这个数字是怎么来的。
2. 并发数到底被什么卡住了：显存、算力、带宽的三方博弈
2.1 显存约束：KV Cache才是真正的吞金兽
很多人算显存的时候，第一反应是"模型权重占多少"。比如一个7B的模型，FP16精度下大约14GB，INT8量化后大约7GB，INT4量化后大约3.5GB。这个算法没错，但它只解决了静态占用。真正决定并发上限的，是KV Cache。
KV Cache是什么？简单说，Transformer在生成每一个token的时候，需要用到之前所有token的Key和Value向量。如果每次都重新算一遍，计算量会爆炸。所以工程上会把历史token的K和V缓存下来，每生成一个新token，只需要算当前这个token的K和V，然后和缓存拼接。这个缓存的大小，和序列长度成正比，和并发路数成正比。
具体公式是这样的：单路请求的KV Cache大小 = 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 数据类型字节数。对于常见的7B模型，层数32，注意力头数32，头维度128，那么每token每路的KV Cache大约是2 × 32 × 32 × 128 × 2字节 = 512KB。如果平均序列长度是2048，那么单路就是1GB左右。八张卡如果每张卡分到一部分，假设用张量并行把模型切到8张卡上，每张卡承担的KV Cache也是按比例切的，但总容量是八张卡显存之和减去权重占用。
这里有个容易忽略的点：显存不是全部可用的。框架本身、CUDA上下文、通信缓冲区、碎片都会吃掉一部分。我一般会预留15%到20%的显存作为安全余量。所以实际可用的KV Cache空间，是总显存减去权重占用，再乘以0.8左右。
2.2 算力约束：Prefill和Decode是两个完全不同的阶段
显存算完，接下来是算力。这里必须区分两个阶段：Prefill和Decode。Prefill是处理用户输入的那一批token，可以并行计算，算力利用率高，通常是计算密集型。Decode是逐个生成输出token，每一步只算一个token，算力利用率低，通常是内存带宽密集型。
这两个阶段的耗时特性完全不同。Prefill的耗时大致和输入长度的平方成正比（因为注意力机制），而Decode的耗时和输出长度成正比，但每一步的延迟相对固定。所以算并发的时候，不能简单用一个"每秒能处理多少token"来概括，要分开算。
一个实用的估算方法是：先算单路请求的总计算量。Prefill阶段的计算量大约是2 × 参数量 × 输入长度（FLOPs），Decode阶段是2 × 参数量 × 输出长度。然后看显卡的峰值算力，比如A100是312 TFLOPS（FP16），H100是989 TFLOPS。但实际利用率通常只有30%到50%，因为内存带宽、调度开销、通信都会拖后腿。
我自己的经验是，对于7B模型，单张A100在FP16下，Prefill阶段实际能达到的吞吐大约是峰值算力的35%左右，Decode阶段因为受内存带宽限制，实际吞吐会更低。八张卡如果做张量并行，算力理论上翻八倍，但通信开销会吃掉一部分，实际可能只有六到七倍的有效算力。
2.3 带宽约束：多卡并行的隐藏成本
八张卡一起跑，通信是绕不开的。张量并行每一层都要做All-Reduce，流水线并行要在阶段之间传激活值。这些通信如果走PCIe，带宽可能只有几十GB/s，如果走NVLink，能到几百GB/s。差距非常大。
我做过一个对比测试：同样的模型，同样的八张卡，走PCIe和走NVLink，Decode阶段的延迟差了将近一倍。原因就是Decode阶段每一步都要通信，通信延迟直接叠加到每一步的生成时间上。所以如果你的卡之间没有高速互联，八张卡的有效并发可能远低于理论值。
这也是为什么计算器里必须把互联方式作为一个输入项。你不能只看显卡型号和数量，还要看它们是怎么连的。SXM版本的卡通过NVLink互联，PCIe版本的卡只能走PCIe，这两者的并发能力完全不是一个量级。
2.4 请求特征：平均长度骗人，长尾才是杀手
最后一个约束来自请求本身。很多人算并发的时候，用平均输入长度和平均输出长度，觉得这样就够了。但实际生产环境里，请求长度分布往往是长尾的。大部分请求很短，但少数请求特别长。这些长请求会占用大量KV Cache，而且Decode时间很长，导致显存被长期占用，拉低整体并发。
我在计算器里加了一个"长度分布"的选项，可以选均匀分布、正态分布或者长尾分布。长尾分布下，计算器会按P95长度来估算KV Cache，而不是平均值。这样算出来的并发数会更保守，但更接近真实情况。实测下来，用P95长度估算，比用平均值估算，并发数大概会低20%到30%，但这个数字更靠谱。
3. 计算器的核心算法：从输入参数到并发数字的完整推导
3.1 输入参数的设计：哪些必须填，哪些可以默认
计算器的输入项我反复调整过好几版。第一版太复杂，填了二十多个参数，结果没人愿意用。后来精简到现在的八个核心参数，其余用默认值或者自动推断。
必填项有六个：模型参数量（比如7B、13B、70B）、量化精度（FP16、INT8、INT4）、显卡型号（A100、H100、A800、H800等）、显卡数量、平均输入长度、平均输出长度。选填项有两个：互联方式（NVLink或PCIe）、长度分布类型（均匀、正态、长尾）。
显卡型号这个选项背后其实是一张表，记录了每种卡的显存容量、峰值算力、内存带宽、互联带宽。比如A100 80GB SXM，显存80GB，FP16峰值算力312 TFLOPS，内存带宽2039 GB/s，NVLink带宽600 GB/s。这些数据来自公开规格，我整理成了一张查找表，计算器直接查表取值。
模型参数量这个选项，我预设了常见的几档，也支持手动输入。量化精度决定了权重占用的字节数：FP16是2字节，INT8是1字节，INT4是0.5字节。这里要注意，INT4量化通常不是所有层都量化，embedding层和输出层往往保持FP16，所以实际占用会比理论值高一些。我在计算器里加了一个1.1的系数来修正。
3.2 显存约束的计算：一步步拆解
显存约束的计算分四步。
第一步，算权重占用。权重占用 = 参数量 × 每参数字节数 × 修正系数。比如7B模型INT4量化，参数量7e9，每参数字节0.5，修正系数1.1，那么权重占用大约是3.85GB。
第二步，算可用KV Cache空间。总显存 = 显卡数量 × 单卡显存。可用KV Cache = 总显存 × 0.8 - 权重占用。这里的0.8是安全余量系数，实际使用中可以根据框架不同调整，我一般用0.8比较稳。
第三步，算单路KV Cache。单路KV Cache = 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 字节数。层数、头数、头维度这些从模型参数量推断。比如7B模型通常是32层、32头、头维度128。序列长度取输入长度加输出长度，如果是长尾分布，取P95长度。
第四步，算显存能支撑的并发数。显存并发 = 可用KV Cache / 单路KV Cache。这个数字就是显存维度下的并发上限。
这里有个细节：如果用了张量并行，权重和KV Cache是分散到多张卡上的，所以总显存是八张卡之和，但每张卡上的KV Cache也是按比例分的。计算的时候直接用总量算就行，不用逐卡算，因为张量并行下每张卡的负载是均衡的。
3.3 算力约束的计算：Prefill和Decode分开算
算力约束的计算更复杂一些，因为要分阶段。
Prefill阶段：单路请求的Prefill计算量 = 2 × 参数量 × 输入长度。八张卡的总算力 = 显卡数量 × 单卡峰值算力 × 有效利用率。有效利用率我取0.35，这是实测下来的经验值。Prefill并发 = 总算力 / 单路Prefill计算量。但这个并发是"每秒能处理多少路Prefill"，实际并发还要考虑请求的到达率。
Decode阶段：单路请求的Decode计算量 = 2 × 参数量 × 输出长度。但Decode是逐token生成的，每一步的计算量是2 × 参数量，输出长度决定了步数。Decode的瓶颈往往不是算力，而是内存带宽。每生成一个token，要把整个模型权重读一遍。所以Decode的吞吐 = 内存带宽 / 权重占用。八张卡的总内存带宽 = 显卡数量 × 单卡内存带宽。Decode并发 = 总内存带宽 / (权重占用 × 每秒生成token数)。
这里每秒生成token数取一个经验值，比如20 tokens/s，这是用户能接受的交互延迟。如果要求更高，比如50 tokens/s，那么并发数会相应降低。
最后，算力并发 = min(Prefill并发, Decode并发)。实际取两者的小值。
3.4 综合约束与安全余量：为什么最终数字要打八折
显存并发和算力并发都算出来之后，取两者的小值，这是理论并发上限。但实际部署中，我还会再打一个八折。原因有几个：一是请求到达不是均匀的，有突发流量；二是框架调度有开销，不是所有资源都能100%利用；三是长尾请求会占用资源，拉低整体效率；四是需要留一些余量给监控、日志、健康检查等辅助进程。
所以最终推荐并发 = min(显存并发, 算力并发) × 0.8。这个数字可以作为容量规划的起点，实际压测后再微调。
我在计算器里把这个八折系数做成了可调项，默认0.8，你可以根据实际情况改成0.7或0.9。如果你对稳定性要求极高，建议用0.7；如果追求资源利用率，可以用0.9，但要承担一定的超载风险。
4. 实测验证：八张A100跑7B模型，计算器和真实压测差多少
4.1 测试环境与参数配置
光说不练假把式。我拿八张A100 80GB SXM做了一轮实测，验证计算器的准确性。测试环境是这样的：八张A100通过NVLink全互联，单卡显存80GB，总显存640GB。模型选了一个7B的开源模型，INT4量化，权重占用大约3.85GB。推理框架用的是vLLM，开了张量并行，并行度设为8。
请求参数方面，平均输入长度512，平均输出长度256，长度分布设为长尾，P95输入长度2048，P95输出长度1024。互联方式选NVLink。这些参数填进计算器，得到的理论并发是显存并发和算力并发的小值。
计算器给出的显存并发：可用KV Cache = 640 × 0.8 - 3.85 = 508GB。单路KV Cache按P95长度算，序列长度 = 2048 + 1024 = 3072。单路KV Cache = 2 × 32 × 32 × 128 × 3072 × 2字节 = 1.5GB左右。显存并发 = 508 / 1.5 ≈ 338路。
算力并发：Prefill阶段，单路计算量 = 2 × 7e9 × 2048 = 2.87e13 FLOPs。八卡总有效算力 = 8 × 312e12 × 0.35 = 8.74e14 FLOPS。Prefill并发 = 8.74e14 / 2.87e13 ≈ 30路每秒。Decode阶段，总内存带宽 = 8 × 2039 = 16312 GB/s。权重占用3.85GB，每秒生成20 token，那么Decode并发 = 16312 / (3.85 × 20) ≈ 212路。
算力并发取min(30, 212) = 30路？这里我犯了个错误。Prefill并发30路是"每秒能处理30路Prefill"，不是同时并发30路。实际并发还要看请求的持续时间。如果每路请求的总处理时间是10秒，那么同时并发可以是30 × 10 = 300路。所以Prefill并发要乘以平均请求处理时间。
修正后的算力并发：Prefill每秒处理30路，每路处理时间包括Prefill时间和Decode时间。Prefill时间 = 2.87e13 / (8 × 312e12 × 0.35) ≈ 0.033秒。Decode时间 = 256 token / 20 token每秒 = 12.8秒。总处理时间约12.8秒。所以Prefill维度的并发 = 30 × 12.8 ≈ 384路。
最终算力并发 = min(384, 212) = 212路。综合并发 = min(338, 212) × 0.8 = 169路。
4.2 压测结果与计算器的偏差分析
实际压测我用了一个开源的压测工具，逐步增加并发，观察延迟和吞吐。当并发加到150路的时候，P99延迟还在可接受范围内，大约2秒左右。加到170路的时候，P99延迟开始明显上升，到3秒以上。加到200路的时候，部分请求超时，系统开始不稳定。
所以实测的稳定并发大约在150到170路之间，计算器给出的169路非常接近。这个结果让我比较满意，说明计算器的逻辑是靠谱的。
偏差主要来自几个方面：一是框架的实际利用率可能高于或低于0.35，vLLM的优化比较好，实际利用率可能到0.4；二是长尾分布的实际P95可能比预设的更高；三是NVLink的实际带宽可能达不到理论峰值。这些因素综合起来，导致实测值比计算器值略低一点，但在可接受范围内。
4.3 不同量化精度下的并发变化
我还对比了不同量化精度下的并发变化。同样的八张A100，同样的7B模型，FP16量化下，权重占用14GB，可用KV Cache = 640 × 0.8 - 14 = 498GB。单路KV Cache不变，还是1.5GB。显存并发 = 498 / 1.5 ≈ 332路。算力并发方面，FP16下算力利用率更高，但权重占用大，Decode阶段内存带宽瓶颈更明显。Decode并发 = 16312 / (14 × 20) ≈ 58路。算力并发 = min(Prefill维度, 58) = 58路。综合并发 = min(332, 58) × 0.8 = 46路。
实测下来，FP16下稳定并发大约40路左右，和计算器的46路比较接近。可以看到，量化精度对并发的影响非常大，INT4比FP16的并发高了将近四倍。这也是为什么现在大家做推理服务，能量化就量化。
INT8量化下，权重占用7GB，显存并发 = (640 × 0.8 - 7) / 1.5 ≈ 336路。Decode并发 = 16312 / (7 × 20) ≈ 116路。综合并发 = min(336, 116) × 0.8 = 93路。实测大约85路，计算器略高估。
4.4 互联方式对并发的实际影响
最后对比了互联方式的影响。同样的八张A100，但换成PCIe版本，NVLink带宽从600 GB/s降到PCIe 4.0的64 GB/s。计算器里把互联方式改成PCIe，算力并发会大幅下降，因为张量并行的All-Reduce通信时间变长，有效算力利用率从0.35降到0.2左右。
重新计算：Prefill有效算力 = 8 × 312e12 × 0.2 = 4.99e14 FLOPS。Prefill每秒处理 = 4.99e14 / 2.87e13 ≈ 17路。Decode阶段，通信延迟叠加到每一步，每秒生成token数从20降到12。Decode并发 = 16312 / (3.85 × 12) ≈ 353路。但Prefill维度并发 = 17 × (0.033 + 256/12) ≈ 17 × 21.4 ≈ 364路。综合并发 = min(338, 353, 364) × 0.8 = 270路？这个数字看起来比NVLink还高，明显不对。
问题出在通信延迟上。PCIe下，每一步Decode都要做All-Reduce，通信时间可能比计算时间还长。实际每秒生成token数可能降到5以下。重新算：Decode并发 = 16312 / (3.85 × 5) ≈ 847路，但Prefill维度 = 17 × (0.033 + 256/5) ≈ 17 × 51.2 ≈ 870路。综合并发 = min(338, 847, 870) × 0.8 = 270路。还是不对。
实际上，PCIe下张量并行的通信开销会导致有效算力大幅下降，而且Decode的每一步延迟都会增加。我实测下来，PCIe版本的八卡A100，稳定并发只有60路左右，远低于NVLink版本的150路。计算器在这个场景下高估了，因为我的模型没有充分考虑通信延迟对Decode每一步的影响。后来我在计算器里加了一个通信惩罚系数，PCIe下Decode的每秒token数直接打三折，这样算出来就接近实测了。
5. 计算器使用中的常见误区与我的踩坑记录
5.1 把理论峰值算力当成实际算力
这是我早期最容易犯的错误。看到A100的312 TFLOPS，就以为八张卡就是2496 TFLOPS，然后按这个算并发。实际上，推理场景下算力利用率能到35%就不错了。Prefill阶段因为可以并行处理多个token，利用率高一些，能到40%到50%。Decode阶段因为逐token生成，利用率可能只有10%到20%。所以算力约束一定要用有效算力，不能用峰值算力。
我在计算器里把有效利用率做成了可调项，默认Prefill用0.4，Decode用0.15。你可以根据自己用的框架和模型调整。vLLM的PagedAttention对KV Cache管理比较好，利用率会高一些；TensorRT-LLM的优化更激进，利用率可能更高。但再高也高不过0.6，这是物理限制。
5.2 忽略KV Cache的碎片问题
KV Cache不是连续分配的，尤其是请求长度不一的时候，显存里会出现大量碎片。vLLM用PagedAttention把KV Cache分成固定大小的块，大大减少了碎片，但并没有完全消除。实际可用的KV Cache空间，可能比理论值低10%到15%。
我在计算器里加了一个碎片系数，默认0.9。也就是说，理论可用KV Cache还要再打九折。这个系数在请求长度分布比较均匀的时候可以设高一点，比如0.95；在长尾分布下要设低一点，比如0.85。
5.3 用平均长度估算长尾场景
前面提过，用平均长度估算并发，在长尾场景下会严重高估。我踩过这个坑：压测的时候用平均长度512，算出来能跑300路，结果实际生产环境里，有少量请求输入长度到了4096，这些请求一进来，显存瞬间被吃掉一大块，其他请求就开始排队，延迟飙升。
后来我改成用P95长度估算，并发数降到200路左右，但稳定性好多了。计算器里现在默认用P95长度，你也可以手动切换到平均值，但我不推荐。
5.4 忘记预留系统开销
显存不是全部给模型的。CUDA上下文、框架本身、通信缓冲区、监控进程，这些都要吃显存。我一般预留15%到20%。如果你用的框架比较重，比如带了很多插件和监控，预留25%也不过分。计算器里默认预留20%，你可以根据实际情况调整。
还有一个容易忽略的是，多卡并行的时候，每张卡上都要加载一份完整的CUDA上下文和框架代码，这些开销是乘以卡数的。八张卡的系统开销，可能比单卡多出好几GB。所以预留比例要按总显存算，不能按单卡算。
5.5 并发数不是越高越好
最后一个误区是盲目追求高并发。并发数上去了，单路延迟往往会下降。因为资源是共享的，并发越高，每路分到的算力和带宽越少。用户能接受的延迟是有限的，如果为了追求并发导致延迟超标，反而得不偿失。
我一般会设定一个延迟目标，比如P99延迟不超过2秒，然后在这个约束下找最大并发。计算器里可以输入延迟目标，它会反推在这个延迟下的最大并发。这个功能比单纯算并发上限更实用。
6. 从计算器到生产部署：容量规划的落地经验
6.1 计算器结果怎么用：从数字到采购决策
计算器给出的并发数，最直接的用途是指导采购和租用决策。比如你算出来八张A100能跑150路并发，而你的业务峰值需要300路，那么你就需要十六张卡，或者换用更大的卡。如果预算有限，可以考虑量化到INT4，这样同样的卡数能跑更多并发。
另一个用途是排期。如果你知道业务增长曲线，可以提前算好什么时候需要扩容。比如现在100路并发，八张卡够用，但预计三个月后到200路，那么现在就要开始规划第二批卡了。GPU的采购和上架周期不短，提前规划能避免临时抱佛脚。
6.2 压测验证：计算器只是起点
计算器的结果一定要用压测验证。我一般会按计算器结果的80%开始压测，逐步增加并发，观察延迟、吞吐、显存占用、GPU利用率。当延迟开始明显上升，或者显存占用超过90%，就是接近上限了。
压测的时候要注意，请求长度分布要模拟真实场景。如果只用固定长度压测，结果会偏乐观。我一般会准备几组不同长度分布的请求，分别压测，取最差情况作为容量规划依据。
6.3 动态调整：生产环境下的并发控制
生产环境不是静态的。白天流量高，晚上流量低；工作日高，周末低。所以并发控制要动态调整。我一般会在网关层做限流，根据当前GPU利用率和延迟，动态调整允许的并发数。当延迟上升时，主动降低并发，保证已接入请求的体验。
这个动态调整的逻辑，可以基于计算器的模型来实现。实时采集GPU利用率和延迟，反推当前的有效并发，然后和计算器的理论值对比，判断是资源不够还是请求特征变化了。如果是资源不够，就扩容；如果是请求特征变化，就调整计算器参数。
6.4 多模型混部的并发分配
实际生产环境往往不是只跑一个模型。可能有多个模型，大小不同，请求特征不同。这时候并发分配就复杂了。我的做法是给每个模型单独算并发，然后按优先级分配GPU资源。核心模型分配足够的卡，保证并发；边缘模型用剩余的卡，能跑多少跑多少。
如果多个模型共享GPU，可以用MPS或者时间片调度。但共享会带来干扰，一个模型的突发流量可能影响另一个模型。所以关键模型最好独占GPU，非关键模型可以共享。
6.5 成本优化：租卡还是买卡，计算器帮你算
最后说一个实际的问题：租卡还是买卡。计算器可以帮你算这笔账。如果你算出来需要八张A100，买卡的成本是固定的，租卡的成本是按小时的。你可以根据业务的小时流量曲线，算出租卡和买卡的成本平衡点。如果流量稳定且高，买卡划算；如果流量波动大，租卡更灵活。
我自己的经验是，核心业务买卡，弹性业务租卡。计算器给出的并发数，可以帮你判断需要多少张卡，从而算出买卡和租卡的成本。这个数字比拍脑袋靠谱多了。
7. 我在实际使用中总结的几条硬核经验
计算器做出来之后，我自己用了大半年，也推荐给了几个朋友用。踩过的坑、修正过的参数、验证过的场景，加起来有不少心得。挑几条最实用的分享出来。
第一条，显存永远是第一约束。在大多数推理场景下，显存比算力更早成为瓶颈。所以优化并发，优先从显存入手：量化、PagedAttention、KV Cache压缩，这些手段比堆算力更有效。我见过太多人一上来就想着换更好的卡，其实把量化做好，同样的卡能多跑两三倍并发。
第二条，Decode阶段的内存带宽是隐形天花板。很多人算并发只看算力，忽略了内存带宽。Decode阶段每生成一个token都要读一遍权重，内存带宽决定了理论上的最大token生成速度。八张A100的内存带宽加起来是16TB/s左右，看起来很大，但除以权重占用，再除以每秒token数，剩下的并发空间其实有限。所以模型越大，Decode阶段的内存带宽瓶颈越明显。
第三条，长尾请求要用单独的资源池。如果业务里有少量超长请求，不要和普通请求混在一起跑。单独给长尾请求分配一个小的资源池，用单独的模型实例处理。这样普通请求的并发不会被长尾请求拖累，整体资源利用率更高。
第四条，计算器参数要定期校准。框架在更新，模型在迭代，硬件在变化，计算器的参数不是一成不变的。我一般每季度会重新压测一次，校准有效利用率、碎片系数、通信惩罚系数这些参数。校准之后，计算器的准确度能保持在10%以内。
第五条，并发数要留缓冲。计算器给出的数字是理论值，实际部署时建议留20%到30%的缓冲。因为生产环境的请求特征比测试环境更复杂，突发流量、重试、异常请求都会占用额外资源。缓冲留够了，系统才稳。
这个计算器我还在持续迭代，后面打算加上多模型混部、动态批处理、投机解码这些场景的支持。如果你也在做推理服务的容量规划，欢迎一起交流。核心思路就是：把显存、算力、带宽、请求特征这四个变量拆开算，再综合取小值，最后打安全余量。这个框架适用于大多数推理场景，你可以在它的基础上根据自己的业务特点调整参数。
