Práctica de programación de tareas/recursos heterogéneos de Koordinator

prefacio

Koordinator es una nueva generación de sistema de programación de código abierto de Alibaba Cloud basado en la tecnología y la experiencia práctica acumulada en el sistema de programación unificado que construimos en el pasado. Koordinator admite la programación híbrida de varias cargas de trabajo en Kubernetes. Su objetivo es mejorar la eficiencia del tiempo de ejecución y la confiabilidad de las cargas de trabajo (incluidas las cargas de trabajo sensibles a la latencia y las tareas por lotes). Koordinator no solo es bueno en escenarios de departamentos mixtos, sino que también es compatible con escenarios de programación de tareas, como big data y capacitación de IA. Este artículo comparte la experiencia práctica del uso de Koordinator para admitir escenarios heterogéneos de gestión de recursos y programación de tareas.

Los AI/LLM brindan nuevas oportunidades y nuevos desafíos

Desde el lanzamiento de ChatGPT en noviembre de 2022 hasta el presente, la atención y el impacto que ha atraído ChatGPT pueden haber superado casi todos los puntos críticos en la historia de la tecnología de la información. Muchos expertos de la industria han sido conquistados por él. Por ejemplo, Zhang Yong, CEO de Alibaba Cloud, dijo: "Vale la pena rehacer todas las industrias, aplicaciones, software y servicios en función de las capacidades de los modelos grandes". El CEO de NVIDIA, Huang Renxun, dijo que trajo el tiempo de AI iPhone. ChatGPT ha marcado el comienzo de una nueva era, y las empresas nacionales y extranjeras y las instituciones de investigación científica han seguido. Casi todas las semanas, se lanzan uno o más modelos nuevos, que van desde el procesamiento del lenguaje natural, la visión por computadora hasta la investigación científica impulsada por inteligencia artificial, generativo. Las aplicaciones de IA, etc., están floreciendo; los modelos grandes se convierten en la clave para mejorar la eficiencia empresarial y abrir el próximo punto de crecimiento. También está llegando la misma demanda de computación en la nube, infraestructura y sistemas distribuidos.

Para respaldar las necesidades de capacitación de modelos grandes de decenas de miles de millones y cientos de miles de millones de parámetros, la computación en la nube y la infraestructura deben proporcionar recursos de computación y almacenamiento más potentes y escalables. Una de las tecnologías centrales en las que se basa el entrenamiento de modelos grandes es el entrenamiento distribuido.El entrenamiento distribuido necesita transferir una gran cantidad de datos entre múltiples nodos informáticos, por lo que se requiere una red de alto rendimiento con mayor ancho de banda y menor latencia. Para maximizar el rendimiento de los recursos informáticos, de almacenamiento y de red y garantizar la eficiencia de la formación, los sistemas de gestión de recursos y programación deben diseñar estrategias más razonables. Sobre esta base, la infraestructura debe mejorar continuamente en confiabilidad, con capacidades de recuperación de fallas de nodo y tolerancia a fallas para garantizar la operación continua de las tareas de capacitación.

El entrenamiento de modelos grandes es inseparable de los dispositivos informáticos heterogéneos, normalmente la conocida GPU. En el campo de las GPU, NVIDIA aún ocupa una posición dominante, y otros fabricantes, como AMD y los fabricantes de chips nacionales, luchan por ponerse al día. Tomando a NVIDIA como ejemplo, sus sólidas capacidades de diseño de productos, su solidez técnica y su estrategia de mercado flexible le permiten lanzar rápidamente mejores chips, pero la arquitectura de los productos es bastante diferente, como el modelo NVIDIA A100 y el sistema modelo NVIDIA H100. las diferencias son muy obvias, y hay muchos detalles a los que se debe prestar atención en la forma de uso, lo que trae muchos desafíos al sistema de programación de nivel superior y al sistema de gestión de recursos.

La poderosa combinación de Koordinator+KubeDL

En el escenario de entrenamiento de modelos grandes respaldado por Alibaba Cloud, usamos Koordinator para resolver los requisitos básicos de programación de tareas y los requisitos de administración de recursos de dispositivos heterogéneos. Al mismo tiempo, use KubeDL para administrar el ciclo de vida del trabajo de capacitación y los requisitos de programación y colas de trabajo de capacitación.

Koordinator no solo es bueno en escenarios de programación de departamentos mixtos, sino que también proporciona capacidades generales de programación de tareas, incluida la programación de cuotas elásticas y la programación de grupos para escenarios de entrenamiento de modelos de inteligencia artificial y big data. Además, tiene capacidades de gestión de programación de recursos de granularidad fina, no solo admite la asignación centralizada de GPU, sino que también percibe la topología del sistema de hardware para asignar recursos, y admite capacidades de asignación conjunta y uso compartido de dispositivos de GPU y RDMA.

Elegimos usar KubeDL para administrar el ciclo de vida del trabajo de capacitación porque no solo admite una gran cantidad de escenarios internos relacionados con el campo de IA, sino que también se beneficia de su excelente diseño e implementación, operabilidad, confiabilidad y escalabilidad funcional. Todos son excelentes y son un controlador unificado que puede soportar una variedad de cargas de trabajo de entrenamiento, como TensorFlow, PyTorch, Mars, etc. Además, también puede adaptarse a las capacidades de programación en grupo proporcionadas por diferentes programadores, lo que puede ayudar a los escenarios de existencias que ya han utilizado el proyecto KubeDL a cambiar sin problemas a Koordinator; KubeDL también tiene un mecanismo de cola de trabajo general incorporado, que puede resolver eficazmente las necesidades de programación del trabajo en sí.

La poderosa combinación de Koordinator y KubeDL puede resolver perfectamente las necesidades de programación del entrenamiento de modelos grandes.

programación de trabajos

Un trabajo es una abstracción de nivel superior, generalmente con una tarea u operación computacional específica. Se puede dividir en múltiples subtareas para completar en paralelo, o dividirse en múltiples subtareas para completar en colaboración. Por lo general, el trabajo no depende de otras cargas de trabajo y puede ejecutarse de forma independiente. Además, Job es más flexible y tiene menos restricciones en términos de dimensión temporal, espacial o de recursos.

Trabajo en cola

El programador también debe programar el trabajo, lo que significa que el trabajo también debe estar en cola cuando se programa. Entonces, ¿por qué necesitas hacer fila? ¿O qué problemas podemos resolver haciendo cola?

Es porque los recursos en el sistema son limitados y nuestro presupuesto también es limitado, mientras que la cantidad de trabajos y los requisitos informáticos suelen ser ilimitados. Si no se realizan las colas y la programación, los trabajos con requisitos informáticos elevados o un tiempo de ejecución prolongado ocuparán una gran cantidad de recursos, lo que provocará que otros trabajos no puedan obtener suficientes recursos informáticos e incluso que el sistema del clúster se bloquee.

Por lo tanto, para garantizar que cada trabajo pueda obtener recursos de manera justa y evitar la contención y los conflictos de recursos, es necesario poner en cola y programar los trabajos.

Utilizamos el mecanismo general de cola y programación de trabajos proporcionado por KubeDL para resolver este problema. Debido a que KubeDL admite una variedad de cargas de trabajo de capacitación, naturalmente admite la programación de acuerdo con la granularidad del trabajo; y tiene un mecanismo de garantía de equidad entre múltiples inquilinos, lo que reduce la contención de recursos y los conflictos entre trabajos, y en el proceso de cola y programación, KubeDL evalúa y asigna trabajos en función de factores como los requisitos informáticos, las prioridades y los requisitos de recursos para garantizar que cada trabajo pueda obtener los recursos adecuados para la informática. KubeDL admite una variedad de complementos de extensión, como complementos de filtro, complementos de puntuación, etc., que pueden expandir aún más sus funciones y características para satisfacer las necesidades de diferentes escenarios.

Cuota elástica

Uno de los problemas centrales que debe resolver la cola de trabajos es la equidad en el suministro de recursos, que generalmente se resuelve a través del mecanismo de cuotas elásticas en el sistema de programación.

Hay varias cuestiones fundamentales que deben resolverse mediante el mecanismo de Cuota elástica: primero, para garantizar la equidad, de modo que la demanda de recursos de ciertas tareas no pueda ser demasiado alta como para causar que otras tareas mueran de hambre, y la mayoría de las tareas deberían poder obtener recursos tanto como sea posible; en segundo lugar, debe haber una cierta elasticidad puede compartir cuotas inactivas con tareas que necesitan más recursos en este momento, y también ser capaz de recuperar recursos compartidos cuando se necesitan recursos, lo que significa que las estrategias flexibles deben ser para satisfacer las necesidades de diferentes escenarios.

Koordinator implementa la capacidad de programación de cuotas elásticas, que puede garantizar la equidad entre los inquilinos. Al comienzo del diseño, consideramos la compatibilidad con ElaticQuota CRD definido en el proyecto de la comunidad de complementos del programador, de modo que los clústeres y usuarios existentes puedan realizar una transición sin problemas a Koordinator.

Además, no solo somos compatibles con la capacidad original de ElasticQuota de administrar la cuota según el espacio de nombres, sino que también admitimos la administración según la estructura de árbol, que puede cruzar el espacio de nombres. Este método puede satisfacer las necesidades de gestión de cuotas de una organización compleja. Por ejemplo, hay varias líneas de productos en una empresa, y el presupuesto y el uso de cada línea de productos son diferentes. Se pueden convertir a Cuota para la gestión, y con el ayuda de la cuota de flexibilidad, para compartir temporalmente los recursos inactivos que no se utilizan temporalmente a otros departamentos en forma de cuotas.

Coprogramación

Cuando un trabajo se pone en cola y se programa, el controlador de trabajos creará un lote de subtareas, correspondientes a K8, que es un lote de pods. Estos Pods a menudo requieren un inicio y funcionamiento coordinados. Esto también requiere que el programador asigne recursos de acuerdo con un grupo de Pods durante la programación.Este grupo de Pods debe poder solicitar recursos, o una vez que un Pod no pueda obtener recursos, se considerará una falla de programación. Esta es la semántica de programación de todo o nada que el programador debe proporcionar.

Si no programamos de acuerdo a un grupo de esta manera, habrá un punto muerto en la dimensión de recursos debido a la competencia entre múltiples trabajos a nivel de programación de recursos, es decir, al menos dos trabajos no podrán obtener recursos, incluso si originalmente están inactivos Si el recurso es suficiente para ejecutar uno de los trabajos, no estará disponible.

Por ejemplo, en la siguiente figura, el Trabajo A y el Trabajo B crean un lote de Pods al mismo tiempo. Si no se ordenan en la Cola de Programación intermedia sino que se programan aleatoriamente, parecerá que los Pods del Trabajo A y el Trabajo B cada uno mantener parte de los recursos de algunos nodos.Si los recursos del clúster son escasos en este momento, es muy probable que tanto el trabajo A como el trabajo B no puedan obtener recursos. Pero si después de la clasificación, intentamos dejar que los pods de uno de los trabajos primero intenten asignar recursos primero, entonces se puede garantizar que al menos un trabajo se ejecute.

Cuando un conjunto de pods dividido por un trabajo es muy grande y los recursos en el clúster no son suficientes o la cuota no es muy grande, dicho conjunto de pods se puede dividir en más subgrupos, cuyo tamaño se puede ejecutar Según la tarea, suponiendo que un trabajo requiere una granularidad de corte mínima de 3 pods por grupo, esta granularidad mínima generalmente se denomina min disponible en el dominio de programación.

Específicamente en el campo del entrenamiento de modelos de IA, para algunos trabajos especiales como TFJob, sus subtareas tienen dos roles Estos dos roles también deben configurarse con diferentes minutos disponibles en el entorno de producción. Este escenario de distinguir diferentes roles también puede requerir que se satisfaga el mínimo disponible de cada rol antes de que pueda considerarse conforme a la semántica de todo o nada.

Koordinator tiene una capacidad de programación Coscheduling incorporada, que es compatible con los complementos de programación/coscheduling de la comunidad para definir los CRD de PodGroup, y también admite la programación conjunta de varios PodGroups, de modo que los escenarios mínimos disponibles se pueden establecer por rol. Koordinator implementa un complemento KubeDL Gang Scheduler, de modo que se puede integrar con KubeDL para admitir tales escenarios de programación.

Gestión de equipos refinados

Limitaciones de la gestión de dispositivos K8s

K8s es responsable de la administración y asignación de dispositivos a través de kubelet, e interactúa con el complemento del dispositivo para implementar todo el mecanismo. Este mecanismo fue suficiente en los primeros días de K8s, y otros fabricantes como AMD y los fabricantes de chips nacionales también aprovecharon la oportunidad para aprovechar arriba.

Proceso de colaboración entre Kubelet y complementos de dispositivos

En primer lugar, K8s solo permite que los dispositivos se asignen a través de kubelet, lo que hace que sea imposible obtener una disposición de recursos óptima a nivel mundial, es decir, es fundamentalmente incapaz de ejercer la eficiencia de los recursos. Por ejemplo, hay dos nodos en un clúster, ambos tienen el mismo dispositivo y el número restante de dispositivos asignables es igual. Sin embargo, de hecho, la topología de hardware de los dispositivos en los dos nodos causará una gran diferencia en el efecto de tiempo de ejecución del Pod No hay programador En el caso de intervención, es posible que no sea posible compensar esta diferencia.

La segunda es que no admite la capacidad de asignar conjuntamente GPU y RDMA. El entrenamiento de modelos a gran escala se basa en redes de alto rendimiento, y la comunicación entre nodos de redes de alto rendimiento requiere el uso de protocolos RDMA y dispositivos de red que admitan protocolos RDMA, y estos dispositivos trabajan en estrecha colaboración con las GPU en el nivel de topología del sistema en los nodos. , como la siguiente La imagen de arriba es la topología de hardware del modelo A100 de NVIDIA. Podemos ver que el conmutador PCIe está conectado con una GPU y una tarjeta de red de alto rendimiento. Necesitamos asignar estos dos dispositivos cerca para lograr una baja latencia comunicación entre nodos. Y lo que es más interesante aquí es que cuando se deben asignar varias GPU, si hay varios conmutadores PCIe involucrados, significa que se deben asignar varias tarjetas de red. Esto está relacionado con otra limitación de K8, es decir, el protocolo de recursos declarado. es cuantitativo, en lugar de cambios arbitrarios, es decir, el usuario no sabe realmente cuántas tarjetas de red compatibles con RDMA se necesitan para este Pod. El usuario solo sabe cuántos dispositivos GPU se necesitan y espera asignar tarjetas de red RDMA cercano.

Además, kubelet no admite funciones de inicialización y limpieza de dispositivos, ni mecanismos para compartir dispositivos, este último generalmente no se usa en escenarios de entrenamiento, pero se usa en servicios de inferencia en línea. El propio servicio de inferencia en línea también tiene características evidentes de picos y valles, y no necesita ocupar recursos de GPU completos en muchas ocasiones.

Las capacidades de administración de dispositivos de nodos como K8 se han quedado atrás hasta cierto punto. Aunque la última versión admite el mecanismo de asignación de DRA (similar al mecanismo de programación de PVC existente), este mecanismo solo es compatible con la última versión de K8. , pero la situación real es que todavía hay una gran cantidad de clústeres de stock en uso, y actualizar a la última versión de K8s no es un asunto trivial, por lo que tenemos que encontrar otras formas.

Mecanismo de gestión de dispositivos refinado de Koordinator

Proponemos una solución en Koordinator, que puede resolver estos problemas y lograr una programación de recursos detallada.

Mecanismo de gestión de dispositivos refinado de Koordinator

Como se puede ver en la figura anterior, el programador koord-scheduler asigna un pod creado por el usuario de acuerdo con el CRD del dispositivo informado por koordlet, y se escribe en la anotación del pod, y luego el Sandbox y el contenedor son extraídos por el kubelet En el medio, el kubelet iniciará una solicitud CRI a containerd/docker, pero en la solución Koordinator, la solicitud CRI será interceptada por koord-runtime-proxy y reenviada al complemento GPU en koordlet, que percibir los resultados de asignación de dispositivos en Pod Annotation y generar las variables de entorno de dispositivo necesarias, etc. La información se devuelve a koord-runtime-proxy y, finalmente, la solicitud de CRI modificada se reenvía a containerd/docker y finalmente se devuelve a kubelet. De esta forma, puede intervenir sin problemas en el ciclo de vida de todo el contenedor para implementar una lógica personalizada.

Koordinator Device CRD se utiliza para describir la información del dispositivo del nodo, incluida la información de topología del dispositivo, que puede guiar al programador para implementar una lógica de asignación detallada.

Objeto de dispositivo Koordinator

Futuro: modelo NRI

Como se mencionó anteriormente, el lado de una sola máquina de Koordinator se basa en koord-runtime-proxy para cooperar para completar la inyección de información del dispositivo.También nos damos cuenta de que el método koord-runtime-proxy no es fácil de implementar en su clúster. Esto implica modificar los parámetros de inicio de kubelet.

Por lo tanto, la comunidad Koordinator introducirá mecanismos como NRI/CDI para resolver el problema en este escenario. Este trabajo está siendo co-construido con equipos relevantes de Intel.

NRI/CDI es un mecanismo de complemento compatible con containerd. Su método de implementación es algo similar al conocido CNI, que admite la oportunidad de modificar parámetros o implementar alguna lógica personalizada antes y después de iniciar Sandbox/Container. Esto es equivalente al mecanismo runtimeproxy integrado de containerd.

GPU y RDMA se asignan conjuntamente de acuerdo con la topología del hardware

Como se mencionó anteriormente, el entrenamiento de modelos grandes no solo usa GPU, sino que también se basa en dispositivos de red RDMA. Asegúrese de que la demora entre GPU y RDMA sea lo más baja posible; de lo contrario, la demora entre dispositivos se amplificará en toda la red de capacitación distribuida, lo que ralentizará la eficiencia general de la capacitación.

Esto requiere conocer la topología del hardware al asignar GPU y RDMA, y asignar dichos dispositivos lo más cerca posible. Intente asignar en el orden del mismo PCIe, el mismo nodo NUMA, el mismo zócalo NUMA y NUMA cruzado, y la demora aumentará a su vez.

Además, también encontramos que diferentes modelos de GPU del mismo fabricante de hardware tienen diferentes topologías de sistemas de hardware, lo que requiere que nuestro programador tenga en cuenta estas diferencias. Por ejemplo, la siguiente figura es un diagrama de conexión de dispositivo simple de Topología del sistema modelo NVIDIA A100 y NVIDIA H100.

Topología del sistema NVIDIA A100

El método de comunicación NVLINK entre las GPU NVIDIA A100 es diferente al de los modelos NVIDIA H100, y la cantidad de NVSwitches también es diferente. Esta diferencia traerá grandes diferencias en los métodos de uso.

NVIDIA H100

Diferencias del sistema basado en NVIDIA en modo multiusuario

La característica especial de la GPU NVIDIA H100 en el escenario de VM de múltiples inquilinos es que la comunicación entre múltiples GPU debe realizarse mediante el funcionamiento de NVSwitch.

En un escenario de múltiples inquilinos, NVIDIA administra el estado de aislamiento de NVLink a través de NVSwitch para garantizar la seguridad y solo requiere un software confiable para operar NVSwitch. Este software de crédito se puede personalizar.

NVIDIA admite varios modos, uno es el modo Full Passthrough, que conecta directamente la GPU y el NVSwitch al sistema operativo invitado de la máquina virtual .

El otro se llama modo multiusuario de NVSwitch compartido, que solo requiere que la GPU esté conectada directamente al sistema operativo invitado, y luego administra NVSwitch a través de una VM especial llamada Service VM, y llama a NVIDIA Fabric Manager a través de ServiceVM para activar NVSwitch para realizar inter -Comunicación GPU. Este modo no aparecerá debido a los inconvenientes del modo Full Passthrough, pero la forma de uso obviamente es más complicada. Esta arquitectura y uso de hardware especiales también generan algunos requisitos adicionales al asignar GPU. NVIDIA define qué instancias de dispositivos de GPU se pueden combinar y asignar juntas. Por ejemplo, si un usuario solicita la asignación de 4 GPU, debe asignarse de acuerdo con las normas 1, 2, 3 y 4 o 5, 6, 7 y 8 juntos, de lo contrario, los pods no se pueden ejecutar.

No sabemos la razón detrás de este método de asignación especial, pero al analizar estas restricciones de asignación, podemos encontrar que la relación de combinación estipulada por el fabricante está en línea con la topología del sistema de hardware, es decir, la asignación que puede cumplir con las expectativas. de la asignación conjunta de GPU y RDMA mencionada anteriormente.

Topología del sistema NVIDIA H100

Autor: Li Tao (Lv Feng)

¡Haga clic para probar los productos en la nube de forma gratuita ahora para comenzar el viaje práctico en la nube!

Enlace original

Este artículo es el contenido original de Alibaba Cloud y no se puede reproducir sin permiso.