Orchestration du fine‑tuning multi‑phase avec Workflow v6

Contexte

Le fine‑tuning d’un grand modèle de langue (LLM) n’est pas toujours un processus monolithique. Selon la tâche, il est fréquent de séparer l’apprentissage en phases : pré‑entraînement sur un corpus générique, adaptation intermédiaire sur un domaine spécifique, puis spécialisation sur un jeu de données de validation très ciblé. Cette approche réduit le gaspillage de calcul, améliore la stabilité du modèle et facilite la mise en production, car chaque phase peut être validée indépendamment.

Workflow v6 offre un cadre déclaratif qui permet de chaîner ces étapes tout en conservant la visibilité sur les artefacts générés (poids, métriques, logs). Le défi consiste à modéliser les dépendances de version, à gérer les ressources de façon dynamique et à garantir que les artefacts d’une phase soient correctement consommés par la suivante.

Architecture du pipeline multi‑phase

Le pipeline se compose de trois workers principaux :

1. pretrain_worker – charge le modèle de base, applique un jeu de données large et exporte un checkpoint nommé base_v1.
2. domain_adapt_worker – prend base_v1 comme poids d’entrée, fine‑tune sur un corpus de domaine et produit domain_v2.
3. task_specialize_worker – utilise domain_v2 pour un apprentissage final ultra‑spécifique, génère le modèle de production task_v3 et les métriques associées.

Chaque worker est défini dans un fichier YAML qui décrit :

• les ressources (CPU, GPU, RAM) ;
• les artefacts d’entrée et de sortie ;
• les triggers de reprise en cas d’échec.

Le diagramme suivant illustre les flux de données :

base_model --> pretrain_worker --> base_v1
base_v1 --> domain_adapt_worker --> domain_v2
domain_v2 --> task_specialize_worker --> task_v3 + metrics

Implémentation pas à pas

1. Définir le fichier de configuration principal

# workflow.yaml
name: fine_tuning_multi_phase
version: 1.0
workers:
  - name: pretrain_worker
    image: registry.example.com/ai/pretrain:latest
    resources:
      gpu: 1
      cpu: 4
    inputs:
      - name: base_model
        type: model
        path: s3://models/llm-base
    outputs:
      - name: checkpoint
        type: model
        path: s3://checkpoints/base_v1

  - name: domain_adapt_worker
    image: registry.example.com/ai/domain_adapt:latest
    resources:
      gpu: 1
      cpu: 2
    inputs:
      - name: checkpoint
        from: pretrain_worker.checkpoint
    outputs:
      - name: checkpoint
        type: model
        path: s3://checkpoints/domain_v2

  - name: task_specialize_worker
    image: registry.example.com/ai/task_specialize:latest
    resources:
      gpu: 2
      cpu: 4
    inputs:
      - name: checkpoint
        from: domain_adapt_worker.checkpoint
    outputs:
      - name: model
        type: model
        path: s3://models/task_v3
      - name: metrics
        type: json
        path: s3://metrics/task_v3.json

2. Ajouter des callbacks de validation

# callbacks.py
import json

def validate_metrics(path: str, threshold: float = 0.85):
    with open(path) as f:
        data = json.load(f)
    if data.get('accuracy', 0) < threshold:
        raise RuntimeError('Métrique en dessous du seuil acceptable')

Dans le worker task_specialize_worker, on invoque le callback :

    post_process:
      - script: callbacks.validate_metrics
        args:
          - /outputs/metrics/task_v3.json
        kwargs:
          threshold: 0.88

3. Gestion dynamique des ressources

Workflow v6 intègre un scheduler qui ajuste le nombre de GPU alloués en fonction de la charge du cluster. Il suffit d’activer le mode auto‑scale :

scheduler:
  auto_scale: true
  max_gpu: 4

Le scheduler attribuera 1 GPU aux deux premières phases (faible charge) et 2 GPU à la phase finale, sans intervention manuelle.

Validation et monitoring

Une fois le pipeline lancé (wf run workflow.yaml), les métadonnées de chaque exécution sont inscrites dans la base de suivi de Workflow v6. Les tableaux de bord intégrés offrent :

• la visualisation des temps d’exécution par phase ;
• le suivi des versions de checkpoints (hash SHA‑256) ;
• l’historique des métriques et des alertes déclenchées par les callbacks.

Pour automatiser la promotion du modèle en production, on peut ajouter une règle de branchement :

rules:
  - when: task_specialize_worker.success
    then: promote model task_v3 to production

Cette règle ne s’exécute que si le callback de validation a passé toutes les vérifications, garantissant ainsi que seules les itérations conformes sont déployées.

Conclusion

En découpant le fine‑tuning en phases clairement définies et en exploité les primitives de versionnage, de scheduling et de monitoring de Workflow v6, les équipes produit gagnent en contrôle et en prévisibilité. Le pattern présenté ici est réutilisable pour tout projet nécessitant une adaptation progressive d’un LLM, tout en conservant la traçabilité requise pour les audits de conformité.