企业官网建设流程全解析

1. 显存不是硬盘，别拿存储容量去套推理需求

很多人第一次接触本地模型部署时，最容易犯的一个错误，就是把显存和硬盘容量混为一谈。看到自己机器上挂着 512GB 的固态，就觉得跑个 7B、13B 的模型绰绰有余，结果模型权重刚加载到一半，程序就抛出内存不足的报错。这个误解非常普遍，因为大家在日常使用电脑时，习惯了“存储空间越大，能装的东西越多”这个逻辑。但显存的工作方式完全不同，它更像是你办公桌的桌面面积，而不是文件柜的容量。桌面就这么大，你要同时摊开多少本书、多少张图纸，决定了你能不能顺利干活。模型推理时，权重、激活值、KV Cache 全都要同时摆在桌面上，桌面不够大，活就干不下去。

我见过不少朋友在选显卡时只盯着算力参数看，比如浮点运算次数、张量核心数量，却忽略了显存带宽和显存容量这两个更直接影响推理体验的指标。算力决定的是“算得多快”，显存决定的是“能不能算”。对于本地推理来说，能不能跑起来是 0 和 1 的问题，跑得快不快是 1 和 10 的问题。先解决 0 到 1，再谈优化。所以这篇文章我想把显存计算的逻辑从头到尾捋一遍，让你拿到一张显卡时，能快速判断它能承载多大的模型，以及在显存吃紧时有哪些腾挪空间。

在展开具体计算之前，先明确一个核心结论：模型推理所需的显存，主要由三块构成——模型权重、KV Cache、以及推理框架的额外开销。这三块里，权重是最大头，KV Cache 随上下文长度和并发数增长，框架开销则相对固定但也不能忽略。下面我会逐块拆解，给出可复现的计算公式和实测验证方法。

1.1 为什么“参数量”不等于“显存占用量”

一个 7B 参数的模型，字面意思是 70 亿个参数。如果每个参数用 32 位浮点数存储，那就是 70 亿乘以 4 字节，约等于 28GB。但实际部署时你会发现，7B 模型在 FP16 精度下大约占 14GB 显存，在 INT8 量化下约 7GB，在 INT4 量化下约 3.5GB。这里的差异就来自精度。参数量是固定的，但每个参数占多少字节是可以变的。这就像同样是一千个汉字，你用毛笔写和用钢笔写，占的纸张面积完全不同。

所以当你看到“7B 模型需要多少显存”这个问题时，第一个要追问的就是：用什么精度跑？FP32 全精度、FP16 半精度、INT8 量化、INT4 量化，这四种常见精度下，每个参数分别占 4 字节、2 字节、1 字节、0.5 字节。计算公式非常简单：显存占用（GB）≈ 参数量（B）× 每参数字节数。比如 13B 模型在 FP16 下就是 13 × 2 = 26GB，在 INT4 下就是 13 × 0.5 = 6.5GB。这个估算和实际加载后的显存占用通常相差不超过 10%，因为还有少量额外开销。

但这里有个坑：量化并不是免费的午餐。INT4 量化虽然把显存压到了四分之一，但模型输出质量会有可感知的下降，尤其是在需要精细推理的任务上。我实测过同一个 13B 模型在 FP16 和 INT4 下的表现，简单问答差异不大，但涉及多步逻辑推理时，INT4 版本出错的概率明显更高。所以选精度时不能只看显存，还要看任务对质量的容忍度。

1.2 一张速查表：常见参数量与精度的显存对照

为了让你不用每次都掏计算器，我整理了一张常用对照表。这张表里的数值是纯权重占用，不含 KV Cache 和框架开销，实际部署时要在这些数字上再加 20% 到 40% 的余量。

从这张表可以直观看出，为什么消费级显卡在 FP16 下跑 70B 模型几乎不可能——140GB 的权重占用远超单卡容量。但 INT4 量化后 35GB 的占用，让双卡 24GB 的方案有了理论上的可行性。这也是为什么量化技术对本地部署如此关键：它把很多“不可能”变成了“勉强可以”。

不过我要提醒一句，这张表是理论下限。实际部署时，推理框架本身要占显存，CUDA 上下文要占显存，如果你用的是带图形界面的系统，显示输出也要占显存。这些杂项加起来，在 24GB 卡上通常要吃掉 1GB 到 2GB。所以 24GB 的卡，实际可用显存往往只有 22GB 出头。做规划时一定要把这个损耗算进去，否则就会出现“理论能跑，实际报错”的尴尬。

2. KV Cache：那个容易被忽略的显存大户

权重占用是静态的，模型加载完就固定了。但 KV Cache 是动态的，它随着你输入的上下文长度和并发请求数不断增长。很多人算显存时只算了权重，结果一跑长文本就爆显存，问题就出在这里。KV Cache 的本质是：在自注意力机制中，为了避免重复计算，模型会把之前所有 token 的 Key 和 Value 向量缓存下来。你输入的文本越长，缓存就越大；同时处理的请求越多，缓存也要翻倍。

KV Cache 的显存占用公式可以简化为：2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 批大小 × 精度字节数。这个公式看起来复杂，但可以进一步简化。对于大多数主流模型，KV Cache 每 token 的占用大约在几十 KB 到几百 KB 之间。以 7B 模型为例，在 FP16 精度下，每 token 的 KV Cache 大约占 0.5MB。如果你输入 4096 个 token，那就是 2GB。如果同时处理 4 个请求，就是 8GB。这个数字已经相当可观了。

我实测过一个场景：13B 模型在 FP16 下权重占 26GB，单请求 2048 token 时 KV Cache 约 2GB，总共 28GB，在 32GB 卡上跑得挺稳。但当我把上下文拉到 8192 token 时，KV Cache 涨到 8GB，总占用 34GB，直接爆了。这就是为什么长文本场景对显存的要求远高于短文本。如果你主要做长文档摘要、代码仓库分析这类任务，KV Cache 的预算必须留足。

2.1 上下文长度如何成倍放大显存压力

上下文长度对显存的影响是线性的，但叠加并发后就是乘法效应。假设单请求每 token 的 KV Cache 是 0.5MB，那么 2048 token 是 1GB，4096 token 是 2GB，8192 token 是 4GB，16384 token 是 8GB。看起来还能接受，但如果你要同时服务 8 个用户，每个用户都发 8192 token 的请求，那就是 64GB 的 KV Cache，再加上权重，单卡根本扛不住。

这也是为什么在生产环境中，长上下文和高并发往往不能同时满足。你要么限制上下文长度，要么限制并发数，要么上多卡做张量并行。我个人的经验是，在单张 24GB 卡上，7B 模型 INT4 量化后权重占 3.5GB，剩余约 18GB 可用。如果留 2GB 给框架开销，16GB 给 KV Cache，按每 token 0.25MB（INT4 下 KV Cache 也可以量化）算，能支持 64K token 的总缓存量。分给 4 个并发请求，每个请求 16K token，这个配置对大多数对话场景已经够用了。

但如果你用的是 FP16 精度，KV Cache 每 token 0.5MB，同样的 16GB 只能支持 32K token 总量，4 个并发每个只有 8K token。这就是精度选择对并发能力的直接影响。所以我在做部署规划时，会先确定目标并发数和平均上下文长度，反推需要的 KV Cache 预算，再决定权重用什么精度。

2.2 量化 KV Cache：一个被低估的省显存手段

很多人知道权重量化，但不知道 KV Cache 也可以量化。主流推理框架如 vLLM、TensorRT-LLM 都支持 FP8 甚至 INT8 的 KV Cache。把 KV Cache 从 FP16 降到 FP8，显存直接减半，而输出质量的下降通常比权重量化更小。我实测过 FP8 KV Cache 和 FP16 KV Cache 的对比，在长文本问答任务上，两者的回答质量差异几乎不可察觉，但显存占用差了一倍。

这个手段在长上下文场景下特别有用。比如你有一张 24GB 卡，跑 7B FP16 模型权重占 14GB，剩 10GB。如果 KV Cache 用 FP16，只能支持 20K token 总量；换成 FP8，就能支持 40K token 总量。对于需要处理长文档的场景，这个提升非常关键。当然，不是所有框架都支持 KV Cache 量化，部署前要确认你用的推理后端有没有这个选项。

还有一个技巧是限制 KV Cache 的最大长度。有些框架允许你设置一个上限，超过这个长度的对话会被截断或滑动窗口处理。这虽然会损失一些上下文信息，但能保证显存不爆。对于对话类应用，用户很少真的需要 32K 的上下文，设置 8K 或 16K 的上限通常就够用了。

3. 从显存容量反推：你的卡到底能跑什么

现在我们把权重和 KV Cache 放在一起，从显存容量出发反推能跑的模型。假设你有一张 24GB 显存的卡，实际可用按 22GB 算。先扣掉 2GB 框架和系统开销，剩 20GB 给权重和 KV Cache。如果你做短文本对话，KV Cache 预算留 4GB，那么权重可用 16GB。在 FP16 下，16GB 能跑 7B 模型（14GB）还有余量；在 INT8 下能跑 13B 模型（13GB）；在 INT4 下能跑 34B 模型（17GB）但会有点紧。

如果你做长文本处理，KV Cache 预算要留 10GB，权重只剩 10GB。FP16 下只能跑 3B 模型，INT8 下能跑 7B，INT4 下能跑 13B。可以看到，任务类型对模型选择的影响非常大。同样的卡，短文本场景能跑 34B，长文本场景只能跑 13B，差了将近三倍。

我整理了一个更实用的对照表，按显存容量和任务类型给出推荐配置：

这张表里的推荐是保守估计，实际能跑多大还取决于具体模型架构、推理框架效率、以及你对生成速度的要求。比如有些模型用了分组查询注意力，KV Cache 比标准多头注意力小很多，同样的显存能支持更长的上下文。所以在选模型时，除了看参数量，也要看它的注意力机制设计。

3.1 多卡并行：显存不够时的横向扩展思路

当单卡显存不够时，多卡并行是最直接的扩展方式。但多卡并行不是简单地把显存加起来，因为卡间通信有开销，而且不同的并行策略对显存的有效利用率不同。常见的并行方式有张量并行和流水线并行。张量并行是把每一层的计算切分到多张卡上，每张卡存一部分权重，通信频繁但显存利用率高。流水线并行是把不同层分配到不同卡上，通信较少但会有流水线气泡，显存利用率略低。

以两张 24GB 卡跑 70B INT4 模型为例，权重总共 35GB，每张卡分 17.5GB，加上 KV Cache 和框架开销，每张卡大约占 20GB，刚好能塞进 24GB。但这是理想情况，实际部署时卡间通信的缓冲区也要占显存，而且张量并行对卡间带宽要求很高。如果两张卡之间的互联带宽不够，推理速度会大打折扣，甚至不如单卡跑小模型。

我的经验是，双卡方案适合显存需求刚好超出单卡 50% 以内的场景。如果超出太多，比如单卡 24GB 想跑需要 70GB 的配置，那四卡方案的成本和复杂度会急剧上升，不如直接考虑量化更激进的版本或者换更小的模型。多卡并行的边际收益是递减的，每增加一张卡，通信开销和部署复杂度都在涨。

3.2 实测验证：用一行命令看真实显存占用

理论算得再多，不如实际跑一次。我习惯在部署新模型时，先用一个最小化的脚本加载模型，然后打印显存占用。如果你用 PyTorch，可以在加载模型后调用显存查询接口，看看实际占了多少。这个数字和理论估算的差异，就是你后续做容量规划的依据。

具体操作上，我会分三步走。第一步，加载模型后立即查显存，得到纯权重占用。第二步，跑一个短文本推理，再查显存，差值就是短文本的 KV Cache 和激活值开销。第三步，跑一个长文本推理，再查显存，得到长文本场景的总占用。这三步下来，你对这个模型在你卡上的表现就有了精确的画像，比任何理论公式都可靠。

实测中我发现一个规律：实际显存占用通常比理论估算高 10% 到 20%。高出来的部分主要来自推理框架的预分配策略、CUDA 内核的临时缓冲区、以及内存碎片。所以做规划时，理论值只能作为下限参考，实际可用容量要打八折。这个经验帮我避免了好几次“理论可行但实际爆显存”的翻车。

4. 选模型时的显存之外：那些同样致命的因素

显存算清楚了，只解决了“能不能跑”的问题。但“跑得好不好”还取决于另外几个因素，这些因素在选模型时同样关键，却经常被忽略。第一个是显存带宽。同样容量的显存，带宽高的卡生成速度快很多。因为模型推理是显存密集型任务，每生成一个 token 都要把整个权重读一遍，带宽决定了读得快不快。这就是为什么有些老卡虽然显存够大，但生成速度慢得让人抓狂。

第二个是模型架构对显存的友好程度。分组查询注意力和多头潜在注意力这类设计，能大幅压缩 KV Cache。同样 7B 的模型，用分组查询注意力的版本可能比标准多头注意力版本省一半的 KV Cache。所以在显存吃紧时，优先选那些用了高效注意力机制的模型，比单纯降精度更划算。

第三个是推理框架的显存管理能力。不同的框架在显存复用、分页管理、连续批处理上的实现差异很大。同样的模型和硬件，换个框架可能显存占用差 20% 到 30%。我实测过几个主流框架，在长上下文场景下的显存效率确实有明显差距。所以选型时不能只看模型，框架的显存优化能力也要纳入考量。

4.1 显存带宽如何决定生成速度上限

显存带宽的单位是 GB/s，它决定了每秒能从显存里读出多少数据。模型推理时，每生成一个 token，都要把参与计算的权重读一遍。所以生成速度的理论上限约等于显存带宽除以模型权重的大小。举个例子，一张带宽 1000GB/s 的卡，跑 14GB 的 7B FP16 模型，理论上每秒能读 1000/14 约 71 次权重，也就是每秒最多生成 71 个 token。实际因为计算开销和调度损耗，能达到理论值的 60% 到 80% 就不错了。

这个公式解释了一个常见现象：为什么量化后生成速度会变快。INT4 量化把权重压到 3.5GB，同样带宽下每秒能读 285 次，生成速度理论上翻了好几倍。实际测试中，INT4 版本的生成速度通常是 FP16 版本的 2 到 3 倍。所以量化不仅省显存，还提速，这是很多人没意识到的双重收益。

但带宽不是唯一因素。如果模型的算力需求超过了显卡的计算能力，那瓶颈就从带宽转移到了算力。这种情况在批处理规模较大时容易出现，因为批处理能提高算力利用率，但也会增加计算量。所以选卡时要平衡带宽和算力，不能只看一个指标。

4.2 模型架构里的显存优化设计

现在的模型架构越来越注重显存效率，最典型的就是分组查询注意力和多头潜在注意力。标准多头注意力里，每个注意力头都有独立的 Key 和 Value 投影，KV Cache 很大。分组查询注意力把多个查询头共享一组 Key 和 Value，KV Cache 直接按共享比例缩小。比如 8 个查询头共享 1 组 KV，KV Cache 就降到八分之一。这个设计对长上下文场景的显存节省非常显著。

多头潜在注意力则更进一步，它把 Key 和 Value 投影到低维空间再缓存，进一步压缩 KV Cache。有些模型用这种设计后，KV Cache 只有标准注意力的几分之一。所以在显存有限时，选一个架构高效的模型，比选一个参数量小但架构老旧的模型更明智。参数量小不代表显存占用低，架构设计才是关键。

我在选模型时会优先看它的注意力机制类型。如果是分组查询注意力或多头潜在注意力，那长上下文场景的显存压力会小很多。如果是标准多头注意力，那就要对上下文长度做更严格的限制。这个判断在部署前就能做，不需要实际跑起来才知道。

5. 显存吃紧时的腾挪空间与实操建议

即使算清楚了显存需求，实际部署时还是会遇到各种意外。这时候就需要一些腾挪手段。最直接的是降低精度，从 FP16 降到 INT8 再到 INT4，每一步都能省一半显存。但精度降太多会影响输出质量，所以要找到质量和显存的平衡点。我的做法是先在 INT8 下跑，如果显存够就保持，不够再降 INT4，同时用一批测试用例对比输出质量，确认下降在可接受范围内。

第二个手段是限制上下文长度和并发数。这两个参数直接决定 KV Cache 的大小。在显存吃紧时，把上下文上限从 32K 降到 8K，KV Cache 直接降到四分之一。并发数从 8 降到 2，再降一半。虽然牺牲了一些能力，但保证了稳定性。对于大多数应用场景，8K 上下文和 2 并发已经能满足基本需求。

第三个手段是启用 CPU 卸载。有些推理框架支持把部分层放到内存里，需要时再加载到显存。这能让你跑起原本显存不够的模型，但代价是速度大幅下降，因为内存带宽远低于显存带宽。我只在极少数场景下用这个方案，比如一次性批处理任务，对速度不敏感，只要求能跑完。

5.1 精度、速度、质量的三方权衡

显存优化的本质是在精度、速度、质量之间做取舍。降精度省显存、提速度，但降质量。限上下文省显存，但损失长文本能力。降并发省显存，但降低吞吐量。这三个维度没有完美的解，只有适合你场景的平衡点。

我的经验是，先明确场景的硬性要求。如果是实时对话，速度不能太慢，那精度不能降太狠，因为 INT4 有时会明显增加生成时间（虽然带宽降了，但反量化有计算开销）。如果是离线批处理，速度不重要，那可以大胆用 INT4 和 CPU 卸载。如果是长文档分析，上下文不能太短，那就要在精度上妥协，用 INT8 或 INT4 换更长的上下文。

这个权衡没有标准答案，但有一个原则：先保证能跑，再优化跑得好。很多人一上来就想用最高精度跑最大模型，结果反复爆显存，浪费时间。不如先用低精度小模型跑通流程，再逐步往上调，找到显存的上限。

5.2 部署前的显存预算清单

最后分享一个我在部署前必做的显存预算清单。这个清单帮我避免了很多次翻车，也让我对每张卡的承载能力有了清晰认知。

按这个清单逐项填数字，加总后和实际可用显存对比。如果超出，就逐项压缩：先压 KV Cache（限上下文和并发），再压权重（降精度），最后才考虑 CPU 卸载。这个顺序保证了性能损失最小化。

我踩过最大的一个坑，是忽略了框架的预分配行为。有些框架在启动时就会按最大上下文预分配 KV Cache，哪怕你实际只用了一小部分。这种情况下，你设置的上下文上限直接决定了启动时的显存占用。所以部署前一定要看框架的文档，确认它的显存分配策略是预分配还是按需分配。按需分配更省显存，但可能有碎片问题；预分配更稳定，但浪费显存。了解这些细节，才能做出准确的容量规划。

显存计算这件事，理论公式只是起点，真正的功夫在实测和调优。每张卡、每个模型、每个框架的组合都有自己的脾气，跑一遍、记下来、形成自己的经验表，比任何通用公式都管用。我到现在还保持着每部署一个新组合就记录显存占用的习惯，这些记录在后续选型时就是最可靠的参考。