多数人卡在「懂点原理但落不了地」：模型选好了，数据不知道怎么准备，显存算不准，微调完也不知道算不算成功。这篇不重复榜单和自建对比，只给一条从原理认知到微调上线的动作链路，每一步都能照着做，并说明什么情况下这条路不适用。
很多人对注意力、参数、上下文这些词都能说两句，但一到自己动手就卡住：模型选好了，数据不知道从哪下手，显存算不准，跑完一圈也不知道算不算成功。这篇不聊榜单，也不聊自建对比，只给一条从原理认知走到微调上线的动作链路，每一步都能照着做，同时说清什么情况下这条路不适合你。
整体思路就一句：原理只挑会改变你动作的那几层看，其余先放一边。下面按「先看懂哪几层影响落地 → 数据怎么准备 → 路线和显存怎么算 → 怎么判断成功 → 成本与上线怎么衔接」的顺序展开，遇到不熟的术语先对照站内词条，别凭印象猜。
先分清原理里哪几层会直接影响你的落地动作
原理不等于论文，你只需要盯住三件会直接改动作的事：注意力机制决定长输入的代价，参数规模决定显存和训练方式，上下文长度决定你要不要把长文切段。把这三件事和你后面的数据格式、批量大小、输入长度对上，原理这一层就算用上了。
- 预训练
- 从零学通用语言能力，个人和小团队基本不碰，成本量级完全不同
- 后训练
- 在通用模型上做对齐，通常由模型方完成，你拿到的是成品
- 微调
- 用自己的数据让成品模型贴合具体任务，这才是大多数人真正要走的一层
- 提示词与检索
- 不改模型权重，靠输入约束和外部知识解决，能覆盖就别上微调
- 任务约束能用提示词写清楚、知识又经常变的，先用提示词加检索，别急着微调；
- 任务要求稳定输出固定格式、且领域表达有大量内部习惯的，才值得进微调这一步；
- 一个判断标准：如果换一批新数据你就得重训，说明该用检索而不是微调；
- 遇到陌生术语先到 /ai-dict 和 /ai-dict/category/tech 对照，别靠印象猜，猜错会连锁影响后面所有决策。
数据准备：按「够用、干净、可验证」三步走
数据是微调里最容易被低估的一环。很多人把时间花在调参上，结果发现是数据格式本身就错了。正确顺序是先定任务边界，再定数据格式，最后才谈规模。边界没定清，格式一定反复改，前面洗的数据全部作废。
- 定任务边界写清楚输入是什么、输出是什么、哪些情况算对。边界写不出来就先别收数据，否则收回来也没法标。
- 定数据格式指令、问答、分类三种格式对应的训练写法不同，先按目标任务的真实调用方式定格式，再往模板里填内容。
- 清洗留痕按去重、去噪、长度截断、敏感信息处理的顺序做，每一步保留版本记录，出问题能回滚到上一步。
- 划训练与验证两边不能同源同批，否则验证结果等于自己考自己。具体比例思路可对照站内训练集相关页面核对当时的做法。
- 小批量跑通先拿一小批数据走完整流程，确认格式、显存、产出都正常，再放量，别一上来就把预算烧在错的格式上。
还有一个常被忽略的动作：把验证集的抽检问题固定下来，每次评测都用同一套。这样你才能分辨「这次真的变好」还是「换题之后碰巧好看」。评测集本身也要留版本。
路线与显存：先算再选，别先买卡
显存焦虑大多来自顺序错了：先想买什么卡，再想跑什么模型。正确做法是先按参数量和量化档位估一遍账，再决定路线。全参微调和参数高效微调是两个量级的开销，选错方向，后面调什么参数都救不回来。
| 变量 | 影响什么 | 常见应对 |
|---|---|---|
| 参数量 | 决定基础显存与训练方式 | 按需求选量级，不是越大越好 |
| 量化档位 | 影响显存占用与输出质量 | 先看 /tools 能做的换算，再去 /models/deploy 核对配置 |
| 批量大小 | 直接影响瞬时显存 | 先降批量，别先换硬件 |
| 序列长度 | 长输入代价被普遍低估 | 先缩序列，或把长文切段处理 |
| 梯度累积 | 用小批量凑出等效大批量 | 显存不够时的首选替代手段 |
显存不够时按固定顺序排查：先降批量，再缩序列，接着上梯度累积，然后加量化，最后才考虑换硬件。顺序反了，你会花大钱解决一个本来调参就能解决的问题。租卡还是按量，可以先去 /compute/finetune 看当时的口径再决定。
跑起来之后：怎么判断这次微调算成功
训练跑完不等于成功。「变聪明了」这种说法在验收里没有意义，你需要能对比、能复现的证据。判断分三档看，任何一档明显不对，都先回头查数据和配置，而不是急着调结构。
- 第一档看训练是否稳定：损失是否收敛，有没有剧烈震荡或直接发散；
- 第二档看泛化：验证集是否和训练集同步下降，两者分叉就是过拟合信号；
- 第三档看真实任务：用固定抽检问题前后对比，确认输出确实贴合任务要求；
- 训练好、验证差，优先加数据或减轮次，别第一时间改结构；
- 验收要用同一套问题，避免换题之后得出误导性的好结论。
上线前留好回退路径：记录本次的数据版本、关键参数和评测结果，写清楚「什么结果对应回滚到哪一版」。没有这套记录，第二次迭代时会完全无从下手，也无法判断是改动起效还是数据换批带来的波动。
算成本与落地衔接：微调完不等于结束
最后一节把账算清、把链路接上。成本至少拆成算力、数据处理、评测复跑三块，很多人只算第一块，结果后两块反复超支。微调产物怎么进推理服务也要提前确认：是合并权重，还是加载适配层，部署侧支持哪种直接决定你的交付方式。
- 算三块成本算力、数据处理、评测复跑分开记。租卡与按量的分界线参考 /compute/finetune 当时的说明。
- 确认部署接口问清部署侧支持合并权重还是加载适配层，提前对齐能省掉一次返工。
- 建监控基线上线后盯输出漂移和延迟，可参照 /tools/quality-monitor 一类工具建立基线，别等用户反馈才发现问题。
- 留回退开关把旧版本保留在可随时切回的状态，出现异常先回退再排查。
如果你的场景是知识频繁变化、用户问题开放，那这条「微调落地」的链路本身就不是最优解，换检索方案更省事。判断标准很简单：需要频繁重训才能跟上的任务，不适合用微调硬扛。
下一步先别急着动手，去站内把模型资料、部署口径和算力口径对一遍，确认微调确实是你要走的那条路，再开始收数据。→常见问题
没有算法背景，能直接上手微调吗？
能做，但要先把注意力、参数量、上下文这三件事和你的显存、数据、输入长度对应起来，再按数据准备、显存估算、跑通小批量、验证抽检的顺序走。跳过任何一步都会在后面返工，尤其是数据格式和划分方式。
微调一次大概要准备多少数据、多少显存？
没有通用答案，取决于参数量、量化档位、批量与序列长度。建议先到 /models/deploy 和 /compute/sizing 按你的模型算一遍，用最小可用数据量跑通流程再放量，别一上来就堆满数据和大批量。
微调完效果没变好，先查什么？
按顺序查：数据格式与标注是否一致、训练与验证是否同源、轮次是否过多导致过拟合、评测问题是否固定同一套。多数情况问题在数据和验收方式，不在模型本身。
