finetuning-method-selection

微调方法选择

这是微调生命周期的路由技能：它决定微调 究竟是不是正确的工具，如果是，又该选择 哪种方法以及哪个基座模型规模等级。本插件 中的其他所有技能都假定这一路由已经完成—— 在打开 lora-qlora-recipes、preference-optimization 或 grpo-rlvr-training 之前，请先从这里开始。

何时使用本技能

• 在启动任何微调工作时，且尚未选定框架或 基座模型之前。
• 不确定 RAG 或提示词工程是否比训练更廉价地 解决问题时。
• 针对同一个底层任务，在偏好优化（DPO 系列）与强化学习方法（GRPO/RLVR）之间 做选择时。
• 在正式投入一次运行之前，评估候选的模型/ 方法组合的规模时。

快速参考

情况	路由
事实频繁变化（价格、文档、新闻）	RAG，而非微调
期望的行为仍在摸索中	提示词工程
稳定的领域知识，≥500MB 文本	先 CPT 再 SFT——见“先说退出路径”
有输入/输出演示	SFT——见 lora-qlora-recipes
有偏好对或点赞/点踩	DPO/ORPO/KTO——见 preference-optimization
有可验证的通过/失败信号	GRPO+RLVR——见 grpo-rlvr-training
尚无评估工具链	停止——见 eval-harness-first

先说退出路径

大多数听起来像“微调这个”的请求，在别处 能以更好、更廉价的方式得到满足。在打开一次 训练运行之前，先检查这些退出路径：

• 受知识约束且易变（差距在于会变化的 事实——价格、文档、时事）：路由到 RAG， 而非微调。微调后的模型会把某个快照固化 进去；易变的事实会立即过时。
• 受行为约束且不断变化（期望的行为仍在 摸索中，或会随请求而变化）：路由到提示词 工程。微调会锁定一种行为；不要锁定一种 尚未稳定下来的行为。
• 稳定且密集的领域知识：这里是继续预训练 （CPT）介入的地方，其规模取决于存在多少 领域文本：

领域文本量	路由
<10MB	仅 RAG
10MB–500MB	RAG + 微调
500MB–10GB	CPT，然后 SFT
>10GB	必须 CPT

CPT 学习率 ≈ 预训练学习率的 10%。 本插件中 CPT 仅为指导性质——规模与学习率 指导在此处，但本插件不执行 CPT 运行。

方法路由器

一旦排除了退出路径，这就是完整的决策树 （逐字摘自本插件所依据的研究）：

New FACTS?  volatile → RAG | stable+dense → CPT (LR ~10% of pretrain) → SFT
New BEHAVIOR? shifting → prompt-engineering | stable:
  demos → SFT (LoRA/QLoRA, all-linear, α=2r)
  preference pairs → DPO (SimPO if length-bias, ORPO if memory-bound)
  unpaired 👍/👎 → KTO
  verifiable success → RLVR + GRPO (DAPO/GSPO/Dr.GRPO per failure mode)
Deploy: FP8 (Hopper+) | NVFP4 (Blackwell scale) | AWQ (older) | GGUF+imatrix (edge)
BEFORE ANY OF THIS: the eval harness must exist first.

自上而下阅读这棵树：先回答“新事实还是新 行为”，然后沿着与手头数据形态（演示、偏好 对、点赞/点踩，或可验证的成功/失败）相匹配 的分支走。是数据形态决定方法——而不是 反过来。

路由实例

• “用户希望助手完全遵循我们的支持 话术。” 行为稳定且可从对话记录中演示 → 演示 → SFT。
• “我们有来自审阅者点赞/点踩的好/坏响应 对，但未配对。” → 未配对信号 → KTO， 而非 DPO（DPO 需要配对的偏好）。
• “模型已经能解出其中一些数学问题，而且 我们可以自动评判正确性。” → 可验证的 成功信号 → GRPO+RLVR，而且要先确认 模型至少有时能成功（见下方关键路由 事实）。
• “我们希望模型了解本周的定价页。” → 易变事实 → RAG，完全无需训练运行。

关键路由事实

• 损失函数的选择杠杆率很低。 一项 240 次 H100 运行的研究发现，方法选择的价值约为 1 个百分点，而模型规模的约为 50 个百分点，并且 20 种 DPO 变体中没有一个能胜过原版 DPO。不要把路由决策浪费在纠结 DPO 变体的选择上——把它花在把数据形态和规模搞对上面。
• DPO 用于品味，GRPO+RLVR 用于推理。 编码主观判断（语气、风格、“哪个答案更好”）的偏好对路由到 DPO。具有可验证通过/失败信号的任务（数学、代码、工具调用）则改为路由到 GRPO+RLVR。
• RL 不是从不成功的模型的解药。 GRPO 和其他 RL 方法是在磨砺已有能力——它们不能从零教会一种能力。如果模型还不理解任务或输出格式，先跑 SFT；只有当模型至少有时能成功时，才引入 RL。

常见路由错误

• 为了修每周都在变的事实而动用微调——那是 RAG 的问题，而微调只会比源数据老化得更快。
• 在检查真正的瓶颈是数据质量还是模型规模之前就挑选 DPO 变体——变体选择是约 1pp 的杠杆，不是约 50pp 的那个。
• 在一个每次 rollout 都失败的模型上启动 RL 运行——先路由到 SFT，这样 RL 才有东西可以磨砺。
• 把 CPT 当作“模型不了解我们的领域”的默认方案——先检查数据量阈值；低于 500MB 时，RAG 或 RAG+微调的迭代速度比一次 CPT 运行更快。

模型选择

基座模型的选择是先看规模档位，其次看家族，而且它会很快过时——所以它只存在于一个地方：references/model-catalog.md。该文件是本插件（以及 DGX Spark 运维插件）中唯一会点名基座模型家族的地方。本 skill 和 references/memory-math.md 都不点名；两者都只按规模档位描述模型（例如“8B-class LoRA”，而不是某个模型名称）。

该目录有意标注日期——模型排名每季度都会变化。它带有一个“last verified”日期和一份刷新清单。在信任某一行之前，先核对那个日期；如果已过时，在依据它推荐模型之前，先执行目录中的刷新清单。

当目录与方法 skill 不一致时的优先级： 目录每行的 Notes 列说明的是硬件/规模档位的可行性，而不是方法推荐——实际方法选择由 lora-qlora-recipes 的 LoRA vs QLoRA vs Full FT 表（按任务形态路由）决定。

内存可行性

在确定采用某种方法之前，先估算规模：总内存 ≈ params × dtype bytes + optimizer state + gradients + activations。针对所选 dtype 和方法（全量微调、LoRA 或 QLoRA）逐项计算——演算好的工作表和规模档位示例位于 references/memory-math.md。

具体到 DGX Spark，统一内存的行为会打破朴素估算（瞬时加载峰值、nvidia-smi 低报、长时间运行时的热降频）。一旦安装了 dgx-spark-ops 插件，就把 Spark 特有的可行性判断交给它的 spark-memory-thermal-ops skill，而不是在这里重新推导。

相关 Skill

一旦本 skill 选定了方法，就移交给执行它的 skill：

• lora-qlora-recipes — 通过 LoRA/QLoRA 进行 SFT
• preference-optimization — DPO、ORPO、KTO
• grpo-rlvr-training — 带可验证奖励的 GRPO

在 eval harness 存在之前，不选定任何方法——见 eval-harness-first。