打算微调一个模型，第一句通常就是「得多大的卡」。显存不是拍脑袋定的，它由参数量、精度、优化器状态、批量大小和序列长度共同决定，任何一项变了，结果就差一大截。这篇不给你一个死数字，而是给一套能自己代入的估算顺序和配置对照，帮你在租卡或买卡之前先把账算明白，再决定要不要动手。
打算微调一个模型，第一句通常就是「得多大的卡」。显存不是拍脑袋定的，它由参数量、精度、优化器状态、批量大小和序列长度共同决定，任何一项变了，结果就差一大截。这篇不给你一个死数字，而是给一套能自己代入的估算顺序和配置对照，帮你在租卡或买卡之前先把账算明白，再决定要不要动手。
先说清楚结论：没有「微调某模型需要多少 G」这种一句话答案，只有「按你选的训练方式、精度、批量与序列长度算出来大概多少 G」。所以下面讲的是一套算法和判断标准，具体显卡规格和租用行情，到站内的硬件页面核对当时的数字，不要按记忆里的行情拍。
微调的显存到底被谁吃掉了
微调显存大致分四块：模型权重、梯度、优化器状态、激活值。全量微调时，前三块加起来往往是你权重的好几倍，而不是一样大。很多人只算了权重就下单，结果卡到手才发现连一个 batch 都跑不起来，问题基本都出在没算优化器状态和激活值。
- 模型权重
- 参数量乘精度字节数，fp16 大约是每参数两个字节，这是估算的起点，不是终点
- 梯度
- 每个可训练参数都要存一份，规模一般与权重同量级，冻结层不产生这部分
- 优化器状态
- Adam 系优化器通常要为每个可训练参数额外存多份状态，是显存暴涨的主因
- 激活值
- 前向过程各层的中间结果，随批量大小和序列长度涨，长文本微调时最容易先爆
- 先分清哪些参数可训练：全量微调是全部，LoRA 只训练一小部分旁路参数，冻结层两者都不算
- 优化器状态常被忽略，换优化器或换成 LoRA 这类只训练少量参数的方式，能省下一大块
- 激活值随批量大小和序列长度线性涨，先按你数据集里最长的样本估，别按平均值估
- 估算时把推理验证、checkpoint 保存的开销也算进去，这些在训练中会真实占用显存
按这个顺序估：四步走完再谈买卡
估算不需要多精确，但顺序不能乱。先定规模和精度，再乘训练方式对应的倍数，然后代入批量与序列长度估激活值，最后留余量。四步走完再去看卡，比先看卡再反推模型要省事得多。
- 第一步：定参数规模与精度确定你要微调的模型大概多大、用什么精度训练。精度越低权重占用越小，但也会影响训练稳定性，这一步只要得到一个权重占用的数量级即可。
- 第二步：乘训练方式倍数全量微调的倍数最高，只训练部分层或加 LoRA 会低很多。把权重占用乘上这个倍数，得到权重、梯度、优化器状态的粗略合计。
- 第三步：估激活值用你数据集里最长的样本长度和计划使用的批量大小代入估算，这部分随两者线性变化，长文本场景要特别保守。
- 第四步：留余量并对照在合计值上再加一截给推理验证、checkpoint 和框架缓存。算完拿站内 /models/deploy 的部署测算对照一遍口径，别自己另起一套算法。
估算出来的数字和站内测算工具给出的口径对不上时，优先检查是不是漏了优化器状态，或者激活值按平均长度而不是最长长度算的。这两个地方是最常见的偏差来源。
配置方案对照：什么情况选哪种卡
| 场景 | 判断标准 | 建议方向 |
|---|---|---|
| 单卡够用 | 权重乘倍数后，还能塞下按最长样本估的激活值 | 优先单卡，简单好调，省通信开销 |
| 单卡勉强 | 权重放得下，但批量一大激活值就顶满 | 降批量、上梯度累积，或改用 LoRA 降倍数 |
| 必须多卡分片 | 权重乘倍数就已经接近或超过单卡上限 | 考虑张量分片或流水线并行，同时把通信成本算进去 |
| 先别急着买 | 还没确定训练方式和序列长度 | 先用小规模试跑验证流程，再决定最终配置 |
- 放不下时的优先级：先降批量，再上梯度累积模拟大 batch，再考虑量化或 LoRA，最后才是多卡分片
- 多卡不是免费的，通信开销和调试成本要一起算进去，小团队尤其容易低估
- 具体哪张卡什么规格、当前租用价格，到 /compute/gpus 和 /compute/gpu-rental 看当时的数字
- 别按记忆里的行情拍价格，硬件和租用行情变动快，以页面实时数据为准
判断单卡还是多卡，核心就一条：权重乘训练倍数之后，还能不能留下足够空间给按最长样本估的激活值。能留下就单卡，留不下再谈分片，不要因为「多卡听起来更稳」就直接上分布式。
几个容易翻车的地方
- 按推理显存去估微调是最常见的错，两者能差好几倍，推理不需要优化器状态和梯度
- 反过来，按全量微调去估 LoRA 会严重高估，LoRA 只训练少量参数，优化器状态小得多
- 序列长度按平均值估会翻车，实际训练里最长样本才决定峰值占用，按最长估才安全
- 估算通过不等于跑得动，还要留出 checkpoint 保存、评估集推理和框架缓存的额外开销
- 只看单步显存不看训练时长也不够，长训练要留意显存碎片和持续占用带来的问题
还有一个隐蔽的坑：训练中途换批量或换序列长度。前几步跑得动不代表全程跑得动，如果数据集长度分布不均，峰值往往出现在最长的那几个 batch 上。建议正式开跑前先用最长样本做一次冒烟测试。
显存不够时的取舍顺序
显存不够，第一反应不该是加卡，而是回头改训练方式。能改算法解决的，就别先动硬件，因为加卡带来的通信和调试成本，往往比想象中大。
- 先改训练方式优先上 LoRA 这类只训练少量参数的方式，再考虑量化，再考虑缩短序列长度，这三步通常能省下最多显存。
- 再评估要不要自己做改硬件之前先想清楚是不是真的需要自建。托管微调和自建的分界线可参考 /compute/finetune，把维护成本也算进去。
- 最后才考虑多卡多卡分片是最后手段，通信开销和调试成本要一起算。决定前到 /price-watch 看当时的租用行情，别只比单卡价格。
常见问题
微调一定要比推理用更大的卡吗？
大多数情况是的，因为全量微调要额外存梯度和优化器状态，通常比同模型的推理多出数倍。但如果你用 LoRA 这类只训练少量参数的方式，差距会小很多，有时和推理接近。所以先确定训练方式再谈卡，顺序反了容易白花钱。
显存估算出来刚好够，能直接开跑吗？
不建议。峰值占用会被最长样本、框架缓存和保存检查点顶上去，估算值建议留出明显余量。稳妥做法是先拿小批量、短序列跑通一轮，观察实际占用再逐步加上去，别一上来就按满配启动。
用云上按量还是自己租卡更划算？
看你是跑一次还是要反复跑。偶尔试一次，按量或托管微调省掉环境折腾；要长期反复调，租卡或自建才可能回本。具体租金和托管价格到站内 /compute/gpu-rental、/compute/finetune 看当时的数字再比。
