llm-d & Inférence Distribuée sur OpenShift : Découplage Prefill / Decode et Routage Cache-Aware

Le passage à l’échelle de l’inférence générative en entreprise se heurte aujourd’hui à un goulot d’étranglement fondamental : l’inadéquation entre les profils de calcul de l’étape de Prefill (ingestion du prompt et calcul du Key-Value cache) et de l’étape de Decode (génération séquentielle de tokens). Dans un déploiement vLLM monolithique standard, ces deux phases partagent le même GPU, provoquant des congestions massives sur les requêtes à contexte long et une gigue inacceptable sur l’Inter-Token Latency (ITL).

L’architecture llm-d, projet open source porté au sein de la CNCF et soutenu par Red Hat, IBM Research, Google Cloud, CoreWeave et NVIDIA, standardise l’orchestration Kubernetes de l’inférence distribuée désagrégée (Prefill/Decode Disaggregation) et le routage sensible au cache (KV-cache-aware routing) sur Red Hat OpenShift AI.

---

1. Le défi du déploiement monolithique : Conflit de phases de calcul

L’inférence d’un Large Language Model (LLM) s’articule autour de deux régimes d’exécution diamétralement opposés :

1. Phase de Prefill (Compute-Bound) : Traitement parallèle de la séquence d’entrée pour calculer les matrices d’attention initiales et construire le KV-cache. Cette phase sature les cœurs de calcul Tensor Cores et requiert une puissance de calcul brute (TFLOPS) maximale.
2. Phase de Decode (Memory-Bandwidth-Bound) : Génération autorégressive token par token. Chaque nouveau token ne nécessite qu’une fraction du calcul matriciel, mais contraint la bande passante mémoire VRAM (HBM) pour charger l’intégralité des poids du modèle et du KV-cache à chaque étape.

Dans un modèle monolithique, l’arrivée d’un prompt volumineux (ex. 64k ou 128k tokens dans un pipeline RAG d’entreprise) monopolise le GPU et interrompt le flux de décodage des sessions actives. Le Time-To-First-Token (TTFT) explose et l’Inter-Token Latency (ITL) devient imprévisible.

---

2. Désagrégation Prefill / Decode (P/D Disaggregation) avec vLLM

L’inférence désagrégée scinde le pipeline en deux pools de calcul distincts et indépendamment scalables :

• Pool de Prefill (Instances vLLM optimisées pour le calcul) : Absorbe les requêtes entrantes, calcule le KV-cache initial à pleine vitesse et transmet instantanément l’état mémoire sans générer de tokens.
• Pool de Decode (Instances vLLM optimisées pour la bande passante mémoire) : Reçoit le tenseur de KV-cache déjà calculé et exécute la génération de tokens en continu avec une latence ultra-faible et stable.

Le transfert du KV-cache entre les nœuds s’effectue via des connecteurs haute performance (vLLM NIXL / UCX / RDMA over Converged Ethernet), éliminant tout coût de recalcul sur le nœud de décodage.

---

3. Le rôle de llm-d : Ordonnancement intelligent et Extension Gateway API

llm-d apporte le plan de contrôle Kubernetes natif pour orchestrer cette complexité :

• CRD InferencePool et InferenceObjective : Définition déclarative des pools de calcul spécialisés (accélérateurs NVIDIA H100/A100, AMD Instinct ou L40S) et des contraintes de SLO (TTFT cible, latence p99 par token).
• Routage Prefix-Cache-Aware : La passerelle d’inférence (basée sur la Kubernetes Gateway API Inference Extension) maintient un index global distribué des préfixes de KV-cache. Les requêtes partageant un contexte commun (ex. system prompt, documents RAG indexés) sont automatiquement dirigées vers les nœuds détenant déjà ces blocs en cache mémoire, réduisant le TTFT jusqu’à 90%.
• Équilibrage de charge intelligent : Analyse en temps réel de la saturation de la VRAM et de la charge de travail des pods vLLM plutôt qu’un round-robin aveugle.

---

4. Déploiement et Opérationnalisation sur Red Hat OpenShift AI

L’intégration de llm-d dans l’écosystème Red Hat OpenShift s’appuie sur des briques d’infrastructure éprouvées :

• KServe & ServingRuntime : Déploiement déclaratif des instances vLLM sous forme de services cloud-native avec gestion fine du cycle de vie.
• Autoscaling découplé via KEDA : Mise à l’échelle autonome du pool de Prefill en fonction du volume de requêtes et de la taille des contextes entrants, sans impacter la taille du pool de Decode.
• Topologie réseau SR-IOV / RoCE : Configuration des interfaces réseau haut débit pour garantir le transfert du KV-cache à débit maximal (400 Gbps+) entre les pods d’un même cluster.
• Observabilité OpenTelemetry & Prometheus : Suivi granulaire des métriques clés d’inférence (vllm:time_to_first_token_seconds, vllm:time_per_output_token_seconds, ratio de cache hit).

---

5. Compétences & Cursus Aperta Scientia

• Cursus AS300 (AI Platform Engineer — 399h) : Ce sujet est au cœur de l’ingénierie des plateformes d’inférence distribuée — configuration avancée de vLLM, mise en place des ServingRuntimes KServe sous Red Hat OpenShift AI (RHOAI), gestion du KV-cache distribué, implémentation des CRDs InferencePool de llm-d, et benchmarking comparatif (GuideLLM / lm_eval) sur architectures désagrégées.
• Cursus AS200 (DevOps Platform Engineer — 399h) : Déploiement et sécurisation des passerelles Kubernetes Gateway API, politiques de routage avancées, configuration du réseau haute performance (SR-IOV / RoCE), monitoring temps réel via Prometheus / Grafana, et automatisation GitOps multi-environnements avec OpenShift GitOps (ArgoCD).

---

6. Sources & Références Techniques

• Red Hat Developer Blog — Intelligent inference scheduling with llm-d on Red Hat AI : developers.redhat.com/articles/2026/06/11/intelligent-inference-scheduling-llm-d-red-hat-ai
• Red Hat Developer Blog — Introduction to distributed inference with llm-d : developers.redhat.com/articles/2025/11/21/introduction-distributed-inference-llm-d
• Red Hat Blog — Demystifying llm-d and vLLM: The race to production : redhat.com/en/blog/demystifying-llm-d-and-vllm-race-production
• CNCF / llm-d Project Repository : github.com/llm-d/llm-d — documentation : llm-d.ai
• vLLM Documentation — Disaggregated Prefill & Decode Architecture : docs.vllm.ai/en/stable/features/disagg_prefill/
• Kubernetes Gateway API — Inference Extension Working Group : gateway-api.sigs.k8s.io