Procedimientos recomendados de GPU para Azure Kubernetes Service (AKS)

Se aplica a: ✔️ AKS Automatic ✔️ AKS Standard

La ejecución de cargas de trabajo de GPU en AKS requiere una configuración adecuada y una validación continua para asegurarse de que los recursos de proceso son accesibles, seguros y se usan de forma óptima. En este artículo se describen los procedimientos recomendados para administrar nodos habilitados para GPU, validar configuraciones y reducir las interrupciones de la carga de trabajo.

Para la mayoría de las cargas de trabajo de producción en AKS, AKS Automatic es la opción predeterminada recomendada. AKS Automatic proporciona una configuración de referencia lista para producción con operaciones preconfiguradas, medidas de seguridad y disponibilidad de los pods respaldada por un SLA, lo que ayuda a los equipos a reducir la sobrecarga de la plataforma a partir del segundo día.

Elección de AKS Automatic o AKS Standard para cargas de trabajo de GPU

Use las instrucciones siguientes como punto de partida:

Escenario Ruta de acceso recomendada Por qué
Mayoría de las cargas de trabajo de GPU de producción AKS Automatic Configuración predeterminada lista para producción, medidas de seguridad integradas y reducción de la sobrecarga operativa del clúster.
Ruta de acceso más rápida de la implementación a la producción estable AKS Automatic Operaciones de clúster preconfiguradas y comportamiento de inicio predecible gracias al acuerdo de nivel de servicio de disponibilidad del pod.
Personalización avanzada de la plataforma y control operativo explícito AKS Standard Mayor flexibilidad para el ciclo de vida del grupo de nodos personalizado y la optimización de la plataforma.
Requisitos especializados y no predeterminados de arquitectura de plataforma AKS Standard Control más manual sobre el comportamiento y la configuración de la infraestructura.

Para obtener más información, consulte Introducción a Azure Kubernetes Service (AKS) Automático.

Qué proporciona AKS Automatic para cargas de trabajo de GPU de producción

AKS Automatic ayuda a establecer una línea de base operativa sólida para cargas de trabajo de GPU de producción al proporcionar:

  • Valores predeterminados listos para producción para la configuración del clúster.
  • Procedimientos recomendados integrados y medidas de seguridad.
  • Disponibilidad de los pods respaldada por un SLA para garantizar un comportamiento predecible durante el arranque.
  • Operaciones de clúster administradas que reducen las tareas manuales del día 2.

Estos valores predeterminados de la plataforma no reemplazan los procedimientos recomendados de nivel de carga de trabajo, como controles de selección de ubicación, comprobaciones de validación y directivas de aislamiento que se describen en este artículo.

Las cargas de trabajo de GPU, como el entrenamiento del modelo de IA, la inferencia en tiempo real, las simulaciones y el procesamiento de vídeo, suelen depender de:

  • Compatibilidad correcta del controlador de la GPU y del tiempo de ejecución.
  • Programación precisa de recursos de GPU.
  • Acceso a dispositivos de hardware GPU dentro de contenedores.

Las configuraciones incorrectas pueden provocar altos costes, fallos inesperados en los trabajos o una infrautilización de la GPU.

Aplicación de la asignación de cargas de trabajo de la GPU

De forma predeterminada, el programador de AKS coloca pods en cualquier nodo disponible con suficiente CPU y memoria. Sin controles de selección de ubicación de carga de trabajo, pueden producirse dos problemas:

  • El programador podría colocar cargas de trabajo de GPU en nodos sin GPU, lo que provoca que las cargas de trabajo no se inicien.
  • Las cargas de trabajo de uso general pueden ocupar nodos de GPU, lo que desperdicia recursos costosos.

Para garantizar una colocación correcta:

  • Aplique un taint a los nodos de GPU usando una clave como [gpu-vendor].com/gpu: NoSchedule (por ejemplo, nvidia.com/gpu: NoSchedule). Este taint impide que las cargas de trabajo que no sean de GPU se programe en estos nodos.

  • Añada una tolerancia equivalente en la especificación de su pod de carga de trabajo de GPU para que pueda programarse en los nodos de GPU contaminados.

  • Defina las solicitudes y límites de recursos de GPU en el pod para asegurarse de que el programador reserva la capacidad de GPU. Por ejemplo:

    resources:
      limits:
        [gpu-vendor].com/gpu: 1
    
  • Use directivas de validación o controladores de admisión para exigir que las cargas de trabajo de GPU incluyan las tolerancias y los límites de recursos necesarios.

Este enfoque garantiza que solo las cargas de trabajo listas para GPU lleguen a los nodos de GPU y tengan acceso a los recursos de proceso especializados que necesitan.

En AKS Automatic, los mecanismos de protección de la plataforma están preconfigurados de forma predeterminada. Se siguen aplicando controles de ubicación a nivel de carga de trabajo para garantizar un comportamiento estricto en la programación de las GPU.

Validación de la instalación del controlador de GPU y la preparación del entorno de ejecución

Antes de implementar cargas de trabajo de GPU en producción, compruebe siempre que sus grupos de nodos de GPU estén:

  • Equipados con controladores de GPU compatibles.
  • Hospedaje de un DaemonSet de complemento de dispositivo de Kubernetes correcto.
  • Exponiendo [gpu-vendor].com/gpu como un recurso programable.

Puede confirmar la versión actual del controlador que se ejecuta en sus grupos de nodos GPU con la interfaz de gestión del sistema (SMI) asociada al proveedor de la GPU.

El siguiente comando ejecuta nvidia-smi desde el pod de implementación del complemento de dispositivo GPU para comprobar la instalación del controlador y la preparación en tiempo de ejecución en un grupo de nodos habilitado para GPU de NVIDIA:

kubectl exec -it $"{GPU_DEVICE_PLUGIN_POD}" -n {GPU_NAMESPACE} -- nvidia-smi

La salida debería ser similar a la salida de ejemplo siguiente:

+-----------------------------------------------------------------------------+
|NVIDIA-SMI 570.xx.xx    Driver Version: 570.xx.xx    CUDA Version: 12.x|
...
...

Repita el kubectl exec comando para cada grupo de nodos de GPU para confirmar la versión del controlador instalada en los nodos.

En los grupos de nodos habilitados para GPU de AMD, implemente alternativamente los componentes de GPU de AMD y ejecute el amd-smi comando en el pod del complemento de dispositivo ROCm para confirmar la versión del controlador que está instalada.

Mantenga los nodos habilitados para GPU actualizados con la última imagen del sistema operativo del nodo

Para garantizar el rendimiento, la seguridad y la compatibilidad de sus cargas de trabajo de GPU en AKS, es esencial mantener sus grupos de nodos de GPU actualizados con las últimas imágenes de sistema operativo de nodo recomendadas. Estas actualizaciones son críticas porque:

  • Incluyen los últimos controladores de GPU de nivel de producción, sustituyendo cualquier versión obsoleta o al final de su vida útil (EOL).
  • Se han probado exhaustivamente para garantizar su compatibilidad con su versión actual de Kubernetes.
  • Abordan las vulnerabilidades conocidas identificadas por los proveedores de GPU.
  • Incorporan las últimas mejoras del sistema operativo y del tiempo de ejecución de contenedores para una mayor estabilidad y eficiencia.

Actualice los grupos de nodos de GPU a la imagen de sistema operativo del nodo recomendada más reciente publicada por AKS, ya sea estableciendo el canal de actualización automática o mediante la actualización manual. Puede supervisar y realizar un seguimiento de las últimas versiones de imágenes de nodos mediante el rastreador de versiones de AKS.

Para la mayoría de los escenarios de producción, comience con AKS Automatic como línea base predeterminada. Si usa AKS Standard, configure explícitamente los canales de actualización y las ventanas de mantenimiento.

Separe las cargas de trabajo de la GPU cuando utilice clústeres compartidos

Si un único clúster de AKS con grupos de nodos de GPU ejecuta varios tipos de cargas de trabajo de GPU, como el entrenamiento del modelo, la inferencia en tiempo real o el procesamiento por lotes, es importante separar estas cargas de trabajo para:

  • Evitar interferencias accidentales o conflictos por recursos entre diferentes tipos de cargas de trabajo.
  • Mejorar la seguridad y mantener los límites de cumplimiento.
  • Simplificar la administración y supervisión del uso de recursos de GPU por categoría de carga de trabajo.

Puede aislar las cargas de trabajo de la GPU dentro de un único clúster de AKS mediante el uso de espacios de nombres y directivas de red. Esto permite una gobernanza más clara mediante cuotas, límites y configuraciones de registro específicos para cada carga de trabajo.

Escenario de ejemplo

Considere un clúster AKS que aloja dos tipos diferentes de cargas de trabajo de GPU que no necesitan comunicarse entre sí:

  • Cargas de trabajo de entrenamiento: trabajos de entrenamiento de modelos de IA que consumen muchos recursos.
  • Cargas de trabajo de inferencia: servicios de inferencia en tiempo real sensibles a la latencia.

Puede usar los pasos siguientes para separar las dos cargas de trabajo:

  1. Cree espacios de nombres dedicados por tipo de carga de trabajo mediante el comandokubectl create namespace.

    kubectl create namespace gpu-training
    kubectl create namespace gpu-inference
    
  2. Etiquete los pods de carga de trabajo de GPU por tipo, como se muestra en el ejemplo siguiente:

    metadata:
      namespace: gpu-training
      labels:
        workload: training
    
  3. Aplique directivas de red para aislar el tráfico entre los tipos de carga de trabajo. El manifiesto siguiente bloquea todas las entradas y salidas del espacio de nombres gpu-training (a menos que se permita explícitamente):

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: deny-cross-namespace
      namespace: gpu-training
    spec:
      podSelector: {}
      policyTypes:
      - Ingress
      - Egress
      ingress: []
      egress: []
    

Esta directiva:

  • Se aplica a todos los pods del espacio de nombres gpu-training.
  • Deniega todo el tráfico entrante y saliente de forma predeterminada, lo que admite un aislamiento seguro.

Este modelo mejora la claridad, el control y la seguridad en entornos de GPU compartidos, especialmente cuando los tipos de carga de trabajo tienen diferentes perfiles de tiempo de ejecución, niveles de riesgo o requisitos operativos.

Optimice el uso de recursos en los nodos GPU mediante GPU de varias instancias (MIG).

Las diferentes cargas de trabajo de GPU tienen requisitos de memoria diferentes. Es posible que las implementaciones más pequeñas, como NVIDIA A100 40 GB, no necesiten una GPU completa. Sin embargo, una sola carga de trabajo de forma predeterminada acorta el recurso de GPU incluso cuando está infrautilizado.

AKS admite la optimización de recursos en nodos de GPU dividiéndolos en segmentos más pequeños mediante GPU de varias instancias (MIG), para que los equipos puedan programar trabajos más pequeños de forma más eficaz. Obtenga más información sobre los tamaños de GPU admitidos y cómo empezar a trabajar con GPU de varias instancias en AKS.

Uso de discos de datos NVMe efímeros como caché de alto rendimiento

En el caso de las cargas de trabajo de IA que se ejecutan en máquinas virtuales de GPU en AKS, el acceso rápido y confiable al almacenamiento temporal es fundamental para maximizar el rendimiento de entrenamiento e inferencia. Los discos de datos NVMe efímeros proporcionan almacenamiento de baja latencia y alto rendimiento conectado directamente al host de máquina virtual, lo que los convierte en ideales para escenarios como el almacenamiento en caché de conjuntos de datos, el almacenamiento de puntos de control intermedios y pesos del modelo, o proporcionar espacio temporal para el preprocesamiento y el análisis de datos.

Al implementar grupos de nodos habilitados para GPU para cargas de trabajo de IA, configure discos de datos NVMe efímeros para que sirvan como caché de alto rendimiento o espacio temporal. Este enfoque ayuda a eliminar los cuellos de botella de E/S, acelera las operaciones con un uso intensivo de datos y garantiza que los recursos de GPU no estén inactivos mientras esperan los datos.

Azure admite discos de datos NVMe efímeros en una amplia gama de familias de máquinas virtuales de GPU de Azure. Según el tamaño de la máquina virtual de GPU, la máquina virtual tiene hasta ocho discos de datos NVMe efímeros con una capacidad combinada de hasta 28 TiB. Para obtener configuraciones detalladas sobre los tamaños de máquina virtual, consulte la documentación de la serie ND H100 v5 o la documentación de tamaño de máquina virtual para la familia de GPU elegida.

Para simplificar el aprovisionamiento y la administración, use Azure Container Storage, que puede detectar y organizar automáticamente discos NVMe efímeros para las cargas de trabajo de Kubernetes.

Entre los escenarios recomendados se incluyen:

  • Almacenamiento en caché de grandes conjuntos de datos y puntos de control de modelos para el entrenamiento e inferencia de inteligencia artificial.
  • Almacenamiento en caché de pesos del modelo para la inferencia de IA. Por ejemplo, el modelo de alojamiento KAITO como artefactos OCI en NVMe local.
  • Proporciona un espacio rápido para trabajos por lotes y flujos de datos.

Importante

Los datos en discos NVMe efímeros son temporales y se perderán si la máquina virtual está desasignada o se vuelve a implementar. Use estos discos solo para datos no críticos, transitorios y almacene información importante sobre las soluciones de almacenamiento de Azure persistentes.

Para obtener más instrucciones sobre discos de datos NVMe efímeros, consulte Procedimientos recomendados para discos de datos NVMe efímeros en AKS.

Para más información sobre las cargas de trabajo de AKS y GPU, consulte los artículos siguientes: