Calcul et provisionnement
Acquisition de capacité GPU, pools de nœuds, pilotes et piles CUDA maintenus compatibles avec le moteur de service.
Guide de l’inférence IA
Infrastructure et exploitation
Tout ce qui entoure le modèle et le maintient en service : les composants de la plateforme, la discipline opérationnelle pour livrer sans risque les changements de modèle, la montée en charge sous un trafic en rafales, l’exécution à travers plusieurs régions et plusieurs clouds, et la composition de plusieurs modèles en un seul produit.
Ce que recouvre une infrastructure d’inférence
Couche de service
Le moteur d’inférence plus une passerelle en amont : authentification, quotas, routage, bascule entre backends.
Orchestration et montée en charge
Placement des modèles sur le matériel, politiques d’autoscaling, allocation dynamique entre charges de travail.
Versionnage et registre
Quel modèle, quels poids, quel prompt et quelle configuration sont en service et où ; savoir répondre à cette question est un prérequis à tout changement sûr.
Sécurité
Contrôle d’accès sur l’invocation et sur les artefacts de modèle, protection des prompts et des sorties, audit de qui a changé quoi.
Maîtrise des coûts
Coût de service par charge de travail et par fonctionnalité ; les leviers sont le choix du modèle, l’adéquation du matériel, le batching, le routage et la politique de montée en charge.
InferenceOps : livrer sans risque les changements de modèle
La pratique opérationnelle qui consiste à traiter les déploiements de modèles avec la même rigueur que les déploiements de code, adaptée à des artefacts dont les défaillances sont comportementales et pas seulement des plantages :
- Pipeline de livraison : des workflows de déploiement normalisés avec une validation avant livraison (suites de non-régression qualité, contrôles de latence et de débit de jetons) avant l’arrivée du trafic.
- Déploiement progressif : des livraisons canary ou blue-green qui comparent la version candidate à la version en service sur du trafic réel, avec un rollback automatique branché sur cette comparaison.
- Tolérance aux pannes : des réessais encadrés par un budget, des délais d’expiration, des disjoncteurs et du délestage de charge, pour qu’un modèle ou un fournisseur dégradé ne provoque pas de cascade.
- Gouvernance : un registre avec l’état du cycle de vie, la propriété, les journaux d’audit et les métadonnées de conformité ; une traçabilité du déploiement qui remonte de la requête à la version du modèle.
- Hygiène des coûts : détection des GPU inactifs et revue du taux d’utilisation ; la capacité réservée mais inutilisée est la façon la plus discrète de brûler du budget.
Montée en charge rapide et problème du cold start
Le trafic d’inférence arrive en rafales, et la minute de GPU coûte cher dans les deux sens : surprovisionner gaspille de l’argent, sous-provisionner fait tomber des requêtes. La montée en charge élastique pour les LLM est plus difficile que l’autoscaling classique, pour deux raisons :
Les cold starts sont longs
Un nouveau réplica paie trois factures successives : le provisionnement d’une instance GPU, le téléchargement d’une grosse image de conteneur, et le chargement de dizaines de gigaoctets de poids depuis le stockage vers la mémoire GPU. Les parades s’attaquent à chaque étape : pools préchauffés, mise en cache et allègement des images, poids sur du stockage local rapide ou transférés en parallèle. Le scale-to-zero économise le coût d’inactivité mais fait porter tout le cold start à la première requête ; à trancher charge par charge.
Les signaux évidents induisent en erreur
Le taux d’utilisation CPU dit peu de chose d’un service limité par le GPU, et le taux d’utilisation GPU rapporté peut sembler élevé alors que la puce fait peu de travail utile. Pilotez plutôt la montée en charge sur des signaux côté demande : profondeur de file, concurrence en cours et débit de requêtes, corrélés aux tailles de lot que le moteur atteint réellement.
Distribué, multi-région, multi-cloud
- L’inférence distribuée se joue à deux échelles : le partitionnement d’un modèle entre GPU et nœuds (parallélisme de tenseurs, de pipeline et d’experts, traité dans optimisation du service), et la répartition d’une flotte de réplicas entre zones et clusters, avec un ordonnancement conscient de l’état, des sondes de santé et une reprise sur panne.
- Pourquoi les équipes passent en multi-région ou multi-cloud : la pénurie de GPU et les écarts de prix entre fournisseurs et régions, la latence pour l’utilisateur, la bascule en cas de panne, le droit sur la localisation des données (des contraintes de type GDPR ancrent certaines données à une juridiction) et l’évitement de la dépendance à un fournisseur.
- Ce que cela demande : répliquer les artefacts de modèle près de chaque site de service, un équilibrage de charge global au routage conscient de la capacité et de la conformité, une bascule automatisée, et une observabilité unifiée avec attribution des coûts par site.
- La facture : le trafic inter-régions paie une latence bien réelle et des frais de sortie, et chaque cloud supplémentaire multiplie la surface d’exploitation. Concentrez par défaut ; ne distribuez que pour une raison nommée.
Pipelines multi-modèles
Une fonctionnalité en production repose rarement sur un seul modèle. Une réponse augmentée par la recherche documentaire enchaîne un modèle de plongements, un moteur de recherche, souvent un reclasseur, un générateur et des contrôles de sûreté ; l’IA documentaire enchaîne OCR, analyse de mise en page, classification et résumé ; les assistants multimodaux ajoutent un encodeur par modalité. Composer des spécialistes l’emporte sur un modèle monolithique unique lorsque les étapes ont des besoins de capacité différents, des optima matériels différents et des comportements de montée en charge différents.
- Topologies : étapes séquentielles, éclatement parallèle avec fusion, et routage conditionnel entre elles.
- Dimensionnez et placez chaque étape indépendamment ; un petit classifieur n’a pas besoin de la classe de GPU du générateur.
- Répartissez explicitement un budget de latence sur tout le graphe et gardez stables les interfaces entre étapes ; les modes de défaillance de chaque étape doivent être observables, sans quoi le diagnostic se réduit à des conjectures.
- À distinguer du parallélisme de pipeline (un modèle découpé en étages) et des boucles agentiques (flot de contrôle dynamique piloté par le modèle) ; le graphe d’un pipeline est fixé par l’application.
Faire ou acheter, chiffré honnêtement
Une infrastructure d’inférence auto-gérée porte des coûts qui apparaissent rarement dans la première estimation : l’approvisionnement en GPU sur un marché sous tension, l’autoscaling et le contrôle de concurrence construits et réglés à la main, des fonctionnalités d’optimisation (prefix caching, désagrégation) que les plateformes intègrent mais qu’une pile maison doit implémenter, une observabilité qui comprend le GPU, et un tapis roulant de dépendances où les versions du moteur, du framework et des pilotes doivent avancer de concert. Ajoutez la glu applicative (pré et post-traitement, connecteurs, comportement de streaming et de cache propre à chaque modèle) et les profils rares et coûteux capables de faire tourner l’ensemble. Pesez ce coût d’ingénierie récurrent face aux frais de plateforme et au coût d’opportunité de ce que l’équipe ne construit pas ; la bonne réponse dépend de l’échelle, et il faut la réexaminer à mesure que le volume croît.