Información acerca de la obtención de GPU con el modelo de aprovisionamiento de inicio flexible

En esta página, se describe el modo de aprovisionamiento de inicio flexible en Google Kubernetes Engine (GKE). El inicio flexible, impulsado por el programador dinámico de cargas de trabajo, proporciona una técnica flexible y rentable para obtener GPUs cuando necesitas ejecutar cargas de trabajo de IA/AA.

El inicio flexible te permite aprovisionar aceleradores de forma dinámica según sea necesario, por hasta siete días, sin estar limitado a una hora de inicio específica y sin la administración de reservas a largo plazo. Por lo tanto, el inicio flexible funciona bien para cargas de trabajo de menor a mediano tamaño con requisitos de demanda fluctuantes o duraciones cortas. Por ejemplo, el entrenamiento previo de modelos pequeños, el ajuste fino de modelos o los modelos de entrega escalables.

La información de esta página puede ayudarte a hacer lo siguiente:

  • Comprende cómo funciona el inicio flexible en GKE.
  • Decide si el inicio flexible es adecuado para tu carga de trabajo.
  • Decide qué configuración de inicio flexible es adecuada para tu carga de trabajo.
  • Administra las interrupciones cuando usas flex-start.
  • Comprende las limitaciones de flex-start en GKE.

Esta página está dirigida a operadores y administradores de plataformas, y a ingenieros de aprendizaje automático (AA) que deseen optimizar la infraestructura del acelerador para sus cargas de trabajo.

Cuándo usar flex-start

Te recomendamos que uses flex-start si tus cargas de trabajo cumplen con todas las siguientes condiciones:

  • Tus cargas de trabajo requieren recursos de GPU.
  • Tienes una capacidad limitada o no reservada de GPU y necesitas un acceso más confiable a las GPUs.
  • Tu carga de trabajo es flexible, y tu caso de uso puede permitirse esperar para obtener toda la capacidad solicitada, por ejemplo, cuando GKE asigna los recursos de GPU fuera de las horas de mayor actividad.

Requisitos

Para usar el inicio flexible en GKE, tu clúster debe usar la versión 1.32.2-gke.1652000 o una posterior.

Cómo funciona el modo de aprovisionamiento de inicio flexible

Con el inicio flexible, especificas la capacidad de GPU requerida en tus cargas de trabajo. Además, con los clústeres estándar, configuras el inicio flexible en grupos de nodos específicos. GKE aprovisiona VMs automáticamente completando el siguiente proceso cuando la capacidad está disponible:

  1. La carga de trabajo solicita recursos de GPU que no están disponibles de inmediato. La especificación de la carga de trabajo o las herramientas de programación, como las clases de procesamiento personalizadas o Kueue, pueden realizar esta solicitud directamente.
  2. GKE identifica que tu nodo tiene habilitado el inicio flexible y que la carga de trabajo puede esperar por un tiempo indeterminado.
  3. El escalador automático del clúster acepta tu solicitud y calcula la cantidad de nodos necesarios y los trata como una sola unidad.
  4. El programador espera hasta que todos los recursos necesarios estén disponibles en una sola zona.
  5. El escalador automático de clústeres aprovisiona los nodos necesarios cuando están disponibles. Estos nodos se ejecutan durante un máximo de siete días o por un período más corto si especificas un valor en el parámetro maxRunDurationSeconds. Este parámetro está disponible con la versión 1.28.5-gke.1355000 de GKE o una posterior. Si no especificas un valor para el parámetro maxRunDurationSeconds, el valor predeterminado es de siete días.
  6. Después de que finaliza el tiempo de ejecución que definiste en el parámetro maxRunDurationSeconds, los nodos y los Pods se interrumpen.
  7. Si los Pods finalizan antes y los nodos ya no se usan, el escalador automático del clúster los quita según el perfil de ajuste de escala automático.

GKE cuenta la duración de cada solicitud de inicio flexible a nivel del nodo. El tiempo disponible para ejecutar Pods puede ser un poco menor debido a demoras durante el inicio. Los reintentos de Pod comparten esta duración, lo que significa que hay menos tiempo disponible para los Pods después del reintento. GKE cuenta la duración de cada solicitud de inicio flexible por separado.

Parámetros de configuración de inicio flexible

GKE admite las siguientes configuraciones de inicio flexible:

  • Flex-start, en el que GKE asigna recursos por nodo. Esta configuración solo requiere que establezcas la marca --flex-start durante la creación del nodo.

  • Inicio flexible con aprovisionamiento en cola, en el que GKE asigna todos los recursos solicitados al mismo tiempo. Todos los Pods de la carga de trabajo pueden ejecutarse juntos en nodos recién aprovisionados. Los nodos aprovisionados no se reutilizan entre las ejecuciones de cargas de trabajo. Para usar esta configuración, debes agregar las marcas --flex-start y enable-queued-provisioning cuando crees el grupo de nodos.

En la siguiente tabla, se comparan las configuraciones de inicio flexible:

Inicio flexible Inicio flexible con aprovisionamiento en cola
Disponibilidad Versión preliminar
Nota: Para inscribirte en la vista previa de inicio flexible, completa el formulario de solicitud. Para enviar comentarios o solicitar asistencia para esta función, comunícate con dws-flex-start-feedback@google.com.

Disponibilidad general (DG)

Nota: Flex-start admite las marcas flex-start y enable-queued-provisioning en la versión preliminar. Para inscribirte en la vista previa de estas marcas, completa el formulario de solicitud. Para enviar comentarios o solicitar asistencia para esta función, comunícate con dws-flex-start-feedback@google.com.
Tamaño de carga de trabajo recomendado De pequeña a mediana, lo que significa que la carga de trabajo se puede ejecutar en un solo nodo. Por ejemplo, esta configuración funciona bien si ejecutas trabajos de entrenamiento pequeños, inferencia sin conexión o trabajos por lotes. De mediana a grande, lo que significa que la carga de trabajo se puede ejecutar en varios nodos. Tu carga de trabajo requiere varios recursos y no puede comenzar a ejecutarse hasta que todos los nodos de GPU se aprovisionen y estén listos al mismo tiempo. Por ejemplo, esta configuración funciona bien si ejecutas cargas de trabajo de entrenamiento de AA distribuidas.
Tipo de aprovisionamiento GKE aprovisiona un nodo a la vez cuando hay recursos disponibles. GKE asigna todos los recursos solicitados de forma simultánea.
Complejidad de configuración Menos complejo. Esta configuración es similar a las VMs puntuales y según demanda. Es más complejo. Te recomendamos que uses una herramienta de administración de cuotas, como Kueue.
Compatibilidad con clases de procesamiento personalizadas Sí No
Reciclaje de nodos Sí No
Precio SKU de inicio flexible SKU de inicio flexible
Cuota Interrumpible Interrumpible
Estrategia de actualización de nodos Actualizaciones de corta duración Actualizaciones de corta duración
Marca gcloud container node pool create --flex-start
  • --flex-start
  • --enable-queued-provisioning
Comenzar Ejecuta una carga de trabajo a gran escala con inicio flexible con aprovisionamiento en fila

Optimiza la configuración de flex-start

Para crear una infraestructura de IA/AA sólida y optimizada en función del costo, puedes combinar configuraciones de inicio flexible con las funciones de GKE disponibles. Te recomendamos que uses las clases de procesamiento para definir una lista priorizada de configuraciones de nodos según los requisitos de tu carga de trabajo. GKE seleccionará la configuración más adecuada según la disponibilidad y la prioridad que hayas definido.

Administra las interrupciones en las cargas de trabajo que usan el programador dinámico de cargas de trabajo

Las cargas de trabajo que requieren la disponibilidad de todos los nodos, o de la mayoría de los nodos, en un grupo de nodos son sensibles a las expulsiones. Además, los nodos que se aprovisionan con solicitudes del programador dinámico de cargas de trabajo no admiten la reparación automática. La reparación automática quita todas las cargas de trabajo de un nodo y, por lo tanto, evita que se ejecuten.

Todos los nodos que usan el inicio flexible, el aprovisionamiento en fila o ambos usan actualizaciones de corta duración cuando el plano de control del clúster ejecuta la versión mínima para el inicio flexible, 1.32.2-gke.1652000 o una posterior.

Las actualizaciones de corta duración actualizan un grupo de nodos estándar o un grupo de nodos en un clúster de Autopilot sin interrumpir los nodos en ejecución. Los nodos nuevos se crean con la configuración nueva y, con el tiempo, reemplazan gradualmente los nodos existentes con la configuración anterior. Las versiones anteriores de GKE, que no admiten actualizaciones de inicio flexible ni de corta duración, requieren prácticas recomendadas diferentes.

Prácticas recomendadas para minimizar las interrupciones de la carga de trabajo de los nodos que usan actualizaciones de corta duración

Los nodos de inicio flexible y los que usan el aprovisionamiento en fila se configuran automáticamente para usar actualizaciones de corta duración cuando el clúster ejecuta la versión 1.32.2-gke.1652000 o una posterior.

Para minimizar las interrupciones en las cargas de trabajo que se ejecutan en nodos que usan actualizaciones de corta duración, realiza las siguientes tareas:

En el caso de los nodos de clústeres que ejecutan versiones anteriores a la 1.32.2-gke.1652000 y, por lo tanto, no usan actualizaciones de corta duración, consulta la guía específica para esos nodos.

Prácticas recomendadas para minimizar las interrupciones de la carga de trabajo en los nodos de aprovisionamiento en cola sin actualizaciones de corta duración

Los nodos que usan el aprovisionamiento en cola en un clúster que ejecuta una versión de GKE anterior a la 1.32.2-gke.1652000 no usan actualizaciones de corta duración. Los clústeres que se actualizaron a la versión 1.32.2-gke.1652000 o posterior con nodos de aprovisionamiento en cola existentes se actualizan automáticamente para usar actualizaciones de corta duración.

Para los nodos que ejecutan estas versiones anteriores, consulta la siguiente guía:

Consideraciones para cuando tu clúster migra a actualizaciones de corta duración

GKE actualiza los nodos existentes con el aprovisionamiento en fila para usar actualizaciones de corta duración cuando el clúster se actualiza a la versión 1.32.2-gke.1652000 o una posterior. GKE no actualiza otros parámetros de configuración, como habilitar las actualizaciones automáticas de nodos si las inhabilitaste para un grupo de nodos específico.

Te recomendamos que consideres implementar las siguientes prácticas recomendadas ahora que tus grupos de nodos usan actualizaciones de corta duración:

  • Si inhabilitaste las actualizaciones automáticas de nodos con la marca --no-enable-autoupgrade, esta migración no vuelve a habilitar las actualizaciones automáticas de nodos para el grupo de nodos. Te recomendamos que habilites las actualizaciones automáticas de nodos, ya que las actualizaciones de corta duración no interrumpen los nodos existentes ni las cargas de trabajo que se ejecutan en ellos. Para obtener más información, consulta Actualizaciones de corta duración.
  • También te recomendamos que, si tu clúster aún no está inscrito en un canal de versiones, lo inscribas para que puedas usar alcances de exclusión de mantenimiento más detallados.

Reciclaje de nodos en el inicio flexible

Para garantizar una transición fluida de los nodos y evitar el tiempo de inactividad de las tareas en ejecución, flex-start admite el reciclaje de nodos. Cuando un nodo llega al final de su duración de siete días, GKE puede reemplazarlo automáticamente por uno nuevo para preservar tus cargas de trabajo en ejecución.

Para usar el reciclaje de nodos, debes crear un perfil de clase de procesamiento personalizado e incluir el campo nodeRecycling en la especificación flexStart con los siguientes parámetros:

  • leadTimeSeconds: Es un parámetro configurable que te permite equilibrar la disponibilidad de los recursos y la eficiencia de costos. El parámetro leadTimeSeconds especifica cuántos segundos antes de que un nodo alcance el final de su duración de siete días un nuevo proceso de aprovisionamiento de nodos debe comenzar a reemplazarlo. Un tiempo de preparación más largo aumenta la probabilidad de que el nodo nuevo esté listo antes de que se quite el antiguo, pero podría generar costos adicionales.
  • maxRunDurationSeconds: Es un parámetro configurable que te permite establecer la duración máxima durante la que un nodo puede estar activo.

El proceso de reciclaje de nodos consta de los siguientes pasos:

  1. Fase de reciclaje: GKE valida que un nodo aprovisionado con inicio flexible tenga la marca nodeRecycling establecida en true. Si es así, GKE inicia la fase de reciclaje de nodos cuando la fecha actual es mayor o igual que la diferencia entre los valores de los siguientes campos:

    • creationTimestamp más maxRunDurationSeconds
    • leadTimeSeconds

    La marca creationTimeStamp incluye la hora en que se creó el nodo.

  2. Creación de nodos: Comienza el proceso de creación del nodo nuevo, que continúa con las fases de cola y aprovisionamiento. La duración de la fase de cola puede variar de forma dinámica según la zona y la capacidad específica del acelerador.

  3. Acordona el nodo que está llegando al final de su duración de siete días: Después de que se ejecute el nodo nuevo, se acordona el anterior. Esta acción evita que se programen Pods nuevos en él. Los Pods existentes en ese nodo siguen ejecutándose.

  4. Desaprovisionamiento de nodos: El nodo que llega al final de su duración de siete días se desaprovisiona después de un período adecuado, lo que ayuda a garantizar que las cargas de trabajo en ejecución se hayan migrado al nodo nuevo.

Para obtener más información sobre cómo usar el reciclaje de nodos, prueba el instructivo Cómo entregar LLM en GKE con una estrategia de aprovisionamiento de GPU con alta disponibilidad y optimización de costos.

Limitaciones

  • No se admite la antiafinidad entre Pods. El escalador automático del clúster no tiene en cuenta las reglas de antiafinidad entre Pods durante el aprovisionamiento de nodos, lo que puede generar cargas de trabajo no programables. Esta situación puede ocurrir cuando se aprovisionan nodos para dos o más objetos del Programador de cargas de trabajo dinámicos en el mismo grupo de nodos.
  • Solo se admiten los nodos de GPU.
  • Las reservas no son compatibles con el programador dinámico de cargas de trabajo. Debes especificar la marca --reservation-affinity=none cuando creas el grupo de nodos. El programador de cargas de trabajo dinámico solo requiere y admite la política de ubicación ANY para el ajuste de escala automático del clúster.
  • Una sola solicitud del programador dinámico de cargas de trabajo puede crear hasta 1,000 máquinas virtuales (VM), que es la cantidad máxima de nodos por zona para un solo grupo de nodos.
  • GKE usa la cuota ACTIVE_RESIZE_REQUESTS de Compute Engine para controlar la cantidad de solicitudes del programador dinámico de cargas de trabajo pendientes en una cola. De forma predeterminada, esta cuota tiene un límite de 100 solicitudes por proyecto de Google Cloud. Si intentas crear una solicitud de Dynamic Workload Scheduler superior a esta cuota, la solicitud nueva fallará.
  • Los grupos de nodos que usan el programador dinámico de cargas de trabajo son sensibles a las interrupciones, ya que los nodos se aprovisionan juntos. Para obtener más información, consulta Administra las interrupciones en las cargas de trabajo que usan el programador dinámico de cargas de trabajo.
  • Es posible que veas VMs adicionales de corta duración adicionales en la consola de Google Cloud. Este comportamiento está previsto porque Compute Engine podría crear y quitar VMs de forma oportuna hasta que la capacidad de aprovisionar todas las máquinas necesarias esté disponible.
  • No se admiten las VMs Spot.
  • El programador de cargas de trabajo dinámico no admite volúmenes efímeros. Debes usar volúmenes persistentes para el almacenamiento. Para seleccionar el mejor tipo de almacenamiento que use volúmenes persistentes, consulta Descripción general del almacenamiento de los clústeres de GKE.
  • Si la carga de trabajo usa el reciclaje de nodos y la implementa un trabajo, configúralo con el modo de finalización establecido en Indexed.

¿Qué sigue?