08 · Entraîner, fine-tuner et choisir un LLM sur Azure

Version : 1.1 · Date : 2026-10-21 · Hors programme (besoin de mission)

Chapitre hors programme. L'examen AI-300 teste le fine-tuning managé, le choix d'un modèle et l'entraînement distribué dans Azure Machine Learning (chapitres 03, 05 et 07). Ce chapitre va plus loin pour une mission où on entraîne vraiment des LLM : quand personnaliser, comment choisir un modèle, où entraîner sur Azure, comment dimensionner, combien ça coûte et comment gouverner les données. Niveau : décision d'architecture, pas recherche en machine learning.

En une phrase : on personnalise un modèle par paliers (prompt, RAG, fine-tuning, puis seulement en dernier recours un entraînement plus profond), on choisit le modèle sur ses propres données et pas seulement sur un classement public, et sur Azure on préfère le fine-tuning managé de Foundry tant qu'il couvre le besoin, avant Azure Machine Learning, AKS avec KAITO ou un cluster GPU que l'on exploite soi-même.

Ce chapitre renvoie aux autres cours plutôt que de redire :

1. Faut-il vraiment entraîner ? Les cinq paliers#

1.1 L'idée clé#

Chaque palier coûte plus cher, demande plus de données et plus de temps que le précédent. On ne monte d'un palier que lorsque le précédent est mesuré comme insuffisant sur un jeu de test représentatif.

Microsoft résume les raisons de passer au palier 3 (Fine-tuning in Microsoft Foundry) : améliorer la précision sur une tâche, réduire la longueur des invites, aligner le ton et le format, mieux utiliser les outils, mieux exploiter le contexte récupéré, spécialiser un modèle plus petit. Et ses limites : les gains ne sont pas garantis, le fine-tuning ajoute des coûts d'entraînement et d'hébergement, et il ne remplace ni la récupération pour l'information à jour, ni les contrôles de sécurité applicatifs.

Règle d'architecte : le fine-tuning apprend un comportement (format, ton, raisonnement sur une tâche, usage d'outils), pas des faits qui changent. Les faits vont dans le RAG. Dans une mission « on va entraîner des LLM », la première question à poser reste : quel comportement le modèle actuel ne sait-il pas produire, et comment le mesure-t-on ?

1.2 L'arbre de décision#

flowchart TD
    A["Besoin métier + jeu de test de référence"] --> B{"Le modèle de base,<br/>bien prompté, suffit ?"}
    B -- Oui --> P["Palier 1 : prompt engineering<br/>+ structured outputs"]
    B -- Non --> C{"Il manque des connaissances<br/>(documents, données récentes) ?"}
    C -- Oui --> R["Palier 2 : RAG"]
    C -- Non --> D{"Problème de comportement :<br/>format, ton, raisonnement, outils ?"}
    R --> D
    D -- Oui --> E{"Des exemples ou un grader fiable<br/>existent-ils ?"}
    E -- "Exemples entrée → sortie" --> F["SFT"]
    E -- "Réponses préférées / rejetées" --> G["DPO"]
    E -- "Grader qui note les réponses" --> H["RFT"]
    D -- Non --> I{"Langue ou domaine très éloigné<br/>du pré-entraînement ?"}
    I -- Oui --> J["Palier 4 : continued pre-training<br/>(cluster GPU, projet dédié)"]
    I -- Non --> K["Changer de modèle :<br/>plus grand, reasoning, autre famille"]

1.3 Les méthodes de fine-tuning en une ligne chacune#

LoRA et QLoRA sont des familles de PEFT (parameter-efficient fine-tuning) : on n'entraîne qu'un petit nombre de paramètres, avec des performances comparables à un fine-tuning complet (Hugging Face PEFT).

2. Choisir un modèle#

2.1 Les critères, dans l'ordre où ils éliminent#

Open-weight ou propriétaire ?

2.2 Les benchmarks publics : utiles pour trier, pas pour décider#

Les model leaderboards de Foundry (preview) comparent les modèles du catalogue sur quatre axes (Model leaderboards) :

On y trouve aussi des scenario leaderboards (raisonnement, code, questions-réponses…), des trade-off charts (qualité contre coût, débit ou sécurité) et une comparaison côte à côte de trois modèles (benchmarks, model details, supported endpoints, feature support) (Compare models). Il faut au moins le rôle Reader sur le Foundry project.

Les limites que Microsoft documente elle-même (benchmark limitations) :

• les jeux de benchmark saturent quand les modèles sont entraînés sur des données proches ;
• les résultats varient selon la construction des invites et le nombre d'exemples few-shot ;
• les mesures de performance utilisent des charges synthétiques à ratio d'entrée / sortie fixe, dans une seule région ;
• l'estimation de coût suppose un ratio de trois jetons d'entrée pour un jeton de sortie, et les prix du moment.

Conclusion : le leaderboard sert à constituer une shortlist de deux ou trois modèles. La décision se prend en les évaluant sur vos données, avec les mêmes evaluators et le même jeu de test (voir AI-103 · 04 et le chapitre 06). Dans le nouveau portail, l'option « Try with your own data » de l'onglet Benchmarks n'existe pas : on passe par Evaluate generative AI apps.

2.3 La décision, en quatre étapes#

flowchart LR
    A["1. Exigences éliminatoires<br/>résidence, licence, méthode,<br/>modalités, contexte"] --> B["2. Shortlist<br/>leaderboards, scenario,<br/>trade-off charts"]
    B --> C["3. Évaluation sur vos données<br/>même jeu de test,<br/>mêmes evaluators"]
    C --> D["4. Décision chiffrée<br/>qualité, latence, coût total,<br/>exploitation"]

3. Où entraîner et fine-tuner sur Azure#

3.1 Les quatre options#

Sources : Fine-tuning in Microsoft Foundry, Azure ML quotas, Distributed GPU training, AI on Azure infrastructure, AKS · 06.

Repère pratique : la page Foundry (classic) résume le compromis. Le fine-tuning serverless ne demande aucun quota GPU et donne accès aux modèles OpenAI, avec moins d'hyperparamètres ; le managed compute offre plus de modèles et de réglages, mais demande des quotas élevés que beaucoup de clients n'ont pas (Serverless or managed compute?).

3.2 Les training types de Foundry#

Le training type (où l'on entraîne) est séparé du deployment type (comment on sert le modèle). Pour servir un modèle fine-tuné, Foundry propose Serverless, Managed compute (preview : GPU dédiés qui portent un modèle de base et un ou plusieurs adaptateurs LoRA compatibles) et Fireworks on Foundry (preview), avec des deployment types dont Developer : facturation au jeton, pas de frais d'hébergement horaires, pas de garantie de résidence, 24 heures maximum, réservé à l'évaluation (deployment options).

3.3 Quels modèles sont fine-tunables ?#

La liste évolue vite : elle se lit dans le tableau Supported models de la page de fine-tuning. Au 21/10/2026, elle contient par exemple :

Un adaptateur n'est pas interchangeable entre deux modèles de base au nom proche : vérifier méthode, training type, version et déploiement avant d'entraîner (challenges and limitations).

4. Le pipeline d'un fine-tuning, de bout en bout#

4.1 Les données d'abord#

4.2 Les contrôles de sécurité intégrés#

Pour les modèles concernés (preview), Foundry ajoute deux contrôles (Safety evaluation for fine-tuning) :

1. Data evaluation, avant l'entraînement : si le jeu contient du contenu nuisible au-delà du seuil, le job échoue, sans frais.
2. Model evaluation, après l'entraînement : une conversation simulée mesure la propension du modèle à produire du contenu nuisible ; au-delà d'un seuil, le modèle n'est pas déployable, et l'entraînement n'est pas facturé.

Les seuils sont prédéfinis et non modifiables ; seul le verdict (déployable ou non) est conservé. Ces contrôles ne remplacent ni les guardrails de l'application, ni une évaluation du runtime final de service.

4.3 Lire les métriques et choisir un checkpoint#

Pour le RFT, on suit la récompense moyenne de validation, les récompenses par grader et les taux d'erreur des graders : une récompense qui monte ne prouve rien si le modèle exploite les failles du grader. Le dernier checkpoint n'est pas forcément le meilleur : on compare les candidats sur le jeu de test tenu à l'écart (Review training metrics).

4.4 Déployer, surveiller, maintenir#

sequenceDiagram
    participant D as Équipe data
    participant F as Foundry (managed fine-tuning)
    participant E as Évaluation
    participant P as Production
    D->>F: Jeu train / validation (JSONL), modèle de base, méthode, training type
    F->>F: Data evaluation (sécurité), puis entraînement et checkpoints
    F->>F: Model evaluation (sécurité) : déployable ou non
    F->>E: Déploiement Developer (24 h, sans frais d'hébergement)
    E->>E: Comparaison base contre fine-tuné sur le jeu de test tenu à l'écart
    E-->>D: Gain mesuré ? Sinon, revoir les données
    E->>P: Déploiement Standard ou Global Standard, guardrails, tracing
    P-->>D: Dérive, nouveaux cas, retrait du modèle de base : réentraîner

5. Dimensionner un entraînement#

5.1 La mémoire GPU, ordre de grandeur#

La documentation Hugging Face détaille ce qui occupe la mémoire pendant un entraînement en précision mixte avec Adam (GPU memory usage) :

La même page donne un repère : entraîner un modèle de 4B paramètres en précision mixte avec un batch de 16 demande environ 85 Go de mémoire GPU.

Ce que l'on en déduit, par simple arithmétique :

Ces chiffres servent à choisir une famille de VM et un ordre de grandeur de quota, pas à garantir qu'un job tient en mémoire : les activations dépendent du batch et de la longueur de séquence. Le seul vrai test reste un essai court.

5.2 Les familles GPU documentées#

Sources : ND-H100-v5, ND-H200-v5, ND family, NC family, ND GB200-v6.

5.3 Ce qu'un architecte doit prévoir#

6. Distiller et réduire : le bon modèle au bon prix#

La distillation utilise les réponses d'un grand modèle (l'enseignant) pour fine-tuner un modèle plus petit (l'élève), qui atteint des performances proches sur la tâche visée, avec un coût et une latence plus faibles (fine-tuning considerations).

Bonnes pratiques :

• l'élève n'est bon que sur la tâche apprise : garder le grand modèle (ou un routage) pour le reste ;
• évaluer l'élève et l'enseignant sur le même jeu de test tenu à l'écart, jamais sur les données générées par l'enseignant ;
• vérifier que la licence de l'enseignant autorise l'usage de ses sorties pour entraîner un autre modèle.

Pour l'inférence, la quantization (poids en 8 ou 4 bits) réduit la mémoire de 2 à 4 fois par rapport au bf16, au prix d'une perte de qualité à mesurer ; elle se met en œuvre côté moteur d'inférence (vLLM sur AKS, voir AKS · 06).

7. Le coût total, pas seulement l'entraînement#

Sources : Manage fine-tuning costs, Deploy a fine-tuned model, Managed compute billing.

Exemple de calcul (méthode de la page de coûts, sans prix figé) : 500 paires invite-réponse soit 1 million de jetons, 2 epochs, training type Global : coût d'entraînement = 1 M × 2 × T, où T est le prix Global par million de jetons du modèle. La durée du job (2 h 15 dans l'exemple Microsoft) ne change pas le prix d'un SFT.

8. Gouverner les données d'entraînement#

Les données d'entraînement passent par un Storage account en Private Endpoint, avec accès par managed identity et RBAC : les règles de SC-500 · 04 s'appliquent telles quelles.

9. Pièges de production#

10. Lab : un premier SFT, à moindre coût#

Objectif : mesurer le gain d'un fine-tuning sur une tâche de format, sans payer d'hébergement horaire.

1. Dans un abonnement de test, créer un Foundry project dans une région qui accepte le training type Developer pour gpt-4.1-nano (voir le tableau Supported models).
2. Préparer 60 exemples JSONL d'une tâche de format (par exemple : transformer un incident en ticket JSON strict), avec le même system message partout ; en garder 10 de côté comme jeu de test (non envoyé à l'entraînement).
3. Lancer un SFT de gpt-4.1-nano, training type Developer, 2 epochs ; noter le nombre de jetons d'entraînement pour calculer le coût (jetons × epochs × prix).
4. Suivre train_loss et full_valid_loss dans Monitor, comparer les Checkpoints.
5. Déployer le modèle en deployment type Developer (24 h, sans frais horaires) ; évaluer le modèle de base et le modèle fine-tuné sur les 10 exemples de test, avec le même evaluator (par exemple la validité du JSON et l'exactitude des champs).
6. Nettoyage : supprimer le déploiement s'il existe encore, puis les fichiers d'entraînement ; supprimer le groupe de ressources si le project ne sert plus.

Résultat attendu : un tableau base / fine-tuné sur les mêmes 10 cas, le coût réel de l'entraînement, et une décision argumentée (le gain justifie-t-il le fine-tuning, ou un meilleur prompt suffisait-il ?).

11. Questions d'entretien et de cadrage#

1. Le client veut « entraîner son propre LLM ». Que lui répondez-vous ?

On commence par le besoin mesurable et un jeu de test. On essaie dans l'ordre : prompt engineering, RAG, fine-tuning. Entraîner un modèle depuis zéro ou faire du continued pre-training ne se justifie que si un domaine ou une langue est très éloigné des modèles existants, avec un corpus et un budget à la hauteur. Dans la plupart des cas, un fine-tuning managé ou un RAG répond au besoin pour une fraction du coût.

2. Fine-tuning ou RAG ?

RAG pour les connaissances (documents, données qui changent, citations) ; fine-tuning pour le comportement (format, ton, usage d'outils, raisonnement sur une tâche). Souvent les deux : un modèle fine-tuné pour mieux exploiter le contexte récupéré.

3. SFT, DPO ou RFT ?

SFT si l'on sait écrire la bonne réponse ; DPO si l'on sait dire laquelle de deux réponses est meilleure ; RFT si plusieurs réponses sont possibles et qu'un grader fiable sait les noter. On commence presque toujours par SFT.

4. Comment choisissez-vous un modèle ?

D'abord les critères éliminatoires : résidence, licence, méthode de personnalisation, modalités, contexte. Puis une shortlist avec les leaderboards de Foundry. Puis une évaluation sur nos données, mêmes evaluators, même jeu de test. La décision chiffre qualité, latence, coût total et exploitation.

5. Pourquoi ne pas se fier aux benchmarks publics ?

Microsoft le dit elle-même : les jeux saturent, les résultats dépendent de la construction des invites, la performance est mesurée sur des charges synthétiques et le coût suppose un ratio d'entrée / sortie fixe. Ils servent à trier, pas à décider.

6. Foundry managed fine-tuning ou Azure Machine Learning ?

Foundry tant que le modèle et la méthode y sont disponibles : pas de GPU à provisionner, pas de quota GPU pour le serverless, des contrôles de sécurité intégrés. Azure ML quand il faut un modèle ou une méthode non proposés, un contrôle fin de l'entraînement ou une traçabilité MLflow complète, en acceptant de gérer quota, cluster et code.

7. Comment estimez-vous la mémoire GPU d'un fine-tuning complet ?

Environ 18 octets par paramètre en précision mixte avec Adam (poids, états de l'optimiseur, gradients), plus les activations qui dépendent du batch et de la longueur de séquence. Un 7B demande donc plus de 120 Go avant activations : plusieurs GPU et DeepSpeed, ou bien LoRA / QLoRA pour rester sur un GPU.

8. Pourquoi LoRA ?

On n'entraîne que de petits adaptateurs : l'article d'origine annonce 10 000 fois moins de paramètres entraînables et 3 fois moins de mémoire sur GPT-3, sans latence ajoutée. On stocke et on sert plusieurs adaptateurs sur la même base, ce que permet le managed compute de Foundry.

9. Quelles VM pour un grand entraînement distribué ?

La famille ND (ND_H100_v5, ND_H200_v5) : 8 GPU par VM, NVLink dans la VM et InfiniBand à 3,2 Tbit/s entre VM. Seules les tailles RDMA (un « r » dans le nom) ont InfiniBand. Prévoir le quota tôt, un stockage rapide pour les checkpoints et des tests NCCL.

10. Qu'est-ce qui fait exploser le coût d'un modèle fine-tuné ?

L'hébergement horaire, dû même sans appel, les réentraînements quand le modèle de base est retiré, et les évaluations répétées. L'entraînement lui-même est souvent le plus petit poste.

11. Comment éviter qu'un fine-tuning dégrade la sécurité ?

Données nettoyées et revues, data et model evaluation de Foundry, evaluators de sécurité et red teaming après fine-tuning, guardrails de l'application maintenus, approbation tracée avant la production.

12. Quand distiller ?

Quand un grand modèle fait bien une tâche étroite et répétitive : on génère des exemples avec lui, on fine-tune un petit modèle, on vérifie sur un jeu de test indépendant que l'écart de qualité est acceptable, puis on sert le petit modèle pour moins cher.

12. Fiche à retenir#

• Personnaliser par paliers : prompt → RAG → fine-tuning → continued pre-training → entraînement complet, chaque palier mesuré.
• Fine-tuning = comportement ; RAG = connaissances. Le fine-tuning ne remplace ni la récupération ni les guardrails.
• SFT (exemples), DPO (préférences), RFT (grader) ; LoRA et QLoRA pour réduire la mémoire.
• Choisir un modèle : critères éliminatoires, shortlist par leaderboards, décision par évaluation sur ses données.
• Training types : Standard (région), Data zone (US), Global (moins cher, sans résidence), Developer (préemptible).
• Deployment Developer : 24 h, sans frais horaires, pour évaluer.
• Modèle fine-tuné déployé = frais horaires même sans appel ; déploiement inactif 15 jours = supprimé.
• SFT / DPO facturés en jetons × epochs ; RFT au temps + graders ; pas de frais pour la file, les échecs, les data safety checks.
• Mémoire d'un fine-tuning complet : ~18 octets / paramètre + activations ; inférence bf16 : 2 octets / paramètre + cache KV.
• ND_H100_v5 : 8 × H100 80 Go ; ND_H200_v5 : 8 × H200 141 Go ; 3,2 Tbit/s InfiniBand par VM ; seules les tailles « r » ont RDMA.
• Quota GPU à 0 par défaut : le demander dès le cadrage ; quota managed compute séparé du quota de VM.
• Checkpoints sur Azure Managed Lustre + archive Blob ; Spot impose les checkpoints.
• Gouvernance : provenance, PII, licences, biais, red teaming après fine-tuning, approbation tracée.

Références#

Lues le 21/10/2026.

Microsoft Learn :

• Fine-tuning in Microsoft Foundry
• Manage fine-tuning costs in Microsoft Foundry
• Deploy fine-tuned models in Microsoft Foundry
• Customize a model with fine-tuning
• Reinforcement fine-tuning
• Safety evaluation for fine-tuning (preview)
• Generate synthetic data for fine-tuning (preview)
• Fine-tuning considerations
• Fine-tune models with Microsoft Foundry (classic)
• Azure OpenAI stored completions and distillation (retiré le 15/10/2026)
• Managed compute in Microsoft Foundry (preview)
• Model leaderboards in Microsoft Foundry portal (preview)
• Compare models using the model leaderboard (preview)
• Model migration process
• Distributed GPU training guide (SDK v2)
• Manage and increase quotas for Azure Machine Learning
• Manage and optimize Azure Machine Learning costs
• How to use open source foundation models curated by Azure Machine Learning
• ND-H100-v5 sizes series
• ND-H200-v5 size series
• 'ND' sub-family GPU accelerated VM size series
• 'NC' sub-family GPU accelerated VM size series
• ND GB200-v6 sizes series
• Tiered checkpoints for AI training with Azure Managed Lustre
• Implementation option for AI on Azure infrastructure
• Well-architected considerations for AI on Azure infrastructure
• What is Azure CycleCloud Workspace for Slurm?

Autres sources :

• Hugging Face Transformers : GPU memory usage
• Hugging Face PEFT
• Hu et al., 2021 : LoRA, Low-Rank Adaptation of Large Language Models
• Dettmers et al., 2023 : QLoRA, Efficient Finetuning of Quantized LLMs
• Rafailov et al., 2023 : Direct Preference Optimization