Sélection de la Méthode de Fine-Tuning

Ceci est la skill de routage pour le cycle de vie du fine-tuning : elle décide si le fine-tuning est le bon outil, et si c'est le cas, quelle méthode et quelle classe de taille de modèle de base utiliser. Toute autre skill de ce plugin suppose que ce routage a déjà été fait — commencez ici avant d'ouvrir lora-qlora-recipes, preference-optimization, ou grpo-rlvr-training.

Quand Utiliser Cette Skill

• Commencer tout effort de fine-tuning, avant qu'un framework ou un modèle de base n'ait été choisi.
• Incertitude sur le fait que RAG ou l'ingénierie des prompts résoudraient le problème moins cher que l'entraînement.
• Choisir entre l'optimisation des préférences (famille DPO) et une méthode de renforcement (GRPO/RLVR) pour la même tâche sous-jacente.
• Dimensionner une combinaison modèle/méthode candidate avant de s'engager dans une exécution.

Référence Rapide

Off-Ramps D'Abord

La plupart des demandes qui ressemblent à « fine-tuner ceci » sont mieux et moins chères à servir ailleurs. Vérifiez ces contournements avant d'ouvrir une exécution d'entraînement :

• Limité aux connaissances et volatile (l'écart concerne les faits qui changent — prix, docs, événements actuels) : routez vers RAG, pas le fine-tuning. Un modèle fine-tuné intègre une capture instantanée ; les faits volatiles deviennent rapidement obsolètes.
• Limité au comportement et changeant (le comportement désiré est encore en cours de définition, ou change par requête) : routez vers l'ingénierie des prompts. Le fine-tuning verrouille un comportement ; ne verrouillez pas celui qui n'a pas encore stabilisé.
• Connaissances de domaine stables et denses : c'est là qu'intervient le continued pretraining (CPT), dimensionné par le volume de texte de domaine existant :

Le taux d'apprentissage CPT ≈ 10 % du taux de pretraining. CPT est guidance-only dans ce plugin — le dimensionnement et les conseils de taux d'apprentissage vivent ici, mais ce plugin n'exécute pas une exécution CPT.

Routeur de Méthode

Une fois les contournements écartés, c'est l'arbre de décision complet (verbatim à partir de la recherche sur laquelle ce plugin est construit) :

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.

Lisez l'arbre de haut en bas : répondez à « faits nouveaux ou comportement nouveau », puis suivez la branche qui correspond à la forme des données en main (démos, paires de préférences, pouces levés/baissés, ou succès/échec vérifiable). La forme des données choisit la méthode — pas l'inverse.

Exemples de Routage Détaillés

• « Les utilisateurs veulent que l'assistant suive exactement nos macros de support. » Le comportement est stable et démontrable à partir des transcriptions → démos → SFT.
• « Nous avons des paires de bonnes/mauvaises réponses provenant de pouces levés/baissés d'examinateurs, non appariées. » → signal non apparié → KTO, pas DPO (DPO a besoin de préférences appariées).
• « Le modèle peut déjà résoudre certains de ces problèmes de maths et nous pouvons évaluer automatiquement la correction. » → signal de succès vérifiable → GRPO+RLVR, et seulement après confirmation que le modèle réussit au moins parfois (voir Key Routing Facts ci-dessous).
• « Nous voulons que le modèle connaisse la page de tarification de cette semaine. » → faits volatiles → RAG, aucune exécution d'entraînement du tout.

Faits Clés de Routage

• Le choix de la fonction de perte a peu d'effet de levier. Une étude avec 240 H100 a trouvé que le choix de la méthode valait ~1 point de pourcentage contre ~50 points pour l'échelle du modèle, et zéro des 20 variantes DPO n'ont surpassé la DPO vanille. Ne dépensez pas une décision de routage en se tortillant sur la sélection de variante DPO — dépensez-la à bien obtenir la forme et l'échelle des données.
• DPO est pour le goût, GRPO+RLVR est pour le raisonnement. Les paires de préférences qui encodent un jugement subjectif (ton, style, « quelle réponse est meilleure ») routent vers DPO. Les tâches avec un signal réussite/échec vérifiable (maths, code, appels d'outils) routent vers GRPO+RLVR à la place.
• Le RL n'est pas le correctif pour un modèle qui n'a jamais de succès. GRPO et d'autres méthodes RL affinent une capacité existante — ils n'en enseignent pas une à partir de zéro. Si le modèle ne comprend pas encore la tâche ou le format de sortie, lancez d'abord SFT ; n'amenez le RL que lorsque le modèle réussit au moins parfois.

Erreurs Courantes de Routage

• Se tourner vers le fine-tuning pour corriger les faits qui changent chaque semaine — c'est un problème RAG, et le fine-tuning deviendra juste obsolète plus vite que les données source.
• Choisir une variante DPO avant de vérifier si le vrai goulot d'étranglement est la qualité des données ou l'échelle du modèle — le choix de variante est le levier ~1pp, pas le ~50pp.
• Lancer une exécution RL sur un modèle qui échoue à chaque rollout — routez d'abord vers SFT pour que le RL ait quelque chose à affiner.
• Traiter CPT comme le défaut pour « le modèle ne connaît pas notre domaine » — vérifiez d'abord les seuils de volume de données ; sous 500MB, RAG ou RAG+fine-tune itère plus vite qu'une exécution CPT.

Sélection du Modèle

Le choix du modèle de base est classe de taille d'abord, famille ensuite, et cela devient obsolète rapidement — donc cela se trouve exactement à un endroit : references/model-catalog.md. Ce fichier est le seul endroit dans ce plugin (et dans le plugin des opérations DGX Spark) qui nomme une famille de modèle de base. Ni cette skill ni references/memory-math.md n'en nomme une ; les deux décrivent les modèles par classe de taille uniquement (par exemple, « 8B-class LoRA », pas un nom de modèle).

Le catalogue est volontairement daté — les classements de modèles changent trimestriellement. Il porte une date « dernière vérification » et une liste de contrôle de rafraîchissement. Avant de faire confiance à une ligne, vérifiez cette date ; si elle est obsolète, travaillez la liste de contrôle de rafraîchissement du catalogue avant de recommander un modèle à partir de celui-ci.

Priorité quand le catalogue et une skill de méthode ne sont pas d'accord : la colonne Notes par ligne du catalogue énonce la faisabilité matérielle/classe de taille, pas une recommandation de méthode — le tableau LoRA vs QLoRA vs Full FT de lora-qlora-recipes (routé par forme de tâche) régit le choix de méthode réel.

Faisabilité de la Mémoire

Avant de s'engager dans une méthode, dimensionnez-la : mémoire totale ≈ params × octets dtype + état de l'optimiseur + gradients + activations. Travaillez chaque terme pour le dtype choisi et la méthode (fine-tune complet, LoRA, ou QLoRA) — les feuilles de travail détaillées et les exemples par classe de taille vivent dans references/memory-math.md.

Sur DGX Spark spécifiquement, le comportement de la mémoire unifiée casse l'estimation naïve (pics de charge transitoires, sous-signalement de nvidia-smi, ralentissement thermique sur les exécutions longues). Une fois le plugin dgx-spark-ops installé, déférez les appels de faisabilité spécifiques à Spark à sa skill spark-memory-thermal-ops plutôt que de les redériver ici.

Skills Associées

Une fois que cette skill a choisi une méthode, passez à la skill qui l'exécute :

• lora-qlora-recipes — SFT via LoRA/QLoRA
• preference-optimization — DPO, ORPO, KTO
• grpo-rlvr-training — GRPO avec récompenses vérifiables

Aucune méthode n'est sélectionnée avant que le harnais d'évaluation n'existe — voir eval-harness-first.