本地部署大模型，从模型卡估算本地显存

文章目录1. 简单口算的局限2. 先说结论3. 四项字段的作用3.1 总参数total params3.2 激活参数activated / active params3.3 上下文长度context3.4 量化格式quantization4. 一套可执行的估算顺序4.1 权重显存规划公式4.2 KV 显存规划公式4.3 运行时余量5. 用脚本做粗算5.1 稠密 7BQ44K 上下文5.2 同模型拉到 32K 上下文5.3 MoE总参 47B激活 13B6. 上机采样对照纸面数字7. 检查清单8. 常见误区8.1 只用总参数 × 28.2 把激活参数直接当成显存需求8.3 按模型宣传的最大上下文估日常需求8.4 粗算通过就下单旗舰卡8.5 不同框架共用同一套“经验 GB 数”9. 术语速查10. 小结11. 相关阅读摘要本地部署前很多人只用“7B ≈ 14GB”这种口算决定买不买卡、能不能跑。纸面公式在稠密 FP16 场景偶尔够用一遇到量化、长上下文和 MoE偏差就会很大。本文把模型卡上的总参数、激活参数、上下文长度、量化格式放进同一套估算流程并给出可运行的粗算脚本。适合已经会看模型卡、准备本机或工作站部署的人。数字只作规划参考最终以目标推理框架在你机器上的实测为准。承接前文大模型里的 MoE本地部署大模型的详细考虑含脚本/代码本地部署大模型前要不要加显卡建议目录mkdir-p~/vram-lab/{notes,scripts,logs}cd~/vram-lab# 本文estimate_vram.py / probe_runtime_mem.sh / vram_checklist.md文件作用scripts/estimate_vram.py用模型卡字段做显存粗算scripts/probe_runtime_mem.sh推理时采样 GPU / 系统内存notes/vram_checklist.md估算与实测对照清单1. 简单口算的局限常见口算是参数量B× 2 ≈ FP16 权重大小GB它只覆盖了一种很窄的情况稠密模型、权重以 FP16/BF16 常驻、上下文不长、忽略框架开销。下面任一条件出现口算就会漂变化影响换成 Q4 / Q5 / INT8每参数字节数下降权重显存明显变小上下文从 2K 拉到 32K / 128KKV 缓存可能从“可忽略”变成主角MoE 总参很大、激活参较小算力直觉和权重占用不再是同一条线batch 1 或并发会话KV 与临时缓冲一起放大不同推理引擎是否卸载专家、是否分页 KV结果差一截图1. 总参数、激活参数、上下文、量化缺一项都容易估错。2. 先说结论目标更该盯的字段磁盘能不能放下总参数 量化后体积 / 文件大小单次算力与延迟直觉激活参数MoE 尤其重要长对话会不会爆显存上下文长度 KV 精度 batch权重常驻显存大概多少常驻参数量 × 每参数字节最终能不能上线粗算 余量 同任务实测再压成四条显存不是只有权重KV 和运行时开销经常被漏掉。量化先改的是每参数字节数上下文先改的是 KV。MoE 的激活参数更适合理解算力权重显存仍要看加载策略默认常按总参保守估。粗算只用于排除明显不可能的组合下单或定案前必须实测。图2. 规划时至少拆成权重 KV 运行时余量。3. 四项字段的作用3.1 总参数total params总参数回答的是这个模型“装了多大一箱零件”。影响下载体积、磁盘、冷启动加载时间多数本机加载器会把专家权重也放进可寻址内存/显存池除非明确卸载看模型卡时优先同时找官方给出的量化后文件大小3.2 激活参数activated / active params激活参数回答的是处理一个 token 时大约有多大规模在参与计算。对理解 MoE 的延迟上限很有用不等于“显卡只需要装下激活参数那么大的权重”详见大模型里的 MoE3.3 上下文长度context上下文主要推高 KV 缓存近似随seq_len × batch增长长上下文模型卡写着“支持 128K”不代表你的 12GB 卡能开满 128K实务上先定业务需要的上下文再反推显存而不是先开到模型宣称上限3.4 量化格式quantization量化改的是“每个参数大概占多少字节”以及一定的精度损失。常见标签粗算用字节/参数备注FP16 / BF162.0基线INT8 / Q81.0视实现而定Q5~0.625不同打包略有出入Q4~0.5本机很常见Q3~0.375更省质量风险更高这些是规划用近似值。GGUF / GPTQ / AWQ 的真实体积以文件大小和框架文档为准。4. 一套可执行的估算顺序图3. 先读卡再拆权重与 KV最后加余量并实测。4.1 权重显存规划公式权重字节 ≈ N resident × bytes_per_param \text{权重字节} \approx N_{\text{resident}} \times \text{bytes\_per\_param}权重字节≈Nresident​×bytes_per_param其中稠密模型N resident N_{\text{resident}}Nresident​通常用总参数MoE默认先用总参数做保守估计只有确认引擎按需加载专家时才改用激活参数4.2 KV 显存规划公式一个常用近似KV 字节 ≈ 2 × L × H k v × d × S × B × b k v \text{KV 字节} \approx 2 \times L \times H_{kv} \times d \times S \times B \times b_{kv}KV字节≈2×L×Hkv​×d×S×B×bkv​符号含义(L)层数(H_{kv})KV head 数(d)head dim(S)上下文长度(B)batch / 并发序列数(b_{kv})每个 KV 元素字节数FP16 常取 2模型卡若没写全 (H_{kv}) 和 (d)先用同系列公开配置或先用“上下文翻倍、KV 近似翻倍”做相对判断。4.3 运行时余量框架临时缓冲、显存碎片、驱动预留纸面上很难估准。实务做法先算 权重 KV再加 15%25% 运行时整体再留 20%40% 安全余量上机实测图4. 激活参数帮你理解算力权重显存要看总参和是否卸载。5. 用脚本做粗算保存为scripts/estimate_vram.py仓库内已提供同名脚本。5.1 稠密 7BQ44K 上下文python3 scripts/estimate_vram.py\--total-b7\--quantq4\--context4096\--layers32\--kv-heads8\--head-dim128你会看到类似拆分weights权重大致占用kv_cache当前上下文下的 KVwith_margin加余量后的规划值5.2 同模型拉到 32K 上下文python3 scripts/estimate_vram.py\--total-b7\--quantq4\--context32768\--layers32\--kv-heads8\--head-dim128对比两次输出里的kv_cache上下文变长时爆显存往往先发生在 KV而不是权重突然变大。5.3 MoE总参 47B激活 13B默认按总参估权重更保守也更接近很多本地加载行为python3 scripts/estimate_vram.py\--total-b47\--activated-b13\--quantq4\--context8192\--layers32\--kv-heads8\--head-dim128若你明确知道引擎只常驻激活专家权重再加上--moe-active-weights不要默认打开它。多数情况下先按总参保守估更不容易买错预期。输出 JSON 便于记日志python3 scripts/estimate_vram.py --total-b7--quantq4--context8192--json\|teelogs/est_7b_q4_8k.json6. 上机采样对照纸面数字粗算通过后用同一验收任务看真实占用。保存为scripts/probe_runtime_mem.sh#!/usr/bin/env bashset-euopipefail# 用法:# ./probe_runtime_mem.sh 15# 在另一个终端启动推理服务/对话本脚本采样 15 秒sec${1:-15}ts$(date%Y%m%d_%H%M%S)outlogs/mem_${ts}.txtmkdir-plogs{echo host mem free-hechoifcommand-vnvidia-smi/dev/null21;thenecho nvidia-smi sample for((i0;isec;i));dodate%F %Tnvidia-smi --query-gpuname,memory.total,memory.used,utilization.gpu--formatcsvsleep1doneelseechonvidia-smi not foundfi}|tee$outechosaved$out用法chmodx scripts/probe_runtime_mem.sh# 终端 A启动 ollama / vLLM / 你的服务并跑固定提示词# 终端 B./probe_runtime_mem.sh20把峰值memory.used写回清单和with_margin对比。若实测系统性高于粗算优先检查上下文是否被框架自动抬高、是否多会话、是否还有草稿模型常驻。图5. 规划值通过后仍以同任务实测为准。7. 检查清单保存为notes/vram_checklist.md# 模型卡显存估算清单 ## 从模型卡抄下 - [ ] 总参数 - [ ] 激活参数如有 - [ ] 目标量化格式 / 权重文件大小 - [ ] 业务需要的上下文而不是宣传上限 - [ ] 层数、KV heads、head dim或同系列配置 ## 粗算 - [ ] 权重显存 - [ ] KV 显存按业务上下文 batch - [ ] 运行时 安全余量 - [ ] MoE 是否按总参保守估计权重 ## 实测 - [ ] 同一提示词 / 同一上下文 - [ ] 记录峰值显存与是否换出/失败 - [ ] 记录 tokens/s 是否可接受决策时可直接用这张表粗算结果建议动作余量后仍明显高于显卡容量降上下文、换更重量化、换更小激活规模或换硬件接近上限余量 15%先实测不要只看纸面“刚好放下”余量充足仍做一次峰值采样再定日常默认上下文MoE 总参很大但激活小分别评估磁盘/加载与延迟不混成一个数字8. 常见误区8.1 只用总参数 × 2忽略量化与 KV 后长上下文场景几乎必然误判。8.2 把激活参数直接当成显存需求对 MoE 尤其危险算得少不等于权重没加载。8.3 按模型宣传的最大上下文估日常需求业务若只需 4K8K就按业务值估宣传上限留给压力测试。8.4 粗算通过就下单旗舰卡先用现有机器实测瓶颈再决定加卡。相关判断见本地部署大模型前要不要加显卡。8.5 不同框架共用同一套“经验 GB 数”vLLM、llama.cpp、Ollama 对分页、卸载、多会话的策略不同迁移时要重测。9. 术语速查术语本文用法模型卡模型页/README 中的参数与限制说明总参数模型全部参数规模激活参数单次前向大致参与计算的参数规模量化降低权重数值精度以减小体积与带宽KV 缓存推理时缓存的 Key/Value随上下文增长余量给碎片、驱动和框架开销预留的安全空间常驻权重实际留在显存/内存中的权重量10. 小结从模型卡估本地显存可靠做法是四项一起看总参数 → 体积与保守权重占用激活参数 → 算力与延迟直觉MoE上下文 / batch → KV量化 → 每参数字节数然后粗算 → 加余量 → 同任务实测。纸面数字负责快速排除不可能实测数字负责最终决策。11. 相关阅读大模型里的 MoE本地部署大模型的详细考虑含脚本/代码本地部署大模型前要不要加显卡本地大模型跑通了为什么还是不好用本地部署大模型显卡/Orin如果后面继续写相关主题可以再展开同一张卡上上下文、batch 和量化怎么联动调才能把可用显存打满又不频繁失败相关链接Hugging Face Model CardsNVIDIA nvidia-smi 用户指南GGUF 格式说明llama.cpp 生态常用如果这篇帮你把模型卡数字翻译成可执行的显存规划欢迎点赞、收藏也欢迎关注后续更新。