Architecture des LLM : Conception de systèmes pour l'IA en production
Exécuter un modèle est un problème d’infrastructure. Tirer de la valeur d’un modèle est un problème d’architecture.
La couche d’infrastructure — les temps d’exécution, le matériel, les points de terminaison API — détermine ce qui est possible. La couche d’architecture détermine ce qui se produit réellement pour une requête : quel modèle la traite, combien elle coûte, ce qui la valide et comment les échecs sont gérés.
La plupart des systèmes commencent avec un seul modèle et aucune architecture. C’est correct pour le prototypage. Cela devient un passif en production.
L’architecture des LLM couvre les décisions de conception qui transforment « un modèle que je peux appeler » en « un système sur lequel je peux compter ».
Où se situe l’architecture LLM dans la pile
L’architecture LLM se situe au milieu d’un modèle à trois couches :
| Couche | Ce qu’elle couvre | Domaine connexe |
|---|---|---|
| Modèles | Temps d’exécution, service, configuration GPU | Hébergement LLM · Performance LLM |
| Architecture | Routage, coût, garde-fous, orchestration | Vous êtes ici |
| Applications | Assistants IA, pipelines RAG, agents | Systèmes IA · RAG |
La couche d’architecture est souvent négligée au début. Elle devient essentielle lorsque vous avez plus d’un modèle, plus d’un type de tâche ou plus d’un utilisateur. Chaque modèle d’architecture de ce cluster existe parce que l’approche « un modèle pour tout » a cessé de fonctionner.
Carte du cluster
Les cinq sujets de ce cluster s’appuient les uns sur les autres. Lisez-les dans cet ordre pour suivre le chemin le plus logique :
- Vous êtes ici — ce pilier : ce qu’est l’architecture LLM, comment les pièces s’assemblent
- Prompts — Rédaction de prompts efficaces pour les LLM — la base : façonner ce que le modèle reçoit
- Routage — Stratégies de routage des modèles — le répartiteur : quel modèle traite quoi
- Coût — Optimisation des coûts pour les systèmes LLM — budgétisation des jetons, mise en cache, économie local vs API
- Sécurité — Garde-fous LLM en pratique — validation des entrées, filtrage des sorties, conformité
- Orchestration — Conception de systèmes multi-modèles — motifs séquentiels, parallèles, hiérarchiques et d’ensemble
Si vous n’avez le temps que d’un seul, commencez par le routage. C’est le point de décision où l’architecture commence.
Ingénierie des prompts
L’ingénierie des prompts est la couche la plus proche du modèle. Avant le routage, avant la mise en cache, avant les garde-fous — il y a le prompt. Ce que vous envoyez au modèle détermine ce que vous obtenez en retour.
Les techniques pratiques qui comptent :
- Clarté et structure — des instructions claires surpassent un cadrage astucieux
- Exemples spécifiques — les exemples « few-shot » ancrent le comportement du modèle
- Attribution de rôle — les prompts basés sur le rôle affinent le ton et les contraintes
- Approches variées — différents formats révèlent ce à quoi le modèle répond
- Gestion du contexte — ce que vous incluez façonne ce que le modèle pèse
L’ingénierie des prompts n’est pas une tâche ponctuelle. C’est une calibration continue entre les exigences de votre tâche et le comportement du modèle.
Approfondissement :
- Rédaction de prompts efficaces pour les LLM — techniques pratiques pour la performance des modèles de langage
Routage des modèles
Une couche de routage décide quel modèle traite quelle requête. Sans elle, chaque requête va vers le même modèle — souvent trop grand pour les tâches simples, trop petit pour les tâches complexes.
Quatre stratégies de routage couvrent la plupart des cas de production :
| Stratégie | Optimiser pour | Idéal quand |
|---|---|---|
| Basé sur les capacités | Qualité de la tâche | Charges de travail de complexité mixte |
| Sensible au coût | Dépense de jetons | Systèmes contraints par le budget |
| Sensible à la latence | Temps de réponse | Outils interactifs et chat en temps réel |
| Hybride | Les trois | Systèmes de production avec contraintes réelles |
Une chaîne de repli gère les échecs : ordonnez les modèles du meilleur au plus fiable, en terminant par un modèle local qui ne peut pas être limité par le taux ou arrêté par une panne d’API.
Approfondissement :
- Stratégies de routage des modèles : Local vs API, Sensible au coût, Sensible à la latence — routage basé sur les capacités, sensible au coût et sensible à la latence avec du code Python
Optimisation des coûts
Les coûts des LLM évoluent linéairement avec l’utilisation. Les stratégies qui réduisent réellement la facture :
La budgétisation des jetons fixe des limites par session, par tâche ou adaptatives. Les budgets adaptatifs suivent l’utilisation réelle et resserront les allocations au fil du temps.
L’inférence locale change entièrement la structure des coûts. Après l’amortissement du matériel, les modèles locaux fonctionnent au coût de l’électricité. Un GPU à une utilisation modérée rembourse son prix en quelques mois.
La mise en cache est l’optimisation la plus sous-estimée. La mise en cache de correspondance exacte attrape les prompts répétés. La mise en cache sémantique attrape les prompts qui signifient la même chose. Pour les systèmes à fort trafic, la mise en cache sémantique élimine une grande part des appels API avant qu’ils ne se produisent.
Les chaînes de repli réduisent le coût moyen par requête : privilégiez les modèles coûteux lorsque le budget le permet, passez aux modèles moins chers ou locaux au fur et à mesure de la session.
Approfondissement :
- Optimisation des coûts pour les systèmes LLM : Budgétisation des jetons, Modèles de repli, Mise en cache — chiffres matériels réels, tableaux de seuil de rentabilité et motifs Python fonctionnels
Garde-fous
Les LLM sont imprévisibles par défaut. Les garde-fous contraignent ce qui entre et ce qui sort — sans réduire la capacité du modèle.
Trois couches de garde-fous comptent en pratique :
La validation des entrées stoppe les problèmes avant qu’ils n’atteignent le modèle. La sanitisation des prompts attrape les tentatives d’injection. Les limites de longueur empêchent le gaspillage de jetons. Les filtres de contenu bloquent les violations de politique avant que l’inférence ne coûte quoi que ce soit.
Le filtrage des sorties attrape les problèmes après la génération. La validation structurelle assure les formes de réponse attendues. Les vérifications de contenu bloquent les sorties nuisibles. La vérification des faits (pour les domaines critiques) valide les affirmations contre une base de connaissances.
Les mécanismes de sécurité protègent le système sur le long terme : la limitation de débit empêche l’abus, les budgets de jetons plafonnent les coûts par requête, la gestion de la fenêtre de contexte empêche le débordement et la fuite de données entre les tours.
Pour les systèmes lourds en conformité (RGPD, HIPAA, SOC 2), ajoutez la journalisation d’audit avec des entrées structurées et en ajout uniquement, et des contrôles de résidence des données.
Approfondissement :
- Garde-fous LLM en pratique : Validation des entrées, Filtrage des sorties, Sécurité — motifs de garde-fous pratiques et notes de conformité
Conception de systèmes multi-modèles
Lorsqu’un seul modèle ne suffit pas, la question architecturale est : comment orchestrer plusieurs modèles sans créer une complexité qui coûte plus cher qu’elle ne sauve ?
Cinq motifs couvrent l’espace :
| Motif | Latence | Coût | Qualité | Utiliser quand |
|---|---|---|---|---|
| Modèle unique | La plus basse | Le plus bas | Variable | Prototypage, charges de travail uniformes |
| Séquentiel (Pipeline) | Élevée | Moyen | Élevée | Flux de travail en plusieurs étapes avec spécialisation |
| Parallèle (Fan-Out) | Basse | Élevée | Élevée | Tâches indépendantes, tests A/B |
| Hiérarchique (Planificateur-Exécuteur) | Élevée | Élevée | La plus élevée | Raisonnement complexe avec exécution spécialisée |
| Ensemble | Moyenne | La plus élevée | La plus élevée | Décisions critiques nécessitant un consensus |
La règle générale : commencez par le motif le plus simple qui gère vos contraintes réelles. La plupart des systèmes de production n’atteignent le parallèle ou l’hiérarchique que lorsque le routage basé sur les capacités seul n’est plus suffisant.
Approfondissement :
- Conception de systèmes multi-modèles : Quand utiliser quel modèle et pourquoi — les cinq motifs avec du code Python fonctionnel et des tableaux de compromis
Cadre de décision architecturale
Utilisez ceci comme un tri rapide pour savoir quoi ajouter et quand :
| Problème | Solution | Quand l’ajouter |
|---|---|---|
| La facture est trop élevée | Routage sensible au coût, mise en cache, inférence locale | Lorsque les coûts API deviennent une ligne budgétaire réelle |
| La latence est trop élevée | Routage sensible à la latence, modèles plus petits | Lorsque les utilisateurs remarquent la lenteur |
| La qualité est incohérente | Routage basé sur les capacités, chaîne de repli | Lorsque les tâches simples obtiennent des modèles coûteux ou les tâches complexes des modèles bon marché |
| Les utilisateurs abusent du système | Validation des entrées, limitation de débit | Lorsque vous ouvrez l’accès au-delà d’une équipe de confiance |
| Les réponses sont dangereuses ou hors politique | Filtrage des sorties, garde-fous de contenu | Lorsque vous servez des utilisateurs généraux |
| Un seul modèle gère tout | Conception multi-modèles | Lorsque les charges de travail divergent suffisamment pour justifier la complexité |
| Les prompts ne fonctionnent pas | Itération d’ingénierie des prompts | Toujours — les prompts nécessitent un ajustement au fur et à mesure que les tâches évoluent |
Construisez l’architecture du bas vers le haut. L’ingénierie des prompts est toujours en scope. Ajoutez le routage lorsque les compromis coût/qualité deviennent réels. Ajoutez les garde-fous lorsque vous servez des utilisateurs externes. Ajoutez l’orchestration multi-modèles en dernier.
Comment l’architecture LLM est liée aux autres sujets
L’architecture LLM se situe à l’intersection de plusieurs clusters connexes :
Infrastructure (en dessous de cette couche) :
- Hébergement LLM en 2026 : Infrastructure locale, auto-hébergée et cloud comparées — temps d’exécution (Ollama, llama.cpp, vLLM), matériel et décisions de service. Les motifs d’architecture dépendent de l’infrastructure disponible. Le routage sensible au coût n’a de sens que si vous avez des modèles locaux et API en cours d’exécution.
- Performance LLM en 2026 : Benchmarks, goulots d’étranglement et optimisation — chiffres de latence, limites VRAM, mesures de débit. Ce sont les entrées empiriques pour les décisions de routage et de sélection de modèles.
Couches d’application (au-dessus de cette couche) :
- Systèmes IA : Assistants auto-hébergés, RAG et infrastructure locale — les systèmes qui consomment les décisions de routage, de garde-fous et d’orchestration. L’architecture multi-modèles est un prérequis pour les assistants IA de production.
- Tutoriel sur la génération augmentée par la récupération (RAG) — le RAG est lui-même un motif architectural : un pipeline de récupération alimentant le contexte dans un LLM. Les motifs de routage, de coût et de garde-fous de ce cluster s’appliquent également à l’intérieur des pipelines RAG.
Couche opérationnelle :
- Observabilité : Surveillance, métriques, guide Prometheus et Grafana — l’architecture LLM de production a besoin d’observabilité. Le suivi des coûts, la surveillance de la latence et les métriques de violation des garde-fous nécessitent tous une instrumentation au niveau de l’architecture, pas seulement au niveau de l’infrastructure.
