Chapitre 11 — La couche plateforme et orchestration

Onzième billet de la tournée chapitre par chapitre de LLM Primer VI : Mettre à l'échelle les systèmes IA. Le chapitre qui soutient que le choix de plateforme n'est pas une question de fonctionnalités mais de savoir quel modèle opérationnel correspond à la culture d'exploitation de l'équipe.

Pourquoi ce chapitre existe

Un moteur enveloppe un modèle sur un GPU et produit des tokens. C'est toute sa fiche de poste. Dès que la production a besoin de deux répliques derrière un load balancer, ou de deux moteurs différents sous un même endpoint, ou d'un pipeline qui exécute embed → récupération → reranking → génération comme un seul appel logique, ou d'un système de quotas qui empêche un locataire d'affamer un autre, ou d'un autoscaler qui ajoute des répliques quand la profondeur de file grimpe, le moteur a épuisé ses réponses. Le Chapitre 11 parcourt les quatre plateformes qui dominent ce travail en 2026 — Ray Serve, KServe, BentoML, Triton Inference Server — et soutient que le choix entre elles est une question d'adéquation à la culture d'exploitation de l'équipe, non une question de fonctionnalités.

11.1 Ray Serve est natif Python ; KServe est natif Kubernetes

Ray Serve est la plateforme qui émerge quand la question de départ est « à quoi ressemblerait un framework de service si je n'avais jamais à quitter Python pour composer, mettre à l'échelle et déployer un pipeline de modèles ? » La réponse est des classes Python décorées comme acteurs, câblées ensemble par des appels de fonction Python, répliquées, placées et autoscalées par le runtime Ray. Les déploiements se composent en pipelines en s'appelant mutuellement ; le pipeline est Python, l'observabilité est Python, l'ops est Python. C'est le choix naturel quand le même cluster fait déjà tourner Ray pour l'entraînement. KServe émerge du point de départ inverse : Kubernetes-first, neutre en fournisseur, déclaratif. Un InferenceService KServe est un CRD qui capture où vivent les poids, quel runtime les sert et comment l'autoscaling doit se comporter. La plateforme câble les pods via Knative pour la mise à l'échelle vers zéro et Istio pour le routage du trafic, et expose un endpoint HTTP stable. L'arbitrage est l'expressivité — la composition de pipelines dans KServe est plus YAML que dans Ray Serve — contre la portabilité et la standardisation.

11.2 BentoML empaquette ; Triton batche des modèles hétérogènes

BentoML prend une troisième posture : le travail premier de la plateforme est de faire du modèle + code + dépendances un artefact unique et cohérent — un Bento — et de faire du déploiement de cet artefact vers n'importe où (Kubernetes, Lambda, Cloud Run, une VM nue) une opération en une commande. C'est ce qu'une image Docker est aux applications générales, à la couche de service de modèles. L'expérience d'écriture est du Python en forme FastAPI ; le déploiement est le mouvement centré sur l'artefact. Meilleure adéquation : petite empreinte d'ops et une équipe qui veut le chemin le plus court entre « classe Python » et « endpoint déployé qui tourne partout ». Triton Inference Server est le batcheur dynamique de qualité entreprise qui a historiquement dominé le service aligné NVIDIA. Il héberge côte à côte TensorFlow, PyTorch, ONNX, TensorRT, TensorRT-LLM et des backends Python, applique son batcheur dynamique aux charges non-LLM (recommandeurs, classifieurs, embedders), et utilise l'ordonnanceur de batching continu pour les LLM sous son backend TensorRT-LLM. Meilleure adéquation : charges hétérogènes ou équipe déjà profondément installée dans la pile NVIDIA.

11.3 Les quatre choix se partagent par culture d'ops

Les quatre plateformes se partagent nettement. Python et Ray comme centre de gravité → Ray Serve. Kubernetes, manifests déclaratifs, portabilité multi-cloud, isolation multi-tenant → KServe. Petite empreinte d'ops, chemin le plus court entre classe et endpoint → BentoML. Charges hétérogènes ou boutique NVIDIA-first → Triton. Elles ne sont pas mutuellement exclusives au niveau d'une organisation : un motif fréquent dans les grandes orgs est Triton pour les LLM de production à plus fort volume, Ray Serve pour les pipelines RAG et agents qui composent plusieurs appels de modèle, KServe comme parapluie qui impose le multi-tenant, et BentoML dans les environnements de développement. L'exercice utile au moment du choix est de lister trois propriétés opérationnelles dont l'équipe a absolument besoin et trois avec lesquelles elle peut absolument vivre sans, puis de classer les plateformes contre cette liste. Résistez à la plateforme qui « prend tout en charge » — chacune supporte bien son cœur et mal sa périphérie, et celle dont le cœur recoupe les indispensables est celle que l'équipe aimera exploiter.

Ce que prépare le Chapitre 11

La frontière moteur/plateforme est propre quand l'unité de réplication est un pod qui possède un modèle sur un nœud GPU. Elle cesse d'être propre dès qu'on honore le fait du Chapitre 1 : préremplissage et décodage sont des charges contradictoires. Le Chapitre 12 les sépare sur des pools de GPU distincts, transporte le cache KV entre les pools sur le tissu réseau, et exprime la séparation en primitives Kubernetes — LeaderWorkerSet, PodCliqueSet de Grove, la conscience de topologie du planificateur KAI. La couche plateforme est ce qui rend la séparation opérable ; la couche plateforme est la raison pour laquelle la séparation est exprimable du tout.

Prochaine étape — Chapitre 12 : Service désagrégé et Kubernetes. Séparer préremplissage et décodage en pods distincts et les primitives Kubernetes qui expriment la séparation.