本地跑大模型要多少显存：8 档参数与 3 种精度对照

显存算错的人，通常在买完卡之后才发现问题：权重装得下，上下文一开长就 OOM；或者反过来，按总参数买了八张卡，结果模型只需要两张。这篇只做一件事——把「跑得动」拆成三个可以分别计算的量：权重、KV 缓存、框架开销。

先记住一个公式

权重显存 ≈ 参数量 × 每参数字节数

每参数字节数由精度决定：

最后一行的差距值得单独说：很多人按 0.5 算，得出 7B 只要 3.5 GB，实际下载下来是 4.2 GB 左右。多出来的部分是分块量化存储的 scale 与 zero-point。经验系数是 理论 INT4 × 1.15 到 1.2，这个偏差在大模型上会被放大成几十 GB。

8 档参数，三种精度

下表按「权重」口径计算，Q4_K_M 一列已按 1.2 系数修正。

看到这张表就能明白为什么 24 GB 是消费级的分水岭：它刚好落在 27B–32B 的 Q4 区间。也正因为卡在边界上，站内那篇 Qwen3.8-27B 的显存账本 才会得出「权重装得下、262K 装不下」这个结论——16.4 GB 之外只剩不到 8 GB，而完整的 262K 缓存要 16 GiB。

第二笔账：KV 缓存

权重是一次性成本，KV 缓存是随上下文线性增长的持续成本。

KV 缓存 ≈ 2 × 层数 × KV 头数 × head_dim × 序列长度 × 批大小 × 字节数

以常见的 GQA 结构为例（32 层、8 个 KV 头、head_dim 128、FP16）：

• 单层单 token：2 × 8 × 128 × 2 = 4096 字节
• 全模型单 token：4096 × 32 = 131072 字节，即 128 KB
• 32K 上下文：128 KB × 32768 ≈ 4 GB
• 128K 上下文：≈ 16 GB

128K 上下文的缓存和 7B 模型的 FP16 权重一样大。这就是「上下文长度是第二个显存黑洞」的算术依据。

70B 级别更极端：80 层、8 个 KV 头、head_dim 128，单 token 约 320 KB，32K 上下文就要 10 GB，128K 要 40 GB——已经超过半张 80 GB 卡。

降低这笔开销的手段有三个，效果递减：

1. GQA / MQA：减少 KV 头数，是架构层最有效的办法；
2. KV 量化到 FP8：缓存直接减半，质量损失很小，vLLM 等框架已支持；
3. PagedAttention 一类的分页管理：减少碎片，不减少总量。

第三笔账：框架开销

容易被忽略，但确实存在：CUDA context、激活值、框架自身的缓冲区，通常吃掉 1–2 GB。批大小越大、并发越高，激活值占用越明显。

所以实际可用显存的算法是：

可用显存 = 显卡容量 − 权重 − 框架开销（1–2 GB）− 其他进程占用

24 GB 卡跑 27B Q4，可用给 KV 的只有 24 − 16.4 − 1.5 ≈ 6.1 GB，按 128 KB/token 换算约 4.7 万 token。站内实测给出的是「约 38K」，差额来自并发与碎片预留——这也说明：算出来的上限要再打七到八折。

常见显卡能跑多长上下文

这张表的前提是单用户、单请求。一旦上并发，可用上下文要按并发数往下除——批大小 4 的时候，24 GB 卡跑 27B 的可服务上下文会掉到 8K 上下。

三个最容易踩的坑

坑一：拿激活参数当显存

MoE 模型的宣传语常写「总参数 2.8T，激活 104B」。激活参数决定的是算力开销，不是显存开销——所有专家的权重都得加载进显存，否则路由到未加载的专家就没法算。

所以 2.8T 的 MoE 模型，Q4 下权重是 TB 级，消费级显卡根本装不下，和「只激活 104B」没有关系。站内拆解 Kimi K3.1 Pro 的开放权重 时提到「开放权重」不等于「本地可跑」，也是同一个道理。

反过来，LongCat-2.5 这类万亿参数模型能在国产算力上跑通，靠的是多卡集群与并行策略，不是单卡优化。

坑二：把量化当成免费的午餐

Q4 相比 FP16 损失多少，取决于任务。经验规律：

• 通用对话、摘要、翻译：Q4_K_M 与 FP16 差距很小，可以接受；
• 数学推理、代码生成：Q4 掉点明显，建议 Q5 或 Q6；
• 长上下文检索：量化误差会在注意力里累积，Q4 在 100K 以上容易出现「看得到但答不准」。

有一个便宜的验证方法：拿你自己的 20 条真实任务，分别跑 FP16 与 Q4，比对通过率。差 3 个点以内可以接受，超过 8 个点就该换精度或者换更小的模型。

坑三：只看模型大小，不看并行策略

多卡不是把显存简单相加。张量并行有通信开销，流水并行有气泡，专家并行在 MoE 上才有效。同样 8 张 80 GB 卡，跑 671B 能到的上下文长度，取决于你用哪种并行、切几路、batch 开多大。

经验值：张量并行超过 8 路，通信开销会吃掉大部分收益；跨机部署时，节点间带宽往往成为真正的瓶颈，而不是显存。

一张决策流程

要判断一个模型能不能在你的机器上跑，按顺序问四个问题：

1. 权重要多少？ 参数量 × 精度字节数，Q4 记得乘 1.2。
2. 要开多长上下文？ 按 128 KB/token（7B–32B）或 320 KB/token（70B）估算 KV。
3. 剩多少给并发？ 减掉框架的 1–2 GB，再按并发数除。
4. 是不是 MoE？ 是的话按总参数算，别看激活参数。

四步走完还是算不清，最省事的办法是先用 Q4 跑起来，然后在框架日志里看实际的显存峰值——比任何公式都准。

一句话总结：显存 = 权重 + KV 缓存 + 框架开销，三项分别可算。真正让人买错卡的不是公式，而是把激活参数当显存、把理论 INT4 当实际占用这两件事。