llm-d-router

# Présentation de llm-d Router llm-d Router est un point d’entrée intelligent pour le trafic d’inférence dans les environnements Kubernetes, conçu pour optimiser le service LLM en fournissant un routage tenant compte de la charge et du cache de préfixes, la hiérarchisation des requêtes et un contrôle de flux avancé. Il prend en charge divers formats de requêtes et des objectifs de service complexes, ce qui le rend adapté aux déploiements IA de niveau production. ## Composants principaux Le dépôt héberge plusieurs composants clés : 1. **Endpoint Picker (EPP)** : le moteur de routage intelligent qui agit comme le « cerveau » du routeur. Il évalue les requêtes entrantes en fonction de l’état actuel de l’InferencePool, en tenant compte de facteurs tels que la localité du cache KV, la charge actuelle et la priorité pour prendre des décisions de placement optimales. Il s’intègre aux proxys L7 via le protocole ext-proc. 2. **API de gestion des requêtes** : des ressources qui influencent le comportement de l’EPP : - **InferenceObjective** : configure les objectifs d’ordonnancement pour des requêtes spécifiques, y compris les niveaux de priorité et les cibles de performance. - **InferenceModelRewrite** : permet la réécriture des noms de modèles pour une gestion flexible du trafic, avec prise en charge des tests A/B et des déploiements canary. 3. **Sidecar de désagrégation** : un composant de coordination déployé aux côtés des serveurs de modèles (généralement en sidecar des workers de décodage). Il orchestre des cycles de vie d’inférence complexes en plusieurs étapes, tels que P/D (Prefill/Decode) et E/P/D (Encode/Prefill/Decode), en communiquant avec des workers spécialisés pour gérer le cache KV et les transferts d’embeddings. ## Modes de fonctionnement llm-d Router prend en charge deux modes de déploiement principaux : ### 1. Mode autonome Ce mode utilise un proxy Envoy autogéré sans nécessiter d’infrastructure Gateway API. Le chart Helm autonome prend en charge deux topologies : - **Mode sidecar** (par défaut) : le proxy s’exécute dans le pod EPP, adapté aux tests de base et aux évaluations locales. - **Mode service** : le proxy s’exécute en tant que Deployment et Service distincts, évolutifs horizontalement, et atteint l’EPP via son Service. Définissez `router.proxy.mode=service` pour mettre à l’échelle le proxy indépendamment. ### 2. Mode passerelle (Inference Gateway) Le mode de production recommandé s’appuie sur la Kubernetes Gateway API officielle. L’EPP agit comme backend pour un InferencePool, référencé par une HTTPRoute sur une passerelle partagée. Cela permet une gestion avancée du trafic, un équilibrage de charge multi-clusters et une infrastructure partagée pour l’inférence comme pour les charges de travail traditionnelles. ## Architecture et documentation Le projet fournit une documentation complète comprenant : - Des détails d’architecture, la logique de routage et les plugins (filtres et scorers) - Des recommandations de dimensionnement des conteneurs pour les charges de travail lourdes ou à long contexte - Les spécifications du format de journal OpenTelemetry JSON sur stdout - Des guides de configuration de la désagrégation - Des instructions de vérification des artefacts pour la sécurité ## Exigences techniques Pour l’installation automatique d’Envoy, le projet fournit des outils, mais une installation manuelle nécessite la prise en charge des modes de corps de requête/réponse `FULL_DUPLEX_STREAMED` dans le filtre ext-proc. ## Communauté et contributions Le projet encourage la participation communautaire avec des réunions bihebdomadaires, un canal Slack dédié (#sig-router) et des lignes directrices de contribution. Il suit le guide de contribution de l’organisation llm-d, et les modifications importantes doivent d’abord être discutées via des issues. ## Sécurité Les images de conteneur publiées comportent une attestation de provenance signée et un SBOM (nomenclature logicielle). Les consignes de signalement des problèmes de sécurité sont documentées dans SECURITY.md, avec des instructions de vérification pour les artefacts publiés. Globalement, llm-d Router est une solution robuste pour les organisations recherchant un routage d’inférence intelligent et évolutif dans Kubernetes, en particulier pour les charges de travail LLM modernes avec des exigences de service désagrégé.