llm-d-router

# Visión general del llm-d Router El llm-d Router es un punto de entrada inteligente para el tráfico de inferencia en entornos Kubernetes, diseñado para optimizar el servicio de LLM al proporcionar enrutamiento consciente de la carga y del caché de prefijos, priorización de solicitudes y control de flujo avanzado. Admite diversos formatos de solicitud y objetivos complejos de servicio, lo que lo hace adecuado para implementaciones de IA de grado productivo. ## Componentes principales El repositorio aloja varios componentes clave: 1. **Endpoint Picker (EPP)**: El motor de enrutamiento inteligente que actúa como el "cerebro" del router. Evalúa las solicitudes entrantes frente al estado actual del InferencePool, considerando factores como la localidad del KV-cache, la carga actual y la prioridad para tomar decisiones óptimas de colocación. Se integra con proxies de capa 7 a través del protocolo ext-proc. 2. **APIs de gestión de solicitudes**: Recursos que influyen en el comportamiento del EPP: - **InferenceObjective**: Configura los objetivos de programación para solicitudes específicas, incluidos niveles de prioridad y metas de rendimiento. - **InferenceModelRewrite**: Permite reescribir nombres de modelos para una gestión flexible del tráfico, admitiendo pruebas A/B e implementaciones canary. 3. **Sidecar de desagregación**: Un componente de coordinación desplegado junto a los servidores de modelo (típicamente como sidecar de los trabajadores de decodificación). Orquesta ciclos de vida de inferencia multietapa complejos, como P/D (Prefill/Decode) y E/P/D (Encode/Prefill/Decode), comunicándose con trabajadores especializados para gestionar transferencias de KV-cache y embeddings. ## Modos de operación El llm-d Router admite dos modos de implementación principales: ### 1. Modo autónomo Este modo utiliza un proxy Envoy autogestionado sin requerir infraestructura de Gateway API. El chart Helm autónomo admite dos topologías: - **Modo sidecar** (predeterminado): El proxy se ejecuta en el pod del EPP, adecuado para pruebas básicas y evaluaciones locales. - **Modo de servicio**: El proxy se ejecuta como un Deployment y Service separados y escalables horizontalmente, alcanzando el EPP a través de su Service. Establezca `router.proxy.mode=service` para escalar el proxy de forma independiente. ### 2. Modo Gateway (Inference Gateway) El modo recomendado para producción aprovecha la API oficial de Kubernetes Gateway. El EPP actúa como backend para un InferencePool, referenciado por un HTTPRoute en un Gateway compartido. Esto permite una gestión avanzada del tráfico, balanceo de carga multicúster e infraestructura compartida tanto para cargas de trabajo de inferencia como tradicionales. ## Arquitectura y documentación El proyecto proporciona documentación integral que incluye: - Detalles de arquitectura, lógica de enrutamiento y plugins (filtros y scorers) - Recomendaciones de dimensionamiento de contenedores para cargas pesadas o de contexto largo - Especificaciones de formato de registro stdout JSON de OpenTelemetry - Guías de configuración de desagregación - Instrucciones de verificación de artefactos para seguridad ## Requisitos técnicos Para la instalación automática de Envoy, el proyecto proporciona herramientas, pero la instalación manual requiere soporte para modos de cuerpo de solicitud/respuesta `FULL_DUPLEX_STREAMED` en el filtro ext-proc. ## Comunidad y contribuciones El proyecto fomenta la participación comunitaria con reuniones quincenales, un canal dedicado de Slack (#sig-router) y pautas de contribución. Sigue la guía de contribución de la organización llm-d, y los cambios más grandes deben discutirse primero mediante issues. ## Seguridad Las imágenes de contenedor publicadas llevan atestación de procedencia firmada y SBOM (lista de materiales de software). Las pautas de informe de seguridad están documentadas en SECURITY.md, con instrucciones de verificación para artefactos liberados. En general, el llm-d Router es una solución robusta para organizaciones que buscan enrutamiento de inferencia inteligente y escalable en Kubernetes, particularmente para cargas de trabajo modernas de LLM con requisitos de servicio desagregado.