La Forge Technique : Optimiser l’Entraînement avec Unsloth & QLoRA

Une fois que nous disposons de données de haute qualité (le dataset ReAct de l’Article 2), il est temps de passer à la “forge”. Fine-tuner un modèle de 12 milliards de paramètres (comme Mistral-Nemo-12B) n’est pas une mince affaire sur du matériel grand public. Sans optimisation extrême, l’entraînement d’un expert métier pourrait prendre des heures, ce qui briserait le cycle d’itération rapide indispensable à notre usine.

Pour l’Usine à LoRAs, nous avons fait deux choix technologiques majeurs : QLoRA pour l’efficience mémoire et Unsloth pour la vitesse de calcul brute.

Note de terrain : l’article initial décrivait l’entraînement de Mistral-Nemo-12B. En pratique, le retour d’expérience de cyber-agent-engine a orienté vers des SLM (Small Language Models) — des modèles 3 à 4B de paramètres — comme modèles déployés. Les LLM (12B+) restent utilisés côté génération de données d’entraînement uniquement. Cette distinction change profondément les contraintes matérielles et la stratégie d’entraînement.

1. QLoRA : L’Efficience au Service de l’Expertise Métier

Le Fine-Tuning complet (Full Fine-Tuning) est souvent une mauvaise idée pour la spécialisation d’outils. Il risque de briser le “bon sens” du modèle de base (phénomène de Catastrophic Forgetting). Nous utilisons donc le QLoRA (Quantized Low-Rank Adaptation).

Les Hyperparamètres de l’Expert

Pour les tâches de “Tool Use” (utilisation d’outils), les hyperparamètres classiques de génération créative ne fonctionnent pas bien. Voici notre configuration “Signature” pour lora-factory :

• Rank (r) = 16 : Un rang suffisamment élevé pour capturer la complexité des 40 endpoints OPNsense, mais assez bas pour rester léger et éviter l’overfitting.
• Alpha = 32 : Facteur de mise à l’échelle. Pour les tâches de suivi de directive strictes, nous utilisons un ratio alpha/rank de 2:1 pour “stabiliser” les poids.
• Target Modules : Nous ne nous contentons pas de q_proj et v_proj. Nous ciblons l’intégralité de la structure d’attention : k_proj, o_proj, gate_proj, up_proj et down_proj. Cette “couverture totale” permet au modèle d’ajuster son raisonnement ReAct sur l’ensemble du flux d’attention.
• Quantization (4-bit) : Utilisation de bitsandbytes pour charger le modèle de base avec une empreinte VRAM minimale.

# Extrait du configurateur d'entraînement
def get_lora_config():
    return LoraConfig(
        r=16,
        lora_alpha=32,
        target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
                        "gate_proj", "up_proj", "down_proj"],
        lora_dropout=0.05,
        bias="none",
        task_type="CAUSAL_LM",
    )

1bis. Le Paradigme SLM : Former un Expert, pas un Généraliste

L’un des apprentissages les plus structurants de cyber-agent-engine concerne le choix du modèle déployé.

L’intuition initiale est de fine-tuner le modèle le plus capable possible. La réalité opérationnelle impose l’inverse : un SLM de 3-4B paramètres fine-tuné sur un domaine étroit surpasse un LLM généraliste de 70B sur ses tâches cibles, tout en étant :

• 10 à 20× plus léger — déployable sur du matériel standard sans GPU datacenter
• 3 à 5× plus rapide à l’inférence — compatible avec des pipelines temps-réel
• Privé par défaut — tout tourne localement, aucune donnée sensible n’est exposée

Le rôle des LLM (GPT-4o, Qwen-72B, Mistral-Nemo-12B) est alors recentré sur la génération du dataset d’entraînement — tâche ponctuelle où leur supériorité en compréhension est utile. Une fois les données générées et validées, le LLM est mis de côté.

Rôle LLM  →  Génération & validation des traces (offline, ponctuel)
Rôle SLM  →  Agent déployé, inférence en production (online, permanent)

Cette séparation des rôles permet de scaler horizontalement : on peut déployer des dizaines d’agents SLM spécialisés sur des serveurs standards, chaque agent maîtrisant parfaitement son périmètre.

Conséquences sur les hyperparamètres

Un SLM de 3-4B avec QLoRA et des séquences de 2048 tokens présente des contraintes VRAM différentes d’un 12B. Sur GPU grand public (12-16 GB VRAM), le batch size doit être ajusté — souvent réduit à 2 ou 4 — pour éviter les OOM (Out Of Memory). La compensation se fait via le gradient accumulation pour maintenir un batch effectif raisonnable.

2. Unsloth : La Magie des Kernels Triton

Unsloth n’est pas qu’une simple surcouche de Hugging Face. Il implémente des kernels Triton écrits à la main qui optimisent les calculs fondamentaux du Deep Learning. D’après nos benchmarks, Unsloth permet de réduire la consommation mémoire de 60% et d’accélérer l’entraînement de 2x.

Pourquoi est-ce si rapide ?

Unsloth réécrit les composants critiques :

1. RoPE (Rotary Positional Embeddings) : Optimisé pour traiter les longues séquences de logs et de traces ReAct sans latence.
2. CrossEntropy Loss : Réécrite pour être 2x plus rapide et consommer moins de mémoire tampon.
3. Kernel Fusion : Fusion de plusieurs opérations GPU en un seul “pass”, réduisant les goulots d’étranglement de transfert de données entre le CPU et le GPU.

L’Impact sur Notre Pipeline

Sur GPU grand public, Unsloth réduit le temps d’entraînement d’un facteur ~3 et libère suffisamment de VRAM pour augmenter la longueur de séquence ou le rang LoRA. Cette rapidité permet à un ingénieur de tester plusieurs versions de l’agent en une journée de travail.

Caveat : dépendances et compatibilité

Unsloth repose sur des kernels Triton compilés à la main et est sensible aux versions de CUDA, PyTorch et transformers. Il arrive qu’une mise à jour de l’écosystème casse la compatibilité (erreur au chargement du modèle, incompatibilité de quantization). Il faut toujours avoir une configuration de fallback Hugging Face standard prête — l’entraînement sera 2-3× plus lent mais fonctionnera. Ne bloquez jamais un run de production sur une dépendance Unsloth non testée.

from unsloth import FastLanguageModel
import torch

# Chargement optimisé avec Unsloth
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name = "mistralai/Mistral-Nemo-Instruct-2407",
    max_seq_length = 2048,
    load_in_4bit = True,
)

# Application du PEFT (LoRA)
model = FastLanguageModel.get_peft_model(
    model,
    r = 16,
    target_modules = ["q_proj", "k_proj", "v_proj", "o_proj",
                     "gate_proj", "up_proj", "down_proj"],
    lora_alpha = 32,
    lora_dropout = 0,
    bias = "none",
)

3. Métriques de Sécurité : Le Focus sur le FNR

En MLOps classique, on regarde l’Accuracy. En cybersécurité, l’Accuracy est une métrique trompeuse. Pourquoi ? Parce qu’un agent peut avoir 99% d’Accuracy mais échouer sur la seule action critique qui protège d’une intrusion majeure.

Nous avons introduit une métrique vitale : le FNR (False Negative Rate), ou taux de faux négatifs.

Définition du FNR Opérationnel

• Faux Positif (FPR) : L’utilisateur demande de bloquer le port 80, l’agent bloque aussi le port 443 par erreur. C’est pénalisant pour la production, mais la sécurité est maintenue.
• Faux Négatif (FNR) : L’utilisateur demande de bloquer une IP malveillante, l’agent confirme l’action ("IP bloquée") mais fait une erreur de syntaxe invisible dans l’appel API. C’est une faille de sécurité.

Le Dashboard de Validation

Chaque agent généré par lora-factory est soumis à un test aveugle sur 140 cas de test non vus durant l’entraînement. Les résultats sont compilés dans un rapport JSON de validation :

L’Accuracy des Tokens n’est pas l’Accuracy de l’Agent

Un enseignement critique : le modèle peut atteindre une très haute token accuracy (>95%) lors de l’entraînement tout en restant médiocre en production. La raison est simple — le token accuracy mesure si le modèle reproduit bien les tokens de la réponse attendue, pas s’il sélectionne la bonne fonction dans un contexte réel.

Il faut donc compléter les métriques Hugging Face par un score de validation fonctionnelle : soumettre un jeu de requêtes représentatives à l’agent en mode inférence et mesurer le taux de sélection correcte de la fonction (nom + paramètres). C’est cette métrique — et non la loss ou le token accuracy — qui détermine si l’agent est déployable.

Analyse des Échecs (Fail-Safe Loop)

Si un agent échoue à atteindre ces seuils, lora-factory ne valide pas l’expert. Le pipeline remonte alors à l’étape de génération (Article 2) pour identifier les “zones d’ombre” : manque de traces sur une fonction spécifique (ex: update_alias), confusion entre deux protocoles, etc.

Conclusion

L’entraînement n’est pas une fin en soi, c’est un processus de certification technique. Grâce à l’efficience du QLoRA et à la puissance brute d’Unsloth, nous forgeons des experts fiables en un temps record. Mais un expert certifié doit encore être mis à l’épreuve du monde réel, sur une infrastructure vivante.

Dans le prochain article, nous verrons comment ces experts sont orchestrés par LangGraph et validés “Bare-Metal” sur des serveurs Hyper-V.

Navigation dans la série :

• Article 2 : Apprendre à l’IA à “Réfléchir” — Le Moteur de Traces ReAct
• Article 4 : Du Modèle au Système — Orchestration & Validation Bare-Metal