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 运行。

方法路由

一旦排除岔路口，以下是完整的决策树（逐字取自本插件所依据的研究）：

新事实？多变 → RAG | 稳定且密集 → CPT（LR 约为预训练的 10%）→ SFT 新行为？仍在变化 → 提示工程 | 稳定：示范 → SFT（LoRA/QLoRA，all-linear，α=2r）偏好对 → DPO（若存在长度偏差用 SimPO，若内存受限用 ORPO）未配对的 👍/👎 → KTO 可验证的成功 → RLVR + GRPO（按失败模式选用 DAPO/GSPO/Dr.GRPO）部署：FP8（Hopper+）| NVFP4（Blackwell 规模）| AWQ（较旧）| GGUF+imatrix（边缘）

在此一切之前：评估框架必须首先存在。

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

路由示例

“用户希望助手完全遵循我们的支持话术。”行为稳定且可从记录中示范 → 示范 → 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 运维插件）中唯一点名基座模型家族的地方。本技能与 references/memory-math.md 都不点名任何模型；两者只按规模档描述模型（例如“8B 级 LoRA”，而非模型名）。
该目录有意标注日期——模型排名按季度更替。它带有“最后验证”日期和刷新清单。在信任某一行之前，先检查该日期；若已过时，先按目录中的刷新清单操作，再据此推荐模型。
当目录与方法技能冲突时的优先级：目录的每行 Notes 列陈述的是硬件/规模档可行性，而非方法推荐——lora-qlora-recipes 的 LoRA vs QLoRA vs Full FT 表（按任务形态路由）才决定实际方法选择。

内存可行性

在确定方法之前，先估算规模：总内存 ≈ 参数量 × dtype 字节数 + 优化器状态 + 梯度 + 激活值。针对所选 dtype 和方法（全量微调、LoRA 或 QLoRA）逐项计算——演算工作表与规模档示例见 references/memory-math.md。
在 DGX Spark 上尤其要注意，统一内存行为会打破朴素估算（瞬时加载峰值、nvidia-smi 低报、长时间运行的热降频）。安装 dgx-spark-ops 插件后，Spark 特有的可行性判断应交由其 spark-memory-thermal-ops 技能，而非在此重新推导。

技能介绍