2 Votre organisation a entraîné un grand modèle de langage ou en a obtenu un sous licence auprès d’un fournisseur. Vous vous préparez maintenant à le déployer en production pour servir les requêtes d’inférence d’applications, d’utilisateurs ou de systèmes internes. La phase d’entraînement était intensive en calcul, mais elle est terminée. La phase d’inférence est différente : elle est permanente, continue et incontournable. Votre infrastructure d’inférence LLM fonctionne sans interruption et sert des requêtes 24 h/24 et 7 j/7. Toute indisponibilité affecte directement votre activité et vos utilisateurs. Déployer une infrastructure d’inférence LLM impose de repenser la résilience en production. Les grands modèles de langage sont coûteux à servir en calcul : un seul GPU peut traiter des dizaines ou des centaines de requêtes par seconde, mais l’empreinte de stockage d’un modèle (poids, caches d’activation, index associés) se mesure en dizaines de gigaoctets, voire en téraoctets selon sa taille. Faire évoluer l’inférence exige à la fois des ressources de calcul et une architecture de stockage sophistiquée. Le stockage doit être assez performant pour fournir les poids du modèle et les données intermédiaires au rythme qui alimente les GPU. Il doit être assez fiable pour que toute dégradation de ses performances n’affecte l’inférence que de manière prévisible. Et il doit être assez sécurisé pour protéger les poids de vos modèles et rendre votre infrastructure d’inférence défendable. Envisagez une infrastructure de stockage pour l’IA agentique (en anglais) conçue spécifiquement pour ces charges. Cet article présente l’architecture de résilience, de sécurité et de reprise après sinistre qui sous-tend une infrastructure d’inférence LLM en production, et ce que les RSSI et les architectes d’infrastructure doivent prendre en compte pour concevoir des déploiements d’inférence à la fois performants et sûrs. L’architecture de stockage de l’inférence LLM : les modèles sont des données Les grands modèles de langage sont fondamentalement des données. Un modèle se compose de milliards, voire de milliers de milliards de paramètres : les poids qui constituent la représentation apprise du modèle. Au moment de l’inférence, ces poids doivent être accessibles avec de hautes performances. Un serveur d’inférence charge les poids en mémoire (généralement la mémoire GPU ou CPU), traite le prompt d’entrée et génère la réponse. Le temps de chargement des poids influe directement sur le délai d’obtention du premier token et sur la latence globale. Pour les grands modèles, le fichier de poids dépasse la mémoire d’un seul GPU. Cela crée des exigences d’architecture : il faut des stratégies pour répartir les modèles sur plusieurs GPU, précharger efficacement les poids ou les charger dynamiquement selon les besoins. Toutes ces stratégies dépendent du stockage, c’est-à-dire de la capacité à lire rapidement les poids depuis le stockage persistant pour les mettre à disposition des serveurs d’inférence. L’inférence génère par ailleurs des données intermédiaires. Les frameworks d’inférence maintiennent des caches d’activation, des vecteurs d’attention et des états de calcul intermédiaires. Certaines optimisations, comme le décodage spéculatif ou la mise en cache des préfixes, reposent sur des caches persistants qui accélèrent les requêtes suivantes. Toutes ces données doivent être stockées quelque part, et ce stockage doit être performant. Conséquence : votre infrastructure d’inférence n’est pas seulement une affaire de calcul, elle est aussi intensive en données. Votre architecture de stockage détermine directement la rapidité de chargement des modèles, le degré de parallélisation de l’inférence et l’efficacité avec laquelle vous pouvez augmenter la capacité. Une architecture de stockage inadaptée rend impossible le respect des exigences de latence et de débit de l’inférence en production. La sécurité des poids des modèles en production Les poids d’un modèle constituent une propriété intellectuelle. Pour les organisations qui ont investi des capitaux importants dans l’entraînement d’un modèle, les protéger contre le vol est essentiel. Pour celles qui utilisent un modèle sous licence, le contrat interdit généralement toute copie ou exposition non autorisée des poids. Pourtant, les poids doivent être accessibles en production : un serveur d’inférence doit pouvoir les charger, et quelqu’un doit les gérer (les versionner, les mettre à jour, revenir à une version antérieure si une nouvelle version dégrade les performances). Cela crée une surface d’attaque : partout où les poids sont accessibles, ils peuvent être exfiltrés. Votre architecture de sécurité doit protéger les poids des modèles tout au long du cycle de vie de l’inférence. Au repos, chiffrez-les avec des clés distinctes de l’infrastructure d’inférence : un attaquant qui compromet un serveur d’inférence ne peut pas les déchiffrer sans accès aux clés. Cela exige un service de gestion des clés distinct de votre infrastructure d’inférence, qui contrôle l’accès aux poids. En transit, chiffrez les poids lorsqu’ils circulent du stockage vers les serveurs d’inférence, généralement grâce au chiffrement TLS. Pour les modèles les plus sensibles, une authentification cryptographique des poids apporte une garantie supplémentaire qu’ils n’ont pas été modifiés pendant le transfert. Pendant l’inférence, les poids résident dans la mémoire GPU ou CPU. Cette menace est plus difficile à contrer : un attaquant disposant d’un accès administrateur à un serveur d’inférence peut techniquement extraire les poids de la mémoire. La défense exige que votre infrastructure d’inférence soit protégée avec la même rigueur que tout autre système de production sensible : isolation réseau, contrôles d’accès, journalisation d’audit et détection des menaces. Haute disponibilité et tolérance aux pannes Une infrastructure d’inférence LLM qui sert des charges de production ne peut pas se permettre d’indisponibilité. Contrairement au traitement par lots, où une panne entraîne simplement la relance d’une tâche, une indisponibilité de l’inférence affecte directement les utilisateurs. Concevoir pour la haute disponibilité signifie architecturer l’inférence pour la tolérance aux pannes à plusieurs niveaux. Au niveau des serveurs d’inférence, il faut de la redondance : plusieurs serveurs exécutant le même modèle, avec une répartition de charge entre eux. Si un serveur tombe, les requêtes sont redirigées vers les autres. Cela suppose des serveurs d’inférence sans état, afin qu’une requête puisse être routée vers n’importe quel serveur disponible sans perte d’état. Au niveau des modèles, il faut une gestion des versions et une capacité de retour arrière. Si une nouvelle version déployée dégrade les performances ou provoque des erreurs, vous devez pouvoir revenir rapidement à la version précédente. Les versions antérieures doivent donc rester disponibles, et votre infrastructure doit permettre de changer rapidement de modèle. Au niveau du stockage, il faut de la redondance et une restauration rapide. Les poids des modèles doivent être répliqués pour qu’une panne de stockage n’entraîne pas leur perte totale. La réplication doit être géographique lorsque c’est possible : des copies dans différents data centers ou zones de disponibilité protègent contre les pannes régionales. La restauration doit être suffisamment rapide pour que l’inférence reprenne sans enfreindre les SLA. Pour les modèles coûteux à servir, vous pouvez aussi mettre en place des stratégies de mise en cache : les réponses aux requêtes fréquentes sont conservées en cache, afin que les requêtes identiques ou similaires soient servies sans calcul d’inférence coûteux. L’invalidation du cache devient alors une exigence opérationnelle : lorsque les modèles sont mis à jour, les caches doivent être vidés ou gérés pour éviter de servir des réponses périmées. La reprise après sinistre de l’infrastructure d’inférence La reprise après sinistre de l’infrastructure d’inférence recouvre deux enjeux distincts : la restauration de l’infrastructure elle-même et celle des artefacts de modèles dont elle dépend. Bien comprendre la différence entre RTO et RPO (en anglais) devient essentiel pour planifier la restauration des déploiements à grande échelle. Restaurer l’infrastructure d’inférence est relativement simple : si votre déploiement principal est perdu, vous pouvez redéployer les serveurs d’inférence à partir d’images de conteneurs standard ou d’infrastructure-as-code et les faire pointer vers les poids de vos modèles. Si ces poids sont répliqués et accessibles, votre infrastructure peut être reconstruite en quelques minutes ou quelques heures. Le problème le plus difficile est la reprise des artefacts de modèles. Si la seule copie de votre modèle entraîné se trouve dans votre data center principal et que celui-ci subit une panne catastrophique, le modèle est perdu. Les modèles entraînés doivent donc être sauvegardés, avec des copies conservées sur un site distinct, idéalement dans une autre région géographique. Pour les modèles critiques, les copies de sauvegarde doivent être testées régulièrement pour vérifier qu’elles peuvent réellement être déployées et exécutées. Cela crée un besoin de stockage important : les modèles critiques exigent un stockage de sauvegarde. Si vos plus grands modèles pèsent plusieurs téraoctets, il vous faut des téraoctets de capacité de sauvegarde, synchronisée avec les modèles de production à mesure que de nouvelles versions sont entraînées. Pour les organisations qui disposent de nombreux modèles et itèrent rapidement, le stockage de sauvegarde peut devenir un poste important de dépenses d’exploitation et d’investissement. La reprise après sinistre par l’immuabilité et le versionnage Une stratégie efficace de reprise après sinistre pour l’inférence LLM consiste à mettre en place un versionnage immuable des modèles. Chaque fois qu’un modèle est entraîné ou mis à jour, il est stocké avec un identifiant de version immuable, et les versions précédentes sont conservées indéfiniment ou pendant une durée définie. Vous obtenez ainsi un référentiel d’artefacts où n’importe quelle version antérieure peut être restaurée ou redéployée. L’immuabilité empêche la suppression accidentelle ou malveillante des versions de modèles. Une fois une version enregistrée dans le référentiel, elle ne peut être ni modifiée ni supprimée sans autorisation explicite. La reprise après sinistre est ainsi toujours possible : il existe toujours une version saine et connue du modèle. Le versionnage permet aussi un retour arrière rapide. Si une nouvelle version déployée pose problème, vous pouvez rapidement faire revenir les serveurs d’inférence à une version précédente, bien plus vite qu’en réentraînant ou en reconstruisant un modèle. La contrepartie est le coût de stockage : conserver plusieurs versions de grands modèles consomme beaucoup d’espace. Les organisations le maîtrisent grâce à des politiques de conservation, par exemple garder les 10 dernières versions d’un modèle ou toutes les versions des 90 derniers jours. Ces politiques sont raisonnables en pratique et concilient besoins de reprise et coûts de stockage. Supervision, observabilité et détection des menaces Une infrastructure d’inférence LLM en production exige une supervision poussée. Vous devez suivre la latence et le débit d’inférence, les taux d’erreur, l’utilisation des GPU et les performances du stockage. Ces indicateurs montrent directement si votre infrastructure est en bonne santé et si les utilisateurs bénéficient d’une qualité de service acceptable. Au-delà de la supervision opérationnelle, il faut détecter les menaces. Les serveurs d’inférence sont des systèmes connectés au réseau qui peuvent être ciblés par des attaquants. Des schémas de trafic inhabituels, des tentatives d’élévation de privilèges ou une consommation de ressources inattendue peuvent signaler une attaque. Votre supervision de sécurité doit inclure une détection au niveau de l’infrastructure qui repère toute activité suspecte. Surveillez aussi les anomalies de comportement des modèles. Si la qualité de l’inférence se dégrade (le modèle produit des réponses incohérentes, ou la latence s’envole sans raison), cela peut signaler un problème dans l’infrastructure de service, ou une modification du modèle. Surveiller les réponses du modèle et les comparer à un comportement de référence permet de détecter certaines catégories d’attaques ou de problèmes d’infrastructure. Bâtir une infrastructure d’inférence sûre et résiliente Les organisations qui exploitent leur infrastructure d’inférence LLM de la manière la plus sûre et la plus fiable la traitent comme un système critique de production, avec la même rigueur que toute autre infrastructure sensible. Elles investissent dans une architecture de sécurité qui protège les poids des modèles, dans la redondance et la réplication pour la tolérance aux pannes, et dans une supervision et une planification de la reprise après sinistre qui garantissent la disponibilité de l’inférence. À mesure que la dépendance de votre organisation à l’inférence LLM augmente, les exigences opérationnelles et de sécurité de cette infrastructure prennent de l’importance. Investissez dans un stockage IA haute performance capable de fournir les performances qu’exige l’inférence. Mettez en place des contrôles de sécurité qui protègent les poids des modèles et l’infrastructure d’inférence. Planifiez les scénarios de reprise après sinistre et testez-les régulièrement. Le coût des défaillances de l’infrastructure d’inférence croît avec la dépendance de votre organisation. Bâtissez une infrastructure résiliente, sécurisée et conçue pour la production : cet investissement protège à la fois la propriété intellectuelle de vos modèles et votre capacité à servir vos utilisateurs de manière fiable. Pour aller plus loin Qu’est-ce que la haute disponibilité (HA) ? (en anglais) DRaaS : la reprise après sinistre en tant que service (en anglais) Le chiffrement des données : guide pour les responsables conformité et IT (en anglais) Le plan de continuité d’activité (en anglais) Stockage immuable et défense contre les ransomwares (en anglais) Préserver l’intégrité des données face aux pannes de disques (en anglais)
