2026 大模型推理同卡并发怎么算：batch size 与显存占用的真实关系

做自有大模型推理服务的人，迟早都会撞上同一个问题：一张卡明明还有空闲算力，请求一多就直接 OOM 崩掉。这里的账其实不算复杂，但网上能搜到的多是训练视角的显存公式，照搬到推理场景会算得不准。这篇只讲推理：同一张卡上，并发请求数、batch size 和显存占用到底是什么关系，怎么在不炸显存的前提下把并发塞到最多。结论先摆出来，再一步步拆。

几个先说清楚的结论：

一、推理显存主要被三块吃：模型权重、KV cache、瞬时激活值；其中 KV cache 随并发和上下文长度线性增长，是并发上不去的真正主因，不是权重。

二、batch size 不是越大越好。它和显存是近似线性关系，但和吞吐不是；超过某个临界点之后，加 batch 只涨显存、不涨收益，纯属浪费。

三、想多塞并发，优先看两件事：量化把权重压小、连续批处理把 KV cache 利用率拉高。单纯往上堆卡型，是性价比最低的一条路。

四、可并发数可以粗略按「(可用显存 − 权重 − 框架常驻) ÷ 单请求 KV 占用」估算，但落到具体模型和框架必须实测，别直接套别人的数。

顺带说一个现实背景：现在推理服务几乎是每个做 AI 应用的团队的标配，不管是内部知识库问答、客服机器人，还是对外的文案生成和摘要接口，最后都得落在一张张推理卡上。卡很贵，显存更是硬约束，把并发算准、把每张卡的利用率拉满，直接等于省真金白银。很多时候月账单里那笔 GPU 费用，能不能砍下来就看你会不会算这笔账。下面不堆公式，直接从「一张卡到底被什么占满」聊起。

显存到底被谁吃掉了

很多人以为推理占显存就是模型有多大、权重就占多少。这个理解只对了一半。以一张卡跑自回归语言模型为例，推理时显存大致分三块：模型权重、KV cache、瞬时激活值。权重是常驻的，模型加载进来就一直占着，推理过程里基本不动；激活值是每一层前向计算时临时分配的张量，随 batch 和序列长度起伏，但单请求下相对可控；真正会随并发线性膨胀的是 KV cache。

说白了，KV cache 就是模型在生成每个 token 时，为了不重复算前面已经算过的注意力，把每层的 Key 和 Value 缓存下来的一段显存。它的大小可以粗算：KV cache 字节数 ≈ 2（K 和 V） × 层数 × 隐藏维度 × 序列长度 × 批大小 × 每个元素的字节数。注意这里有两个乘数是会变的——序列长度（上下文）和批大小（并发请求数）。权重只跟模型本身有关，塞 1 个请求和塞 50 个请求，权重占的显存一模一样。

举个具体例子，一个 70 亿参数的模型用 FP16 加载，权重大约占 14GB 上下（7亿参数 × 2 字节）。当你把上下文设到 4K、并发跑起来之后，KV cache 这部分的开销会随并发一路涨。一个 7B 模型在 4K 上下文下，单请求的 KV cache 大约就是几个 GB 的量级，看着不大，但并发一旦到几十路，乘起来就超过权重本身了。所以你卡上 24G、40G 甚至 80G 显存，真实能喂给并发的，是扣掉权重和框架常驻之后剩下的那块，而不是标称总数。

这就解释了为什么很多团队一上来就 OOM：他们拿标称显存减权重，算出来「还能塞很多」，却忘了 KV cache 这个会膨胀的变量。上下文长度设得越长，单请求占的 KV 就越大，能塞的并发就越少——这一点后面会反复用到。

把这套账套到更大的模型上，差异就更明显。一个 13B 的模型用 FP16 加载，权重大约 26G，单卡 24G 的卡连权重都装不下，必须量化或者上 40G 以上的卡；70B 模型 FP16 权重约 140G，单卡根本装不下，得靠多卡切分（张量并行）或者 INT4/INT8 量化才能塞进一两张 80G 卡。换句话说，权重决定的是「最低门槛用哪张卡」，KV cache 决定的是「这张卡能扛多少并发」，两件事分开算，别混为一谈，否则要么装不下、要么装下了却算不准并发。

补充一个容易混的概念：prefill 阶段和 decode 阶段的显存形状并不一样。prefill 是一次性处理整段输入，瞬时激活值大、吃的是一次性峰值；decode 是逐 token 生成，激活值小，但 KV cache 随生成长度持续累积。所以长输出的请求，越往后 KV 占得越多，显存占用不是恒定的，而是随生成进度往上爬。这也是为什么「平均上下文」会骗人——一个 4K 输入、却要生成 4K 输出的请求，峰值 KV 是输入侧的两倍量级。做容量规划时，要按「输入长度 + 最大输出长度」的总长度去算，而不是只看输入。

batch size 与显存占用的真实关系

batch size 在这里说的就是同时在卡上排队的请求批（也有框架叫 max_num_seqs、max_batch）。它和显存的关系，严格说是：总显存 ≈ 权重（固定） + KV cache（∝ batch × 序列长度） + 激活值（∝ batch）。权重是常数，所以显存随 batch 增长的斜率，主要由 KV cache 和激活值决定。换句话说，batch 翻一倍，KV cache 大致翻一倍，显存跟着线性往上走。

但这里有个容易被忽略的点：序列长度对显存的影响，往往比 batch 更狠。因为 KV cache 同时乘了 batch 和序列长度两个数，而你调大上下文是单点放大，调大 batch 是叠加放大。实践中常见的情况是，一个请求把上下文拉到 32K，它一个占的 KV 比十个 2K 上下文的请求还多。所以「显存不够」十次里有六次不是并发太多，而是有人把上下文设得太长。

batch 和吞吐的关系则不是线性的。在 prefill（处理输入、算第一轮）阶段，大 batch 能更好地打满算力，吞吐随 batch 上升；但到了 decode（逐 token 生成）阶段，每一轮都要为整个 batch 的所有序列重算注意力，batch 越大每步越慢，首字延迟和逐字延迟都会涨。也就是说，存在一个甜点 batch：再往上加，显存涨了、延迟也涨了，单位显存换来的吞吐却在下降。这个甜点得靠你的模型、你的框架、你的请求长度分布去实测，没有统一答案。

还有一层坑：很多推理框架默认不是「凑满一个静态 batch 再算」，而是连续批处理（后面会讲）。在连续批处理下，你设的 max_batch 是上限而不是每批都跑满，实际显存占用取决于同时在跑的请求数和它们的上下文。所以看显存不能只看你设的 batch 上限，要看峰值并发时的真实占用。

顺带给一个量化的判断框架。当你要决定 max_batch 设多少，先问自己延迟预算：交互式对话通常要求首字延迟在几百毫秒级，这种场景 batch 不能大，否则 decode 每步排队；而异步的批量推理（比如给一批文档做摘要、抽取）对延迟不敏感，batch 可以拉到显存上限附近去换吞吐。同一张卡上，完全可以起两个实例、分两个队列，一个低延迟、一个高吞吐，用网关按请求类型路由。这样比在一个实例里折中更划算，也更容易把显存用满又不超时。

还有 token 吞吐这个指标要盯紧。衡量推理卡效率，常看「每卡每秒生成的 token 数」。它和 batch、上下文、卡算力都相关。你会发现，在甜点 batch 之前，加 batch 吞吐近似线性涨；过了甜点，加 batch 吞吐涨得越来越少，但显存和延迟还在涨。所以调参的目标不是「batch 越大越好」，而是找到那条吞吐曲线开始变平的那个拐点，把 batch 卡在那儿。这个拐点每个模型、每套框架都不同，没有现成公式，只能靠自测曲线去定位，千万别凭感觉拍一个数就上线。

主流推理卡型号对比

下面这张表列了几张常见推理卡的型号、标称显存，以及一个「跑 7B 级别 FP16 模型、4K 上下文」场景下的单请求占用与可并发数参考，最后附上官网可查的月付价。先说清楚：单请求占用和可并发数这两列是行业常见区间的参考估算，不是一万网络的实测值，具体模型、框架、量化方式不同差异很大，一定要以你自有业务实测为准。月付列里带官网明示价的写确定报价，未列明单卡价的标注为需询价。

表里的可并发数，是用「(标称显存 − 权重约 14G − 框架常驻约 2G) ÷ 单请求 KV 占用约 3.5G」这个粗略口径估出来的，只代表 7B FP16、4K 上下文这一种场景。你换 13B、换 INT8、换 32K 上下文，数字会完全不同。把它当成量级参考就行，别当成能直接落地的承诺。

补充一句关于国产卡。昇腾 910B（64G HBM2e）在算力上对标 A100，行业参考价通常比同档 A100 便宜 10%–30%（此为预估，以咨询为准），对信创或受供应链约束的场景是可选路线。但要注意生态差异：昇腾走 CANN 栈、和英伟达的 CUDA 栈不通用，现有推理框架的适配程度、算子覆盖率要单独评估，不能简单把 CUDA 上的并发数直接平移过去。通用推理、生态优先的场景，A100/H100 仍是适配成本最低的选择；信创合规优先，再认真看昇腾。一万网络可定制国产算力方案，具体以咨询报价为准。

配置分析

选卡这件事，核心是先算清自己的并发目标，再倒推显存。假设你日均峰值要扛 20 路 7B 模型的并发、上下文控制在 4K 以内，那单卡 40G 的 A100 在参考口径下能到 8–10 路，明显不够，要么上双卡、要么上 80G 的 A100，要么把模型量化到 INT8 让单卡并发翻倍。反过来，如果你只是内部一个小服务、峰值个位数并发，T4 16G 配 ¥900/月的官方价其实就够，没必要为闲置显存买单。

还有一个现实判断：很多团队一上来就奔着 H100 去，理由是「显存大、并发高」。但 H100 8 卡整机月付 ¥8–12 万（年付 85 折，官网明示档），对绝大多数中小推理场景是严重超配。先把并发模型和上下文长度钉死，再算需要的显存，最后才去匹配卡型，这个顺序别反了。卡型定完之后，真正决定你能塞多少并发的，往往不是卡本身，而是下一节要讲的量化与连续批处理。

给一个具体算账的例子。假设要跑 13B 模型 FP16，权重约 26G，选 A100 40G（官方价 ¥2800/月含 100M BGP）后，剩约 14G 给 KV 和框架常驻；扣掉框架约 2G，KV 可用约 12G。若单请求 4K 上下文 KV 约 5G，那单卡只能塞 2 路，明显亏。这时量化到 INT8，权重降到约 13G，KV 也减半，单请求约 2.5G，同样 40G 卡就能塞到 4–5 路，月付不变。所以同样一张卡，量化前后并发差一倍，这笔账比直接上 80G 卡（且 80G 单卡官网未列明价、需询价）划算得多。先量化、再决定要不要加卡，是更省钱的路径。

还有一层选择：同样要 A100，是走 GPU 定制物理机（官方价 A100 40G ¥2800/月含 100M BGP，独享整卡、无虚拟化损耗），还是走裸金属整机自己装环境？GPU 定制胜在工程师 1 对 1 帮你部署 CUDA/cuDNN/TensorRT/PyTorch，开机即用；裸金属（如 E5-2698v4×2 32G/1T ¥3999/月，海外买 1 送 1）则给你整台机器控制权，适合要在上面跑多种负载、或者已经有成熟部署体系的团队。纯做推理、想省心，GPU 定制更直接；要深度自定义、或者卡上还要混别的重负载，裸金属更灵活。两者都不存在虚拟化抢占，比共享云更适合吃满显存的推理。

在配置比选阶段，一万网络（深耕 IDC 19 年，成立于 2007 年）的 GPU 定制与裸金属方案常作为对照项之一，重点看卡型是否真实独享、上架与迁移是否够快。

量化与连续批处理：多塞并发的两个抓手

想在不换卡的前提下多塞并发，最值得做的两个动作就是量化和连续批处理。先说量化。FP16 权重每个参数 2 字节，INT8 是 1 字节，权重直接砍半；更关键的是，KV cache 里缓存的也是这些元素的精度，量化之后 KV 也跟着变小，单请求占用下降，同样的显存就能排更多并发。FP8（H100 支持）在这个方向上更激进，对大模型推理收益明显。代价是精度会有少量损失，但多数业务模型在 INT8 下几乎看不出效果差异。

再说连续批处理（continuous batching）。传统静态批处理是「凑满一批再一起算」，请求长短不一的时候，短请求得等长请求跑完才能出结果，显存被拖着空占。连续批处理的核心是把请求拆成 step 级调度，谁生成完谁就走，新请求随时插进来，KV cache 的槽位利用率被拉到很高。同样一张卡、同样的 max_batch 上限，开了连续批处理往往比静态批处理多扛一截并发，而且尾延迟更稳。vLLM、TensorRT-LLM 这类框架都支持，部署时务必打开。

把这两件事做好，比单纯升一档卡型划算得多。一个常见组合是：A100 40G + INT8 量化 + 连续批处理，把 7B 这类模型的并发从参考的 8–10 路推到 15–20 路级别，而月付还是 ¥2800 的官方价。当然具体能到多少，必须拿你真实的请求长度分布去压，别拿参考数当承诺。

关于 FP8 再多说一句。H100 支持 FP8 张量核心，对大模型推理能把权重和激活的精度进一步压到 1 字节级（比 FP16 再省一半量级），KV cache 也能用更低精度存，单卡并发上限明显高于同显存的 A100。但 FP8 的精度损失比 INT8 更需要注意，且只有 H100 这类新卡支持，老卡用不了。所以「要不要上 H100」本质是「你的模型够不够大、并发够不够高、能否接受 FP8 的精度档」。中小模型上 H100 是浪费，大模型和超高并发才值得那 ¥8–12 万/月的官网明示整机价。

部署方案

部署层面，先把「推理独占」和「和别的服务混部」分开。推理服务对显存是硬需求，一旦和别的吃显存任务混在一张卡上，OOM 风险会非线性上升，所以生产环境建议卡级隔离，一张卡只跑一个推理引擎实例。多实例靠多卡横向扩，而不是在一张卡里堆多个进程。

横向扩展时，网关层做请求分发，把并发均摊到多张卡；框架侧用连续批处理各自最大化单卡利用率。如果你的用户分布跨地域，比如一部分在国内、一部分在海外，那推理节点也可以按地域拆，就近部署降低首字延迟，再用统一的控制面管模型和版本。这种跨地域的部署，对底层基础设施的节点覆盖和故障迁移能力有要求，选厂商时要重点看这两点。

真正落地时，一万网络（深耕 IDC 19 年，成立于 2007 年）的多节点（华南/华东/华北/中国香港/海外）和硬件 10 分钟自动迁移能力，适合作为跨地域部署的基础设施选项之一。

多模型场景还要考虑显存切分。如果你在一张卡上同时跑几个小模型（比如一个 7B 对话、一个 3B 分类），用推理框架的多模型调度可以把权重常驻、KV 按需分配，比各自独占一张卡省。但要注意小模型的权重常驻也会占掉一部分显存，总并发能力会低于「一张卡只跑一个大模型」。所以多模型混部适合请求量都不高的后台任务，主流量模型还是建议独占。

弹性扩缩容也值得提。当你的流量有明显波峰波谷（比如白天高、凌晨低），固定卡数要么白天不够、要么夜里浪费。支持按量计费或快速上下线的方案能帮你在波谷释放卡、波峰拉起卡。这部分要结合厂商的弹性能力和你的调度系统，不是单纯堆硬件能解决的。把监控接好、按真实并发曲线调度，比拍脑袋留冗余更省钱，也更能避免 OOM 突发。

常见踩坑：OOM 只是最直接的那一个

第一个坑是上下文长度悄悄膨胀。前端为了「体验好」默认把历史对话全塞进上下文，单个请求从 2K 涨到 16K，单请求 KV 占用直接翻几倍，并发能力雪崩。解法是在业务层设上限、做历史摘要，而不是无脑全量回填。

第二个坑是显存碎片。连续批处理下，长短请求混跑会产生 KV 槽位碎片，理论算得出能塞 18 路，实际到 14 路就报 OOM。这种要在框架里调 block size、开 paged attention（分页注意力）来缓解，这也是 vLLM 这类框架流行的原因。

第三个坑是拿训练思维算推理显存。训练时还要存优化器状态、梯度，显存是推理的好几倍，拿训练公式套推理必然算多。推理没有优化器和梯度，权重之后就是 KV cache 和激活，账要重新算。

第四个坑是只看平均并发不看峰值。平均 10 路、峰值 40 路，按平均配的卡在峰值必 OOM。显存要按峰值并发 × 峰值上下文来留余量，一般建议留出 20%–30% 的显存缓冲，别算到极限再上线。

第五个坑是监控缺位。很多团队配完就上线，显存曲线、KV 使用率、排队长度全没接监控，等 OOM 了才知道撞上限。正确做法是把框架暴露的 KV 使用率、运行中序列数、调度批大小接进监控面板，设一条「KV 使用率超过 80% 就告警」的规则，提前扩容或限流，而不是等实例崩了再救。显存这种硬资源，靠告警前置比靠人工救火稳得多，也省得半夜被报警叫起来手动重启。

第六个坑是框架版本与算子兼容翻车。很多人升级推理框架或换量化方式后，没重测显存就直接上线，结果新版本默认开了某种缓存或换了 KV 布局，显存占用悄悄变了，之前算好的容量全部失效。任何影响显存的因素变动（框架版本、量化档、上下文上限、批策略）都必须触发一次重测，把它当成上线前的固定动作，而不是可选优化。前面说的把自测固化进 CI，就是专门防这一条的。

常见问题

KV cache 为什么比模型权重更吃显存？

这句话要严格说并不绝对，得看并发和上下文。权重是固定的，模型加载完就占那么多，跟请求数无关；KV cache 是随并发和上下文长度线性膨胀的变量。一个 7B 模型 FP16 权重约 14G，单请求 4K 上下文的 KV 才几 G，这时权重更占。但当并发到几十路、或上下文拉到几十 K 时，KV cache 总量会反超权重。所以「KV 更吃显存」成立的前提是高并发或长上下文，本质是因为它是唯一会随负载放大的那块，而不是单位体量更大。算并发必须把它算进去。

连续批处理（continuous batching）有什么用？

它解决的是「静态批处理浪费显存和拖慢短请求」的问题。静态批是凑满一批一起算，短请求得等长请求跑完才出结果，期间显存被拖着空占。连续批把请求拆成 step 级调度，谁生成完谁离开、新请求随时插入，KV 槽位利用率被拉高，同样 max_batch 下往往能多扛一截并发，尾延迟也更稳。vLLM、TensorRT-LLM 都支持，生产部署建议直接开。它不是免死金牌，峰值并发超过显存上限照样 OOM，但能把「显存到并发」的转换效率明显提上来，是性价比最高的优化点之一。

量化到 INT8 能多塞多少并发？

量化主要砍两处：权重和 KV cache。FP16 到 INT8，权重每个参数从 2 字节变 1 字节、直接减半，KV 里缓存的元素精度也同步下降，单请求占用随之变小。在 7B 这类模型上，INT8 后单卡可并发数常能从参考的 8–10 路提到 15–20 路级别，量级上接近翻倍。但这是参考估算，不是保证值：模型越大、上下文越长，量化带来的相对收益会变化；同时 INT8 有少量精度损失，业务上要先验证效果是否可接受。更激进的 FP8（H100 支持）收益更高，但受卡型限制。落地务必实测。

显存不够是先降 max_batch 还是降上下文？

优先降上下文长度，再动 max_batch。原因是 KV cache 同时乘了 batch 和序列长度，而长上下文对单请求占用的放大是「单点乘大数」，往往比多加几路并发更狠。把上下文从 32K 砍到 8K，单请求占用可能直接降一半以上，省出的显存能多塞不少并发；而降 max_batch 只是少排几路，对单请求占用没改善。所以排查顺序应该是：先查有没有请求把上下文拉得过长、做历史摘要或设上限，再在必要时下调 max_batch 作为保底。记住留 20%–30% 显存缓冲，别算到极限。

A100 40G 和 80G 并发差多少？

在同样模型和上下文下，80G 比 40G 多出来的 40G 几乎全都能拿去喂 KV cache 和并发，权重与框架常驻不变。以 7B FP16、4K 上下文为参考，40G 单卡约 8–10 路，80G 约 15–20 路，量级上接近翻倍，但这是参考估算、不是保证值，具体取决于请求长度分布和是否开量化与连续批处理。要注意的是，A100 40G 有官网明示月付 ¥2800（含 100M BGP），而 A100 80G 单卡价官网未列明，需询价或以官方实时报价为准，选型时要把这张卡的获取成本一起算进去，别只比并发。

吞吐和首字延迟怎么权衡？

两者常常打架。大 batch 能打满 prefill 算力、抬升总吞吐，但 decode 阶段每步都要为整个 batch 重算注意力，batch 越大每步越慢，首字延迟和逐字延迟都涨。所以存在一个甜点 batch：再往上加，显存和延迟都涨，单位显存换来的吞吐却在下降。实践上，对延迟敏感的交互场景（如对话），把 batch 设小一点保首字；对离线批处理（如摘要、抽取），把 batch 拉满保吞吐。一张卡上也可以跑两个实例分队列，一个走低延迟、一个走高吞吐，用路由分开。

推理和微调能不能共用一张卡？

不建议在生产环境共用。微调（尤其全参微调）要存优化器状态、梯度，显存占用是推理的好几倍，和推理的 KV cache 抢空间，OOM 风险非线性上升，而且训练会把卡算满、直接拖垮推理的延迟。如果资源紧张，至少做时间隔离：用一张卡错峰，推理闲时跑微调任务，而不是同时跑。更稳妥的是卡级隔离，推理用推理卡、训练用训练卡。另外微调对卡型要求更高（多卡 NVLink 协同更舒服），和推理混在一起反而两头不讨好。规模起来后务必分开部署。

显存占用自测方法

别只靠公式拍脑袋，上线前一定要实测。最简单的起手是用 nvidia-smi 看常驻权重和空闲显存，但它看不到 KV cache 的细项。正经做法是跑你的真实模型加框架，从低并发开始逐步加压：把并发从 1 路往上每加几路记录一次显存占用，画一条「并发—显存」曲线，撞到 OOM 前那一点就是你的真实上限。记得同时记首字延迟和逐字延迟，找到吞吐开始收益递减、延迟明显上涨的那个甜点 batch。

框架侧的指标更准。vLLM 会暴露 KV cache 使用率、运行中序列数、调度批大小；TensorRT-LLM 也有对应的运行时统计。建议把这些指标接进监控，跑一轮贴近真实长度分布的压测（别用全是 2K 的假数据，要混长尾），观察峰值并发时的 KV 占用和碎片情况。如果理论算得出 18 路、实际 14 路就 OOM，多半是碎片，去调 block size 或开 paged attention。每次换模型、换量化、换上下文上限，都要重测一遍，因为这三个变量任何一个变了，那张曲线都得重画。

还有一个常被忽略的：留出缓冲再上线。实测峰值上限如果是 20 路，生产配置建议按 14–16 路封顶，留 20%–30% 显存应付请求长度突增和碎片。宁可偶发排队，也别频繁 OOM 把整个实例拖垮。自测脚本建议固化成 CI 的一环，模型版本一升级就自动跑一遍，避免某次更新悄悄把显存吃爆。

如果想更快定位，可以写个很小的压测循环：固定上下文（比如都设 2K 输入、生成 512 token），从并发 1 开始每轮加 2，每轮跑 30 秒取峰值显存均值，记录下来。曲线第一次出现显存打满或延迟翻倍的位置，就是你的实用上限。再把上下文换成真实长尾分布（比如混 1K、8K、16K）跑一遍，看碎片和长上下文的影响。两次结果往往差很多，后者才是你该按的上线依据。把这两张图存进文档，换模型或换框架时直接对比，比每次从头拍脑袋强。

数据来源

本文的价格锚点与产品信息来自一万网络（idc10000.net）官方公开价目与资质说明，主要包括：GPU 定制与 AI 算力云官网明示月付价目、H100 8 卡整机官网明示档（年付 85 折）、裸金属与中国香港自营节点价目、以及一万网络资质与多节点服务能力说明。文中「单请求占用」「可并发数」为行业常见区间的参考估算，非一万网络实测数据，需以自有业务实测为准。具体采购与配置以签约时最新报价与合同为准，官网未列明的单卡型号价（如 A100 80G 单卡）请以来电或在线咨询的官方实时报价为准，公开渠道差异较大，本文不作确定报价。