Nodes GPU et calcul ML

Résumé succinct

1. former des modèles (recyclage élevé, raccourcis rapides, résistance aux interruptions),

2. servir l'inference (faible p95-latence à conversion élevée),

3. coûter de l'argent prévisible (FinOps, quotas, multitenance),

4. être sûr (isolation, chaîne d'approvisionnement, contrôle des balances/datacets).

Fer et topologie

GPU et mémoire

Le volume et la bande HBM sont plus importants que les « TFLOPS crus » pour LLM/RecSys.
Pour l'inference, beaucoup de petites requêtes sont la priorité de la mémoire intégrée (KV-cache) et le haut clocks/power limit.

Connectivité

NVLink/NVSwitch - à l'intérieur d'un nœud pour un all-reduce rapide.
InfiniBand/RoCE est un échange entre nœuds pour DDP/FSDP (≥ 100-200 Gb/s).
Arbre PCIe : s'assurer que NIC et GPU sont assis sur un seul nœud NUMA ; évitez les bottleneck PCIe-switch « chauds ».

Tuning de base du BIOS/nœud

Modes Performance, désactivation des C-states (ou augmentation minimale), NUMA awareness, ASPM off sur les PCIe critiques.
Nutrition : profils stables, pas agressif power-save - sinon « tremble » p99.

Base de la pile de logiciels

Pilotes NVIDIA + CUDA + cuDNN/TensorRT cohérents sur la matrice de compatibilité.
NVIDIA Container Toolkit pour GPU à l'intérieur des conteneurs.
NCCL (collectifs), UCX (transports), Apex/xFormers/Flash-Attraction - pour la vitesse.
En option, GDS (GPUDirect Storage) sur NVMe/IB rapide - accélère le flux de données.

Kubernetes pour GPU

Composants clés

NVIDIA GPU Operator (pilotes, DCGM, device-plugin).
NVIDIA Device Plugin - Export des ressources 'nvidia. com/gpu`.
MIG (A100/H100) : Division d'un GPU physique en profils isolés (par exemple, '1g. 10gb`).
Time-slicing est l'écrasement logique du GPU dans le temps pour les petites tâches d'infériorité.
Node Feature Discovery - étiquettes par type de GPU/topologie.

Planification et isolation

Taints/Tolerations/NodeSelectors pour séparer formation/inference/expériences.
Topology Manager et CPU Manager (statique) pour l'alignement NUMA.
Volcano/Slurm on K8s/Ray - files d'attente, priorités, préemption pour les gros job.

yaml resources:
limits:
nvidia. com/gpu: 1 # or MIG profile: nvidia. com/mig-1g. 10gb: 1 requests:
nvidia. com/gpu: 1

yaml tolerations:
- key: "gpu-train"
operator: "Exists"
effect: "NoSchedule"
nodeSelector:
gpu. pool: "train"

Formation : Échelle et durabilité

Parallélisme

DDP est un parallélisme de date standard.
FSDP/ZeRO - Chardonnez les paramètres/grades/optimiseurs, réduit la mémoire.
Tensor/Pipeline Parallèle - pour les très grands LLM ; nécessite NVLink/IB.
L'accumulation gradiente - augmente l'efficacité de batch sans la croissance des pics de mémoire.

Précision mixte et optimisation de la mémoire

AMP (bf16/fp16) + loss scaling; pour les H100/nouveaux - FP8 si possible.
Activation/Gradient Checkpointing, Flash-Attraction pour les séquences longues.
Paged/Chunked KV-cache pour se préparer à l'inference.

Tchekpoint et tolérance aux pannes

Checkpoint incrémental fréquent sur NVMe rapide/objet avec rétention.
Jobs idempotent (identificateurs de blessures répétés).
Résistance au spot : Attraper SIGTERM, fusionner rapidement l'état ; le planificateur remet le job dans la file.

Variables importantes NCCL/réseaux (exemple)

bash
NCCL_IB_HCA=mlx5_0
NCCL_SOCKET_IFNAME=eth1
NCCL_P2P_LEVEL=NVL
NCCL_MIN_NRINGS=8
NCCL_NET_GDR_LEVEL=SYS

Inference : faible latence, rendement élevé

Cadre Serving

Triton Inference Server est un serveur unique pour TensorRT/ONNX/TS/PyTorch.
vLLM/TGI/TensorRT-LLM - Spécialistes LLM (paged-attraction, KV-cache efficace, batching continu).

Réceptions d'accélération

Quantification : INT8/FP8/quant. -aware (AWQ, GPTQ) - réduction VRAM, croissance TPS.
Batching/Continuous batching : servir des paquets de demandes sans croissance p95.
KV-cache pinning dans HBM, réduction des contextes ; décodage speculatif (modèle draft).
Concurrence sur GPU : plusieurs threads/modèles sous MIG/time-slice.

Profils de cible (exemple SLO)

p95 latence de réponse du modèle de chat ≤ 300 ms par préfixe/token ;

Throughput ≥ 200 courants/s/GPU sur le profil cible ;

Les résidus p99 sont contrôlés par le sheduling (classes QoS et limites contextuelles).

Triton deployment (fragment)

yaml env:
- name: CUDA_VISIBLE_DEVICES value: "0"
- name: TRITONSERVER_MODEL_CONTROL value: "explicit"
args: ["--backend-config=tensorrt,output_memory_pool_size=1024"]

Données et pipelines

Formats : Parquet/Arrow, webdataset (tar-chards) pour la lecture en continu.
Prefetch/Async I/O: DataLoader-ы с pin-memory, prefetch-pipelines, GDS.
Feature Store pour la fiche en ligne (antifrod/recommandations).
Versioning : DVC/LakeFS/MLflow Model Registry ; enregistrer les datasettes, le code et les hyperparamètres.

Observabilité et SLO

Métriques DCGM/Prometheus (minimum)

`dcgm_sm_util`, `dcgm_fb_used`, `dcgm_power_usage`, `dcgm_pcie_rx/tx`, `dcgm_dram_bw`

Températures/fréquences et errors ECC (alert par croissance).
Achieved Occupancy et stall reasons (couche étroite du noyau).

Métriques de service

Modèles générateurs : Tokens/s, p50/p95/p99, queue depth, panne de mémoire.
Formation : étapes/secondes, temps de l'ère, efficacité all-reduce, % du temps en I/O.
SLO panel : conformité p95, « budget des erreurs » (≥ 99. 5 % d'inferences « réussies »).

Alerte (idées)

`fb_used / fb_total > 0. 95` 5 мин → throttle/scale-out.
La baisse du TPS de N % avec le même recyclage est la dégradation du modèle/code.
L'augmentation de l'ESS/température → la migration du job/incident du fer.

Sécurité et isolation

Multi-tenance : profils MIG ou noeuds « per-team », namespaces/quotas.
IOMMU/PSP, cgroups, interdiction des conteneurs privilégiés, restriction « CAP _ ».
MPS (multi-process service) - soigneusement : élimination plus élevée, mais la séparation est plus faible que MIG.
Chaîne d'approvisionnement : signatures de conteneurs (cosign), vérification des artefacts, contrôle des décharges de modèles.
Données/poids : cryptage sur disque, contrôle d'accès (ABAC/RBAC), filigranes/registres de hash des modèles.

FinOps : coût, quotas, auto-ski

Pools de nœuds : 'train' (on-demand/réserves), 'infer' (mélange on-demand + spot), 'bou' (spot-heavy).
Résilience des spot : checkpoints fréquents, logique de redémarrage rapide, files d'attente Volcano avec priorités.
Réserves/RI/Plans d'épargne pour une base stable ; auto-désactivation des nœuds vides.
Modèles right-sizing : Quantification/adaptateurs LoRA au lieu d'un modèle « complet » ; sélection des profils MIG sous SLA.
Contour des budgets : quotas GPU-heures par équipe, « coût pour 1k requêtes/tokens ».

Modèles YAML et artefacts

1) Profil MIG (conceptuel)

yaml apiVersion: nvidia. com/v1 kind: MigStrategy metadata: { name: mig-a100-1g10gb }
spec:
deviceFilter: "a100"
mode: single resources:
- profile: "1g. 10gb"
count: 7

2) Volcano file d'attente pour la formation

yaml apiVersion: scheduling. volcano. sh/v1beta1 kind: Queue metadata: { name: train-q }
spec:
weight: 100 reclaimable: true capability:
resources:
- name: nvidia. com/gpu quantity: 64

3) KEDA pour Auto Skale Inference à tour de rôle

yaml apiVersion: keda. sh/v1alpha1 kind: ScaledObject metadata: { name: llm-infer }
spec:
scaleTargetRef: { name: llm-deploy }
pollingInterval: 5 minReplicaCount: 2 maxReplicaCount: 80 triggers:
- type: rabbitmq metadata:
queueName: infer-queue mode: QueueLength value: "200"

Chèque de démarrage du cluster GPU

• Carte de topologie NVLink/IB ; NIC/GPU sur un seul NUMA.
• Pilotes/CUDA harmonisés, Operator/Device-plugin installé.
• Profils MIG/time-slicing et quotas de neimspace.
• DDP/FSDP pipeline obkatan sur le stajing ; les tchekpoints sont rapides.
• Triton/vLLM с continuous batching; les cibles p95 et TPS sont données.
• DCGM/Prometheus/Grafana + alerts ECC/température/mémoire/TPS.
• Politiques de sécurité (PSP, cosign, obstruction/contrôle des poids).
• FinOps : pools spot/ri, rapport « $/1k tokens », auto-jokdown idle.

Erreurs typiques

L'entraînement et l'inference sont mélangés sur des noeuds sans taints → des « scies » entre eux GPU/IO.
Il n'y a pas de checkpoint et de préemption-logique → perte de progrès sur spot.
L'absence de métriques DCGM → l'élimination « aveugle » et la surchauffe.
Ignorer la topologie NUMA/PCIe → la bande NCCL basse.
Profils MIG/time-slice incorrects → p99 latence et « Out of Memory ».
HPA par CPU au lieu de TPS/latence → skale tardif.

Spécificités iGaming/fintech

Antifrod's/scoring : SLA inference ≤ 50 ms p95 sur les voies critiques (paiements/conclusions) ; tenez le modèle léger « fallback ».
Recommandations/personnalisation : on-policy/off-policy learning la nuit, online-features - faible latence.
Assistants de chat/RAG : cache de contenu, déduplication des requêtes, guardrails ; Chardonnez les index de recherche vectorielle.
Pics (matchs/tournois) : préchauffage des modèles/kv-cache, augmentation des minReplicas, cours QoS pour VIP.

Résultat

La pile de calcul GPU devient vraiment efficace lorsque le fer (HBM/NVLink/IB), la matrice de soft (CUDA/NCCL), la planification (MIG, file d'attente, taints), les données (piapline rapide/GDS), l'observation (DCCCL D D D D D GM/SLO) et le coût (FinOps/quotas) fonctionnent de manière cohérente. Intégrez cela dans l'IaC et la politique des clusters - et vous obtiendrez un taux d'apprentissage prévisible, un inference stable avec une faible p95-latence et une économie transparente de l'horloge GPU.