先算显存，再挑硬件——顺序反了就会买错
很多团队做本地大模型硬件规划时，第一反应是「买哪张卡」。这个问题问早了。卡只是显存的一个载体，真正决定方案的是三个容量指标：
把这三个数先算出来，再去挑硬件，顺序反了会买错。下面按三步走。
权重的占用是最容易算、也最容易被忽略的一项。公式很简单：
权重显存 ≈ 参数量 × 每参数字节数 × 1.1（量化元数据与对齐开销）「每参数字节数」由精度决定：FP16/BF16 是 2 字节，INT8 是 1 字节，INT4 是 0.5 字节。乘 1.1 是给量化比例因子、分组信息这些元数据留的余量。
| 模型规模 | FP16 / BF16 | INT8 | INT4 |
|---|---|---|---|
| 1.5B – 3B | 约 3.3GB – 6.6GB | 约 1.7GB – 3.3GB | 约 0.9GB – 1.7GB |
| 7B – 8B | 约 15.4GB – 17.6GB | 约 7.7GB – 8.8GB | 约 3.9GB – 4.4GB |
| 13B – 14B | 约 28.6GB – 30.8GB | 约 14.3GB – 15.4GB | 约 7.2GB – 7.7GB |
| 30B – 32B | 约 66GB – 70.4GB | 约 33GB – 35.2GB | 约 16.5GB – 17.6GB |
| 70B – 72B | 约 154GB – 158.4GB | 约 77GB – 79.2GB | 约 38.5GB – 39.6GB |
这张表能解释一个常见现象：为什么「7B 模型很轻量」和「7B 模型跑不动」同时成立。前者说的是权重，后者说的是权重加上 32K 上下文、多路并发和推理框架本身的开销。
权重是固定成本，KV cache 是随上下文长度线性增长的变动成本。它的量级取决于层数、注意力头数、头维度、批大小和上下文长度，公式是：
KV cache ≈ 2（K 和 V） × 层数 × 注意力头数 × 头维度 × 上下文长度 × 每元素字节数 × 并发数用主流稠密架构做量级估算：把上下文从 4K 拉到 32K，KV cache 会涨到 8 倍；再叠加多路并发，显存占用可能直接翻数倍。这就是为什么「换个大上下文试试」经常是显存事故的起点。
实践上有三个降显存手段可以叠加使用：
实际部署时，权重 + KV cache 之外还有三块常被低估的开销：
稳妥做法是把目标占用控制在物理显存的 85% 以内。把 24GB 卡塞到 23GB 的方案，在压测时往往能跑、在真实并发下会 OOM。
把上面的估算套到实际采购上，可以分成三档。价格与具体型号随市场变化，这里只给容量口径。
| 档位 | 典型场景 | 显存口径 | 内存口径 | 能跑的模型量级 |
|---|---|---|---|---|
| 验证试用 | 内测、Prompt 调试、单人试用 | 16–24GB | 32–64GB | 7B–8B 的 INT4 / INT8，短上下文 |
| 部门落地 | 一个部门日常使用，数十人并发 | 48–80GB（或 2×24GB） | 128GB 起 | 13B–32B 的 INT4/INT8，中等上下文 |
| 生产级 | 跨部门服务，需要高可用与审计 | 80GB × 2 起（多卡） | 256GB 起 | 70B 级 INT4，或 32B 的多实例高并发 |
选型逻辑是倒着推：先确定业务能接受的模型规模与上下文长度 → 用上面的公式算出显存 → 再选卡，而不是先选卡再想能跑什么。
私有化部署的整体路线（数据边界、网络隔离、验收标准）见《AI 私有化部署方案怎么选》。
| 做法 | 怎么做到的 | 代价 |
|---|---|---|
| 量化 | 权重压到 INT8 / INT4，必要时 KV cache 也量化 | 精度损失，长文本与复杂推理任务下降更明显 |
| 多卡切分 | 模型按层切到多张卡，或用张量并行 | 卡间通信开销上升，对互联带宽敏感，延迟增加 |
| CPU offload | 放不下的层放到系统内存，按需换入 | PCIe 带宽远低于显存带宽，速度可能掉一个数量级 |
顺序建议是：先量化，再加卡，最后才考虑 offload。offload 的定位是「让小模型能启动」的兜底手段，不是生产环境的吞吐方案——系统内存到显存的 PCIe 传输通常是 10–30GB/s 量级，与显存内部数百 GB/s 的带宽差着一到两个数量级。
推理服务本身的部署方式（服务化接口、并发控制、鉴权）可参考《AI Agent 与 IM 平台打通：接入架构》。
参数量只决定权重占用。实际需求还要加 KV cache、框架开销和激活值，尤其是长上下文场景，这两项可能和权重同量级。先算权重，再加余量，别拿参数量直接当显存需求。
量化损失是任务相关的。简单问答、分类、摘要类任务上差异往往不明显；但多步推理、代码生成、长链条工具调用上会明显退化。降配前用自己的真实任务集做一轮对比，而不是看公开榜单。
跨卡通信是真实成本。层切分对互联带宽敏感， PCIe 直连的多卡方案在小模型场景往往不如单张大显存卡简单可靠。判断标准是「单次请求的瓶颈在算还是在搬数据」，不是卡的数量。
| # | 验收项 | 判据 |
|---|---|---|
| 1 | 目标模型与精度已确定 | 明确到具体模型与量化等级，不留「先跑起来再说」 |
| 2 | 权重占用已计算 | 参数量 × 精度字节 × 1.1 有书面数字 |
| 3 | KV cache 已按真实上下文长度估算 | 用目标上下文上限算，不是默认值 |
| 4 | 并发数已确认 | 峰值同时在线人数 ÷ 平均处理时长 = 需要的并发实例数 |
| 5 | 显存占用率留有余量 | 峰值占用 ≤ 物理显存的 85% |
| 6 | 内存与磁盘按峰值规划 | 含模型切换、量化转换、临时文件的余量 |
| 7 | 做过真实任务集对比 | 量化前后在自有任务上跑过一轮，差异可接受 |
清单里第 4 条最容易被跳过，但它才是决定「要不要多买一张卡」的关键：并发不是用户数，是并发请求数。10 个人轮流问问题和 10 个人同时问问题，对显存的要求完全不同。
本地大模型的硬件规划不需要复杂，但它有明确的推导链条：业务规模 → 模型规模 → 精度选择 → 权重显存 → 加 KV cache → 加运行时余量 → 选卡。链条上任何一环跳过，都会变成「买回来发现装不下」或者「装得下但一上并发就崩」。
把参数估算了再采购，把真实任务集验证过再上线，这两件事做完，硬件选型的绝大部分风险就消掉了。剩下的才是具体型号和价格层面的选择。