El equipo de Azure Kubernetes Service (AKS) de Microsoft ha compartido recomendaciones para ejecutar el servicio gestionado Ray de Anyscale a escala. Se centran en tres problemas clave: los límites de capacidad de las GPU, el almacenamiento de ML disperso y los problemas con la caducidad de las credenciales.
Esta publicación amplía una visión general anterior de KubeRay en AKS de código abierto. Ahora, destaca el runtime mejorado de Anyscale, anteriormente conocido como RayTurbo. Este runtime ofrece escalado automático inteligente, monitorización mejorada y funciones de entrenamiento tolerante a fallos, todo ello basado en el framework Ray de código abierto.
Ray es un framework de computación distribuida nativo de Python diseñado para escalar cargas de trabajo de IA y ML desde un único portátil hasta clústeres que abarcan miles de nodos. La plataforma gestionada de Anyscale mejora Ray con funciones para su uso en producción. La nueva guía muestra una colaboración entre Microsoft y Anyscale para mejorar la integración con Azure.
La escasez de GPU es uno de los mayores desafíos operativos en el ML a gran escala. Los aceleradores de alta demanda, como las GPU NVIDIA, a menudo tienen problemas de cuota y disponibilidad en las regiones de Azure, lo que puede retrasar la configuración del clúster y la programación de trabajos.
La solución propuesta por Microsoft utiliza una configuración multi-clúster y multi-región. Distribuir los clústeres Ray en diferentes instancias de AKS en varias regiones de Azure permite a los equipos: agregar cuota de GPU más allá de los límites regionales, redirigir automáticamente las cargas de trabajo durante las interrupciones o los problemas de capacidad y extender el grupo de computación a sistemas locales u otros proveedores de la nube utilizando Azure Arc con AKS.
La consola de Anyscale muestra estos clústeres registrados en una sola vista. Anyscale Workspaces gestiona la programación de cargas de trabajo utilizando la capacidad disponible, ya sea manualmente o automáticamente. Puede agregar nuevas regiones creando un manifiesto cloud_resource.yaml y luego aplicándolo mediante la CLI de Anyscale. Este enfoque basado en la configuración facilita la gestión de la expansión multi-región.
Un problema común en las operaciones de ML es la transferencia de datos de entrenamiento, puntos de control y artefactos entre las etapas de la canalización, incluyendo su movimiento desde el pre-entrenamiento hasta el ajuste fino y luego a la inferencia. La guía aborda esto con Azure BlobFuse2, que monta Azure Blob Storage en los pods de trabajador de Ray como un sistema de archivos compatible con POSIX.
Desde la perspectiva de Ray, el punto de montaje es simplemente un directorio local. Las tareas y los actores leen conjuntos de datos y escriben puntos de control utilizando la E/S de archivos estándar. BlobFuse2 luego guarda los datos en Azure Blob Storage, lo que los hace disponibles en todos los pods y grupos de nodos. El almacenamiento en caché local evita los bloqueos de la GPU durante las ejecuciones de entrenamiento a gran escala y, dado que los datos están desacoplados de la computación, los clústeres Ray pueden escalar hacia arriba y hacia abajo sin pérdida de datos.
Para configurar, habilite el controlador CSI de blob al crear el clúster. Luego, defina una StorageClass que utilice la identidad de carga de trabajo para la autenticación. Finalmente, cree una PersistentVolumeClaim con acceso ReadWriteMany. Esto permite que varios trabajadores de Ray en diferentes nodos accedan a los datos compartidos al mismo tiempo. Este enfoque hace que el código de Ray sea portátil y agrega la durabilidad y la escalabilidad del almacenamiento nativo de Azure a la capa de infraestructura.
Otro tema importante es la fiabilidad de la autenticación. Anteriormente, Anyscale y Azure se integraban con tokens de CLI o claves de API que caducaban cada 30 días. Esto significaba que era necesaria una rotación manual, lo que corría el riesgo de interrumpir el servicio.
El nuevo método utiliza Microsoft Entra service principals y AKS workload identity. Emite tokens de corta duración automáticamente. El pod del operador de Kubernetes de Anyscale utiliza una identidad administrada asignada por el usuario. Esta identidad solicita un token de acceso para el principal de servicio de Anyscale desde Entra ID. Azure gestiona la actualización de los tokens de forma transparente, lo que significa que no se almacenan credenciales de larga duración en el clúster y no se requiere una rotación manual.
Los autores señalan que esto es especialmente importante en entornos multi-clúster. Aquí, la gestión manual de las credenciales en muchos clústeres aumenta la carga operativa. El modelo de identidad de carga de trabajo proporciona RBAC granular para el acceso a los recursos de Azure y produce pistas de auditoría completas a través de los registros de actividad de Azure como subproducto.
La integración de Anyscale en AKS está actualmente en vista previa privada. Los equipos que deseen acceder deben comunicarse con su equipo de cuenta de Microsoft. También pueden presentar una solicitud en el repositorio de GitHub de AKS. Incluya detalles sobre las cargas de trabajo de Ray y las regiones objetivo. Puede consultar configuraciones de ejemplo y cargas de trabajo para el ajuste fino con DeepSpeed y LLaMA-Factory en el repositorio Azure-Samples/aks-anyscale en GitHub. Esto también incluye puntos finales de inferencia LLM.
Microsoft no es la única entidad que apuesta por esto. AWS anunció su asociación con Anyscale en Ray Summit 2024. Esto conecta los clústeres de EKS con el runtime RayTurbo. Destaca la flexibilidad del hardware al combinar las GPU NVIDIA con los aceleradores Trainium e Inferentia de AWS. Además, SageMaker HyperPod es ahora un destino de implementación para trabajos de entrenamiento de larga duración que necesitan resistencia a nivel de nodo. Google Cloud lidera las contribuciones de código abierto.
El equipo de GKE trabajó con ingenieros de Anyscale para integrar la programación basada en etiquetas en Ray v2.49. También crearon una capa ray.util.tpu para reducir la fragmentación de recursos en configuraciones de TPU multi-chip. Además, agregaron la asignación dinámica de recursos para las nuevas instancias respaldadas por GB200.
Los tres hiperescaladores han elegido el mismo operador gestionado de Ray y cada uno ha agregado su infraestructura. Esto demuestra que la industria prefiere Kubernetes más Ray para las cargas de trabajo de IA. Ahora, la competencia es menos sobre el runtime y más sobre qué nube puede optimizar mejor la infraestructura circundante.
