Échantillonnage
temperature, top_p, top_k et éventuellement une seed. Une température basse convient à l’extraction, à la classification et au code ; des valeurs plus élevées conviennent à l’idéation et au texte créatif.
Guide de l’inférence IA
Interaction avec le modèle et API
Le contrat entre l’application et le modèle : comment les requêtes sont formées, comment les sorties sont contraintes vers une forme exploitable par une machine, comment les modèles appellent des outils, et les surfaces d’API qui gardent l’ensemble portable.
Anatomie d’une requête
- Messages et rôles : un message système fixe les instructions permanentes, les messages utilisateur portent l’entrée, les messages assistant portent les tours précédents du modèle. Le modèle voit toute la liste soumise, pas seulement la dernière question.
- Gabarits et préamorçage : les applications assemblent les prompts à partir de gabarits à emplacements dynamiques ; préamorcer le début du tour de l’assistant oriente le format et le ton.
- Gestion du contexte : la fenêtre est finie, donc les longues conversations sont tronquées ou résumées. Ce que vous supprimez change la réponse : rendez cette politique délibérée.
- Impact sur le service : la structure du prompt est une décision de performance. Placer le contenu stable (prompt système, exemples) en tête et le contenu volatil en fin est ce qui rend le prefix caching efficace ; voir optimisation du service.
La technique de prompting elle-même (zero-shot, exemples few-shot, chaîne de pensée, cadrage par rôle) est traitée sous forme de catalogue de patterns dans patterns.
Paramètres d’inférence
Chaque requête porte des réglages qui remodèlent la distribution de sortie et le contrat de sortie :
Longueur et arrêt
max_tokens plafonne la génération et la dépense ; les séquences d’arrêt la terminent plus tôt. Les deux changent les résultats, pas seulement le coût.
Mise en forme et introspection
Pénalités de répétition, de présence et de fréquence ; logit_bias pour favoriser ou interdire des jetons ; logprobs pour des signaux de confiance ; n ou best_of pour plusieurs candidats.
La prise en charge des paramètres et leur sémantique exacte varient selon le fournisseur et le runtime. La façon dont ces réglages interagissent avec la reproductibilité est traitée en détail dans non-déterminisme.
Sorties structurées
Les pipelines ont besoin de JSON, pas de prose. Deux familles de techniques y mènent :
Valider et réessayer
Analyser la réponse au regard d’un schéma et relancer le prompt en cas d’échec (le pattern Instructor). Fonctionne avec n’importe quelle API, y compris hébergée, mais chaque tentative ratée coûte de la latence et des jetons.
Décodage contraint
Masquer les jetons invalides à chaque étape pour que seule une sortie conforme au schéma puisse être produite (Outlines, XGrammar, Guidance ; intégré à vLLM et SGLang, et exposé sous forme de modes JSON-schema par les fournisseurs hébergés). Garantit la forme, même si une réponse syntaxiquement valide peut rester sémantiquement fausse.
Un simple « mode JSON » sans schéma ne promet qu’un JSON analysable, pas votre JSON ; préférez l’application d’un schéma doublée d’une validation des valeurs au niveau applicatif.
Function calling et MCP
Function calling
Vous décrivez les outils disponibles (nom, objectif, schéma de paramètres) ; le modèle émet un appel structuré au lieu de prose ; votre code l’exécute et renvoie le résultat sous forme de nouveau message ; le modèle poursuit avec de vraies données. C’est de la prédiction du jeton suivant produisant un format contraint : la qualité du schéma et des descriptions d’outils gouverne donc la fiabilité. Enveloppé dans une boucle planifier-exécuter-évaluer, c’est le mécanisme qui sous-tend les agents ; voir patterns agentiques. La prise en charge et la qualité varient d’un modèle ouvert à l’autre : vérifiez avec votre runtime.
Model Context Protocol
MCP normalise la façon dont les assistants atteignent des systèmes externes : une application hôte exécute des clients MCP qui se connectent à des serveurs MCP, chacun exposant des outils, des ressources de données et des prompts via un protocole commun, en local ou à distance. Au lieu d’intégrations sur mesure par application et par service, chaque côté du protocole ne s’écrit qu’une fois. Plusieurs serveurs peuvent être rattachés simultanément à un même hôte.
Surfaces d’API compatibles
Les moteurs auto-hébergés et les passerelles imitent les API HTTP des grands fournisseurs pour que les SDK existants fonctionnent en ne changeant que l’URL de base. C’est ce qui garde les applications portables entre backends hébergés et auto-hébergés.
Compatible OpenAI
- Endpoints de chat completions et de liste de modèles ; streaming via un drapeau stream
- Le standard de fait : vLLM, SGLang et la plupart des passerelles le servent
- Pointez le SDK officiel vers votre endpoint en remplaçant l’URL de base ; la clé d’API n’est souvent qu’un espace réservé pour les serveurs auto-hébergés
Compatible Anthropic
- Endpoint de type Messages ; authentification via x-api-key et un en-tête anthropic-version
- Le prompt système est un champ de premier niveau, l’usage d’outils arrive sous forme de blocs de contenu typés
- Les fonctionnalités avancées (prompt caching, extended thinking, entrées image et document) ne sont que partiellement reproduites par les backends ouverts
La compatibilité est un dégradé, pas une garantie : la couverture des paramètres et le support des fonctionnalités diffèrent selon le backend, donc testez les fonctionnalités dont vous dépendez avant de changer d’endpoint.