打算做微调时，最常卡住的一步不是怎么调参，而是先选哪条路：全参重训、只训一小块适配层、还是先量化再训。选错方向，后面显存不够、效果不稳、迭代变慢都是连锁反应。这篇不重复榜单和自建调用的对比，只把几种微调策略的代价摊开，按你的数据规模和硬件条件给判断顺序，以及每一步该去哪里核对当前数字。
打算做微调时，最常卡住的一步不是怎么调参，而是先选哪条路：全参重训、只训一小块适配层，还是先量化再训。方向选错，后面显存不够、效果不稳、迭代变慢都是连锁反应。这篇不重复榜单和自建调用的对比，只把几种微调策略的代价摊开，按你的数据规模和硬件条件给判断顺序，每一步该去哪里核对当前数字也都写清楚。
下面按「先认清每条路改了什么、再看四个代价变量、然后按场景走判断顺序、接着避坑、最后给一张动手清单」来组织。看完全文，你应该能回答一个问题：以我手上的数据和卡，第一步该试哪条路，什么条件下该换。
先认清几条路各自改了什么
全参微调动的是全部权重，等于把预训练模型往你的数据上重推一遍，代价最大也最灵活。适配层类方法只加一小块可训练参数，主干冻结，训练产物小、替换快。这两类的区别不是「好」和「坏」，而是你愿不愿意为灵活性付训练和部署两头的账。
- 全参微调
- 所有权重都参与更新，能力上限高，但显存、时长、产物体积都是最重的
- 部分层解冻
- 只放开靠后的若干层，介于全参与轻量之间，适合想省显存又怕轻量方法不够用
- 适配器与低秩方法
- 主干不动，只训一小块旁路参数，训练快、产物小，是最常用的折中
- 只调输出头
- 几乎只改最后一层，最省，但能补的领域知识很有限
- 蒸馏
- 用大模型产出的数据去教小模型，解决的是「要小要快」，不是「要补领域知识」
排个大致顺序：按可训练参数量看，全参 > 部分层解冻 > 适配器与低秩方法 > 只调输出头，越靠前越贵、越靠后越省。但判断起点不该是预算，而是问题性质：只想纠正回答风格和格式，轻量方法通常够；要把模型塞进它完全没见过的专业语料，才考虑更重的做法。
代价不只看卡数，四个变量决定你选哪条
很多人一上来就问「几张卡够」，其实显存只是四个变量之一。数据量、迭代频率、上线形态任何一个卡住，都会把原本可行的方案顶回去。
| 变量 | 偏向轻量方法的信号 | 偏向全参的信号 |
|---|---|---|
| 显存 | 只有单张消费卡 | 有多卡或整机 |
| 数据量 | 样本量小、标注还在补 | 样本到十万级且质量稳定 |
| 迭代频率 | 要反复换数据版本重训 | 一次成型、长期不动 |
| 上线形态 | 要求产物小、能快速替换 | 对推理链路改动不敏感 |
显存这条最实际：全参要存权重、梯度、优化器状态三份，适配层方法通常只多存一小块参数，同一张卡能上更大基座。具体占用按模型规模到 /tools 里的换算工具和 /models/deploy 算一遍，别凭印象估。迭代频率这条也常被忽略：要反复重训，就选训练快、产物小的路；一次成型才值得为全参付代价。上线形态则决定训完能不能和原权重合并、推理时是否多一层加载，可对照 /stacks/fine-tuning 看服务商支持范围。
按场景走的判断顺序
- 第一步：先划任务边界如果只是想让输出稳定遵循格式或语气，先把提示词和检索这条线走到头，再考虑微调。分界可参考 /stacks/atlas 里相关概念页，确认你的问题不在提示词能解决的范围内。
- 第二步：看数据规模与质量样本量不足或标注噪声大时，换任何策略都救不回来。先补齐数据、统一标注口径，再谈方法。这一步没做完，后面全是白跑。
- 第三步：看硬件底牌手上有单张消费卡，基本只能选显存占用低的路；有多卡或整机，才有全参的空间。卡型对照见 /compute/gpus，按你实际能拿到的机器来定，别按理想配置规划。
- 第四步：做小规模对照用同一批留出样本，跑轻量方法和更重方法各一版，比的是领域任务上的实际表现，不是训练损失曲线。两个版本跑完再决定往哪个方向加投入。
这条顺序的关键是「每一步都可能让你停在前一步」。提示词能解决就别微调，数据不行就先补数据，卡不够就老老实实走轻量路线。跳过任何一步直接开训，通常会在后面某一步被迫回头。
容易翻车的几个地方
- 把小样本全参当成万能解：数据少时模型会复读训练样本，泛化反而变差，这种场景轻量方法通常更划算。
- 忽略评测集独立：训练集和验证集混在一起，看起来效果很好，上线就露馅，务必留出一批完全没进训练的样本。
- 忘了基座换代成本：适配层绑在特定基座和版本上，换基座要重训甚至重写数据管线，换代前先看 /models 里格式是否兼容。
- 只比训练成本不比推理成本：有些方法训练便宜，但推理时要额外加载适配层、增加延迟，高并发场景要一并算进账。
- 拿跑分当唯一标准：榜单分数和你的垂直任务不是一回事，判断口径可参考 /benchmarks。
这几条里最常见的是前两条，因为它们不会在训练日志里报错，只会安静地把结果带偏。建议在开训前就把留出验证集切好、把基座兼容性确认掉，再动手。
动手前的一张检查清单
- 写清一句话目标：要模型多做什么、少做什么，能量化最好，比如格式通过率。
- 确认数据量级、标注质量和是否已留出独立验证集。
- 按基座规模估算显存与训练时长，去 /tools 用换算工具过一遍，再对照 /compute/sizing 定卡数。
- 选定两条候选路线，先各跑一小轮，用同一套验证样本对比。
- 确认产物的部署方式、许可证边界与基座换代后的迁移代价，许可证可查 /open-weight-license-basics 同类概念页。
- 把结论落到文档：选了什么、为什么不选另一条、什么条件下要回头重选。
这份清单的价值在第 6 条。微调决策不是一次性的，基座换代、数据翻新、并发量变化都会触发重选。把当时的选择理由写下来，下次面对同样问题时能少绕一圈。
下一步想横向看不同服务商对这几类微调的支持范围和当前报价，到站内对比页核对当时的数字，再决定自己走哪条路。→常见问题
数据量不大，是不是只能做轻量微调？
多数情况下是的，但关键看任务。如果是补一个小领域的问答风格或固定格式，轻量方法往往就够。真要重训全部权重，样本太少会让模型记住训练文本、丢掉原有能力。稳妥做法是先按数据规模算出可训练参数量上限，再挑路线，具体阈值去 /models/deploy 看当时的参考。
全参微调和轻量微调，效果差多少？
没有通用答案，取决于你的领域和基座与目标领域的距离。基座已经见过类似内容时，两者差距常常不大；领域非常偏门、语料量又足时，全参才更可能拉开差距。做法是用同一批留出样本做小规模对照，别拿公开跑分代替自己的验证集。
微调完怎么部署，和原模型能合并吗？
低秩这类适配层方法通常可以把训练产物合并进原权重，得到一个独立的完整模型，推理时不用额外加载；部分适配器方案则需要运行时挂载。能不能合并、合并后精度有没有损失，跟基座格式和训练框架有关，动手前先到 /stacks/fine-tuning 核对服务商与框架的支持情况。
