很多人想在本机跑个 0.5B 这种小模型试试水，结果发现显存装不下，或者装下了却卡在加载阶段。问题通常不在参数太小，而在权重之外还有一堆开销没算进去。这篇给一套能自己动手的估算顺序：先拆显存构成，再按量化档位对一遍，最后用实际加载结果反推。不承诺某个数字，环境和框架不同结果会差不少。
想在本机跑个 0.5B 这种小模型试试水，最容易踩的坑不是模型太大，而是你以为它很小。参数量小只说明权重那一块不大，真正把显存吃满的往往是权重之外的东西。所以别急着背一个数字，先按顺序估一遍，再实跑回收。
这篇给一套自己能动手的估算流程：先拆显存由哪几块构成，再按量化档位对一遍，最后用实际加载结果反推修正。环境、框架、上下文设置不同，结果会差不少，所以这里只给判断标准和动作，不给绝对数字。
先把显存拆成四块，别只算权重
显存占用是叠加关系，不是四选一。权重只是其中一块，剩下三块在小模型上占比反而更显眼。你估的时候要把四块一起加，再留一点余量，不然就会出现「明明装得下却加载失败」的情况。
- 权重
- 模型参数本身占的空间，和参数量、每参数字节数直接相关
- KV 缓存
- 推理时保存上下文键值用的空间，随上下文长度和并发数增长
- 框架运行时开销
- 推理框架自身的常驻占用，加载完就一直在，不随你说话变少
- 显存碎片
- 反复分配释放后留下的零散空洞，峰值占用会比理论值高一截
- 四块是相加的，估的时候一块都不能漏，漏掉任意一块都可能得出偏乐观的结论
- 0.5B 这种规模下，固定开销占比高，权重省下来的空间对总量影响有限
- KV 缓存随上下文长度线性涨，聊两句和喂长文档是两个量级，要分开估
- 判断够不够看峰值占用，不是看空闲时的数字，峰值才决定会不会失败
按量化档位对一遍，从 FP16 往下捋
权重的粗略算法是参数量乘以每参数字节数。不同精度档位每参数占的字节不同，从高精度往下捋一遍，就能看出省下来的绝对值有多大。但省显存不是唯一指标，质量损失和框架兼容性要单独看。
| 档位方向 | 权重占用趋势 | 主要代价 | 什么情况选它 |
|---|---|---|---|
| 高精度 | 最大 | 显存压力最明显 | 显存宽裕、对输出质量敏感时 |
| 中等精度 | 居中 | 有轻微质量损失 | 多数本地试跑的默认档 |
| 低精度 | 最小 | 质量与兼容性风险上升 | 显存紧张、只做轻量任务时 |
小模型量化后的收益有个特点：省下来的绝对值本来就不大，容易被运行时开销吃掉，所以别指望降档就能从装不下变成轻松装下。具体每个档位对应什么区间，到 /tools/speed-test 按当时的参数和你的硬件核一遍，比记死数字靠谱得多。
- 先确认框架支持哪些档位，不支持的格式装了也加载不了
- 降档前先测一轮输出质量，别只看能不能跑起来
- 低精度在某些硬件上会走不同的计算路径，速度未必更快
- 同一档位在不同框架下的实测占用可能不同，以你自己的加载结果为准
估算完必须实跑一次做回收
估算是用来做初筛的，最终判断得靠实跑。跑的时候别一上来就拉满配置，先跑通最小可用的组合，再逐步加压看占用曲线的拐点在哪。
- 跑最小组合短上下文、单并发先跑通，记下稳定后的显存占用，这是你的基线
- 逐步加长上下文一点点往上加，观察占用增长是否线性，找到开始吃力的拐点
- 再加并发在固定上下文下提高并发，看峰值涨幅，判断余量够不够日常用
- 和估算对账实测明显高于估算时，先查上下文和批处理设置，别急着换模型
显存被占满时要有排查顺序：先看并发设置是不是开太高，再看上下文长度是不是拉太长，最后才怀疑碎片和框架本身。顺序反了会白折腾很久。另外不同框架的开销差别挺明显，换之前先看两者的显存与并发对照，路径在 /tools/speed-test。
什么情况下这套估算不适用
上面这套逻辑针对的是单机推理、短到中等上下文、单并发或低并发的场景。一旦需求偏出这个范围，估算的假设就不成立了，硬套会得出误导性结论。
| 你的场景 | 估算是否适用 | 该怎么调整 |
|---|---|---|
| 单机推理、短上下文 | 适用 | 按四块加总，再留余量 |
| 做微调训练 | 不适用 | 要另算优化器状态和激活值，和推理两回事 |
| 多卡或 CPU 卸载 | 不适用 | 显存被拆到多设备，单卡逻辑不成立 |
| 机器上还有别的服务 | 需谨慎 | 可用显存和标称显存是两码事，按剩余量算 |
- 微调不是把推理放大一点， optimizer 状态和激活值会带来额外占用，得单独估
- 多卡张量并行、CPU offload 会改变显存分布，单卡那套公式直接失效
- 同机还跑着其他进程时，先看清当前剩余显存再谈够不够
- 消费级卡跑长上下文高并发，瓶颈可能先出现在别的地方，不一定是显存
常见问题
0.5B 模型是不是随便一台电脑都能跑？
不一定。权重确实小，但推理框架本身有固定开销，加上 KV 缓存和系统占用，低显存设备照样可能装不下或跑得很慢。能不能跑要看你用什么框架、开多长上下文、有没有并发，建议先实跑一次看峰值占用。
参数量乘字节数就是显存需求吗？
不是，那只是权重那部分的粗算。实际还要加 KV 缓存、框架运行时开销和显存碎片，三者在小模型上占比可能相当高。很多人按权重算完以为够，实跑才发现不够，差的就是这几块。
估算出来够用，实跑却爆显存，先查什么？
按这个顺序查：先把上下文长度和并发数降到最低重跑一遍，确认是不是缓存撑爆；再看有没有别的进程占着显存；最后看碎片和批处理设置。框架不同开销差别明显，换框架前先去站内部署测算页对一遍口径。
