本地大模型需要多少显存？拆开估算权重与 KV Cache

模型权重文件看起来小于显卡标称显存，本地服务仍可能启动失败。运行时还要保存已处理 token 的 Key 与 Value；并发请求各有自己的缓存；推理框架还需要临时缓冲和其他显存。本页的计算器先回答一个范围更窄、却很实用的问题：原始权重加常规 KV Cache 是否已经超过这张卡实际可用的物理显存？

只有在已知两项超过物理显存时，才能按这里的单卡假设排除完整驻留。若只是越过你自定的预留计划线，说明不满足自己希望保留的余量；若低于两条线，也不能宣称“装得下”。下方结果只是理论载荷，必须在目标硬件与服务框架上实测峰值。

先核对模型配置，不要只看“14B”名称

模型名里的“14B”是约数。预算表至少应记录模型版本、总参数量、Transformer 层数、每层 KV 头数和每个头的维度。采用分组查询注意力时，缓存公式使用 KV 头数，不能误填 Query 头数。

Qwen2.5-14B-Instruct 官方模型卡列出 147 亿参数、48 层、40 个注意力头和 8 个 KV 头。官方配置中的 hidden size 为 5120，所以每头维度是 5120 ÷ 40 = 128。计算器预填的是这一组可核对的数值。换模型版本、适配器或部署格式时，都要重新核对，而不是沿用示例。

权重和 KV Cache 分开算

这里的参数量以十亿为单位，使用两个原始载荷公式：

项目	计算方法	覆盖范围
权重字节	参数量 × 1,000,000,000 × 权重位数 ÷ 8	假设所填参数都采用同一种位数的理论值
KV Cache 字节	2 × 层数 × KV 头数 × 每头维度 × KV 每元素字节 × 每请求缓存 token × 同时驻留请求数	常规全注意力中 K、V 两组张量的原始元素

缓存 token 应填写一次请求高峰时仍占用缓存的输入与已生成 token，而不只是 Prompt 长度。并发是同时驻留的请求数。如果每个请求长短不同，应分别累加 token，而不要用平均长度直接代表峰值。表单以“每个请求都达到同一峰值”为假设，方便先做明确的负载边界。

结果同时展示 GiB 和 GB：1 GiB = 1,073,741,824 字节，1 GB = 1,000,000,000 字节。显存输入框使用 GiB；若设备资料只给十进制 GB，先换算，并优先使用设备实际报告的可用物理值。计算器将“物理显存减去已知项”和“扣除自定预留的计划线”分开显示。预填的 4 GiB 只是演示假设，不是官方或通用开销系数。

案例一：Qwen 四请求，BF16 对照 4-bit

使用上述官方配置，BF16 权重的原始载荷约 27.38 GiB。每个请求缓存 8192 token，采用 16-bit KV，单请求占 1.50 GiB；四个同时驻留请求的 KV 共 6.00 GiB，已知两项合计 33.38 GiB。假设设备报告可用物理显存为 24 GiB，仅这两项就已超过。按这些单卡假设，无法让两项全部驻留在这张 GPU 上。

把权重位数切到 4-bit，原始权重变为约 6.85 GiB，加上不变的四请求 KV Cache 共 12.85 GiB。它低于 24 GiB 物理显存，也低于演示用的“预留 4 GiB 后 20 GiB 计划线”。真实量化文件还可能包含比例、零点、分组元数据和未量化层；两条线的正余量都不能证明完整驻留、速度或任务质量。

案例二：16 个并发请求改变结论

保留 4-bit 原始权重和每请求 8192 缓存 token，但同时驻留 16 个请求。单请求 KV 仍是 1.50 GiB；并发 KV 合计 24.00 GiB。再加 6.85 GiB 原始权重，已知两项总计 30.85 GiB，超过输入的 24 GiB 物理显存。降低权重精度，并不能抵消并发缓存的增长。

Qwen2.5-14B-Instruct 情境	原始权重	单请求 KV	并发 KV	已知合计	24 GiB 物理显存减已知项
BF16，4 请求	27.38 GiB	1.50 GiB	6.00 GiB	33.38 GiB	−9.38 GiB
4-bit 原始载荷，4 请求	6.85 GiB	1.50 GiB	6.00 GiB	12.85 GiB	+11.15 GiB
4-bit 原始载荷，16 请求	6.85 GiB	1.50 GiB	24.00 GiB	30.85 GiB	−6.85 GiB

关闭 JavaScript 时也能读这张表；下方计算器的三个预设可复现这些数字，再改成自己的模型尺寸和负载。

用部署实测补上未知开销

固定模型修订版、量化格式、服务版本、目标上下文和并发，再分别记录冷启动、预热请求、GPU 峰值、OOM、首 token 延迟与持续吞吐。PyTorch 提供“峰值已分配显存”计数器，但单一框架计数不等于设备上的全部占用；还要看设备报告的使用量。每次结果附上批量策略与缓存设置，才便于他人复跑。

还要确认权重和当前缓存是否都驻留在这张 GPU 上。若框架悄悄卸载到 CPU，或把张量分散到多张卡，“跑起来了”回答的是另一个问题。剩余预算为正时，最有价值的下一步是实测，并为真实流量波动与软件升级留下经验证的余量。

常见问题

能直接用权重文件大小吗？ 它是某个文件的线索，但序列化、分片、压缩与混合精度会改变磁盘大小。最终应测这个文件在目标运行方式中的设备驻留。

KV 改成 8-bit 就一定省一半显存吗？ 原始 KV 元素从两字节变成一字节时，这一项减半；缓存块、比例数据、内核支持、质量和其他运行开销不会自动减半。

多张 GPU 的容量能直接相加吗？ 本计算器只算单卡，不负责分配层、权重与缓存，也没有通信开销模型。多卡方案必须逐卡规划与测量。

不适用边界

本页适用于配置已知、单卡放置、采用常规逐层 K/V Cache 的稠密 Decoder 模型。不覆盖 MoE 的总参数与激活参数差异、Multi-head Latent Attention、滑动窗口或混合缓存、推测解码、多模态张量、适配器、CPU 卸载、张量／流水线并行及训练。预算算出正余量，绝不是“可以运行”的证明。下面的工作表用于记录未计因素和真正能解除不确定性的峰值试验。