Sommaire
Introduction
Un prototype fondé sur une API de modèle peut fonctionner dès le vendredi après-midi. Faire fonctionner la même fonction pour de vrais utilisateurs, à un coût prévisible et avec une qualité défendable, est un problème d’ingénierie des systèmes. L’essentiel du travail se situe autour du modèle : l’acheminement des requêtes, la récupération du contexte, l’évaluation des sorties et la destination de l’argent.
API hébergées ou modèles autohébergés
Les API de modèles hébergés offrent les modèles les plus puissants sans GPU à gérer, et vous payez au token. L’autohébergement de modèles à poids ouverts donne le contrôle sur la résidence des données, la latence et le coût unitaire à fort volume, en échange de la capacité GPU et des compétences pour l’exploiter. La plupart des équipes matures finissent avec les deux, derrière une seule passerelle, et orientent chaque usage vers le modèle le moins cher qui atteint le niveau de qualité voulu.
Les bases du service d’inférence
Deux mesures de latence comptent pour les utilisateurs : le temps jusqu’au premier token et la vitesse d’arrivée des suivants. Le débit, qui détermine le coût, dépend du nombre de requêtes qu’un GPU sert à la fois. Des moteurs comme vLLM, TensorRT-LLM et Hugging Face Text Generation Inference utilisent le traitement continu par lots pour occuper les GPU, ainsi qu’une gestion soignée du cache clé-valeur, qui limite généralement la concurrence. PagedAttention de vLLM, par exemple, alloue ce cache par pages pour réduire la mémoire gaspillée.
- Mettez à l’échelle selon la profondeur de file, les tokens en cours ou l’utilisation du GPU. L’usage du processeur ne dit presque rien d’un serveur d’inférence.
- La quantification en poids sur 8-bit ou 4-bit permet souvent de faire tenir un modèle sur des GPU plus petits ou moins nombreux, pour un coût de qualité modeste. Mesurez ce coût sur votre propre jeu d’évaluation avant de livrer.
- Gardez les modèles chargés. Charger des dizaines de gigaoctets de poids à froid peut prendre des minutes : la réduction à zéro n’a donc de sens que pour le traitement par lots.
Une recherche bien faite
La génération augmentée par la recherche appuie les réponses sur vos propres documents. La qualité dépend bien plus du pipeline de recherche que du modèle. Découpez les documents selon leur structure naturelle plutôt qu’en nombre fixe de caractères, combinez la recherche par mots-clés et la similarité vectorielle (recherche hybride) et ajoutez une étape de reclassement avant que le contexte n’atteigne le modèle. Une configuration pgvector bien réglée suffit à beaucoup d’équipes ; les bases vectorielles dédiées se justifient à plus grande échelle.
Appliquez les droits sur les documents au moment de la recherche. Si un utilisateur ne peut pas ouvrir un document directement, l’assistant ne doit pas non plus le lui citer. C’est la fuite de données la plus courante dans les outils d’IA internes, et la plus difficile à corriger après coup.
Placez une passerelle devant chaque modèle
Une passerelle de modèles est le point de contrôle qui rend tout le reste gérable. Elle gère l’authentification et les limites de débit, oriente les requêtes entre modèles et fournisseurs, bascule lorsqu’un fournisseur se dégrade, met en cache les prompts répétés, masque les données sensibles dans les journaux et attribue le coût à l’équipe et à la fonction concernées.
routes:
- name: support-summaries
primary: small-model
fallback: large-model
escalate_when: confidence < 0.7
max_output_tokens: 400
cache: semantic
daily_budget_usd: 150L’évaluation est le vrai produit
Sans boucle d’évaluation, chaque modification de prompt et chaque mise à niveau de modèle est un pari. Construisez un jeu d’évaluation à partir de trafic réel anonymisé et ajoutez-y sans cesse les échecs signalés par les utilisateurs. Combinez des contrôles automatiques (format, ancrage dans les sources récupérées, contenu interdit) et une relecture humaine régulière d’un échantillon. Exécutez la suite avant tout changement de modèle, de prompt ou de recherche en production, exactement comme des tests de régression pour le code.
Où va réellement l’argent
- GPU inactifs : une capacité réservée dimensionnée pour le pic et utilisée à une fraction la majeure partie de la journée.
- Contexte surdimensionné : des documents entiers insérés dans chaque prompt au lieu de récupérer les bons passages.
- Boucles d’agents : des agents à plusieurs étapes qui appellent le modèle de nombreuses fois par tâche, souvent pour rattraper leurs propres erreurs.
- Tarif interactif pour les traitements par lots : résumés, classification et enrichissement qui pourraient tourner la nuit sur une capacité réduite ou préemptible.
Conclusion
Traitez les fonctions d’IA comme tout autre système de production, avec des SLO de latence et de disponibilité, des budgets et des alertes de dépense, et un modèle de menaces couvrant l’injection de prompt et l’exposition des données. Les équipes qui le font livrent plus vite, car elles peuvent changer de modèles et de prompts avec confiance plutôt qu’avec crainte.
- Infrastructure IA
- LLM
- Inférence
- RAG
- FinOps