Chapitre 12 — Service désagrégé et Kubernetes

Douzième billet de la tournée chapitre par chapitre de LLM Primer VI : Mettre à l'échelle les systèmes IA. Le chapitre qui sépare enfin préremplissage et décodage sur des pools GPU distincts et montre les primitives Kubernetes qui gardent les pods du bon côté de l'interconnexion.

Pourquoi ce chapitre existe

Le Chapitre 11 a tracé une ligne nette entre moteurs et plateformes — jusqu'à ce que le moteur lui-même rappelle que préremplissage et décodage sont des charges contradictoires. Le préremplissage est limité par le calcul ; le décodage est limité par la bande passante mémoire. Les faire tourner sur le même GPU force une pièce de matériel à être bonne sur deux exigences contradictoires et elle finit médiocre sur les deux. Le service désagrégé les sépare sur des pools de GPU distincts, transporte le cache KV entre les pools, et laisse chaque pool être réglé pour sa propre charge. Le prix est la complexité opérationnelle, payée en primitives Kubernetes, topologie de pods et tissu réseau qui porte le trafic KV. Le Chapitre 12 parcourt la forme de cette complexité — les composants, le chemin de transfert et les CRD (LeaderWorkerSet, PodCliqueSet de Grove, planificateur KAI) qui l'expriment.

12.1 Préremplissage et décodage veulent des puces différentes à des cadences différentes

Sur le même H100, un long préremplissage peut réellement atteindre 60–80 pour cent du pic de FLOPs, et un pas de décodage utilise 5–15 pour cent de FLOPs tout en saturant 70–90 pour cent de la bande passante HBM. Les entrelacer sous batching continu est un compromis viable mais qui fuit de deux façons. La passe de calcul du préremplissage frappe le même bus HBM que les décodes en file essaient de faire défiler, et le temps entre tokens gonfle. La carte tourne aussi à un point de fonctionnement unique : régler pour le préremplissage et le décodage est étranglé par la bande passante ; régler pour le décodage et le préremplissage est étranglé par le calcul. Les prompts se sont allongés de centaines à des milliers de tokens à mesure que RAG et agents ont pris le trafic de production, et le coût d'entrelacement a grandi avec eux. La désagrégation donne à chaque phase son propre pool. Les workers de préremplissage peuvent tourner sur des cartes à FLOPs bruts (H100 SXM, B200). Les workers de décodage peuvent tourner sur des cartes à capacité et bande passante (H200, MI300X). Chaque pool est dimensionné à sa propre charge — trafic long contexte à sortie courte demande plus de préremplissage ; trafic chat demande plus de décodage.

12.2 La forme, c'est quatre composants plus un chemin de transfert KV

Un déploiement désagrégé qui marche a quatre composants. Les workers de préremplissage acceptent une requête, calculent le préremplissage, émettent le premier token et préparent le cache KV pour le transfert. Les workers de décodage acceptent un cache KV entrant et ses métadonnées, l'installent dans leur pool paginé et font tourner le batching continu sur leurs générations en vol. Un routeur de cache KV — le plan de contrôle — maintient une vue de la capacité KV libre, de la remplissage de batch et de la localité réseau de chaque worker de décodage, et assigne chaque sortie de préremplissage pour minimiser le coût de transfert et équilibrer la charge. Une passerelle frontale termine la connexion HTTP de l'utilisateur, streame le premier token depuis le worker de préremplissage, puis bascule transparente sur le streaming du reste depuis le worker de décodage. La contrainte critique est le transfert KV : une séquence 70B GQA à 4 096 tokens fait 1,5–2 Go, et elle doit passer du nœud de préremplissage au nœud de décodage dans le même budget TTFT de 50–100 ms que l'utilisateur regarde. NVLink à 900 Go/s à l'intérieur d'un nœud et InfiniBand à 400 Gb/s entre nœuds font tenir les chiffres — si les pods atterrissent du bon côté du tissu.

12.3 LeaderWorkerSet, Grove et KAI expriment la topologie

Kubernetes n'avait pas à l'origine de primitive pour « ces deux pods typés forment une seule réplique logique ». LeaderWorkerSet, ajouté en amont en 2024, exprime une réplique multi-pods avec un leader (disons préremplissage) et des workers (disons décodes) ; le contrôleur maintient le groupe comme une unité d'ordonnancement. PodCliqueSet de NVIDIA Grove (2025, partie de NVIDIA AI Enterprise) généralise davantage avec des cliques typées (préremplissage, décodage, routeur), chacune avec son propre gabarit et sa taille, plus une description de topologie qui décrit les liens entre cliques. Grove soumet l'ensemble au planificateur avec des contraintes de localité intra et inter cliques. Aucun CRD ne suffit à lui seul ; les deux ont besoin d'un planificateur qui connaît la topologie physique du cluster, ce que celui par défaut de Kubernetes ne fait pas. KAI Scheduler — libéré depuis Run:ai en 2024 — consomme un graphe de topologie produit par nvidia-smi topo --matrix et par le subnet manager InfiniBand, et note les placements candidats contre lui. Quand une clique Grove demande nvlinkDomain: required, KAI restreint le placement à un domaine cohérent NVLink unique (les huit GPU d'une carte HGX sur un NVSwitch). Quand la topologie inter-cliques dit sameInfiniBandIsland, KAI maintient les cliques dans un groupe de switch feuille où l'aller-retour KV reste sous 100 μs.

Ce que prépare le Chapitre 12

Le Chapitre 12 a donné au déploiement une image statique : à tout instant, un nombre fixe de cliques tournent et servent le trafic. Le trafic réel n'est pas statique — les assistants de chat balancent d'un facteur 30 entre pic et creux dans une journée, les outils dev tombent à zéro le week-end, les produits grand public suivent le soleil. Le Chapitre 13 parcourt l'histoire de l'autoscaling : pourquoi le HPA standard est le mauvais scaler pour le service LLM, sur quels signaux KEDA scale à la place, comment Knative exprime la mise à l'échelle vers zéro, et ce qui compresse un démarrage à froid de 60–180 secondes en quelque chose qu'une application face utilisateur peut absorber.

Prochaine étape — Chapitre 13 : Autoscaling et atténuation du démarrage à froid. KEDA, Knative, CRIU, cache de graphes CUDA, NVMe — la pile qui fait cohabiter mise à l'échelle vers zéro et vrais utilisateurs.