最近Gemma 4家族陆续放出多个型号身边同行问得最多的不是“跑分多少”而是“我现在这个GPU跑A型号还有富余换到B型号要不要换卡、预算怎么调”。这个问题看起来很具体但真正上手后会发现在哪里都说不上来原因只有一个换型号这件事本质上是把整个资源账重新算一遍而且往往算完就发现原来的富余没那么富余。这篇文章就来聊透这件事。我会先讲清楚为什么换个型号显存、带宽、吞吐这些数字要全部推翻重算再给出可以直接用的估算公式和手算过程然后对照Gemma 4家族几个典型档位看看同样的GPU在不同型号下的位置有什么变化最后分享我实际踩过的一些坑以及现在固定下来的一套验证流程。别管你是刚接触大模型部署的初学者还是已经搞过几版推理服务的工程师按这套思路走一遍至少不会再出现“模型能加载、并发一高就OOM”这种尴尬局面。1. 换型号不是换数字哪些资源被“隐形重算”了1.1 参数规模翻倍显存不是翻倍这么简单很多人下意识的想法是3B模型换到9B模型参数量翻了3倍那显存预算乘3不就行了这个思维在只保存权重的静态场景里勉强能用但真正跑推理任务时显存里装的不只是权重还有KV Cache、激活值、框架自身的缓存这些动态部分和参数规模并不是同比例增长的。我之前在24GB显卡上跑Gemma 4的一个小号模型8K上下文、batch 32跑得稳稳当当。换成中号模型刚开始以为权重翻了3倍18GB应该也能塞得进去。结果一启动就发现不对劲KV Cache的消耗几乎是原先的5到6倍因为参数量变大通常意味着层数更多、序列处理能力更强但显存里能腾给中间状态的空间反而越来越小。这里最核心的一点是显存里同时装着“模型这个静态文件”和“每个请求的活动状态”静态部分大一点点动态部分的容错空间就会快速缩小。1.2 三个最容易算错的关键账本我习惯把推理服务的资源账拆成三本权重账、运行时态账、吞吐账。换型号时这三本全部要重算。权重账最简单就是模型文件在显存里占多大主要取决于参数量和存储精度。运行时态账复杂一些它包含KV Cache、激活值、临时buffer跟着请求并发数和上下文长度走是动态波动的。吞吐账更隐蔽它不直接占显存但决定你的GPU到底能出多少并发、每个请求多快返回由显存带宽、算力、框架调度方式共同决定。换号时最容易错的就是只重新算了权重账把后两本完全忽略。结果就是模型加载成功但并发一上来延迟曲线直接起飞。1.3 为什么小模型的经验不能类推到大模型我见过太多新手拿着小模型部署经验直接套到中大型号上。小模型的时候权重只占显存一小部分剩下的空间足够缓存所有中间状态常常感觉“随便跑”。但跨过一个临界点后权重开始挤压动态空间显存管理的容错性大幅下降同样的参数倍数变化影响完全是另一回事。简单说小模型像在宽轨上跑火车换多大的车厢都能轻松调度大模型像在高架桥上跑重卡超重一吨就是能不能上路的问题。所以从Gemma 4的小型号切到中大型号时绝不能沿用过去“显存差不多够”的模糊判断方式每一步都要重新计算。2. 动手前先把资源账算明白计算公式与手算示例2.1 权重显存唯一能直接算准的部分权重显存的公式是参数量乘以每个参数占用的字节数。一个FP32参数占4字节一个FP16/BF16参数占2字节INT8量化后是1字节INT4量化后是0.5字节。以某个90亿参数的Gemma 4中号版本为例加载FP16权重需要90亿乘以2字节约18GB显存这种规模在24GB显卡上还算宽松。而一个270亿参数的大号版本FP16权重直接到54GB单张24GB卡完全放不下即便换到48GB的专业卡也装不进全精度权重。所以大号版本基本默认走量化路线INT4权重约13.5GB这样高性能显存卡才有可能带得动。提示参数量单位里的“B”是十亿不是字节。计算时先搞清楚单位27B是270亿个参数乘以每个参数字节数后除以1024的三次方得到的才是GB。很多人在这里翻车把数字算小了好几倍。2.2 KV Cache长上下文的吞显存大户KV Cache就是推理过程中给每个请求缓存Key和Value向量的区域。只要请求还活着它的KV Cache就一直占着显存直到请求结束才释放。这个动态内存的字节数等于2乘以层数乘以KV头数乘以每个KV头的维度再乘以序列长度乘以批大小乘以每个数据的字节数。公式里的2表示K和V各一份。举个例子假设一个27B模型有48层GQA后KV头数为8每个KV头维度128按FP16计算每个token每个请求的KV缓存大约0.2MB。上下文8K时单请求约1.6GB看着还好但如果一次并发32个请求就是51.5GB。加上54GB的FP16权重一张80GB显卡直接满载。很多人只是简单把上下文长度调高了一点KV Cache就悄悄把剩下的显存全部吃光这就是OOM最典型的来源之一。这里还要特别注意GQA这个设定。传统多头注意力是每个头都有独立的KVKV Cache极大。GQA让多个查询头共享一组KV头大幅节省显存。不同型号可能组间共享的数量不同KV头数一旦变了KV Cache的总占用也会完全不同这部分不会反映在参数量变化上最容易漏算。2.3 带宽与算力决定你能跑多快显存带宽是指GPU每秒钟能从显存读取多少数据。Transformer推理生成每个token时都要把整个模型权重扫一遍所以单用户生成速度的上限大概是显存带宽除以权重大小。以A100/H100这类约2TB/s带宽的显卡为例27B的FP16权重约54GB理论最高输出速度约37 token/s。同样带宽下9B的FP16权重约18GB理论速度提升到110 token/s左右。这个差距不是参数倍数而是权重读取开销的差距。另外显存带宽是所有并发请求共享的。并发32个用户时GPU总输出token速度依然被这个带宽上限约束每个用户分到的生成速度就下降了。小模型因为权重读取负担轻能扛起更高的并发吞吐大模型即便算力完全够用也可能因为带宽不够而卡住延迟。需要注意的是小模型场景算力可能成为瓶颈这时不需要太关注带宽但当中大型模型在消费级显卡上运行权重就是“读一次算一次”带宽几乎总是瓶颈。所以量化后速度提升不单是显存变小更大程度是每token要读取的字节数少了带宽压力直接下降。3. Gemma 4家族换型号的典型资源对比3.1 同一个GPU不同档位型号的位置完全不同为了把问题具体化我先按常见档位把Gemma 4家族粗略分成三档小号约30亿参数、中号约90亿参数、大号约270亿参数。然后再看几张常见显卡上各自的资源状况。先看24GB显存级别的显卡。小号FP16权重6GB加上KV Cache和框架开销可自由分配空间很充裕甚至能开不小的batch是典型的“随便跑”。中号FP16权重18GBSingle sequence短上下文勉强可行但一旦把上下文拉到8K以上或者并发数量增加空间立刻见底基本建议量化到INT8/INT4。大号在24GB卡上没有任何精度方案能完整装下必须走模型并行或卸载。如果是48GB显存的专业卡比如L40S或A6000中号FP16会非常舒服动态空间很大。大号FP16的54GB放不下但用INT4约13.5GB就能装得很从容可以把省下来的显存留给大批次长上下文。再往上80GB级别的A100/H100大号FP16刚好能装但长上下文并发需要谨慎预留KV Cache如果换成INT4整个模型只占13.5GB剩下60多GB可以全部用于动态缓存服务形态和FP16完全不是一个概念。3.2 同一个型号换精度账也要全重算很多团队换型号会顺势从FP16改成INT4量化部署以为显存需求变成原来的四分之一。实际上只有权重部分是四分之一KV Cache如果不量化体积完全不变激活值和框架缓存也不变。短请求时权重占大头量化收益很明显长请求并发高时KV Cache占大头量化的相对收益就缩水这一点不重新算账很容易误判。我在一次压测中就遇到了这种情况。一个27B模型大幅量化后显存层面确实从超过54GB降到了十几GB本以为并发能力会大幅提升实际测下来并发一高单请求数据集的KV Cache仍把显存扛住结果并不比FP16好多少。所以碰到“量化之后应该跑得动”的直觉建议把KV Cache单独算一遍再下结论。3.3 连续批处理改变了资源账的性质不同推理框架对KV Cache的管理方式极大影响资源上限。传统的静态批处理一个批次的所有请求必须同时开始同时结束显存按最大batch预留浪费很多。连续批处理则是在token级别动态调度哪个请求结束就让新请求插进来显存利用率大幅提升同样物理显存能支撑的并发请求可以高出很多。这个差异换型号时会更明显因为请求处理的时间变了batch的调度节奏都会变。同一个模型在生产环境合理配置连续批处理和没开这个功能能扛的并发可能差3到5倍。所以看资源账不能只盯着显存还要把框架的批处理策略纳入考量。4. 一次完整实操从估算到压测的验证流程4.1 估算先行拿目标模型先算一遍我现在接到换型号需求第一件事不是上机器而是先拿一张纸或电子表格把数据过一遍。以27B FP16在80GB显卡上为例权重54GB假设单请求8K上下文KV Cache约1.6GB激活值和框架缓存按经验预留3GB到5GB。那么允许的并发数大概是可用显存除以每个请求的KV Cache大小80GB减去权重和固定开销后剩大约21GB除以1.6GB差不多能支撑13个8K并发请求。这个估算过程看起来繁琐做熟练后不到五分钟就能出结果。关键是要把每一项分开列出来权重要和KV Cache区分开这样一旦OOM你能立刻判断问题出在哪一项。4.2 上真机压力测试的步骤和指标估算完毕接着上真机验证。我不会只跑单个请求就宣布“能跑”那等于没测。我的标准流程是先用一个短请求确认模型能正常加载和推理然后逐步增加并发数观察显存占用、总吞吐、每个请求的首token延迟和生成速度。通常我会用脚本去压测并发从1、2、4、8一路往上涨每次记录一组显存和延迟数据。for c in 1 2 4 8 16 32; do python benchmark.py --concurrency $c --input-len 512 --output-len 1024 done对比不同并发下的数据可以清楚看到两个关键现象一是显存在某个并发附近达到上限再往上就OOM二是总吞吐在某一点后不再增长说明带宽或算力已经饱和。4.3 我踩过的坑计划表与现实差在哪第一个坑是只测短文本。我曾经用512 token的测试用例验证通过上线后业务流程里有大量8K到16K的长文档摘要结果一到长文档就OOM。KV Cache对上下文长度敏感没测过的场景等于没验证。第二个坑是不给框架留“呼吸空间”。CUDA context、框架分配器、序列化器都占显存看起来不起眼实际可能吃掉2GB到4GB。如果估算时把显存占满运行时一定会出问题。所以我默认预留至少4GB。第三个坑是换型号后第一次启动特别慢。很多框架要重新编译CUDA kernel首次启动可能多花几分钟。如果在生产环境直接重启容易出现超时误报需要提前做一次预启动。5. 常见问题速查资源账对不上时怎么办5.1 OOM炸了先分清是权重还是KV Cache爆了OOM是最常见的问题但处理方向要看爆的是哪部分。如果模型刚加载完还没发请求就报显存不足权重或框架预留空间就有问题直接降低模型精度或换更小模型。如果加载正常请求一多才炸基本就是KV Cache或激活值超了优先限制最大上下文长度、降低并发数或者对KV Cache做量化。排查时看监控会很有帮助。显存曲线在启动时先冲高一次之后随请求逐步爬升然后稳定一半是动态部分不够如果显存曲线启动后直接横在最高位一般是权重部分太大动态部分根本没有余量。5.2 吞吐量远低于预期找显存带宽还是算力问题如果GPU利用率很低但单个请求的生成速度明显慢多半是显存带宽瓶颈尤其是大模型还在用高精度权重时。对策就是量化、剪枝或换更小模型让每token读取量降下来。如果GPU利用率已经很高但总吞吐还是上不去说明算力基本跑满了调整batch大小或请求调度方式可能更有意义。判断方法很直观看生成阶段的GPU计算利用率。大模型高精度部署时显存搬运往往成为瓶颈这时降低精度效果显著小模型算力占满时调精度通常没太大改善反而应该优化框架或改batch。5.3 并发一高就卡batch策略和显存碎片并发一高就卡还有一个隐藏因素显存碎片化。KV Cache频繁分配释放会让碎片空间越来越多即使总的空闲显存足够也分配不出连续的大块内存。这个问题可以用支持分页管理的推理框架来解决它在显存里按页分配KV Cache能有效缓解碎片。同时检查连续批处理有没有真正开启。很多框架默认关闭或需显式配置开着和关着在并发场景下差距非常大长期压测时一定要确认。6. 换型号前的最后检查清单与我的经验6.1 一张可以打印的核对表我现在换型号前都会逐项确认这六件事目标模型的参数量和结构细节权重字节数框架和CUDA预留的固定开销最大并发与最大上下文下的KV Cache上限带宽和算力决定的吞吐上限以及默认的批处理与显存管理策略是否满足并发需求。每一项背后都有原因的。比如KV Cache上限如果没提前算好上线后遇到长窗口请求就措手不及吞吐上限如果不对齐业务QPS预期压测阶段就会暴露问题而不是等到生产环境才出状况。6.2 我的习惯把资源账做成自动化脚本算多了以后我干脆写了个Python小脚本输入参数量、层数、KV头数、KV头维度、上下文长度、batch数、精度格式就能直接输出权重显存、KV Cache、总显存估算和理论带宽上限。这样换型号的时候只要改几个数字整张表就出来了。def estimate(parameters_b, layers, kv_heads, head_dim, seq_len, batch, precisionfp16): bytes_per_param {fp16: 2, int8: 1, int4: 0.5}[precision] weight_gb parameters_b * 1e9 * bytes_per_param / (1024 ** 3) kv_bytes_per_token 2 * layers * kv_heads * head_dim * 2 kv_cache_gb kv_bytes_per_token * seq_len * batch / (1024 ** 3) return weight_gb, kv_cache_gb, weight_gb kv_cache_gb这个脚本帮我避过不少雷。有一次同事直接拿上一个大模型的显存估算值来配新模型我跑了一遍脚本发现KV Cache部分完全对不上才及时调整了并发上限。建议你直接把这个逻辑嵌入到部署流程里做成一个小的检查脚本换任何型号时先跑一遍。6.3 最后分享一个小技巧我个人在实际操作中最大的体会是不要只看“能不能加载”要看“跑到什么程度会崩”。每换一个型号确定好目标并发和上下文后主动压到显存上限附近观察表现记录下当时的并发数和延迟存成一份基线数据。下次再调优、再压测时这份数据能帮你快速判断是模型变化还是配置改动带来的效果。实测下来这个习惯比临时抱佛脚看日志要可靠得多。