Precompletar y decodificar desagregados para la inferencia de LLM en SageMaker HyperPod

Cuando el prellenado y la decodificación comparten una GPU, los mensajes largos detiene la generación de tokens para cada solicitud simultánea. El prellenado y decodificación desagregados (DPD) elimina esta interferencia al ejecutar cada fase en grupos de GPU separados conectados a través de Elastic Fabric Adapter (EFA) con acceso remoto directo a memoria (RDMA). La inferencia del modelo de lenguaje grande (LLM) tiene dos fases fundamentalmente diferentes. El prerrelleno está vinculado a la computación. Procesa todo el mensaje de entrada en paralelo para generar la caché de valor-clave (KV) inicial. La decodificación está ligada a la memoria. Genera un token a la vez y requiere un ancho de banda de memoria sustancial para acceder a los pesos del modelo y al creciente caché KV. Al desagregarlos en motores especializados, puede asignar diferentes estrategias paralelas a cada fase. Con esta separación, puede ajustar el tiempo hasta el primer token (TTFT) y la latencia entre tokens (ITL) de forma independiente, controlar la latencia de cola de manera más confiable que el ajuste de precarga fragmentado y evitar que los precargas de contexto largo bloqueen las solicitudes de decodificación en curso. vLLM mejora la eficiencia de un solo nodo mediante procesamiento por lotes continuo y PagedAttention. Sin embargo, las organizaciones que implementan a escala aún enfrentan desafíos cuando organizan implementaciones de múltiples nodos y optimizan el enrutamiento.

En esta publicación, mostramos cómo implementar DPD con vLLM en Amazon SageMaker HyperPod mediante el operador de inferencia HyperPod.

Cuándo utilizar la inferencia desagregada

La desagregación del precompletado y la decodificación ofrece las mayores ganancias para cargas de trabajo de transmisión de contexto largo y alta concurrencia: asistentes de chat, canalizaciones de agentes, puntos finales de análisis de documentos y generación aumentada de recuperación (RAG) con grandes contextos recuperados. En estos casos, un único mensaje largo en una GPU colocada detiene la decodificación en curso para cualquier otra solicitud, lo que provoca picos de latencia por token que DPD elimina mediante construcción.

Considere DPD cuando su carga de trabajo tenga:

Mensajes de entrada que regularmente superan los 4096 tokens. Múltiples usuarios o solicitudes simultáneas. Transmisión de respuestas donde es importante la entrega constante de tokens. Tráfico mixto con indicaciones tanto largas como cortas.

Una implementación coubicada es la opción más sencilla cuando la contención de GPU no es una preocupación real: cargas de trabajo por lotes o fuera de línea que se optimizan para TTFT, implementaciones de baja concurrencia o tráfico de mensajes breves. Por debajo del umbral de enrutamiento, el costo fijo de transferir la caché KV a través de EFA RDMA supera el beneficio de aislar la decodificación. El enrutador DPD envía esas solicitudes directamente a un decodificador. Por lo tanto, un único punto final maneja automáticamente el tráfico mixto largo y corto, sin lógica de enrutamiento manual.

DPD requiere como mínimo un nodo de precarga y un nodo de decodificación con red EFA compatible con RDMA. Para conocer los tipos de instancias admitidos, consulte la sección Implementar un punto final de modelo DPD en su clúster HyperPod.

Arquitectura

La implementación de HyperPod DPD se basa en el enrutador vLLM Production Stack, y LMCache proporciona la capa de transferencia de caché KV a través de NIXL y EFA. La implementación tiene tres componentes más una pila de transporte.

enrutador inteligente

El enrutador es el plano de control. Tokeniza cada mensaje y aplica un umbral de token configurable para decidir si la solicitud toma la ruta desagregada o se ejecuta de un extremo a otro en un decodificador. Las indicaciones de contexto largo pasan por un precarga y luego por un decodificador. Las indicaciones breves omiten el precarga, evitando la transferencia KV entre GPU que no vale la pena. Para solicitudes desagregadas, indica al precompletador que calcule y envíe la caché KV a un decodificador, luego reenvía la solicitud a ese decodificador para su generación. También admite estrategias de enrutamiento por precarga (prefixaware, kvaware, sesión, roundrobin) a través de intelligentRoutingSpec.routingStrategy para maximizar la localidad de caché entre réplicas.

Vaina de precarga

El precompletador es un trabajador vLLM con LMCache como conector KV a través de LMCacheConnectorV1. Calcula el caché KV para indicaciones largas y lo envía al decodificador elegido a través del backend del remitente PD de LMCache capa por capa, superponiendo el cálculo y la transferencia para mantener sus GPU saturadas. LMCache también proporciona a cada precarga una caché de CPU L1. Cuando se repite un prefijo (indicaciones del sistema, historial de múltiples turnos, contextos de recuperación), se sirve desde la memoria de la CPU sin volver a calcular la GPU. Esto produce ganancias TTFT significativas. La activación de DPD en un InferenceEndpointConfig aprovisiona tanto el conector como la caché automáticamente.

Vaina decodificadora

El decodificador es un trabajador vLLM con LMCache como receptor. Reserva memoria de GPU (el búfer PD, dimensionado por PD_BUFFER_SIZE) para transferencias KV entrantes. Ejecuta gráficos CUDA completos para el núcleo de decodificación y comienza la generación tan pronto como se completa la transferencia. Debido a que nunca ejecuta el llenado previo, la latencia de decodificación se mantiene estable en condiciones de concurrencia y agregar una solicitud de contexto largo nunca perturba los tokens que ya se transmiten.

transferencia KV

La transferencia de caché KV utiliza una pila de cuatro capas (LMCache PD → NIXL → libfabric → EFA) que HyperPod compone de un extremo a otro. El backend PD de LMCache organiza la recuperación del lado del precarga y del lado del decodificador. NIXL proporciona una abstracción de memoria unificada entre GPU, CPU y pares remotos y selecciona la operación RDMA correcta. El proveedor libfabric expone EFA como GPU-Direct RDMA de derivación del kernel, manteniendo la CPU host fuera de la ruta de datos. Esto hace que el costo de transferencia sea insignificante en relación con el cálculo previo al llenado: en ml.p5.48xlarge con 3200 Gbps de EFA, una transferencia de 8000 tokens para Llama 3.3 70B toma milisegundos de un solo dígito. HyperPod envía la pila preintegrada, por lo que usted selecciona una imagen de trabajador compatible con DPD y el operador conecta el conector, NIXL y EFA en cada módulo.

Descripción general de la implementación

Precompletar y decodificar desagregados (DPD) es una funcionalidad implementada por el operador de inferencia HyperPod. Esta sección cubre los requisitos previos, la instalación del operador de inferencia y la implementación de un punto final de inferencia que utiliza DPD para brindar servicio eficiente a un modelo Llama 70B.

Requisitos previos e instalación del operador de inferencia HyperPod

Asegúrese de tener la interfaz de línea de comandos de AWS (AWS CLI), acceso kubectl a su clúster HyperPod, un token HuggingFace y una cuota de servicio suficiente. Configure su configuración kubectl local para conectarse a su clúster HyperPod. Para obtener más información, consulte Prellenado y decodificación desagregados para la inferencia de HyperPod.

DPD requiere HyperPod Inference Operador versión 3.2 o posterior. El operador se instala de forma predeterminada en los nuevos clústeres HyperPod EKS. Para obtener instrucciones de instalación, configuración y actualización, consulte Desbloquear la implementación eficiente del modelo: configuración simplificada del operador de inferencia en Amazon SageMaker HyperPod.

Verifique la versión de su operador ejecutando:

El resultado es la referencia de la imagen del contenedor completo. La etiqueta al final codifica la versión, por ejemplo:

Si la versión de su operador no está actualizada, actualícela antes de continuar siguiendo las instrucciones de actualización en las Notas de la versión del operador de HyperPod Inference.

Implemente un punto final de modelo DPD en su clúster HyperPod

En este ejemplo, implementamos el modelo Meta Llama 3.3 70B en dos instancias ml.p5.48xlarge. Verifique que las instancias estén disponibles en un grupo de instancias dentro del clúster HyperPod antes de continuar. Para implementaciones de inferencia DPD, elija tipos de instancia que admitan NVLink y EFA. EFA necesita admitir RDMA en modo de lectura y escritura. Esto incluye las familias de instancias P5 y P6 en AWS. Tenga en cuenta que las instancias deben estar ubicadas dentro de la misma zona de disponibilidad (AZ) para la comunicación de gran ancho de banda de EFA. Aunque las familias de instancias G6, G6e y G7e admiten EFA con lectura/escritura RDMA, el rendimiento en instancias de múltiples GPU se ve obstaculizado por la comunicación de GPU a GPU a través de PCIe.

La imagen de trabajo para la implementación de inferencia debe incluir vLLM, LMCache, NVIDIA NIXL y el proveedor libfabric de EFA. Al momento de escribir este artículo, admitimos dos opciones de imagen:

Ubicación del punto de control del modelo

El operador de inferencia HyperPod admite una amplia gama de fuentes de carga de puntos de control, incluidos los depósitos de Amazon Simple Storage Service (Amazon S3), los sistemas de archivos Amazon FSx y la extracción directa desde HuggingFace y el almacenamiento NVMe de la instancia. Para esta publicación, cargamos el punto de control del modelo desde un depósito de Amazon S3.

Verifique que haya descargado el punto de control de su modelo preferido en un depósito S3 en la misma región que su clúster HyperPod. Si aún no lo ha hecho, configure el nombre de su depósito y el token de HuggingFace, luego descargue Meta Llama 3.3 70B Instruct desde HuggingFace y sincronícelo con Amazon S3. Para lograr una red de gran ancho de banda para Amazon S3, le recomendamos ejecutar esto desde una instancia de Amazon Elastic Compute Cloud (Amazon EC2).

Prepare el manifiesto de implementación del modelo y cambie las variables de entorno según sea necesario:

Para conocer la implementación completa de YAML, consulte Implementar un punto final DPD.

Campos relevantes para DPD en el manifiesto de implementación

La mayoría de los campos de InferenceEndpointConfig se comparten con puntos finales que no son DPD y se documentan en la documentación del operador de inferencia. Los campos siguientes son obligatorios o tienen una semántica diferente para DPD.

spec.pdSpec: Declara la topología de prellenado/decodificación y especifica argumentos. La presencia de este campo es lo que hace que el punto final esté desagregado: el operador crea objetos de implementación separados para precompletar y decodificar y los conecta a través del enrutador y el backend de LMCache PD.

Réplicas: escalar precompletar y decodificar de forma independiente. recursos: se aplica a la especificación del pod del rol. Los recursos de trabajador de nivel superior se ignoran para los pods de DPD. Se anulan los valores por función. routeThreshold: umbral de longitud del token por encima del cual las solicitudes utilizan la ruta desagregada. Por debajo del umbral, las solicitudes pasan por alto el precargador y van directamente al decodificador. args: indicadores vLLM específicos para ese rol, combinados en trabajador.args al inicio. Las banderas que ya están en trabajador.args se reemplazan con el valor por rol y las banderas que no están presentes se agregan.

spec.worker.environmentVariables: estas variables de entorno se aplican de forma idéntica a los contenedores de precarga y decodificador. Actualmente no existe ningún campo de variable de entorno por función. Para el comportamiento por función, utilice pdSpec.{prefillSpec,decodingSpec}.args en su lugar.

Más detalles sobre las variables de entorno se encuentran en Implementar un punto final DPD.

Aplicar el manifiesto y validar la implementación.

El operador crea dos objetos de implementación en su espacio de nombres y un enrutador de implementación en el sistema de inferencia de hiperpod. La extracción de imágenes y la carga del modelo tardan unos minutos. Los pods primero ingresan a ContainerCreating y luego pasan a Running a medida que aparecen los contenedores. Enumere los pods en ambos espacios de nombres:

Cada pod de modelo tiene 3 contenedores: el trabajador vLLM, un proxy inverso de Nginx y un recopilador OpenTelemetry. El módulo del enrutador tiene 2 contenedores (enrutador, hotel). La condición IEC informa de preparación:

Invocar el punto final y verificar la transferencia KV

Una vez que el punto final esté listo, envíe un mensaje breve y uno largo para ejercitar ambas rutas de enrutamiento. Verifique los registros de precarga y decodificador para confirmar que la caché KV se esté transfiriendo a través de EFA. Los siguientes comandos suponen que IEC se implementó con ${NAMESPACE}, ${ENDPOINT_NAME} y ${DEPLOYMENT_NAME} configurados como en el manifiesto anterior.

Obtenga los nombres de pod requeridos y la URL del enrutador:

Aviso breve (por debajo del umbral, ruta directa al decodificador)

Ejecute un breve mensaje a través de un pod dentro del clúster que invoca el punto final:

Aviso largo (por encima del umbral, ruta DPD)

Un mensaje por encima del umbral de enrutamiento de 4096 tokens se enruta a través del precargador y luego al decodificador para la generación de tokens. El siguiente ejemplo crea un mensaje de aproximadamente 6000 tokens repitiendo una oración:

Para confirmar que la invocación utilizó la ruta desagregada, podemos verificar los registros del pod del enrutador:

Para el mensaje largo, puede observar el siguiente resultado:

disaggregate=True confirma que la solicitud tomó la ruta previa al llenado. Las dos líneas de solicitud de enrutamiento muestran el salto de precarga seguido del salto de decodificación.

Guía de escala

Actualmente, DPD admite una única réplica de descodificador con varias réplicas de precarga. Esto significa que puede escalar la capacidad de precarga de forma independiente mientras el decodificador permanece fijo en una instancia.

Comience con una proporción de precarga-descodificación de 1:1 para cargas de trabajo equilibradas (chat, generación de código) donde las longitudes de entrada y salida sean comparables. Escale a 2:1 o 3:1 cuando su carga de trabajo tenga mucha carga previa: resumen, clasificación o RAG con contextos recuperados durante mucho tiempo. Esta relación es apropiada cuando observa que TTFT aumenta bajo carga mientras la latencia de salida por token (TPOT) permanece estable.

Con varios prerrellenos, configure intelligentRoutingSpec.routingStrategy en su carga de trabajo. Utilice kvaware para cargas de trabajo con prefijos repetidos (esto maximiza los accesos a la caché L1 en las particiones de precarga). Utilice la sesión para conversaciones de varios turnos que se benefician de mantener el contexto de un usuario en un relleno previo.

Si, por el contrario, TPOT está subiendo y el rendimiento de salida se estanca a pesar de la disponibilidad del precargador, el decodificador único está saturado. En ese caso, aumente PD_BUFFER_SIZE, reduzca max-model-len o reduzca la concurrencia hasta el punto final hasta que esté disponible la compatibilidad con múltiples decodificadores.

Rendimiento de evaluación comparativa

Los puntos de referencia utilizaron genai-bench con indicaciones sintéticas de longitud fija (4096 tokens de entrada, 256 tokens de salida) en los niveles de simultaneidad 8, 16 y 32. Cada nivel de simultaneidad se ejecutó hasta que los resultados se estabilizaron. Configuración de DPD: 1 precarga y 1 decodificador en 2 nodos (16 GPU), enrutamiento compatible con KV, enforce-eager en el precarga y gráficos CUDA en el decodificador. Línea de base: nodo único (8 GPU), mismo modelo y configuración de GPU. Hardware: ml.p5.48xlarge (8x H100 80GB, EFA habilitado). Modelo: Llama-3.3-70B-Instruct con tensor-parallel-size=8 y max-model-len=16,384. Los siguientes gráficos muestran el porcentaje de mejora que ofrece DPD con respecto a la línea base colocada en dos familias de instancias. Las barras más altas indican una mayor ventaja de DPD.

El siguiente gráfico muestra los mismos puntos de referencia en instancias ml.p5en.48xlarge con GPU H200, donde las ganancias de DPD son igualmente pronunciadas.

En ambas configuraciones de hardware, DPD ofrece ganancias consistentes en latencia de salida por token (TPOT), latencia de extremo a extremo y rendimiento a medida que crece la simultaneidad:

La latencia por token se mantiene estable bajo carga. DPD aísla la decodificación de la interferencia de precarga, manteniendo constante el TPOT independientemente de las solicitudes simultáneas de contexto prolongado. Para cargas de trabajo D(4096,256) con simultaneidad 8 a 32, la mejora oscila entre el 22 % con baja simultaneidad y el 66 % con alta simultaneidad en H100, y entre el 28 % y el 48 % en H200. El rendimiento aumenta con la simultaneidad. El decodificador dedicado funciona con total eficiencia gráfica CUDA sin interrupción de precarga. El rendimiento de salida mejora hasta un 35 % en H100 y hasta un 64 % en H200 con mayor simultaneidad. La latencia de un extremo a otro mejora en P50. Los ahorros acumulados de TPOT en los tokens de salida superan el costo de transferencia de KV. E2E P50 mejora entre un 14 y un 32 % en H100 y entre un 29 y un 41 % en H200.

DPD introduce un modesto aumento en el tiempo hasta el primer token debido a la transferencia de caché KV a través de EFA RDMA. Para cargas de trabajo de streaming en las que la entrega constante por token importa más que la respuesta inicial, esta compensación es favorable. El umbral de enrutamiento condicional (4096 tokens predeterminado) está diseñado para garantizar que las solicitudes breves eviten la desagregación por completo, evitando la sobrecarga de transferencia cuando no es necesaria.

Observabilidad

Puede monitorear las métricas de DPD a través de las funciones de observabilidad de SageMaker HyperPod. Para obtener más información, consulte Acelere el desarrollo del modelo básico con observabilidad con un solo clic en Amazon SageMaker HyperPod.

Las métricas de DPD están disponibles en el panel de Inferencia.

Las métricas adicionales que pueden resultar útiles son el uso de CPU/GPU, que está disponible en el panel de Tareas, así como las métricas disponibles en el panel de descripción general del clúster.

Limpiar

Para evitar cargos continuos, elimine los recursos creados durante este tutorial cuando haya terminado de experimentar.

Elimine InferenceEndpointConfig para eliminar el pod de precarga, el pod de decodificación, el enrutador y todos los servicios asociados:

(Opcional) Elimine el modelo de S3 si lo cargó específicamente para este tutorial:

(Opcional) Reduzca o elimine el grupo de instancias HyperPod si las instancias de GPU se aprovisionaron únicamente para esta implementación. Consulte la documentación sobre Gestión de clústeres de HyperPod para obtener instrucciones.

Conclusión

El precarga y decodificación desagregados (DPD) en Amazon SageMaker HyperPod ejecuta el precarga y la decodificación en grupos de GPU separados. Transferencias de caché KV entre ellos a través de EFA utilizando GPU-Direct RDMA. El prerrelleno está vinculado a la computación. La decodificación está limitada al ancho de banda de la memoria. Cuando se colocan, las dos fases compiten por los mismos recursos de GPU. Un solo mensaje largo puede detener la decodificación en vuelo e inflar la latencia por token de cola. Separarlos elimina esa interferencia, produce una latencia más predecible bajo tráfico mixto y le permite escalar cada fase de forma independiente.

El operador de inferencia de HyperPod maneja la orquestación subyacente: aprovisionar el enrutador, conectar los pods de precarga y decodificación e integrarlos con la observabilidad de HyperPod. Para activar DPD, agregue algunos campos al mismo recurso InferenceEndpointConfig que ya usa para puntos finales no desagregados.

Puede comenzar hoy implementando un punto final DPD en su clúster HyperPod EKS siguiendo los pasos de esta publicación. Para obtener más información, visite la documentación de Amazon SageMaker HyperPod, la guía de implementación del modelo HyperPod Inference Operador o pruebe directamente el manifiesto de ejemplo en esta publicación.

Sobre los autores