Infrastructure AI et pools GPU

(Section : Technologie et infrastructure)

Résumé succinct

La production-AI n'est pas un « modèle sur un seul serveur », mais un cluster de nœuds GPU, de pools d'accélérateurs partagés, de serving unifié, de données/fiches, d'observation et de gestion des coûts. Pour iGaming, c'est critique en temps réel : antifrod, personnalisation, chatbots, assistants LLM, recommandations de jeux/promotions. Briques de base : Kubernetes/Slurm pour la planification, isolation des charges de travail, réseau à grande vitesse (100/200/400G avec RDMA), stockage rapide, MLOps mature, et SLO « en béton armé ».

1) Carte architecturale

1. Cluster de calcul : Nodes GPU (classes A/H, AMD/ROCm, Intel Gaudi, etc.), noeuds CPU pour préprocesseurs/fiches.

2. Réseau : 100G + Ethernet/IB, RDMA (RoCEv2), topologie NCCL, QoS.

3. Stockage : Objet (S3.) distribuée par POSIX (Ceph/grid), local NVMe-scratch.

4. Données/fiches : fichestor (online/offline), bases de données vectorielles (ANN), cache (Redis), files d'attente.

5. Plate-forme ML : registre des artefacts et modèles, piplines (CI/CD), contrôle des versions, fiches comme code.

6. Couche de service : Triton/KServe/vLLM/text-generation-inference (TGI), A/B/canari-deploy, autoprésence.

7. Howernance et sécurité : PII, secrets, audit, politiques d'exportation, licences de balances/datacets.

• Scoring en ligne (p95 ≤ 50-150 ms) - antifrod, recommandations, classement.
• LLM-serving (p95 ≤ 200-800 ms pour 128-512 tokens) - chat/agents/conseils.
• Analyse/enseignement par lots - fenêtres de nuit, métriques hors ligne.
• Faintuning/adaptation - périodiquement, avec la priorité ci-dessous en ligne.

2) GPU pools et planification

Modèle de pools

Pool « Serving » : demandes courtes, haute batch, SLO stricte.
Pool « Training/Faintuning » : jobs longs, entraînement distribué (DDP).
Pool « R & D/Expérimentation » : quotas/limites, préemption autorisée.
Pool « CPU/Pre-/Post-processing » : normalisation, tokenization, rerank sur le CPU.

Planificateurs

Kubernetes (+ device-plugin, NodeFeatureDiscovery, taints/tolerations, PriorityClass, PodPriority/Preemption).
Slurm (souvent pour la formation HPC) - peut être mélangé avec des K8s via des workers individuels.
Fair share et quotas : quotas namespace par GPU, CPU, mémoire ; « banques » de montres GPU ; limites pour le projet/niymspace.

Lot GPU

MIG (Multi-Instance GPU) : découpe de l'accélérateur en diapositives isolées (pour le serving/multi-tenance).
MPS : boule SM pour les petites tâches (surveiller l'interférence).
NVLink/PCIe : prendre en compte la topologie lors du pinning des pods (Topology Aware Scheduling).

yaml apiVersion: v1 kind: Pod metadata:
annotations:
scheduling. k8s. io/group-name: "ai-serving"
spec:
nodeSelector: { gpu-pool: serving }
tolerations: [{ key: "gpu", operator: "Exists", effect: "NoSchedule" }]
priorityClassName: ai-serving-critical

3) Performance réseau et inter-nœuds

RDMA (RoCEv2) pour les NCCL-all-reduces ; Paramètres ECN/PFC, isolation des classes de trafic.
Localisation : formation à l'intérieur d'une « usine » (pod/host/optique), serving - plus proche de l'utilisateur (edge/région).
Contrôle congest : profils tunés, frames jumbo, interfaces pin-ning.

4) Stockage et données

Stockage des échelles/artefacts : objet (versioning, immutabilité).
Datacets/fiches : Lakehouse (Delta/Iceberg/Hudi) + offline-fichestor ; fichestor en ligne (SLA millisecondes).
OBD vectorielle (ANN) : Faiss/ScaNN/accélérateurs, ou moteurs vectoriels vendoriens ; Charding, HNSW/IVF, réplication.
Cache NVMe local : Échauffement des balances/embeddings pour un démarrage à froid.

5) Modèles de Serving

Cadres

Triton Inference Server (multimodel, multitâche, batch dynamique).
KServe (K8s-native, autoscaling HPA/KPA, canari).
vLLM/TGI pour la tokenisation LLM et le décodage haute performance (paged-attraction, cache KV offloud).
ONNX Runtime/TensorRT-LLM - pour la compilation et l'accélération.

Optimisations

Quantification : INT8/FP8/INT4 (percentiles/étalonnage, AWQ/GPTQ) - en ligne prudent, mesurer la qualité.
Compilation du graphique : TensorRT, TorchInductor/XLA, fused-kernels.
Batching/microbatching : dynamique et statique ; для LLM — continuous batching.
Cache KV : boule entre les requêtes, hors ligne sur CPU/NVMe dans des contextes longs.
Décodage spéculatif : modèle de draft + vérificateur pour accélérer le token-prononciation.
Limites de token/contexte, arrêt précoce, mots stop, temps-budget à la demande.

Stratégies de dégagement

A/B, canari, shadow - comparaison latence/qualité/métriques d'affaires.
Blue Green - pas de downtime.
Rollback par SLO/erreurs.

6) Formation/Faintuning

DDP/FSDP/ZeRO : mémoire distribuée/gradients, compte NVLink/topologie.
Chekpoints : incrémental/complet, fréquence vs I/O.
Mixed Precision: bf16/fp16 + loss scaling; profilage de la stabilité.
Datacet-sharding : itérateur uniforme, réplication par nœud.
Priorités : jobs interrompus (préemptible) en faveur du serving.
Piplines autonomes : data → train → eval → registre → promotion dans PROD en fonction de critères gate.

7) MLOps et plateforme

Registre des modèles : versions, signatures, dépendances, licences/droits d'utilisation des balances.
Modèles CI/CD : tests de compatibilité, régression des performances, gîtes de qualité, deploy sécurisé.
Fichestor : consistance offline/online (feature parity), TTL et backfill.
Data/Model Lineage : trace du datacet au rapport/expérience.
Répertoire prompt/template pour LLM (versioning).

8) Observabilité et SLO

• Latence p50/p95/p99, tokens/s, batch occupancy, queue wait, GPU-util/SM occupancy, mémoire, erreurs.
• Spécificité LLM : jetons d'entrée/sortie, longueur moyenne de réponse, taux d'échec par limite, cache-hit KV.
• Qualité : tests de régression automatiques (hors ligne), télémétrie en ligne (drapeaux de contenu, toxicité, précision d'émission sur les échantillons d'or).
• Business SLO : conversion de la personnalisation, précision de l'antifrod, rétention.

Alert : augmentation de p99/file d'attente, chute de tokens/s, dégradation de batch-fill, épuisement de VRAM/PCIe-throttle, augmentation des échecs rate-limit.

9) Sécurité, conformité et vie privée

PII/fin : segmentation des calculs et des données par région, cryptage au repos/en transit, tokenisation.
Secrets/clés : KMS/Secrets Manager ; Exclure le stockage dans les images/codes.
Stratégies de sortie LLM : filtres de sécurité, red-teaming, journal des prompts/réponses (avec anonymisation).
Licences : conformité avec les licences datacets/poids ; « no-redistribute « /restrictions commerciales.
Isolation des tenants : namespace-RBAC, réseaux, diapositives MIG, limites et quotas.

10) Le coût et les dattes

Planification capacitive : profils de charge (RPS, tokens/s), « queues » des tournois et des campagnes.
Reserve/Spot : pools mixtes (reserved + spot/preemptible) avec repositionnement des tâches et chekpoints.
Skale automatique : HPA/KPA par RPS/queue depth/GPU-util ; « départ chaud » avec des échelles chauffées.
Zoo modèle : réduire le nombre d'options ; utiliser l'adaptation (LoRA/PEFT) au lieu de la duplication complète.
Cache : embeddings/résultats de demandes coûteuses, cache KV pour LLM.
Optimisation des tokens : compression des prompts, génération retrieval-augmentée (RAG), rerank avant génération.

11) Multiregion, HA et DR

Serving actif/actif est plus proche de l'utilisateur, itinérance globale (basé sur le latin).
Réplication des balances et des fiches avec contrôle d'intégrité ; réchauffer les caches lors des sorties.
Plan DR : perte d'AZ/région, évacuation en réserve, contrôle de la dépendance au répertoire centralisé.
Jours de chaos : tests de défaillance des domaines GPU/réseau/stockage.

12) Modèles de configuration (concepts)

text dynamic_batching {
preferred_batch_size: [4, 8, 16, 32]
max_queue_delay_microseconds: 2000
}
instance_group { count: 2 kind: KIND_GPU }

yaml spec:
predictor:
canaryTrafficPercent: 20 model:
modelFormat: { name: triton }
resources:
limits: { nvidia. com/gpu: "1" }

--tensor-parallel-size 2
--max-num-seqs 512
--gpu-memory-utilization 0. 9
--enforce-eager

13) Spécificité LLM : RAG et contour de recherche

Indexation : chanking, embeddings, ANN-Charding par 'tenant/locale'.
Rerank : modèle léger sur la diapositive CPU/GPU pour améliorer la précision.
Cache de prompts/contextes : dedup, canonicalization.
Politiques de citation/responsabilité pour les domaines sensibles (CUS/règles).

14) Chèque de mise en œuvre

1. Fixez le SLO (p95 latency/tokens/s, disponibilité) et les profils de charge.
2. Décomposez le cluster en pools (serving/train/R & D), entrez les quotas/priorités.
3. Activer la RDMA/NCCL et la planification topologiquement consciente.
4. Configurez les magasins : échelles, datacets, fichestore (en ligne/hors ligne), bases de données vectorielles.
5. Sélectionnez la pile Serving (Triton/KServe/vLLM), ajoutez le cache batch/KV/quantification.
6. Lancez le registre des modèles, CI/CD, canari/shadow-deploy.
7. Mettez l'observabilité : systèmes + métriques d'affaires, qualité, traçage.
8. Entrez les politiques de sécurité/PII, les licences, la vérification.
9. Optimisez votre TCO : reserved + spot, auto scale, cache, PEFT au lieu de clones complets.
10. Préparez votre HA/DR et passez la journée de jeu.

15) Anti-modèles

« Un grand GPU pour tout » sans pools ni priorités.
L'absence de batch dynamique et de cache KV pour LLM → l'explosion de p99 et le coût.
Entraînement et serving sur une seule balle sans préemption → incident SLO.
Télémétrie zéro qualité/sécurité → dégradations et risques imperceptibles.
Monolithe centralisé sans fichestor/registre de modèle → pas de reproductibilité.
Ignorer les licences poids/données.

Résultats

Une infrastructure AI réussie est un pool de GPU avec une planification intelligente, un réseau élevé et un stockage approprié, un serving efficace (batch, cache, quantification, compilation), des MLOps matures et des SLO rigoureux. Combinée à la sécurité/PII, à l'HA/DR multirégional et à la finesse réfléchie, la plate-forme offre un p99 stable, une demande contrôlée et l'introduction rapide de nouveaux modèles - de l'antifrod à la personnalisation et aux assistants LLM.