企业官网建设流程全解析

先问你一个经常被问到的问题：你的显卡能跑多大的模型？群里聊模型的时候，这个话题几乎天天出现。有人说 7B 模型要 14GB 显存，有人说 8GB 显存也能跑，还有人拿 12GB 显存跑 13B 模型照样不爆。到底谁说得对？答案其实藏在三个数字里：参数规模、精度格式、上下文长度。今天我把自己平时给设备估显存的那套逻辑完整拆开讲，从权重怎么算，到 KV Cache 怎么吃显存，再到怎么选模型和显卡，一次性把“显存计算与模型选择”这件事说透。本文只聊本地推理部署，不涉及训练。

1. 先拆清楚：显存到底被谁吃掉了

很多人以为显存只装一个东西——模型权重。实际上推理时的显存占用至少有三块：权重、KV Cache、运行时缓冲。只盯着“模型文件多大”来选卡，十次有九次要踩坑。

1.1 权重显存：模型的“本体”开销

权重是模型的静态参数，加载后一直常驻显存。计算方法非常简单：权重显存 ≈ 参数量 × 每个参数占用的字节数。

不同精度下每个参数的字节数差别很大：

举个具体例子：一个 7B 参数的模型，如果用 FP16 存储，权重就要 14GB 左右，很多 12GB 显存的卡根本装不下。如果用 INT4 量化存，大概 4GB 就能装下，这就是为什么“8GB 显存也能跑 7B 模型”的说法成立。

这里要提醒一句：模型文件里除了权重，还有词表、嵌入层、输出层等额外参数，所以实际加载大小经常比“参数量 × 字节数”再多个 10% 左右。我一般会按“权重 + 20%”作为最低安全线来预估。

1.2 KV Cache：越聊越长，显存越撑越满

权重是固定开销，但 KV Cache 是动态的。每生成一个 token，模型都要把之前所有 token 的 Key 和 Value 向量存下来，用于后续计算注意力。这个缓存会随着对话长度持续增长，是长上下文场景下的显存大头。

每生成一个 token，KV Cache 的大小大致是：

单 token KV 大小 = 层数 × 2（K和V） × KV 头数 × 每头维度 × 精度字节数

举一个实际例子。某个 7B 规模的模型，32 层，KV 头 4 组，每头 128 维，FP16 精度：

• 每 token 字节数：32 × 2 × 4 × 128 × 2 = 65,536 字节，约 64KB
• 如果上下文长度是 4096，那么 KV Cache 约 256MB
• 如果上下文长度拉到 32,768，KV Cache 约 2GB

看起来不算离谱，但换到 70B 这种大模型就不一样了。70B 模型往往 80 层，KV 头 8 组，每头 128 维，FP16 精度下每 token 的 KV 就高达 320KB。上下文拉到 32K 时，KV Cache 能轻轻松松超过 10GB。

所以你会发现一个现象：有些人的显卡跑 7B 模型起步很顺利，但长文档对话到了一万 token 之后突然 OOM。这不是权重的问题，是 KV Cache 在后期慢慢把显存挤爆了。

1.3 运行时缓冲：被很多人低估的“服务费”

推理框架跑起来之后，中间激活值、临时变量、显存分配器预留的内存池，加起来一般占权重显存的 10% 到 30%。这部分虽然不是大头，但在显存卡得非常紧的时候，就是压垮骆驼的最后一根稻草。

我见过最典型的场景：权重 7GB，KV Cache 预估 3GB，显卡 12GB，看起来还够。结果一跑，框架直接报 OOM，原因就是运行时缓冲吃掉了剩下那 2GB。所以做预算时，永远要预留余量，不要卡着理论最大值去选卡。

2. 一套公式把显存预算算明白

第一部分已经交代了三大开销来源，现在把完整的计算方法拎出来。以后无论是选卡还是下载模型，都可以按这套流程走一遍。

2.1 权重部分的口算公式

我平时口算权重显存只用两个结论：

• FP16 / BF16 下，每 10 亿参数大约占 2GB 显存
• INT4 量化下，每 10 亿参数大约占 0.5GB 显存，实际文件普遍在 0.55 到 0.6GB 之间

所以：

• 3B 模型 FP16 约 6GB，INT4 约 2GB
• 7B 模型 FP16 约 14GB，INT4 约 4GB
• 13B 模型 FP16 约 26GB，INT4 约 8GB
• 70B 模型 FP16 约 140GB，INT4 约 40GB

这个口算公式是大方向判断的利器，基本不会翻车。

2.2 KV Cache 的快速估算法

很多人不想背那串公式，我给一个更简单的办法：先查模型的配置参数，有这几项就能算出“单 token KV 大小”：

• 层数（L）
• KV 头数（GQA 场景下看 KV 头，MHA 场景下就是注意力头数）
• 每头维度（head_dim，常见 128）
• 精度字节数（FP16 是 2，INT8 量化是 1，KV 量化可用 0.5）

然后套标准公式，或者直接用一张参考表。下面这张是假设 head_dim 128、FP16 精度下的每 token KV 大小：

用这个“每 token 大小”乘上上下文长度，就能得到整段对话的 KV Cache。比如某模型每 token 128KB，你开 8192 上下文，那就是 1GB；开到 32,768，就是 4GB。心里有数了吧。

2.3 完整的四步判断流程

我每次估算某个模型能不能跑，永远按下面四步走：

1. 确定精度档位：是原版 FP16，还是 INT8、INT4 量化。
2. 算权重显存：参数量 × 每参数字节数，加 10% 余量。
3. 算 KV Cache：单 token KV 大小 × 计划使用的最大上下文长度。
4. 加运行时缓冲：在（权重 + KV Cache）基础上加 20% 左右。

最后把总数和显卡显存对比。如果预算刚好压在临界点，我的建议是换一个更保守的量化档位或缩短上下文，而不是赌它能跑。因为运行时缓冲、框架预留、显示占用这些变量，不跑起来你永远不知道实际吃了多少。

3. 量化是显存危机的最大变量

聊到显存计算，量化是绕不开的核心话题。前面已经反复提到 INT4 和 INT8，这一节把量化这件事讲透一点，包括它为什么管用、不同量化格式怎么选、以及量化后模型到底跑得快不快。

3.1 量化为什么能把模型“压扁”

量化说白了就是用更少的比特数表示权重。原来一个参数用 16 比特（FP16）存储，现在只用 4 比特或 8 比特，再配合一个缩放系数把数值范围映射回去。省下的空间非常直观：FP16 到 INT4，体积直接缩到原来的四分之一左右。

很多人担心质量问题。我的实测感受是：模型越大，量化越稳。70B 模型用 4bit 量化，跟原版 FP16 的差距十分微小，日常对话基本感觉不出来。但 3B、7B 这种小模型，4bit 量化后有时会出现表达变笨、偶尔胡说的现象，这时候优先考虑 5bit 或 8bit 量化档。

有个反直觉的点是：量化后模型占用的显存下降，但生成的 token 数量和质量并不总是协同下降。某些情况下，同样显存下你能把 7B 模型换成 13B 模型的 4bit 版本，最后效果反而是升级的。所以不要一听说量化就反感，它是本地部署里的常规手段，不是邪门歪道。

3.2 GGUF、GPTQ 这类格式怎么选

实操中我们下载模型时经常会看到不同后缀名，它们代表不同的量化打包方式。这里只说结论：

• GGUF 系列：目前兼容性最好，适合 CPU + GPU 混合部署，文件名里直接写明量化档位，比如 Q4_K_M、Q5_K_S、Q8_0。对大部分人来说，Q4_K_M 和 Q5_K_M 是最省心的选择。
• GPTQ 系列：需要 GPU 推理，4bit 表现稳定，适合显卡够用但想压显存的人。
• AWQ 系列：精度保护做得更好，但对推理框架有要求，部署门槛略高。

我的习惯是：个人电脑上优先选 GGUF 的 Q4_K_M。这个档位在文件大小、显存占用、输出质量三者之间平衡得最好，属于大部队的选择。如果显存还有余量，再往上升一档到 Q5_K_M 或 Q8_0，追求更接近原版的体验。

3.3 量化之后，还要看带宽够不够

这部分必须单独说明，因为它直接影响“能不能跑得爽”。推理时每生成一个 token，正常都要把整个模型权重从头到尾读一遍。因此生成速度的上限大约是：

token/s ≈ 显存带宽 ÷ 模型权重大小

这里的权重大小是每次生成都要扫描的数据量。举几个直观的例子：

• 某 24GB 显卡，显存带宽约 1TB/s，跑 7B 模型的 Q4 版本约 4GB，理论上限约 250 token/s，实际一般在 100 到 150 之间。
• 同样是这张卡，跑 32B 模型的 Q4 版本约 19GB，理论上限约 52 token/s，实际基本在 20 到 30 之间。
• 如果是 70B 模型的 Q4 版本约 40GB，很多 24GB 显卡单卡根本装不下，即便用 48GB 专业卡，按 2TB/s 带宽算，理论上限也只有 50 token/s 左右。

所以显存大小决定“能不能装下”，带宽决定“每秒吐多快”。很多人只看显存大小选卡，买到手才发现速度感人，原因就在这。

4. 一张选型表：从 2B 到 70B 怎么配

理论讲完了，直接给实战结论。这部分我用一张速查表把常见模型规模和不同精度下的显存需求列清楚，再根据显存量级给出选卡建议。

4.1 模型规模、精度与显存需求速查

下面这张表以“单卡推理、batch=1、中等上下文（4K 到 8K）”为前提，所列显存包含权重、KV Cache 和运行时缓冲的合理预估：

需要强调的是，这张表是“能跑起来”的下限参考。实际项目中如果聊天上下文经常拉到 16K 以上，建议直接在对应档位再多留 2GB 到 4GB，否则 KV Cache 会教你做人。

4.2 按显存量级选卡的定位

我用显存大小把市面主流显卡粗略分成四个档位：

• 8GB 档：适合跑 3B、7B 模型的量化版本，日常本地体验足够，但别想着跑 13B，也别开太长上下文。
• 12GB 档：目前性价比很高的甜点位。7B 模型开 INT4 或 INT8 都能比较舒服地跑，13B 模型开 INT4 属于极限操作，需要严格控制上下文长度。
• 16GB 档：真正能干活的门槛。13B 模型 INT4 很稳，8B 模型甚至可以直接跑 FP16，日常使用几乎不用为显存发愁。
• 24GB 档：本地部署的“主力军”。13B 模型 FP16 无压力，32B 模型 INT4 也能启动，是多数私人部署场景下最舒服的选择。

再往上就是 48GB、80GB 这类专业卡的环境，主要服务 70B 甚至更大的模型。那种场景选卡逻辑更看重显存带宽和多卡互联效率，不在这里展开。

4.3 我实际跑过的两组配置参考

我自己在 12GB 显存的机器上长期跑一个 7B 模型，用的 INT4 量化文件。权重约 4GB，上下文 8K 时 KV Cache 约 1GB，加上运行时缓冲，总占用大约 6GB 到 7GB，跑动很轻松，生成速度大概在每秒 30 到 50 token 之间。

另一个朋友用 24GB 显存跑 13B 模型，开 FP16 权重后约 26GB，理论上单卡压力很大。他改用 INT4 量化，权重降到 8GB，8K 上下文下 KV Cache 约 2GB，实际占用在 11GB 左右，非常稳，速度也明显比 7B 模型更流畅。

这两个例子说明同一件事：同一张卡，选对精度和上下文长度，体验天差地别。如果你只是想要一个本地可用的对话助理，12GB 到 16GB 显存完全够用；如果你的目标是本地跑 32B 以上的大模型，那就要接受量化和速度打折的现实。

5. 显存不足时的自救路线

哪怕算清楚了，实际运行过程中还是可能爆显存。这一节讲我遇到 OOM 时的排查顺序和具体操作，能救一次算一次。

5.1 先定位：你真的知道 OOM 发生在哪一步吗

爆显存之后的第一个动作不是改代码，而是看显存观察命令，确认各进程占用。如果模型刚加载就报 OOM，那基本是权重太大了。如果加载成功、跑了一段对话后才 OOM，重点查 KV Cache 和上下文长度。如果是在框架初始化阶段报错，多半是运行时缓冲预留导致。

很多人在 12GB 显卡上跑 7B 模型，加载时报错，第一反应是“这卡不行”，其实换成 INT4 量化档就能跑。反过来，有人加载成功，写长文写到一半 OOM，还以为是显卡性能不够，实际是上下文设成 32K，KV Cache 把显存吃完了。

5.2 常用且有效的四招

真到了显存不够的局面，按优先级依次尝试：

1. 压缩上下文长度。把上下文从 32K 降到 8K，KV Cache 直接缩小四倍，效果立竿见影。
2. 降低量化档位。FP16 换 INT8，INT8 换 INT4，权重显存减半甚至再减半。
3. 调整加载方式。让部分层数放到内存里，而不是全部放到显存，适当牺牲速度换取启动可行性。
4. 尝试 KV Cache 压缩或按需分配缓存技术。这类技术能把长期上下文的缓存开销压得很低，适合长文档场景。

这四招都不用换显卡，成本最低，见效最快。真正全试过一遍还不行，再去考虑升级硬件。

5.3 一个完整排障过程记录

之前帮某开发者排查过一次典型问题：他的显卡 12GB，想跑 7B 模型，上下文默认设置成了 32,768，结果一跑长文档就 OOM。

第一次报错是在加载阶段。把模型换成 INT4 量化后顺利启动，权重占用约 4GB，看起来问题解决了。结果文档读到约三千 token，再次 OOM。这时候我对照 KV Cache 一算：该模型每 token KV 约 128KB，32K 上下文意味着峰值 KV Cache 超过 4GB，加上权重和运行时缓冲，总占用直逼 11GB。问题基本锁定在 KV Cache。

把上下文设置改为 8192 后，KV Cache 降到约 1GB，总占用稳定在 6GB 左右，之后连续跑了很长时间都没有再爆过。这个案例很有代表性：不是显卡不行，是上下文长度设置脱离了显存预算。

6. 关于选模型，我自己的经验之谈

整篇内容到这里，核心计算方法已经写完了。最后分享几条我在实际使用中沉淀下来的体会。

显存计算和模型选择，本质就是一道算术题：权重是固定支出，KV Cache 是随上下文浮动的支出，运行时缓冲是备用金。先把这三笔账算清，再决定用哪个模型、哪个精度、开多长上下文。

我个人的习惯是，下载模型之前只看文件名里的量化后缀先做粗筛。比如看到 Q4_K_M，心里立刻预估文件大小，再和显卡显存比对，不合适就直接换一个档位或换一个规模更小的模型。这个方法比任何压测工具都快，因为文件大小和实际显存占用基本成正比。

还有一个思路可以分享：与其纠结“能不能装下”，不如先想清楚“我实际要用的上下文有多长”。很多人 99% 的需求都在 4K 以内，却把上下文设成 32K，白白浪费大量显存。把上下文砍到够用，有时比换显卡更划算。

如果你正在犹豫买哪张卡，可以把预算卡在一张 16GB 或 24GB 显存的主流卡上，然后按这套公式去想：目标模型在什么精度下要多少显存、什么速度你能接受。先把这两个问题回答清楚，再掏钱也不迟。