IA, agents et inférence sur plateforme télécom

Plan de contrôle, nœuds, scheduler, API. Base pour comprendre comment on place des charges d'IA gourmandes sur un cluster.

Les objets qui portent un serveur d'inférence (Deployment), un entraînement ou un traitement par lots (Job) et une base vectorielle (StatefulSet).

Collecte de métriques et alertes. Les serveurs d'inférence exposent leurs métriques au format Prometheus : latence, débit, file d'attente.

Jetons, transformeurs, fenêtre de contexte, génération. Il faut comprendre ces notions pour dimensionner et diagnostiquer, pas pour entraîner un modèle.

Choisir un modèle ouvert, lire sa licence, vérifier sa provenance et son empreinte. « Poids ouverts » n'est pas toujours « open source » au sens strict.

Réduire la précision (8 ou 4 bits) pour tenir sur moins de mémoire GPU, au prix d'une qualité parfois dégradée. Formats courants : safetensors, GGUF.

Faire tourner un modèle sur un poste ou un petit serveur pour apprendre et prototyper, avant de passer à une plateforme partagée.

Serveur d'inférence open source à fort débit (batching continu, cache de clés-valeurs paginé, API compatible OpenAI). Réglages clés : mémoire GPU, longueur de contexte, parallélisme.

Déclarer un service d'inférence comme ressource Kubernetes : versions, montée en charge, déploiements progressifs.

Séparer le traitement du prompt et la génération, router selon le cache et la charge. Approche récente : suivre l'état du projet avant de l'adopter en production.

Latence du premier jeton, débit, concurrence, coût par million de jetons. Sans mesure, aucun dimensionnement GPU n'est défendable.

Exposer les GPU aux pods : pilotes, plugin de périphérique, découverte des nœuds, supervision. Un opérateur évite d'installer tout cela à la main sur chaque nœud.

Un GPU entier par pod coûte cher. Partitionnement matériel (MIG), temps partagé et allocation dynamique de ressources (DRA) permettent de mutualiser, avec des compromis d'isolation.

Quotas, priorités et équité entre équipes pour des GPU rares. Évite qu'une équipe monopolise la capacité.

L'inférence répartie sur plusieurs nœuds est limitée par le réseau. On retrouve ici les techniques de la plateforme télécom : SR-IOV, interfaces secondaires, RDMA.

Un agent est un modèle qui choisit des actions, appelle des outils et observe le résultat en boucle. Comprendre où il peut se tromper avant de lui donner des droits.

Protocole ouvert pour connecter un agent à des outils et des données : serveurs MCP, authentification, périmètre des droits.

Protocole ouvert pour que des agents de fournisseurs différents se découvrent et collaborent. Utile dans un environnement multi-éditeurs.

Orchestrer plusieurs étapes avec état et reprise : graphes d'exécution, agents qui écrivent du code. Choisir un cadre pour sa maturité et sa sobriété.

Lecture seule par défaut, validation humaine avant toute action sur la production, journal complet des actions. Indispensable en exploitation télécom.

Découper des documents, calculer des vecteurs, retrouver les passages utiles et les fournir au modèle. Applicable aux runbooks et aux spécifications 3GPP.

Stocker et interroger des vecteurs. pgvector convient quand PostgreSQL est déjà là ; une base dédiée se justifie à grande échelle.

Mesurer la pertinence des passages retrouvés et la fidélité des réponses. Sans jeu de test, on ne sait pas si une modification améliore ou dégrade.

Un point d'entrée unique : authentification, quotas par équipe, bascule entre modèles, journalisation. Évite que chaque application parle directement aux serveurs.

Traces des appels, jetons consommés, latence, erreurs. Les conventions OpenTelemetry pour l'IA générative rendent ces mesures comparables entre outils.

Rejouer un jeu de tests à chaque changement de modèle, de prompt ou de quantification pour détecter les régressions.

Les GPU dominent la facture et la consommation. Mesurer le coût par requête, choisir le plus petit modèle suffisant, éteindre ce qui ne sert pas.

Injection de prompt, fuite de données, outils trop permissifs, modèles ou dépendances piégés. Les agents multiplient la surface d'attaque.

Un modèle téléchargé est un artefact comme un autre : provenance, signature, analyse. Éviter les formats qui exécutent du code au chargement.

Recommandations françaises pour sécuriser un système d'IA générative, de l'entraînement au déploiement.

Niveaux de risque, obligations des fournisseurs et des déployeurs, calendrier d'application. À relier aux obligations NIS 2 et RGPD.

Où tournent le modèle et les données, qui y accède, quelles lois extraterritoriales s'appliquent. Argument majeur en faveur de modèles ouverts hébergés en France.

Prévision de charge, détection d'anomalies, assistance à l'exploitation, réseaux autonomes. Distinguer l'IA prédictive classique de l'IA générative.

Fonction normalisée du cœur 5G qui collecte des données réseau et fournit des analyses aux autres fonctions (charge, mobilité, expérience de service).

Des outils open source interrogent le cluster et expliquent un incident à partir des événements, journaux et métriques. Gain réel en diagnostic, à condition de vérifier les conclusions.

Projet type : un agent en lecture seule retrouve le runbook adapté, résume l'incident et propose des actions que l'humain valide. Mesurer le temps gagné et les erreurs évitées.

API ouvertes d'accès aux capacités du réseau (localisation, qualité de service, vérification de numéro). Un agent peut les utiliser comme outils, avec le consentement de l'abonné.

Placer de petits modèles quantifiés près de l'utilisateur pour la latence et la souveraineté des données, sur des sites aux ressources limitées.