Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Computación y escalado automático

Optimización de recursos y administración de costos de GPU

Programe las cargas de trabajo con los requisitos de GPU mediante etiquetas Well-Known

Para AI/ML las cargas de trabajo sensibles a diferentes características de la GPU (por ejemplo, GPU o memoria de la GPU), recomendamos especificar los requisitos de la GPU mediante etiquetas de programación conocidas compatibles con los tipos de nodos utilizados en Karpenter y los grupos de nodos gestionados. Si no se definen, es posible que los pods se programen en instancias con recursos de GPU inadecuados, lo que puede provocar errores o reducir el rendimiento. Recomendamos usar NodeSelector o Node Affinity para especificar en qué nodo debe ejecutarse un pod y configurar los recursos informáticos (CPU, memoria, GPU, etc.) en la sección de recursos del pod.

Ejemplo

Por ejemplo, si utilizas el selector de nodos con el nombre de la GPU cuando utilizas Karpenter:

apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod-example
spec:
  containers:
  - name: ml-workload
    image: <image>
    resources:
      limits:
        nvidia.com/gpu: 1  # Request one NVIDIA GPU
  nodeSelector:
    karpenter.k8s.aws/instance-gpu-name: "l40s"  # Run on nodes with NVIDIA L40S GPUs

Usa el complemento de dispositivo de Kubernetes para exponer las GPU

Para exponer las GPU de los nodos, el controlador de GPU de NVIDIA debe estar instalado en el sistema operativo del nodo y el tiempo de ejecución del contenedor debe configurarse de forma que el programador de Kubernetes pueda asignar pods a los nodos con GPU disponibles. El proceso de configuración del complemento de dispositivo Kubernetes de NVIDIA depende de la AMI de EKS Accelerated que utilices:

Si decides usar las AMI aceleradas de EKS y el operador de GPU NVIDIA para administrar componentes como el complemento de dispositivos NVIDIA Kubernetes, ten en cuenta la posibilidad de deshabilitar la administración del controlador de GPU NVIDIA y del kit de herramientas NVIDIA Container, tal y como se indica en la documentación de NVIDIA Container Toolkit y controladores de GPU Pre-Installed NVIDIA.

Para comprobar que el complemento de dispositivos de NVIDIA está activo y que las GPU están expuestas correctamente, ejecuta:

kubectl describe node | grep nvidia.com/gpu

Este comando comprueba si el nvidia.com/gpu recurso está dentro de la capacidad y los recursos asignables del nodo. Por ejemplo, debería mostrarse un nodo con una GPU. nvidia.com/gpu: 1 Consulta la Guía de programación de GPU de Kubernetes para obtener más información.

Usa muchos tipos de instancias EC2 diferentes

Utilizar tantos tipos de instancias EC2 diferentes como sea posible es una práctica recomendada importante para la escalabilidad en Amazon EKS, tal y como se describe en la sección. Plano de datos de Kubernetes Esta recomendación también se aplica a las instancias con hardware acelerado (por ejemplo, GPU). Si creas un clúster que usa solo un tipo de instancia e intentas escalar la cantidad de nodos más allá de la capacidad de la región, es posible que recibas un error de capacidad insuficiente (ICE) que indique que no hay instancias disponibles. Es importante entender las características únicas de tus AI/ML cargas de trabajo antes de diversificarlas arbitrariamente. Revise los tipos de instancias disponibles con la herramienta EC2 Instance Type Explorer para generar una lista de los tipos de instancias que coincidan con sus requisitos informáticos específicos y evite limitar arbitrariamente el tipo de instancias que se pueden usar en su clúster.

Las instancias de procesamiento acelerado se ofrecen en diferentes modelos de compra para adaptarse a las cargas de trabajo a corto y medio plazo y en estado estable. Para cargas de trabajo a corto plazo, flexibles y tolerantes a errores, en las que no quieras hacer una reserva, opta por las instancias puntuales. Los bloques de capacidad, On-Demand las instancias y los planes de ahorro te permiten aprovisionar instancias de procesamiento acelerado para cargas de trabajo a medio y largo plazo. Para aumentar las posibilidades de acceder correctamente a la capacidad requerida en tu opción de compra preferida, se recomienda utilizar una lista diversa de tipos de instancias y zonas de disponibilidad. Como alternativa, si encuentras ICE para un modelo de compra específico, vuelve a intentarlo con un modelo diferente.

Ejemplo El siguiente ejemplo muestra cómo permitir que un Karpenter aprovisione instancias G y P de generaciones superiores NodePool a las de la generación 3 (por ejemplo, p3). Para obtener más información, consulte la sección Mejores prácticas de escalabilidad de EKS.

- key: karpenter.k8s.aws/instance-category
  operator: In
  values: ["g", "p"] # Diversifies across G-series and P-series
- key: karpenter.k8s.aws/instance-generation
  operator: Gt
  values: ["3"] # Selects instance generations greater than 3

Para obtener más información sobre el uso de instancias puntuales para GPU, consulte la sección «Considere la posibilidad de usar instancias puntuales de Amazon EC2 para GPU con Karpenter», que aparece a continuación.

Considere la posibilidad de usar las instancias puntuales de Amazon EC2 para GPU con Karpenter

Las instancias puntuales de Amazon EC2 le permiten aprovechar la capacidad de EC2 no utilizada en la nube de AWS y están disponibles con un descuento de hasta el 90% en comparación con los precios. On-Demand Las instancias puntuales de Amazon EC2 pueden interrumpirse con dos minutos de antelación cuando EC2 necesite recuperar la capacidad. Para obtener más información, consulte las instancias puntuales en la guía del usuario de Amazon EC2. Amazon EC2 Spot puede ser una excelente opción para cargas de trabajo tolerantes a errores, sin estado y flexibles (tiempo y tipo de instancia). Para obtener más información sobre cuándo usar las instancias puntuales, consulte las prácticas recomendadas de las instancias puntuales de EC2. También puede usar las instancias puntuales para AI/ML cargas de trabajo si son. Spot-friendly

Casos de uso

Spot-friendly las cargas de trabajo pueden ser macrodatos, cargas de trabajo en contenedores, servidores web sin estado CI/CD, computación de alto rendimiento (HPC) y cargas de trabajo de renderizado. Las instancias puntuales no son adecuadas para cargas de trabajo inflexibles, con estado, que no toleran errores o que están estrechamente conectadas entre los nodos de la instancia (por ejemplo, cargas de trabajo con procesos paralelos que dependen en gran medida unos de otros para el cálculo y que requieren una comunicación constante entre nodos, como las aplicaciones informáticas de MPI-based alto rendimiento, como la dinámica de fluidos computacional o las bases de datos distribuidas con interdependencias complejas). Estos son los casos de uso específicos que recomendamos (sin ningún orden en particular):

Consideraciones

Para usar las instancias puntuales para cargas de trabajo aceleradas en Amazon EKS, hay una serie de consideraciones clave (sin ningún orden en particular):

Además de estas prácticas recomendadas básicas de Spot, tenga en cuenta estos factores al administrar las cargas de trabajo de GPU en Amazon EKS. A diferencia CPU-based de las cargas de trabajo, las cargas de trabajo de la GPU son particularmente sensibles a los detalles del hardware, como las capacidades de la GPU y la memoria de la GPU disponible. Las cargas de trabajo de la GPU pueden estar limitadas por los tipos de instancia que pueden usar, con menos opciones disponibles en comparación con las CPU. Como primer paso, evalúa si tu carga de trabajo es flexible con las instancias. Si no sabe cuántos tipos de instancias puede usar su carga de trabajo, pruébelos individualmente para garantizar la compatibilidad y la funcionalidad. Identifica qué tan flexible puedes ser para diversificar lo máximo posible y, al mismo tiempo, confirma que la diversificación mantiene la carga de trabajo en funcionamiento y comprende cualquier impacto en el rendimiento (por ejemplo, en el rendimiento o en el tiempo de finalización). Como parte de la diversificación de sus cargas de trabajo, tenga en cuenta lo siguiente:

Escenario: Diversificación para cargas de trabajo de inferencia en tiempo real

Para disponer de una carga de trabajo de inferencia online en tiempo real en instancias puntuales, puedes configurar un Karpenter NodePool para diversificar las familias y generaciones de instancias de GPU compatibles. Este enfoque garantiza una alta disponibilidad al aprovechar varios grupos de puntos y, al mismo tiempo, mantener el rendimiento debido a las restricciones en las capacidades, la memoria y la arquitectura de la GPU. Admite el uso de alternativas cuando la capacidad de la instancia es limitada, lo que minimiza las interrupciones y optimiza la latencia de inferencia. En este ejemplo se NodePool indica que se deben usar instancias de las series g y p superiores a 3 y que tengan más de 20 GB de memoria de GPU.

Ejemplo

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-inference-spot
spec:
  template:
    metadata:
      labels:
        role: gpu-spot-worker
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"] # Use Spot Instances
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["g", "p"] # Diversifies across G-series and P-series
        - key: karpenter.k8s.aws/instance-generation
          operator: Gt
          values: ["3"] # Selects instance generations greater than 3
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"] # Specifies AMD64 architecture, compatible with NVIDIA GPUs
        - key: karpenter.k8s.aws/instance-gpu-memory
          operator: Gt
          values: ["20480"] # Ensures more than 20GB (20480 MiB) total GPU memory
      taints:
        - key: nvidia.com/gpu
          effect: NoSchedule
      nodeClassRef:
        name: gpu-inference-ec2
        group: karpenter.k8s.aws
        kind: EC2NodeClass
      expireAfter: 720h
  limits:
    cpu: 100
    memory: 100Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 5m # Enables consolidation of underutilized nodes after 5 minutes

Implemente Checkpoint para trabajos de entrenamiento de larga duración

Los puntos de control son una técnica de tolerancia a errores que consiste en guardar periódicamente el estado de un proceso para que pueda reanudarse desde el último punto guardado en caso de interrupciones. En el aprendizaje automático, se suele asociar a la formación, ya que los trabajos de larga duración permiten ahorrar peso a los modelos y estados del optimizador para reanudar el entrenamiento en caso de errores, como problemas de hardware o interrupciones de instancias puntuales.

Los puntos de control se utilizan para guardar el estado de los modelos de aprendizaje automático (ML) durante el entrenamiento. Los puntos de control son instantáneas del modelo y se pueden configurar mediante las funciones de devolución de llamadas de los marcos de ML. Puede utilizar los puntos de control guardados para reiniciar un trabajo de entrenamiento desde el último punto de control guardado. Con los puntos de control, puede guardar las instantáneas de los modelos durante el entrenamiento debido a una interrupción inesperada del trabajo o la instancia de entrenamiento. Esto le permite reanudar el entrenamiento del modelo en el futuro desde un punto de control. Además de implementar un sistema de resiliencia de nodos, recomendamos implementar puntos de control para mitigar el impacto de las interrupciones, incluidas las causadas por fallas de hardware o interrupciones de las instancias puntuales de Amazon EC2.

Sin puntos de control, las interrupciones pueden provocar una pérdida de tiempo de procesamiento y de progreso, lo que resulta costoso para los trabajos de formación de larga duración. Los puntos de control permiten que los trabajos guarden su estado periódicamente (por ejemplo, los pesos del modelo y los estados del optimizador) y se reanuden desde el último punto de control (el último lote procesado) tras una interrupción. Para implementar los puntos de control, diseñe su aplicación de forma que procese los datos en lotes grandes y guarde los resultados intermedios en un almacenamiento permanente, como un bucket de Amazon S3 mediante el controlador CSI de Mountpoint for Amazon S3, mientras se realiza el trabajo de formación.

Casos de uso

Los controles son particularmente beneficiosos en situaciones específicas para equilibrar la tolerancia a los fallos con la sobrecarga de rendimiento. Considere la posibilidad de utilizar los puntos de control en los siguientes casos:

Utilice los bloques de capacidad de aprendizaje automático para garantizar la capacidad de las instancias P y Trainium

Los bloques de capacidad para ML le permiten reservar instancias de GPU muy solicitadas, específicamente instancias P (por ejemplo, p6-b200, p5, p5e, p5en, p4d, p4de) e instancias de Trainium (por ejemplo, trn1, trn2), para que comiencen casi de inmediato o en una fecha futura para respaldar sus cargas de trabajo de aprendizaje automático (ML) de corta duración. Estas reservas son ideales para garantizar la capacidad para tareas que requieren un uso intensivo de la computación, como el entrenamiento de modelos y el ajuste de precisión. Los precios de los bloques de capacidad de EC2 consisten en una tarifa de reserva y una tarifa de sistema operativo. Para obtener más información sobre los precios, consulte los precios de EC2 Capacity Blocks for ML.

Para reservar las GPU para AI/ML cargas de trabajo en Amazon EKS con el fin de garantizar la capacidad de forma predecible, recomendamos utilizar los bloques de capacidad de aprendizaje automático a corto plazo o las reservas de capacidad (ODCR) para garantizar la On-Demand capacidad de uso general.

Reserve capacidad a través de la consola de administración de AWS y configure sus nodos para usar bloques de capacidad de aprendizaje automático. Planifique las reservas en función de los cronogramas de carga de trabajo y realice las pruebas en un clúster provisional. Consulte la documentación sobre los bloques de capacidad para obtener más información.

Tenga en cuenta On-Demand las reservas puntuales o de On-Demand capacidad (ODCR) de Amazon EC2 para las instancias G de Amazon EC2

En el caso de las instancias G de Amazon EC2, tenga en cuenta las diferentes opciones de compra On-Demand, como las instancias puntuales de Amazon EC2 y las reservas de capacidad. On-Demand Los ODCR permiten reservar la capacidad de las instancias EC2 en una zona de disponibilidad específica durante un período determinado, lo que garantiza la disponibilidad incluso en situaciones de alta demanda. A diferencia de los bloques de capacidad de aprendizaje automático, que solo están disponibles para las instancias P y Trainium, los ODCR se pueden usar para una gama más amplia de tipos de instancias, incluidas las instancias G, lo que los hace adecuados para cargas de trabajo que requieren diferentes capacidades de GPU, como la inferencia o los gráficos. Cuando se utilizan instancias puntuales de Amazon EC2, es fundamental poder diferenciar entre diferentes tipos, tamaños y zonas de disponibilidad de instancias para poder permanecer en Spot durante más tiempo.

Los ODCR no tienen ningún compromiso a largo plazo, pero usted paga la On-Demand tarifa por la capacidad reservada, ya sea usada o inactiva. Los ODCR pueden crearse para su uso inmediato o programarse para una fecha futura, lo que brinda flexibilidad en la planificación de la capacidad. En Amazon EKS, los ODCR son compatibles con tipos de nodos como https://karpenter.sh/ Karpenter y con grupos de nodos gestionados. https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html Para priorizar los ODCR en Karpenter, configúrelos para que usen el campo. NodeClass capacityReservationSelectorTerms Consulte la documentación de Karpenter. NodePools Para obtener más información sobre la creación de ODCR, incluidos los comandos de la CLI, consulte la sección Introducción a la reserva de On-Demand capacidad.

Considera otros tipos y tamaños de instancias aceleradas

La selección de la instancia acelerada y el tamaño adecuados es fundamental para optimizar tanto el rendimiento como el coste de las cargas de trabajo de aprendizaje automático en Amazon EKS. Por ejemplo, las distintas familias de instancias de GPU tienen un rendimiento y unas capacidades diferentes, como la memoria de GPU. Para ayudarte a elegir la opción con mejor relación precio-rendimiento, consulta las instancias de GPU disponibles en la página Tipos de instancias EC2, en Computación acelerada. Evalúe varios tipos y tamaños de instancias para encontrar la que mejor se adapte a sus requisitos de carga de trabajo específicos. Considera factores como la cantidad de GPU, la memoria y el rendimiento de la red. Si selecciona cuidadosamente el tipo y el tamaño de instancia de GPU correctos, puede lograr una mejor utilización de los recursos y una mejor rentabilidad en sus clústeres de EKS.

Si usas una instancia de GPU en un nodo de EKS, el nvidia-device-plugin-daemonset pod estará en el espacio de kube-system nombres de forma predeterminada. Para hacerte una idea rápida de si estás utilizando al máximo las GPU de tu instancia, puedes usar https://docs.nvidia.com/deploy/nvidia-smi/index.html nvidia-smi como se muestra aquí:

kubectl exec nvidia-device-plugin-daemonset-xxxxx \
  -n kube-system -- nvidia-smi \
  --query-gpu=index,power.draw,power.limit,temperature.gpu,utilization.gpu,utilization.memory,memory.free,memory.used \
  --format=csv -l 5

Para obtener más información, consulte las instancias de GPU en la documentación de AWS.

Optimice la asignación de recursos de GPU con Time-Slicing la asignación MIG y fraccionada de GPU

Los límites de recursos estáticos en Kubernetes (p. ej., el recuento de CPU, memoria o GPU) pueden provocar un aprovisionamiento excesivo o una infrautilización, especialmente en el caso de cargas de trabajo dinámicas como la inferencia. AI/ML Es importante seleccionar la GPU correcta. En el caso de cargas de trabajo de bajo volumen o con picos de volumen, la segmentación temporal permite que varias cargas de trabajo compartan una sola GPU al compartir sus recursos informáticos, lo que puede mejorar la eficiencia y reducir el desperdicio. El uso compartido de la GPU se puede lograr mediante diferentes opciones:

Para habilitar estas funciones en EKS, puedes implementar el complemento de dispositivos de NVIDIA, que muestra las GPU como recursos programables y admite la tecnología MIG y la segmentación temporal. Para obtener más información, consulte las Time-Slicing GPU en Kubernetes y el uso compartido de GPU en Amazon EKS con instancias EC2 aceleradas y rápidas de NVIDIA.

Ejemplo

Por ejemplo, para poder reducir el tiempo con el complemento de dispositivos de NVIDIA:

apiVersion: v1
kind: ConfigMap
metadata:
  name: nvidia-device-plugin-config
  namespace: kube-system
data:
  config.yaml: |
    version: v1
    sharing:
      timeSlicing:
        resources:
        - name: nvidia.com/gpu
          replicas: 4  # Allow 4 pods to share each GPU

Ejemplo

Por ejemplo, para usar el programador KAI para la asignación fraccionada de GPU, impleméntalo junto con el operador de GPU de NVIDIA y especifica los recursos de GPU fraccionados en la especificación del pod:

apiVersion: v1
kind: Pod
metadata:
  name: fractional-gpu-pod-example
  annotations:
    gpu-fraction: "0.5"  # Annotation for 50% GPU
  labels:
    runai/queue: "default"  # Required queue assignment
spec:
  containers:
  - name: ml-workload
    image: nvcr.io/nvidia/pytorch:25.04-py3
    resources:
      limits:
        nvidia.com/gpu: 1
  nodeSelector:
    nvidia.com/gpu: "true"
  schedulerName: kai-scheduler

Resiliencia de nodos y gestión de tareas de formación

Implemente las comprobaciones del estado de los nodos con una recuperación automatizada

En el caso de los trabajos de entrenamiento distribuidos en Amazon EKS que requieren una comunicación frecuente entre nodos, como el entrenamiento de modelos con varias GPU en varios nodos, los problemas de hardware, como los fallos en la GPU o el EFA, pueden provocar interrupciones en los trabajos de entrenamiento. Estas interrupciones pueden provocar la pérdida del progreso del entrenamiento y un aumento de los costes, especialmente en el caso de las cargas de AI/ML trabajo de larga duración que dependen de un hardware estable.

Para aumentar la resiliencia frente a los fallos de hardware, como los fallos de GPU en clústeres de EKS que ejecutan cargas de trabajo de GPU, recomendamos utilizar Amazon o el agente de monitorización de nodos de EKS con Auto Repair. SageMaker HyperPod Si bien el agente de monitorización de nodos de EKS con reparación automática ofrece funciones como la supervisión del estado de los nodos y la reparación automática mediante los mecanismos estándar de Kubernetes, SageMaker HyperPod ofrece una resiliencia específica y funciones adicionales diseñadas específicamente para el entrenamiento de aprendizaje automático a gran escala, como comprobaciones exhaustivas del estado y la reanudación automática de tareas.

Tanto en el caso del agente de monitoreo de nodos de EKS con reparación automática como en SageMaker HyperPod los clústeres que utilizan EFA, para monitorear EFA-specific métricas como los errores de acceso remoto directo a la memoria (RDMA) y la pérdida de paquetes, asegúrese de que el controlador EFA de AWS esté instalado. https://docs.aws.amazon.com/eks/latest/userguide/node-efa.html Además, recomendamos implementar el sistema CloudWatch Observability Add-on o utilizar herramientas como DCGM Exporter con Prometheus y Grafana para supervisar el EFA y la GPU, así como para medir métricas específicas relacionadas con sus funciones. SageMaker HyperPod

Deshabilite Karpenter Consolidation para cargas de trabajo sensibles a interrupciones

Para cargas de trabajo sensibles a interrupciones, como el procesamiento, las tareas de AI/ML predicción a gran escala o la formación, recomendamos ajustar las políticas de consolidación de Karpenter para evitar interrupciones durante la ejecución del trabajo. La función de consolidación de Karpenter optimiza automáticamente los costos de los clústeres al eliminar los nodos infrautilizados o reemplazarlos por alternativas de menor precio. Sin embargo, incluso cuando una carga de trabajo utiliza por completo una GPU, Karpenter puede consolidar los nodos si identifica un tipo de instancia del tamaño adecuado y de menor precio que cumpla con los requisitos del pod, lo que provoca interrupciones en el trabajo.

La política de WhenEmptyOrUnderutilized consolidación puede cerrar los nodos de forma prematura, lo que prolonga los tiempos de ejecución. Por ejemplo, las interrupciones pueden retrasar la reanudación de los trabajos debido a la reprogramación de los módulos o a la recarga de datos, lo que puede resultar costoso para los trabajos de inferencia por lotes de larga duración. Para mitigar este problema, puede establecer WhenEmpty y configurar una consolidateAfter duración, como 1 hora, consolidationPolicy para retener los nodos durante los picos de carga de trabajo. Por ejemplo:

disruption:
  consolidationPolicy: WhenEmpty
  consolidateAfter: 60m

Este enfoque mejora la latencia de inicio de los pods para cargas de trabajo de inferencia por lotes con picos de picos y otras tareas sensibles a las interrupciones, como el procesamiento de datos de inferencia en línea en tiempo real o el entrenamiento de modelos, en las que el costo de la interrupción supera los ahorros en costos de procesamiento. Karpenter NodePool Disruption Budgets es otra función para gestionar las interrupciones de Karpenter. Con los presupuestos, puedes asegurarte de que no se interrumpirá más de un número determinado de nodos en el lugar elegido en un NodePool momento determinado. También puedes usar los presupuestos de interrupciones para evitar que todos los nodos sufran interrupciones en un momento determinado (por ejemplo, en las horas punta). Para obtener más información, consulte la documentación de Karpenter Consolidation.

Utilice ttl para automatizar los trabajos de SecondsAfterFinished Kubernetes Clean-Up

Recomendamos configurar los trabajos de Kubernetes en Amazon EKS ttlSecondsAfterFinished para eliminar automáticamente los objetos de trabajo completados. Los objetos de trabajo persistentes consumen los recursos del clúster, como la memoria del servidor de API, y complican la supervisión al saturar los paneles (por ejemplo, Grafana o Amazon). CloudWatch Por ejemplo, establecer un TTL de 1 hora garantiza que los trabajos se eliminen poco después de su finalización, lo que mantiene el clúster ordenado. Para obtener más información, consulte Limpieza automática de los trabajos finalizados.

Configure la preferencia de Low-Priority trabajos para Higher-Priority Jobs/workloads

En el caso de AI/ML las cargas de trabajo de prioridad mixta en Amazon EKS, puede configurar la preferencia de tareas de baja prioridad para garantizar que las tareas de mayor prioridad (por ejemplo, la inferencia en tiempo real) reciban los recursos con prontitud. Sin preferencia, las cargas de trabajo de baja prioridad, como los procesos por lotes (por ejemplo, la inferencia de lotes o el procesamiento de datos), los servicios que no funcionan por lotes (por ejemplo, las tareas en segundo plano o los trabajos cron) o CPU/memory-intensive los trabajos (por ejemplo, los servicios web) pueden retrasar los módulos críticos al ocupar los nodos. La preferencia permite a Kubernetes desalojar los pods de baja prioridad cuando los de alta prioridad necesitan recursos, lo que garantiza una asignación eficiente de los recursos en los nodos con GPU, CPU o memoria. Recomendamos usar Kubernetes para asignar prioridades y controlar el comportamiento de desalojo. PriorityClass PodDisruptionBudget

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: low-priority
value: 100
---
spec:
  priorityClassName: low-priority

Consulta la documentación sobre prioridades y preferencias de Kubernetes para obtener más información.

Escalado y rendimiento de las aplicaciones

Personalice la capacidad informática para las cargas de trabajo de aprendizaje automático con Karpenter o nodos estáticos

Para garantizar una capacidad informática rentable y con capacidad de respuesta para los flujos de trabajo de aprendizaje automático (ML) en Amazon EKS, le recomendamos que adapte la estrategia de aprovisionamiento de nodos a las características de la carga de trabajo y a los compromisos de costes. A continuación se presentan dos enfoques a tener en cuenta: el escalamiento justo a tiempo con Karpenter y los grupos de nodos estáticos para la capacidad reservada.

Ejemplo

Este es un ejemplo de un Karpenter diverso NodePool que permite lanzar instancias de g Amazon EC2 cuando la generación de instancias es superior a tres.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-inference
spec:
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["g"]
        - key: karpenter.k8s.aws/instance-generation
          operator: Gt
          values: ["3"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
      taints:
        - key: nvidia.com/gpu
          effect: NoSchedule
  limits:
    cpu: "1000"
    memory: "4000Gi"
    nvidia.com/gpu: "10"  *# Limit the total number of GPUs to 10 for the NodePool*
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: 60m
    expireAfter: 720h

Ejemplo

Ejemplo de uso de grupos de nodos estáticos para una carga de trabajo de entrenamiento:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: ml-cluster
  region: us-west-2
managedNodeGroups:
  - name: gpu-node-group
    instanceType: p4d.24xlarge
    minSize: 2
    maxSize: 2
    desiredCapacity: 2
    taints:
      - key: nvidia.com/gpu
        effect: NoSchedule

Usa restricciones y tolerancias para evitar que las cargas de trabajo no aceleradas se programen en instancias aceleradas

La programación de cargas de trabajo no aceleradas en los recursos de la GPU no es eficiente desde el punto de vista informático, por lo que recomendamos utilizar los límites y la tolerancia para garantizar que los pods de cargas de trabajo no aceleradas no se programen en nodos inapropiados. Consulta la documentación de Kubernetes para obtener más información.

La escala se basa en el rendimiento del modelo

Para las cargas de trabajo de inferencia, recomendamos usar el Event-Driven escalado automático de Kubernetes (KEDA) para escalar en función de las métricas de rendimiento del modelo, como las solicitudes de inferencia o el rendimiento de los tokens, con los períodos de espera adecuados. Las políticas de escalado estático pueden aprovisionar recursos en exceso o de forma insuficiente, lo que repercute en los costes y la latencia. Obtenga más información en la documentación de KEDA.

Asignación dinámica de recursos para una administración avanzada de GPU

La asignación dinámica de recursos (DRA) representa un avance fundamental en la administración de recursos de GPU de Kubernetes. La DRA supera las limitaciones tradicionales de los complementos de dispositivos para permitir el uso compartido sofisticado de las GPU, el reconocimiento de la topología y la coordinación de los recursos entre nodos. Disponible en la versión 1.33 de Amazon EKS, DRA aborda los desafíos críticos de las AI/ML cargas de trabajo al proporcionar lo siguiente:

La asignación tradicional de GPU trata las GPU como recursos enteros opacos, lo que genera una infrautilización significativa (a menudo del 30 al 40% en los clústeres de producción). Esto se debe a que las cargas de trabajo reciben acceso exclusivo a las GPU completas, incluso cuando solo requieren recursos fraccionados. DRA transforma este modelo al introducir una asignación estructurada y declarativa que proporciona al programador de Kubernetes una visibilidad completa de las características del hardware y los requisitos de carga de trabajo. Esto permite tomar decisiones de ubicación inteligentes y compartir recursos de manera eficiente.

Ventajas de usar DRA en lugar del complemento de dispositivo NVIDIA

El complemento de dispositivos de NVIDIA (a partir de la versión0.12.0) admite mecanismos de uso compartido de GPU, como la segmentación temporal, el MPS y el MIG. Sin embargo, existen limitaciones arquitectónicas que DRA aborda.

Limitaciones de los complementos de dispositivos NVIDIA

Soluciones con DRA

Importante: DRA no sustituye por completo al complemento de dispositivos de NVIDIA. El controlador DRA de NVIDIA funciona junto con el complemento del dispositivo para ofrecer capacidades mejoradas. El complemento del dispositivo sigue gestionando las funciones básicas de detección y administración de las GPU, mientras que DRA añade funciones avanzadas de asignación y programación.

Instancias compatibles con DRA y sus funciones

La compatibilidad con DRA varía según la familia de instancias de Amazon EC2 y la arquitectura de la GPU, como se muestra en la tabla siguiente.

Las siguientes son descripciones de cada función de la tabla:

Recursos adicionales

Para obtener más información sobre los controladores DRA de Kubernetes y DRA de NVIDIA, consulte los siguientes recursos sobre: GitHub

Configura la asignación dinámica de recursos para la administración avanzada de las GPU

En el siguiente tema, se muestra cómo configurar la asignación dinámica de recursos (DRA) para la administración avanzada de GPU.

Requisitos previos

Antes de implementar DRA en Amazon EKS, asegúrese de que su entorno cumple los siguientes requisitos.

Configuración del clúster

Componentes necesarios

Paso 1: Crear un clúster con un grupo de DRA-enabled nodos mediante eksctl

Paso 2: Implemente el complemento de dispositivo NVIDIA

Implementa el complemento de dispositivo NVIDIA para permitir la detección básica de GPU:

Paso 3: Implemente el controlador DRA de NVIDIA Helm Chart

Paso 4: Verifique la instalación de DRA

Siga en Programe una carga de trabajo de GPU simple mediante la asignación dinámica de recursos.

Programe una carga de trabajo de GPU simple mediante la asignación dinámica de recursos

Para programar una carga de trabajo de GPU simple mediante la asignación dinámica de recursos (DRA), sigue estos pasos. Antes de continuar, asegúrate de haberlo seguidoConfigura la asignación dinámica de recursos para la administración avanzada de las GPU.

Continúe con Técnicas de optimización de GPU con asignación dinámica de recursos las técnicas de optimización de GPU más avanzadas con DRA.

Técnicas de optimización de GPU con asignación dinámica de recursos

Las cargas de trabajo de GPU modernas requieren una administración sofisticada de los recursos para lograr una utilización y una rentabilidad óptimas. DRA permite varias técnicas de optimización avanzadas que abordan diferentes casos de uso y capacidades de hardware:

Estas técnicas pueden mejorar significativamente la utilización de los recursos. Las organizaciones informan que la utilización de la GPU aumenta del 30 al 40% con la asignación tradicional al 80 al 90% con estrategias de uso compartido optimizadas. La elección de la técnica depende de las características de la carga de trabajo, los requisitos de aislamiento y las capacidades del hardware.

Optimice las cargas de trabajo de la GPU reduciendo el tiempo

Time-slicing permite que varias cargas de trabajo compartan los recursos informáticos de la GPU programándolos para que se ejecuten de forma secuencial en la misma GPU física. Es ideal para cargas de trabajo de inferencia con un uso esporádico de la GPU.

Lleve a cabo los siguientes pasos.

Primer pod (inference-pod-1)

Segundo pod (training-pod-2)

Optimice las cargas de trabajo de la GPU con MPS

Multi-Process El servicio (MPS) permite la ejecución simultánea de varios contextos CUDA en una sola GPU con un mejor aislamiento que la reducción del tiempo.

Realice los siguientes pasos.

Esta configuración demuestra que se comparte realmente la GPU mediante el Multi-Process servicio NVIDIA (MPS) mediante la asignación dinámica de recursos (DRA). A diferencia de la segmentación temporal, en la que las cargas de trabajo se turnan para usar la GPU de forma secuencial, MPS permite que ambos contenedores se ejecuten simultáneamente en la misma GPU física. La idea clave es que para compartir MPS con DRA se necesitan varios contenedores en un solo pod, no varios pods independientes. Cuando se implementa, el controlador DRA asigna uno ResourceClaim al pod y configura automáticamente el MPS para permitir que tanto los contenedores de inferencia como los de entrenamiento se ejecuten simultáneamente.

Cada contenedor obtiene su propio espacio de memoria de GPU y recursos informáticos aislados, y el daemon MPS coordina el acceso al hardware subyacente. Para comprobar que esto funciona, haga lo siguiente:

Este enfoque maximiza la utilización de la GPU al permitir que las cargas de trabajo complementarias compartan el costoso hardware de la GPU de manera eficiente, en lugar de dejarlo infrautilizado por un solo proceso.

Contenedor 1: contenedor de inferencia

root@mps-multi-container-pod:/workspace# nvidia-smi
Wed Jul 16 21:09:30 2025
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.158.01             Driver Version: 570.158.01     CUDA Version: 12.9     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA L4                      On  |   00000000:35:00.0 Off |                    0 |
| N/A   48C    P0             28W /   72W |     597MiB /  23034MiB |      0%   E. Process |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A               1    M+C   python                                  246MiB |
+-----------------------------------------------------------------------------------------+

Contenedor 2: contenedor de entrenamiento

root@mps-multi-container-pod:/workspace# nvidia-smi
Wed Jul 16 21:16:00 2025
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.158.01             Driver Version: 570.158.01     CUDA Version: 12.9     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA L4                      On  |   00000000:35:00.0 Off |                    0 |
| N/A   51C    P0             28W /   72W |     597MiB /  23034MiB |      0%   E. Process |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A               1    M+C   python                                  314MiB |
+-----------------------------------------------------------------------------------------+

Optimice las cargas de trabajo de la GPU con la GPU Multi-Instance

Multi-instance La GPU (MIG) proporciona particiones a nivel de hardware y crea instancias de GPU aisladas con recursos de computación y memoria dedicados.

El uso de particiones MIG dinámicas con varios perfiles requiere el operador de GPU de NVIDIA. https://github.com/NVIDIA/gpu-operator El operador de GPU de NVIDIA usa MIG Manager para crear perfiles MIG y reinicia las instancias de GPU, como P4D, P4De, P5, P6, etc., para aplicar los cambios de configuración. El GPU Operator incluye funciones integrales de administración de MIG a través del componente MIG Manager, que controla los cambios en las etiquetas de los nodos y aplica automáticamente la configuración MIG adecuada. Cuando se solicita un cambio de perfil MIG, el operador cierra correctamente todos los clientes de GPU, aplica la nueva geometría de partición y reinicia los servicios afectados. Este proceso requiere reiniciar los nodos de las instancias de GPU para garantizar que las transiciones de estado de la GPU sean limpias. Por este motivo, es fundamental habilitar WITH–0—REBOOT=true la configuración de MIG Manager para que las implementaciones de MIG tengan éxito.

Necesita tanto el controlador https://github.com/NVIDIA/k8s-dra-driver-gpu NVIDIA DRA como el NVIDIA GPU Operator para trabajar con MIG en Amazon EKS. Además de esto, no necesita el complemento de dispositivo NVIDIA ni el DCGM Exporter, ya que forman parte del operador de GPU de NVIDIA. Como las AMI NVIDIA de EKS vienen con los controladores NVIDIA preinstalados, hemos desactivado la implementación de los controladores por parte del operador de la GPU para evitar conflictos y aprovechar los controladores optimizados que ya estaban presentes en las instancias. El controlador DRA de NVIDIA gestiona la asignación dinámica de recursos para las instancias MIG, mientras que el operador de la GPU gestiona todo el ciclo de vida de la GPU. Esto incluye la configuración de MIG, la funcionalidad de los complementos del dispositivo, la supervisión mediante DCGM y la detección de las funciones de los nodos. Este enfoque integrado proporciona una solución completa para la administración de GPU empresariales, con capacidades de aislamiento a nivel de hardware y asignación dinámica de recursos.

Paso 1: Implemente NVIDIA GPU Operator

NVIDIA GPU Operator ha aplicado correctamente el perfil p4de-half-balanced MIG a tu instancia P4DE y ha creado particiones de GPU a nivel de hardware según la configuración. Así es como funciona la partición:

El operador de la GPU aplicó esta configuración desde tu perfil MIG integrado:

p4de-half-balanced:
  - devices: [0, 1, 2, 3]        # First 4 GPUs: MIG enabled
    mig-enabled: true
    mig-devices:
      "1g.10gb": 2               # 2x small instances (10GB each)
      "2g.20gb": 1               # 1x medium instance (20GB)
      "3g.40gb": 1               # 1x large instance (40GB)
  - devices: [4, 5, 6, 7]        # Last 4 GPUs: Full GPUs
    mig-enabled: false

A partir de tu nvidia-smi -L resultado, esto es lo que creó el operador de GPU:

Una vez que el operador de GPU de NVIDIA crea las particiones MIG, el controlador DRA de NVIDIA detecta automáticamente estas instancias aisladas del hardware y las pone a disposición para la asignación dinámica de recursos en Kubernetes. El controlador DRA descubre cada instancia MIG con su perfil específico (1g.10gb, 2g.20gb, 3g.40gb) y las expone como recursos programables según la clase de dispositivo. mig.nvidia.com

El controlador DRA monitorea continuamente la topología MIG y mantiene un inventario de las instancias disponibles en todas las GPU. Cuando un pod solicita un perfil MIG específico a través de unResourceClaimTemplate, el controlador DRA selecciona de forma inteligente una instancia MIG adecuada de cualquier GPU disponible, lo que permite una verdadera capacidad multiusuario a nivel de hardware. Esta asignación dinámica permite que varias cargas de trabajo aisladas se ejecuten simultáneamente en la misma GPU física, al tiempo que se mantienen estrictos límites de recursos y garantías de rendimiento.

Paso 2: Probar la asignación de recursos de MIG

Ahora veamos algunos ejemplos para demostrar cómo DRA asigna dinámicamente las instancias MIG a diferentes cargas de trabajo. Implemente los módulos resourceclaimtemplates y pruébelos para ver cómo el controlador DRA coloca las cargas de trabajo en las particiones MIG disponibles, lo que permite que varios contenedores compartan recursos de GPU con un aislamiento a nivel de hardware.

Optimice las cargas de trabajo de la GPU con IMEX mediante instancias P6e de 200 GB

El IMEX (Internode Memory Exchange) permite una comunicación coherente con la memoria entre los nodos para un entrenamiento distribuido en la NVIDIA GB200. UltraServers

Realice los siguientes pasos.

Para obtener más información, consulte el ejemplo de NVIDIA en GitHub.