LLMs en production : 5 patterns d'architecture

LLM en production : 5 patterns d'architecture

Mettre un LLM en production ne se résume pas à appeler une API OpenAI depuis votre backend. Dès que la charge monte, que les coûts s'envolent, que la latence devient critique ou que la fiabilité est exigée contractuellement, les architectures naïves s'effondrent. Voici cinq patterns observés sur des systèmes LLM production-grade.

Pattern 1 — Proxy simple

Contexte : équipe qui commence, volume faible, besoin de centraliser les appels.

Le proxy simple s'intercale entre vos applications et les APIs LLM. Il centralise la gestion des clés, le rate limiting, le logging et l'observabilité. C'est le pattern d'entrée — presque toujours le bon point de départ.

Application → LLM Proxy → OpenAI / Anthropic / Mistral
                ↓
           Logs, metrics, budget alerts

Outils : LiteLLM, Portkey, ou un proxy maison en une centaine de lignes. Le proxy expose une interface OpenAI-compatible, ce qui rend la migration vers d'autres providers transparente.

Tradeoffs : ajoute un hop réseau (10-30ms). Doit être hautement disponible — c'est un single point of failure si mal conçu.

Pattern 2 — Cache sémantique

Contexte : workloads avec requêtes redondantes (FAQ, support client, recherche documentaire).

Le cache sémantique stocke les réponses aux requêtes et les compare par similarité vectorielle plutôt que par égalité exacte. Une requête proche d'une requête précédemment traitée retourne la réponse en cache sans appel LLM.

async def query_with_cache(prompt: str, threshold: float = 0.92):
    embedding = await embed(prompt)
    cached = await vector_store.similarity_search(embedding, top_k=1)
 
    if cached and cached[0].score >= threshold:
        return cached[0].response  # ~5ms au lieu de ~800ms
 
    response = await llm.complete(prompt)
    await vector_store.upsert(embedding, prompt, response)
    return response

Gains observés : 30 à 60% de réduction de coût sur des workloads FAQ en production. La latence perçue chute de façon spectaculaire.

Tradeoffs : le seuil de similarité est critique. Trop bas : réponses incorrectes retournées. Trop haut : cache peu efficace. Nécessite une stratégie d'invalidation pour les domaines à données changeantes.

Pattern 3 — Routeur multi-modèle avec fallback

Contexte : optimisation coût/performance, résilience aux pannes de providers.

Toutes les requêtes ne nécessitent pas GPT-4. Un routeur classe la complexité de la requête et dispatch vers le modèle approprié : modèles locaux ou petits pour les tâches simples, grands modèles pour le raisonnement complexe.

Requête → Classifier de complexité
              ├── Simple (~80%) → petit modèle local
              │                   (pas de coût marginal API, mais coût infra non nul)
              ├── Moyenne (~15%) → modèle généraliste intermédiaire
              └── Complexe (~5%) → grand modèle frontier
                                     ↓ (fallback si timeout)
                                  modèle frontier alternatif

Exemple de stack (snapshot janvier 2025) : Mistral 7B / Llama 3.1 8B en local, GPT-4o-mini ou Haiku pour l'intermédiaire, GPT-4o ou Claude Opus pour le frontier. Les prix et les modèles évoluent vite — les classes restent stables, les noms non.

Tradeoffs : le classifier lui-même consomme des ressources. La définition de "complexité" est souvent empirique et demande de l'ajustement. Le fallback doit être testé régulièrement.

Pattern 4 — Couche d'augmentation RAG

Contexte : domaines où le LLM n'a pas la connaissance nécessaire (documentation interne, données récentes, corpus propriétaires).

Ce pattern isole la couche de retrieval comme un service indépendant. Le LLM devient un moteur de raisonnement sur des faits fournis dynamiquement, pas une source de vérité autonome.

L'architecture en couches permet de mettre à jour le corpus de connaissances sans re-déployer le LLM, de tracer précisément les sources de chaque réponse, et d'auditer les hallucinations.

Tradeoffs : ajoute 200-400ms de latence pour le retrieval. La qualité de la réponse est fortement corrélée à la qualité de l'index.

Pattern 5 — Agent avec outils

Contexte : tâches nécessitant des actions dans le monde réel (recherche web, exécution de code, appels API, manipulation de fichiers).

L'agent LLM décide lui-même quels outils appeler, dans quel ordre, en itérant jusqu'à satisfaire l'objectif. C'est le pattern le plus puissant et le plus risqué.

Les gardes-fous non négociables :

• Confirmation humaine pour toute action irréversible
• Sandbox d'exécution pour le code généré
• Timeout et budget de tokens/appels par session
• Audit log de chaque outil appelé avec ses paramètres

Tradeoffs : latence imprévisible (1 à N appels LLM), coût difficile à borner, comportements émergents difficiles à tester exhaustivement.

Ces cinq patterns ne sont pas mutuellement exclusifs. Un système mature combine souvent le proxy (observabilité), le cache sémantique (coût), le routeur (optimisation), et le RAG (connaissance). Les agents sont réservés aux flux où l'autonomie apporte une valeur métier irremplaçable.