准备微调一个 0.5B 到 2B 级别的小模型，跑起来才发现显存爆了，或者反过来租了很贵的卡结果只用了不到一半——这两种浪费都很常见。这篇不给你一个拍脑袋的数字，而是给一套按参数量、训练精度、优化器状态和批大小逐项相加的估算方法，再对照常见显卡显存档位判断该租什么卡、要不要上量化和卸载。数字会随时间变，模型规格和实时价格到站内页面核对。
准备微调一个 0.5B 到 2B 级别的小模型，跑起来才发现显存爆了，或者反过来租了很贵的卡结果只用了不到一半——这两种浪费都很常见。这篇不给你一个拍脑袋的数字，而是给一套按参数量、训练精度、优化器状态和批大小逐项相加的估算方法，再对照常见显卡显存档位判断该租什么卡、要不要上量化和卸载。
需要先说清一件事：显存需求不是一个固定值，它跟着你的训练配置走。同一份 1.5B 权重，换个精度、换个优化方式、把序列长度翻一倍，占用可能差出一张卡的档位。所以下面给的是算账顺序和判断标准，不是结论数字；模型规格和实时价格这类会变的信息，到站内页面核对当时的数字。
微调显存到底花在哪几块
把显存拆成四块看，估算就不会一团乱：权重本体、梯度、优化器状态、激活值。前三块基本只跟参数量和训练精度有关，可以在动手前算出来；激活值跟批大小、序列长度、模型结构强相关，是浮动最大的一块，也是最容易让人低估的一块。
- 权重本体
- 模型参数本身占的内存，按参数量乘每个参数的字节数算，精度越低越省。
- 梯度
- 反向传播时给每个可训练参数配一份梯度，全参微调下通常和权重同量级。
- 优化器状态
- Adam 这类优化器会给每个参数额外存几份统计量，是全参微调显存的大头。
- 激活值
- 前向过程中每层输出要留着做反向，随批大小和序列长度线性甚至更快增长。
关键区别在于：全参微调和 LoRA 这类参数高效微调是两个量级。后者只训练一小部分附加参数，梯度与优化器状态的压力被砍掉大头，权重本体仍然要占显存，但激活值并不会因此消失。所以「上了 LoRA 就不会爆显存」是个误解，长序列照样能把显存吃满。
- 1.5B 和 0.8B 的差距主要体现在权重与优化器状态这两块，参数量翻倍，这两块基本同步翻倍
- 激活值的差异更多来自序列长度和批大小，而不是参数量本身
- 参数量小的模型可以靠大一点的批提升吞吐，参数量大的型号往往被迫先把批降到很小
- 判断瓶颈在哪一块，比记住一个显存数字有用得多
从参数量到显存的估算顺序
按下面这个顺序算，不需要精确到个位，能把量级估对就能做硬件决策。每一步算完都留个印象分，最后加总时心里有数哪块占大头。
- 先定训练精度算权重确定用哪种精度加载与训练，用参数量乘对应的每参数字节数，得到权重占用。这是估算的起点，精度选错后面全偏。
- 再乘倍数得静态占用全参微调时把权重乘以一个包含梯度与优化器状态的倍数，得到静态占用；参数高效微调则只对可训练的那部分参数乘倍数，权重本体按原值另算。
- 估算激活值量级用批大小乘序列长度乘隐藏维度再乘层数，估一个粗糙量级。这一步误差最大，但足以判断这块是不是主要矛盾。
- 留出余量并试跑在加总值上留一到两成余量给临时缓冲和框架开销，然后真跑一次短训练，用显存监控工具看峰值落在哪。
- 调旋钮找临界点依次减小批大小、序列长度、梯度累积，看哪一个最先把峰值压下去，据此决定最终配置。
估算完不要直接下结论，去站内 /models/deploy 按当时的模型规格和可用卡型核对一遍，确认字段含义和你算的对得上。规格表里的数字会随模型版本变化，以页面当时显示为准。
卡不够时按顺序动这几个旋钮
显存不够时最容易犯的错是直接换大卡，其实前面几个旋钮基本不花钱。按下面的顺序动，能省下的成本通常比换卡明显。
| 旋钮 | 调整方式 | 代价 |
|---|---|---|
| 批大小 | 降到很小，用梯度累积补回等效批大小 | 训练步数变多，单步通信开销占比上升 |
| 序列长度 | 截断或分块处理长文本 | 依赖长上下文的评测任务效果可能下降 |
| 梯度检查点 | 开启后用重算换显存 | 训练变慢，时间成本上升 |
| 量化加载 | 4-bit 或 8-bit 加载配参数高效微调 | 质量损失需在小验证集上自己比 |
| CPU offload | 把部分状态挪到内存 | 速度下降明显，适合验证而非正式训练 |
顺序上，先降批加梯度累积，再考虑动序列长度——前提是你的任务不依赖长文本。然后开梯度检查点，用时间换显存；接着考虑量化加载与参数高效微调组合，质量损失必须在自己的验证集上实测。最后才是 CPU offload 或换更大显存的卡，顺序反了会多花不少钱。
- 降批之前先确认评测指标对批大小不敏感，否则调完指标没法比
- 序列长度能不动就不动，很多任务的难点正好在长依赖上
- 量化加载后要单独跑一轮评测，跟未量化版本对比，差异大就回退
- offload 适合先把流程跑通，不适合当长期训练方案
对应到显卡与租卡怎么选
选卡先看显存档位能不能放下你的峰值占用，再看算力和互联。消费级卡适合单卡跑小模型的参数高效微调，专业卡和数据中心卡的优势主要在更大的显存容量与多卡扩展能力，不一定是单卡更快。
| 场景 | 侧重看什么 | 不建议的做法 |
|---|---|---|
| 单卡小模型微调 | 显存容量能否覆盖峰值并留一到两成余量 | 只看显存总量不看激活值占用 |
| 多卡扩展 | 卡间互联带宽与通信开销占比 | 小模型直接上多卡，指望线性加速 |
| 长序列训练 | 单卡显存与序列并行支持 | 把批大小压到极限再上多卡 |
| 短期验证 | 按小时计费的租用方式 | 按整月预留再发现配置不对 |
多卡不等于线性加速，小模型上通信开销可能把收益吃掉，建议先单卡跑通、拿到峰值占用数据，再考虑要不要拆。实时租金与机型库存会变，到站内 /compute/gpu-rental 与 /compute/price-index 看当时的数字，别用记忆里的价格做预算。
什么情况下这套估算不适用
这套估算针对的是单模态、中小序列、参数高效微调或小规模全参微调的场景。条件变了，结论也要跟着变，硬套会出问题。
- 全参微调、多模态输入、超长上下文训练，激活值占比会大幅上升，不能照搬小模型结论
- 换训练框架或换混合精度实现方式，实际占用会明显不同，以试跑峰值为准
- 任务对质量极敏感时，量化与卸载带来的损失可能不可接受，这时估算要让位于效果验证
- 多卡并行策略不同，显存分布也不一样，估算结果只能作参考
- 推理阶段的显存需求规律和训练不同，别拿训练结论去配推理服务
一句话判断：如果你的任务属于上面任意一条，先把这套估算当起点跑一次短训练，拿到真实峰值再调配置，比继续在纸上加总靠谱。
下一步把估算结果和可用卡型对齐时，先到站内部署资料库核对当时的模型规格与卡型参数，再去硬件租用页看实时机型与租金，避免照着过期数字做预算。→常见问题
微调 1.5B 的模型，一定要专业卡吗？
不一定。参数量在这个量级的模型做参数高效微调，单张消费级卡通常够用，关键看序列长度和批大小。如果任务要喂很长文本、批大小压不下来，或者要做全参微调，才需要考虑更大显存的专业卡。建议先按估算顺序试跑一遍，看实际峰值再决定要不要升级，别一上来就租最贵的。
微调 0.8B 和 1.5B 显存差多少量级？
权重、梯度和优化器状态基本随参数量线性走，所以静态占用差不多是接近两倍的关系；但激活值、临时缓冲这些和参数量关系不大，跟序列长度、批大小关系更大。结果是两者实际峰值往往没有两倍那么夸张，小模型上框架开销占比反而更高。具体差多少，用站内部署测算页按你的配置跑一遍更准。
显存不够，是换卡还是先做优化？
先做优化。降批大小配合梯度累积、开梯度检查点、换参数高效微调方式，这三步通常能把占用压到能跑。换卡是最后一步，因为它同时改变成本和迭代速度。只有当你已经压缩到质量不能接受、或者任务本身就要长上下文和全参微调时，升级硬件才划算。
