Les pièges de la mise en production d'un LLM sur site

Huit erreurs qui se paient cher en exploitation, et la mesure qui évite chacune, tirées de retours de terrain et non de la théorie.

Par QDNA · Publié le 5 juillet 2026 · 9 min de lecture

1. Les images qui changent sous vos pieds

Les étiquettes du type nightly ou latest changent de contenu sans prévenir, ce qui impose de figer chaque image par son empreinte. Le déploiement redevient alors reproductible, et une mise à jour silencieuse ne peut plus casser la plateforme.

2. Le cache de compilation corrompu

Au premier démarrage, le moteur compile des routines adaptées au matériel, et interrompre un conteneur pendant cette compilation corrompt le cache en provoquant des blocages en cascade. Ne tuez donc jamais un service pendant sa compilation initiale.

3. Le montage supposé plutôt que réel

Le montage déclaré d'un volume ne correspond pas toujours au montage effectif dans le conteneur, ce qui impose de vérifier le montage réel à l'intérieur du service plutôt que la déclaration. Un cache de modèle qui n'est pas persistant impose un nouveau téléchargement à chaque redémarrage.

4. Les optimisations activées par défaut

Certaines optimisations promettent des gains et livrent souvent une perte nette selon le modèle et la charge, ce qui impose de les tester sur mesure au lieu de les activer par défaut. La bonne configuration se mesure, elle ne se suppose pas.

5. Les caches clients non invalidés

Après un changement de configuration du serveur, notamment de longueur de contexte, invalidez les caches des clients, faute de quoi les applications continuent d'envoyer des requêtes calibrées sur l'ancienne configuration.

6. L'interconnexion non validée

Sur un serveur multi-cartes, la parallélisation échange des données entre cartes à chaque token généré, et une interconnexion mal détectée provoque un repli silencieux avec un débit divisé. On la valide donc une fois, proprement, avant tout déploiement.

7. Les mesures de débit trompeuses

Les mesures d'inférence sont bruitées, avec des écarts importants sur des fenêtres courtes, et le protocole fiable qui les dompte tient en quatre règles.

• Activer la génération complète pour rendre les longueurs comparables.
• Répéter au moins trois fois et retenir la médiane.
• Ne jamais mesurer à froid, car les premiers lots compilent des routines.
• Varier les prompts, sans quoi on mesure le cache et non le calcul réel.

Un rapport de référence chiffré, établi une fois proprement, devient la base de comparaison de toutes les évolutions futures.

8. Les flux réseau et la donnée non maîtrisés

Un service d'inférence ouvert sur le réseau sans politique explicite laisse fuir la donnée, et trois briques ouvertes ferment cette porte au niveau du noyau. Cilium applique une micro-segmentation par identité plutôt que par adresse, de la couche réseau à la couche applicative, Hubble rend visible chaque flux autorisé ou bloqué, et Tetragon arrête un processus non autorisé avant son exécution et journalise toute tentative de sortie. La règle par défaut refuse tout, puis ouvre les seuls flux nécessaires, sans oublier la résolution de noms.

Sur la donnée, un masqueur ouvert détecte et masque les informations personnelles avant transmission, par expression régulière et reconnaissance d'entités. L'injection de prompt reste la première vulnérabilité des applications à modèle de langage, et sa forme indirecte, cachée dans un document ou une page, vise les agents autonomes. Un filtrage des entrées et un test de confidentialité du prompt système ferment ce vecteur. La télémétrie demeure souveraine : les métriques et les journaux de toute la pile se collectent sur site, sur une infrastructure hébergée en Europe, sans dépendance externe.

Sources : la documentation de vLLM pour les options de service et le cache de compilation, le catalogue NVIDIA NGC pour le versionnement des images de conteneur, et les recommandations de sécurité de l'ANSSI.