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. Des retours de terrain, pas 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. Figez chaque image par son empreinte. Le déploiement redevient 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. Interrompre un conteneur pendant cette compilation corrompt le cache et provoque des blocages en cascade. Ne tuez 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. Vérifiez le montage réel, à l'intérieur du service, pas 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. À tester sur mesure, jamais à 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. Sinon, 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 jeton généré. Une interconnexion mal détectée provoque un repli silencieux et un débit divisé. On la valide 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. Le protocole fiable 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. 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é. 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.