本地部署大模型需要多少内存

很多人下模型前只看到「多大参数」，结果一到加载就 OOM，或者跑起来慢得像幻灯片。问题不在模型多大，而在权重、KV 缓存、框架开销三块加起来有没有超过你能用的内存和显存。这篇不讲虚的，给一套按规模估算的口径和排查顺序，让你在下载之前就把配置框定下来。

很多人下模型前只盯着「多少参数」，结果一加载就 OOM，或者跑起来了慢得像放幻灯片。问题不在模型大不大，而在三笔账加起来有没有超过你能用的内存和显存：权重、KV 缓存、框架与运行时开销。这篇不讲虚的，给你一套按规模估算的口径和排查顺序，让你在点下载之前就把配置框死。

先说清楚一点：显存和内存是两套账，不是一回事。显存不够可以把部分层卸载到内存，照样能跑，只是速度掉一个量级；内存也不够，那就真的起不来。所以估算时别只算一边，两边都要留余量。

先搞清内存到底被谁吃了

权重

参数量乘以每参数字节数，量化档位直接决定这个乘数

KV 缓存

随上下文长度、并发数、层数线性增长，长上下文场景常比权重还大

框架与运行时

CUDA 上下文、加载缓冲、容器本身都要占一截，估的时候得留出余量

卸载

显存不够时把层挪到内存，能跑但速度掉一个量级

第二块 KV 缓存最容易被低估。它是唯一随「你实际怎么用」变化的部分：上下文越长、并发越高，它涨得越快。同一块卡，短对话单路能跑，换成几万 token 的长文档或几路并发，直接就被 KV 缓存吃满。所以看到别人说「某卡能跑某模型」，先问他是多长上下文、几路并发。

• 权重是固定成本，量化档位一降就跟着降，但降过头输出质量和稳定性都会受影响
• KV 缓存是可变成本，跟层数、隐藏维度、上下文长度、并发数都相关，四个里改一个数就变
• 框架开销相对固定，但不同推理框架差异不小，容器环境下还要算上宿主机那一层
• 显存与内存要分开记账，别用显存读数直接反推内存够不够

按规模粗估：一张表定配置

粗估的顺序是：先算权重占位，再叠 KV 缓存，最后加上固定开销，得到一个「最低可用容量」。低于这个值就别试了，贴着这个值跑也会因为内存碎片和运行时波动偶发失败。下面这张对照表给的是判断方向，具体字节数去站内页面核对当时的数字。

• 并发不要用权重直接乘，权重不随并发叠加，KV 缓存才叠加
• 「一张卡能跑几路」要单独按 KV 缓存算，别拍脑袋
• 把上下文长度当成可调参数而不是固定条件，估算会灵活很多
• 估算完留出余量，实际加载经常卡在碎片和运行时上，不是卡在理论值上

想省事就记住一条：权重决定你能不能装下，KV 缓存决定你能不能同时伺候多个请求。前者看模型和量化，后者看你自己的使用方式。

容量不够时的降级顺序

1. 先降上下文长度把 KV 缓存压下来，代价最小。验证方式：同样的并发数下逐档缩短上下文，看显存占用和速度变化
2. 再降量化档位代价是输出质量和稳定性可能变差。验证方式：拿同一批问题跑两档，比较答非所问的比例
3. 然后降到单路并发把资源集中给一个请求。验证方式：压测时逐步加并发，找到开始明显变慢的那个点
4. 最后才加卡或换卡用张量分片把权重摊开，会引入卡间通信开销。验证方式：对比加卡前后的单请求延迟，别只看吞吐

这个顺序的前提是你的任务对质量不极端敏感。如果你的任务强依赖长上下文或多路并发，前两步基本没得省，硬降只会把问题从「跑不动」变成「跑得动但没用」。这种情况下直接按你真实需要的上下文和并发数去配容量，比事后降级省事。

下载前先做三个动作

1. 查清目标模型的结构参数层数、隐藏维度、最大上下文这三项决定 KV 缓存量级。不查这三项，估算基本会歪，尤其是长上下文模型
2. 用站内换算工具代入四个输入参数量、量化档位、上下文长度、并发数，代进去得到一份目标配置。数字以页面当时显示的为准，别背旧值
3. 落地后压真实负载再扩并发别用空闲时的显存读数判断上限。先跑一遍接近真实使用的请求，看稳定占用，再往上加并发

还有一个常见坑：估算值贴着硬件上限去配。理论上够用，实际加载时因为内存碎片、框架缓冲波动、容器本身占用，经常就在启动那一步失败。留出余量不是浪费，是把「跑得起来」变成确定的事。搜配置的时候，与其到处问别人用多大的机器，不如把上面四个输入代进站内工具，得到属于你自己场景的答案。