Ray 2.55 añade tolerancia a fallos para despliegues de modelos de IA a gran escala

Joerg Hiller 02 abr 2026 18:35

La actualización de Ray Serve LLM de Anyscale habilita la tolerancia a fallos de grupos DP para despliegues vLLM WideEP, reduciendo el riesgo de tiempo de inactividad para sistemas de inferencia de IA distribuida.

Anyscale ha lanzado una actualización significativa de su framework Ray Serve LLM que aborda un desafío operativo crítico para organizaciones que ejecutan cargas de trabajo de inferencia de IA a gran escala. Ray 2.55 introduce tolerancia a fallos de grupos de datos paralelos (DP) para despliegues de vLLM Wide Expert Parallelism, una característica que previene que fallos de una sola GPU derriben clusters completos de servicio de modelos.

La actualización se dirige a un punto de dolor específico en el servicio de modelos Mixture of Experts (MoE). A diferencia de los despliegues de modelos tradicionales donde cada réplica opera independientemente, las arquitecturas MoE como DeepSeek-V3 fragmentan capas de expertos a través de grupos de GPUs que deben trabajar colectivamente. Cuando una GPU en estas configuraciones falla, el grupo completo—potencialmente abarcando de 16 a 128 GPUs—se vuelve no operativo.

El problema técnico

Los modelos MoE distribuyen redes neuronales "expertas" especializadas a través de múltiples GPUs. DeepSeek-V3, por ejemplo, contiene 256 expertos por capa pero activa solo 8 por token. Los tokens se enrutan a las GPUs que poseen los expertos necesarios mediante operaciones de despacho y combinación que requieren que todos los rangos participantes estén saludables.

Anteriormente, un fallo de un solo rango rompería estas operaciones colectivas. Las consultas continuarían enrutándose a las réplicas supervivientes en el grupo afectado, pero cada solicitud fallaría. La recuperación requería reiniciar el sistema completo.

Cómo lo resuelve Ray

Ray Serve LLM ahora trata cada grupo DP como una unidad atómica mediante programación en grupo. Cuando un rango falla, el sistema marca el grupo completo como no saludable, detiene el enrutamiento de tráfico hacia él, desmonta el grupo fallido y lo reconstruye como una unidad. Otros grupos saludables continúan sirviendo solicitudes durante todo el proceso.

La característica se envía habilitada por defecto en Ray 2.55. Los despliegues DP existentes no requieren cambios de código—el framework maneja verificaciones de salud a nivel de grupo, programación y recuperación automáticamente.

El autoescalado también respeta estos límites. Las operaciones de escalado hacia arriba y hacia abajo ocurren en incrementos del tamaño del grupo en lugar de réplicas individuales, previniendo la creación de grupos parciales que no pueden servir tráfico.

Implicaciones operativas

La actualización crea una consideración de diseño importante: ancho de grupo versus número de grupos. Según los benchmarks de vLLM citados por Anyscale, el rendimiento por GPU permanece relativamente estable a través de tamaños de paralelismo de expertos de 32, 72 y 96. Esto significa que los operadores pueden ajustar hacia grupos más pequeños sin sacrificar eficiencia—y grupos más pequeños significan radios de explosión más pequeños cuando ocurren fallos.

Anyscale señala que esta resiliencia a nivel de orquestación complementa el trabajo de elasticidad a nivel de motor que está ocurriendo en la comunidad vLLM. El RFC de vLLM Elastic Expert Parallelism aborda cómo el tiempo de ejecución puede ajustar dinámicamente la topología dentro de un grupo, mientras que Ray Serve LLM gestiona qué grupos existen y reciben tráfico.

Para organizaciones que despliegan modelos estilo DeepSeek a escala, el beneficio práctico es directo: los fallos de GPU se convierten en incidentes localizados en lugar de interrupciones en todo el sistema. Las muestras de código y pasos de reproducción están disponibles en el repositorio de GitHub de Anyscale.

• ray
• vllm
• infraestructura de IA
• machine learning
• computación distribuida