显存计算器
这个页面用来回答一个具体问题：手上这张显卡，能跑哪个尺寸的本地大模型，能开多长的上下文。填入显存容量、想要的上下文长度和并发数，下面会列出每个 Gemma 4 变体在每种量化格式下的显存占用拆解，以及装不装得下。
所有模型体积都是从 HuggingFace API 查到的真实文件字节数，不是按参数量乘以位宽估算的。这个区别很重要：同一个模型的不同量化格式，体积差异经常和直觉相反，后面会解释为什么。
模型体积是从 HuggingFace API 查到的真实文件字节数换算成 GiB，不是按参数量估算。跑 GGUF 时 E 系列的 PLE 表和 token embedding 留在系统内存，这部分已经从显存里扣掉了——所以「权重」一栏会明显小于文件体积。KV cache 按各变体的层数、KV 头数、共享层数和滑动窗口计算。整套公式拿一台 8G 笔记本上 E4B 在 8K/32K/64K/128K 四档上下文的实测显存校准过，误差在 0.15 GB 以内；其他变体属于同架构外推，判定为「勉强」时建议先把上下文调小试跑。多卡是按「显存可叠加、每卡各留一份计算缓冲」建模的，没有实机验证过，实际还要看卡间互联带宽和切分方式。
怎么读这几个数字
权重是模型参数本身要占的显存。它不等于模型文件的大小——跑 GGUF 格式时，Gemma 4 的 E 系列会把 PLE（per-layer embedding）表和 token embedding 留在系统内存里，不上显卡。E4B 的 q4_0 文件有 4.8 GiB，但真正进显存的只有 2.2 GiB 左右，因为那张 PLE 表一个人就占了 2.8B 参数。如果按文件体积去估算显存，会凭空多算 2 GB 以上，足以让一张 8G 卡被误判成跑不了 E4B——实际上它跑得很轻松。
KV cache 是推理过程中缓存的注意力键值，随上下文长度和并发数线性增长。Gemma 4 的 E 系列在这一项上格外省，原因有两个：一部分层直接共享上层的 KV 不单独占空间，另一部分层用 512 token 的滑动窗口注意力，无论上下文开多长，这些层只需要保留窗口内的那一小段。所以 E4B 从 8K 开到 128K，KV 只涨了约 1.1 GB；换成没有这些设计的同尺寸模型，涨幅会是好几倍。
运行开销包括计算缓冲区、显存碎片和推理引擎自身占用。这一项没法从模型结构精确推出来，是拿实测数据拟合的：常数项加一个随上下文线性增长的量。
误差有多大
整套公式在一台 8G 显存的笔记本上校准过，对象是 E4B 的 q4_0 量化，用 llama.cpp 的 Vulkan 后端，KV cache 量化到 q8_0。四档上下文的实测与预测对比：
| 上下文 | 预测 | 实测 | 误差 |
|---|---|---|---|
| 8K | 2.96 GiB | 2.90 GiB | +0.06 |
| 32K | 4.16 GiB | 4.25 GiB | −0.09 |
| 64K | 4.52 GiB | 4.54 GiB | −0.02 |
| 128K | 5.26 GiB | 5.14 GiB | +0.12 |
需要说清楚的是：这是一个变体、一套软件栈的校准结果。其他变体是按同一套架构公式外推的，没有逐个实测过，误差可能更大。所以判定结果分三档而不是简单的能／不能：留出足够余量才算「装得下」，余量很薄的标成「勉强」。看到「勉强」时，建议先把上下文调小一档实际跑一次，再决定要不要往上顶。
量化格式的体积陷阱
选型时最容易踩的坑，是假设「同一个模型，4 bit 量化后体积大约是参数量的一半」。Gemma 4 官方的 QAT 版本用的是 compressed-tensors 格式，配置里写的是 targets: ["Linear"]——只量化线性层，embedding 层保持 bf16 原样。对于 embedding 占比很高的模型，量化后的体积会比预期大得多。
最反直觉的一组数字：E4B 的 QAT W4A16 版本有 10.72 GiB，而参数量是它三倍的 12B Unified，同样是 QAT W4A16，只有 9.56 GiB。也就是说，如果你按「参数少的一定更小」去选，会选到一个更大更慢的模型。E 系列那张巨大的 PLE 表在 bf16 下没被压缩，直接把体积撑上去了。
换成 GGUF 的 q4_0 就没这个问题，因为它连 embedding 一起量化，E4B 降到 4.8 GiB。所以小显存机器上应该优先考虑 GGUF + llama.cpp，而不是 QAT 权重 + vLLM——后者是给显存充裕的机器准备的，它的优势在吞吐和并发，不在体积。
多卡的两个限制
把显卡数量调到大于 1 时，可用显存是各卡相加，但有两点不是简单叠加。
vLLM 的张量并行要求 KV 头数能被卡数整除。它把注意力头切开分到各张卡上，切不整除就起不来。Gemma 4 各变体的 KV 头数分别是：E2B 1 个、E4B 2 个、12B 和 26B A4B 各 8 个、31B 16 个。所以 E2B 在任何多卡配置下都用不了张量并行，E4B 最多 2 卡；而卡数取 3、5、6 这类非 2 的幂时，没有任何变体能整除。计算器会在这种情况下直接说明，而不是让对应的行凭空消失。
llama.cpp 按层切分，没有整除限制，但也不会更快。它把不同的层放到不同卡上，推理时逐层流过——同一时刻只有一张卡在算。多卡对它的意义是「装得下更大的模型」，不是「跑得更快」。想要多卡带来吞吐提升，得走 vLLM 的张量并行，并接受上面那条整除约束。
另外，每张卡都要自己的一份计算缓冲，所以运行开销是按卡数放大的，不是摊薄的。这部分我没有多卡实机可以验证，是按模型推算的，比单卡的数字更粗糙。
还需要留多少余量
「已被占用」那一栏容易被忽略。接了显示器的机器，桌面合成器和浏览器通常已经吃掉 0.3 到 1 GB，这部分要先扣掉再算模型。纯计算卡或者用核显输出显示的机器可以填 0。
另外，多模态投影（mmproj）是单独一个文件，只有需要图片输入时才加载。如果只做纯文本推理，把那个勾去掉能省下 0.9 GB 左右——在 8G 卡上这不是小数目。
相关文章
- Gemma 4 全变体解析：性能、效率与怎么选：逐个讲清 E2B、E4B、12B Unified、26B-A4B 和 31B 的架构差异、benchmark 表现和适用场景。
- 自建 Gemma 4 网关：实跑才会撞上的坑：从选型算错体积到隧道抢占路由，记录整个部署过程中真实踩到的问题。
- 本地大模型部署教程（一）：选型与环境准备：按步骤操作的部署教程系列，第一篇讲怎么根据硬件选变体和推理引擎。
- 实用功能：站点内其他浏览器端工具。
计算器只解决「装不装得下」这一个问题。装得下之后模型跑多快、上下文开大以后首 token 延迟会涨到什么程度、并发几路开始明显掉速，这些要看实际的推理引擎配置和显卡带宽，计算器给不出答案，得实测。教程系列里有对应的压测方法和参数调整记录。