Agradecemos a Greg Pereira y Robert Shaw del equipo de llm-d por su apoyo para llevar llm-d a AWS.
En la era de la agencia y el razonamiento, los grandes modelos de lenguaje (LLM) generan 10 veces más tokens y computan a través de complejas cadenas de razonamiento en comparación con respuestas de un solo disparo. Los flujos de trabajo de IA agente también crean demandas muy variables y otro aumento exponencial en el procesamiento, lo que atasca el proceso de inferencia y degrada la experiencia del usuario. A medida que el mundo pasa de la creación de prototipos de soluciones de IA a la implementación de IA a escala, la inferencia eficiente se está convirtiendo en el factor decisivo.
La inferencia LLM consta de dos fases distintas: prellenado y decodificación. La fase de prellenado está vinculada al cálculo. Procesa todo el mensaje de entrada en paralelo para generar el conjunto inicial de entradas de caché de valores clave (KV). La fase de decodificación está ligada a la memoria. Genera de forma autorregresiva un token a la vez y requiere un ancho de banda de memoria sustancial para acceder a los pesos del modelo y al caché KV en constante crecimiento. Además de esta complejidad, las solicitudes de inferencia varían ampliamente en los requisitos computacionales según la longitud de entrada y salida, lo que hace que la utilización eficiente de los recursos sea particularmente desafiante.
Los enfoques tradicionales a menudo implican la implementación de modelos en infraestructura y topología predeterminadas o el uso de estrategias distribuidas básicas que no tienen en cuenta estas fases únicas de la inferencia LLM. Esto conduce a una utilización subóptima de los recursos, con GPU infrautilizadas o sobrecargadas durante las diferentes fases de inferencia. Si bien vLLM ha surgido como un popular motor de inferencia de código abierto que mejora la eficiencia a través de procesamiento por lotes casi continuo y PagedAttention, las organizaciones que implementan a escala aún enfrentan desafíos a la hora de orquestar implementaciones y optimizar las decisiones de enrutamiento en múltiples nodos.
Anunciamos un esfuerzo conjunto con el equipo de llm-d para brindar potentes capacidades de inferencia desagregada a AWS para que los clientes puedan aumentar el rendimiento, maximizar la utilización de GPU y mejorar los costos para atender cargas de trabajo de inferencia a gran escala. Este lanzamiento es el resultado de varios meses de estrecha colaboración con la comunidad de llm-d para ofrecer un nuevo contenedor ghcr.io/llm-d/llm-d-aws que incluye bibliotecas específicas de AWS, como Elastic Fabric Adapter (EFA) y libfabric, junto con la integración de llm-d con la biblioteca NIXL para admitir características críticas como la inferencia desagregada de múltiples nodos y el paralelismo experto. También hemos realizado evaluaciones comparativas exhaustivas a través de múltiples iteraciones para llegar a una versión estable que permita a los clientes acceder a estas poderosas capacidades listas para usar en sistemas AWS Kubernetes como Amazon SageMaker HyperPod y Amazon Elastic Kubernetes Service (Amazon EKS).
A lo largo de esta publicación de blog, presentamos los conceptos detrás de las capacidades de inferencia de próxima generación, incluido el servicio desagregado, la programación inteligente de solicitudes y el paralelismo experto. Analizamos sus beneficios y explicamos cómo implementarlos en Amazon SageMaker HyperPod EKS para lograr mejoras significativas en el rendimiento de inferencia, la utilización de recursos y la eficiencia operativa.
¿Qué es llm-d?
llm-d es un marco nativo de Kubernetes de código abierto para servir modelos distribuidos de lenguaje grande (LLM). Construido sobre vLLM, llm-d amplía el motor de inferencia central con orquestación de nivel de producción, programación avanzada y soporte de interconexión de alto rendimiento para permitir un servicio de modelos escalable de múltiples nodos.
En lugar de tratar la inferencia como un problema de ejecución de un solo nodo, llm-d introduce patrones arquitectónicos para el servicio desagregado, separando y mejorando etapas como el prellenado, la decodificación y la gestión de caché KV en los recursos de GPU distribuidos. Esto permite a los operadores utilizar eficientemente estructuras de alta velocidad como AWS Elastic Fabric Adapter (EFA), manteniendo al mismo tiempo la compatibilidad con los flujos de trabajo de implementación nativos de Kubernetes.
Para que estas capacidades sean accesibles, llm-d proporciona un conjunto de caminos bien iluminados: arquitecturas de servicio de referencia que incluyen estrategias de optimización comprobadas para diferentes objetivos de rendimiento, escalabilidad y carga de trabajo:
Programación de inferencia inteligente
Si bien el ejemplo de programación inteligente toma decisiones de enrutamiento basándose en otros factores, como la profundidad de la cola, su enfoque único para el enrutamiento es que intenta adivinar la localidad de las solicitudes en KVcache, sin requerir que tenga visibilidad del estado de KVCache. En un entorno de instancia única, motores como vLLM utilizan el almacenamiento en caché de prefijos automático para reducir el cálculo redundante al reutilizar entradas de caché KV anteriores, lo que genera un rendimiento más rápido y eficiente. Sin embargo, en el momento en que se escala a un entorno distribuido de múltiples réplicas, las suposiciones sobre qué kvblocks existen en qué GPU no se pueden sostener. Sin conocimiento de la localidad de las solicitudes en sus estados intermediarios, las solicitudes podrían enrutarse a instancias que carecen de un contexto almacenado en caché relevante, anulando por completo los beneficios del almacenamiento en caché de prefijos.
El programador llm-d soluciona esto manteniendo la visibilidad del estado de la caché en todas las réplicas de servicio y enrutando las solicitudes en consecuencia. Para cargas de trabajo con alta reutilización de prefijos, como conversaciones de varios turnos o flujos de trabajo agentes, este enrutamiento con reconocimiento de caché puede generar mejoras significativas en el rendimiento y la latencia al garantizar que las solicitudes se dirijan a servidores que ya contienen entradas de caché KV relevantes.
Desagregación de prellenado y decodificación
Como se describió anteriormente, las fases de prellenado y decodificación de la inferencia LLM tienen perfiles de recursos fundamentalmente diferentes: el prellenado requiere un uso intensivo de computación y la decodificación requiere un uso intensivo de ancho de banda de memoria. En una implementación tradicional, ambas fases comparten el mismo hardware, lo que significa que ninguna se puede optimizar de forma independiente. Separar estas dos fases abre varias oportunidades de optimización. Por ejemplo, si la longitud del contexto de salida es mayor que la longitud de la entrada, puede asignar más GPU para decodificar que para precompletar. También puede colocar estas dos fases en diferentes tipos de hardware, cada uno adaptado a sus respectivas características de carga de trabajo.
En llm-d, los servidores de precarga están optimizados para procesar mensajes de entrada de manera eficiente, mientras que los servidores de decodificación se centran en generar tokens de salida con baja latencia. El programador inteligente decide qué instancias deben recibir una solicitud determinada y la transferencia se coordina mediante un sidecar que se ejecuta junto con las instancias de decodificación. El sidecar indica a vLLM que realice transferencias de caché KV punto a punto a través de interconexiones rápidas para garantizar que el servidor de decodificación reciba el contexto en caché necesario del servidor de precarga con una sobrecarga mínima. Esta desagregación mejora significativamente tanto el tiempo hasta el primer token (TTFT) como el rendimiento general, particularmente para cargas de trabajo con solicitudes largas o cuando se procesan modelos grandes.
Amplio paralelismo experto
Para modelos de mezcla de expertos (MoE) como DeepSeek-R1, Qwen3.5, Minimax y Kimi K2.5, llm-d proporciona patrones de implementación optimizados que utilizan paralelismo de datos y paralelismo experto. Este enfoque permite la implementación eficiente de grandes modelos MoE al distribuir expertos horizontalmente en múltiples nodos mientras se mantiene el rendimiento. Al distribuir expertos en modelos entre aceleradores y utilizar patrones de comunicación mejorados, llm-d puede reducir significativamente la latencia de un extremo a otro y aumentar el rendimiento de estas arquitecturas complejas. Sin embargo, la ampliación de los modelos MoE introduce requisitos de paralelismo, comunicación y programación más complejos que deben ajustarse cuidadosamente para cada escenario de implementación.
Almacenamiento en caché de prefijos por niveles
El almacenamiento en caché de prefijo evita realizar cálculos de caché KV costosos y repetitivos, lo que mejora métricas como TTFT y el rendimiento general. Si bien los motores de inferencia como vLLM tienen incorporado el almacenamiento en caché de prefijos nativos, están limitados por la cantidad de memoria de GPU disponible en una instancia determinada. Para ampliar el tamaño efectivo de la caché KV más allá de los límites de la memoria de la GPU, llm-d ofrece una ruta de almacenamiento en caché por niveles que descarga las entradas de la caché KV de la memoria de la GPU a otros niveles de almacenamiento, como la memoria de la CPU o el disco local.
Estos caminos bien iluminados se ofrecen como puntos de partida para la configuración e implementación de servidores modelo. Están diseñados como bloques de construcción componibles para implementaciones de vLLM y configuración del programador de inferencia, lo que significa que las funciones de múltiples rutas se pueden combinar y configurar juntas para adaptarse a requisitos de carga de trabajo específicos.
Ejecutando llm-d en AWS
Amazon SageMaker HyperPod EKS
Amazon SageMaker HyperPod ofrece una infraestructura de Kubernetes resistente y de alto rendimiento optimizada para la inferencia y el entrenamiento de modelos a gran escala. Proporciona clústeres persistentes y de alto rendimiento que abordan muchos de los desafíos de infraestructura que enfrentan las organizaciones al implementar modelos grandes. La supervisión del estado está integrada en el sistema, con detección y corrección proactivas de fallos de hardware para mantener una alta disponibilidad para las cargas de trabajo de producción. La compatibilidad nativa con Kubernetes simplifica la orquestación de contenedores, lo que la convierte en una base ideal para la arquitectura nativa de Kubernetes de llm-d.
Arquitectura de referencia
Para comprender cómo opera llm-d de manera eficiente en la infraestructura de AWS, es importante comprender las capas de comunicación que permiten la inferencia distribuida de alto rendimiento. Para la comunicación de GPU a GPU en un solo nodo, NVLink y NVSwitch se utilizan para transferencias de gran ancho de banda entre trabajadores de precarga y decodificación. Las siguientes secciones describen los componentes clave y cómo funcionan juntos.
NIXL para transferencias de inferencia punto a punto
NCCL, que se usa ampliamente en la capacitación de LLM, se destaca en los patrones de comunicación colectiva; las arquitecturas de inferencia desagregadas requieren transferencias de datos eficientes de punto a punto, por ejemplo, mover datos de caché KV de un nodo de precarga a un nodo de decodificación. La biblioteca NVIDIA Inference Xfer (NIXL) está diseñada específicamente para este escenario. NIXL proporciona una capa de abstracción de memoria que abarca la memoria de la CPU, la memoria de la GPU y los backends de almacenamiento, incluidos almacenes de archivos, bloques y objetos como Amazon S3. Funciona como una capa de abstracción sobre diferentes métodos de transferencia, incluido libfabric para interfaces EFA, UCCL y GPUDirect Storage.
A través de NIXL, las instancias transfieren datos de caché KV entre servidores de precarga y decodificación mediante RDMA. RDMA permite a las GPU omitir el sistema operativo y leer la memoria del dispositivo par directamente, lo cual es fundamental para cargas de trabajo de inferencia donde TTFT es una métrica de rendimiento clave. En la arquitectura llm-d, los servidores vLLM se implementan en InferencePools para el enrutamiento, y la desagregación de precarga/decodificación se configura utilizando NIXL como conector para compartir caché KV. NIXL aprovecha las interfaces EFA conectadas a instancias para una comunicación de gran ancho de banda, asegurándose de que la sobrecarga de transferir el contexto almacenado en caché entre fases desagregadas siga siendo mínima.
UCX y la capa de transporte
Unified Communication X (UCX) es un marco de comunicación de nivel inferior que proporciona la capa de transporte que NIXL puede usar para la comunicación entre nodos. UCX admite operaciones RDMA que permiten la creación de redes sin copia y sin kernel, lo cual es fundamental para minimizar la latencia y maximizar el ancho de banda en cargas de trabajo distribuidas. Es importante destacar que UCX tiene soporte nativo para AWS Elastic Fabric Adapter (EFA) a través de la interfaz libfabric, lo que proporciona la tubería de alto rendimiento en la que NCCL confía cuando las GPU necesitan comunicarse entre nodos.
Adaptador de tela elástica (EFA)
EFA proporciona una interfaz de red de alto rendimiento en AWS, que es esencial para escalar la inferencia distribuida en múltiples nodos. EFA utiliza libfabric como interfaz de espacio de usuario y UCX incluye una capa de transporte libfabric que puede aprovechar EFA directamente. Esta integración significa que cuando llm-d implementa vLLM en múltiples nodos, la pila de comunicación subyacente puede aprovechar al máximo la red de baja latencia y alto ancho de banda de EFA sin requerir cambios a nivel de aplicación.
Podemos configurar el controlador AWS Load Balancer para aprovisionar balanceadores de carga para conectarse a Inference Gateway. La puerta de enlace de inferencia (IGW) se ubica frente a las instancias de vLLM y proporciona programación y enrutamiento de solicitudes inteligentes en función de varios factores, incluida la localidad de la caché y la carga del servidor. KV Cache Manager permite el enrutamiento con reconocimiento de caché y la gestión de caché distribuida, rastreando qué bloques de caché KV residen en qué nodos. Estos componentes trabajan juntos para crear un sistema flexible y extensible para la inferencia LLM que aborda los desafíos únicos de servir modelos grandes a escala.
Con los paneles de observabilidad de SageMaker HyperPod, puede monitorear métricas clave durante el tiempo de inferencia, como la utilización de GPU, métricas de EFA y recuentos de errores para monitorear y optimizar de manera proactiva sus cargas de trabajo de inferencia.
Mejores prácticas
La inferencia desagregada le permite escalar sus nodos de precarga por separado a sus nodos de decodificación, lo que le permite ajustar su rendimiento para sus cargas de trabajo. Por ejemplo, las longitudes de secuencia de entrada más grandes con longitudes de secuencia de salida más cortas suponen una carga de trabajo pesada para el prerrelleno. La inferencia desagregada le permite escalar sus grupos de precarga para manejar más solicitudes de manera eficiente sin aumentar el costo. Sin embargo, no es para todas las cargas de trabajo. Puede probarlo con modelos más grandes, secuencias de entrada más largas y arquitecturas MoE escasas.
llm-d también proporciona rutas para enrutar el tráfico de forma inteligente a pods específicos en función de métricas como colas de solicitudes y eventos de caché KV a través de la puerta de enlace de inferencia. Esto funciona para mejorar el rendimiento y los aciertos de caché KV para cargas de trabajo de inferencia LLM para mejorar el rendimiento. El proyecto aún se está desarrollando y agregando más rutas y mejoras para alojar cargas de trabajo de LLM.
Descripción general de la implementación
Requisitos previos
Antes de continuar con la implementación de cualquiera de los patrones, necesita configurar los siguientes componentes localmente en su dispositivo:
Configuración de llm-d
llm-d utiliza la extensión API Gateway Inference, que requiere la instalación de CRD y una implementación como Istio. Clone el repositorio llm-d y navegue hasta el asistente de instalación:
Instalar el proveedor y la implementación.
Una vez instaladas, puede comenzar a implementar las guías.
Implementación del modelo
El repositorio llm-d proporciona una serie de rutas bien iluminadas para la inferencia en Kubernetes ubicadas en su GitHub. Cada guía se configura mediante un archivo helm y se divide en dos carpetas. Uno para Gateway AI Extension, que configura Kubernetes Gateway y otro para el servicio modelo, que configura la configuración de alojamiento del modelo.
Imagen de Docker con bibliotecas de AWS: ghcr.io/llm-d/llm-d-aws:v0.5.1
Para exponer una puerta de enlace con un balanceador de carga de AWS, puede configurar el tipo y las anotaciones requeridas en ./guides/prereq/gateway-provider/common-configurations.
Por ejemplo, configuramos ./guides/prereq/gateway-provider/common-configurations/istio.yaml como
Cuando se crea Istio Gateway, proporcionará un equilibrador de carga de red en su VPC para su uso. Desde aquí, puede configurar el ejemplo según las instrucciones del archivo README para implementar la pila. Para comenzar a ejecutar el ejemplo de programación de inferencias, desde el directorio llm-d ejecute:
Aquí verá la estructura que aparece como:
La carpeta ms-inference-scheduling contiene los valores de configuración para ejecutar réplicas de vLLM en sus nodos. gaie-inference-scheduling configurará la puerta de enlace de inferencia utilizando el proveedor seleccionado anteriormente.
Una vez que esté listo para implementar, ejecute helmfile apply para implementar la guía en su clúster.
Implementación con desagregación previa al llenado y decodificación
La guía para implementar con desagregación de prellenado/decodificación se encuentra en guías/pd-desagregación. Para ejecutar dentro de un entorno como un clúster de SageMaker HyperPod, debe configurar las réplicas para que se ejecuten utilizando una imagen habilitada para EFA y asegurarse de asignar interfaces EFA a los pods.
Dentro de ms-pd/values.yaml, lo configura de manera similar a:
La imagen debe utilizar el contenedor compatible con AWS de llm-d. vLLM está configurado donde NIXL utilizará el backend libfabric para maximizar el ancho de banda de la red. Para configurar la cantidad de interfaces EFA, debe realizar la asignación según la cantidad de GPU con las que se ejecuta cada pod y la cantidad de interfaces EFA disponibles en la instancia. Por ejemplo, una instancia p5.48xlarge tiene 8 GPU H100 con 32 interfaces de adaptador Elastic Fabric, por lo que debe configurar cada réplica para que tenga 4 interfaces EFA por GPU.
Opcionalmente, también puede configurar "enable_cross_layers_blocks": "True" para kv_connector_extra_config para reducir la cantidad de datos que transferirá vLLM.
Ejecución de inferencia
Una vez implementado, EKS habrá creado un balanceador de carga de red de AWS para su implementación. Para obtener el nombre DNS del equilibrador de carga, ejecute kubectl get gateways. Luego puedes invocar esto con curl:
Inferencia desagregada
Evaluación comparativa
Implementamos GPT-OSS de OpenAI en vLLM con un grado de tensor paralelo de 4 en un ml.p6-b200.48xlarge. Lo comparamos con la ruta de llm-d para la desagregación de precarga/decodificación con 4 pods de precarga, cada uno con un grado de tensor paralelo de 1 y 1 pod de decodificación con un grado de tensor paralelo de 4. Los pods se conectaron usando NIXL con Libfabric como backend de transporte subyacente para usar redes de Elastic Fabric Adapter en las instancias.
En nuestras pruebas, descubrimos que el uso de la ruta de desagregación de prellenado/decodificación de llm-d aumenta los tokens por segundo hasta en un 70 % a medida que aumenta la concurrencia en comparación con el uso de una implementación de vLLM estándar cuando se realizan pruebas de carga con una secuencia de entrada de 1024 tokens de entrada y se reciben 1024 tokens de salida hasta una concurrencia de 128. Este perfil de rendimiento varía según la configuración y la carga de trabajo de vLLM. Ajustar la proporción de precarga/decodificación y otros parámetros disponibles en el servidor vLLM puede generar potencialmente un mayor rendimiento.
Conclusión
llm-d proporciona rutas para métodos de implementación como desagregación de prellenado/decodificación, enrutamiento preciso con reconocimiento de KV y almacenamiento en caché de KV por niveles. Estos proporcionan métodos adicionales para mejorar el rendimiento del alojamiento a escala. Puede ajustar la configuración de vLLM según sea necesario para mejorar métricas como TTFT, ITL o aciertos de caché. También puede utilizar marcos como LMCache para la descarga de KV. Consulte llm-d en https://llm-d.ai/docs/architecture
Sobre los autores
Vivek Gangasani
Vivek Gangasani es líder mundial en arquitectura de soluciones, SageMaker Inference. Dirige la arquitectura de soluciones, la comercialización técnica (GTM) y la estrategia de productos salientes para SageMaker Inference. También ayuda a empresas y nuevas empresas a implementar y optimizar modelos GenAI y a crear flujos de trabajo de IA con SageMaker y GPU. Actualmente, se centra en desarrollar estrategias y contenidos para optimizar el rendimiento de la inferencia y casos de uso, como flujos de trabajo Agentic, RAG, etc. En su tiempo libre, Vivek disfruta hacer senderismo, ver películas y probar diferentes cocinas.
Andrés Smith
Andrew Smith es ingeniero senior de soporte en la nube en el equipo de SageMaker, Vision & Other en AWS, con sede en Sydney, Australia. Apoya a los clientes que utilizan muchos servicios de IA/ML en AWS con experiencia en el trabajo con Amazon SageMaker. Fuera del trabajo, le gusta pasar tiempo con amigos y familiares, así como aprender sobre diferentes tecnologías.
Annem Goutham
Goutham Annem es gerente técnico senior de cuentas en AWS, con sede en el Área de la Bahía, California. Se asocia con clientes para diseñar y optimizar la infraestructura de la nube con un enfoque en la escalabilidad, la confiabilidad y el rendimiento, respaldando la implementación de cargas de trabajo en contenedores, soluciones GenAI, canalizaciones MLOps y estrategias técnicas que impulsan los resultados comerciales. Es un entusiasta de los deportes con especial afición por el bádminton y el cricket, y con frecuencia realiza caminatas en el Área de la Bahía para conectarse con la naturaleza.