Realiza operaciones de lanzamiento para la puerta de enlace de inferencia de GKE

En esta página, se muestra cómo realizar operaciones de lanzamiento incrementales, que implementan gradualmente versiones nuevas de tu infraestructura de inferencia para la puerta de enlace de inferencia de GKE. Esta puerta de enlace te permite realizar actualizaciones seguras y controladas en tu infraestructura de inferencia. Puedes actualizar nodos, modelos básicos y adaptadores de LoRA con una interrupción mínima del servicio. En esta página, también se proporciona orientación sobre la división del tráfico y las reversiones para garantizar implementaciones confiables.

Esta página está dirigida a los administradores de cuentas y de identidades de GKE, y a los desarrolladores que desean realizar operaciones de lanzamiento para la puerta de enlace de inferencia de GKE.

Se admiten los siguientes casos de uso:

Actualiza el lanzamiento de un nodo

Las implementaciones de actualizaciones de nodos migran de forma segura las cargas de trabajo de inferencia a nuevas configuraciones de hardware o aceleradores de nodos. Este proceso se realiza de forma controlada sin interrumpir el servicio del modelo. Usa implementaciones de actualizaciones de nodos para minimizar las interrupciones del servicio durante las actualizaciones de hardware, las actualizaciones de controladores o la resolución de problemas de seguridad.

  1. Crea un InferencePool nuevo: Implementa un InferencePool configurado con las especificaciones de hardware o nodo actualizadas.

  2. Divide el tráfico con un HTTPRoute: Configura un HTTPRoute para distribuir el tráfico entre los recursos InferencePool existentes y los nuevos. Usa el campo weight en backendRefs para administrar el porcentaje de tráfico dirigido a los nodos nuevos.

  3. Mantén un InferenceModel coherente: Conserva la configuración de InferenceModel existente para garantizar un comportamiento uniforme del modelo en ambas configuraciones de nodos.

  4. Conserva los recursos originales: Mantén activos los nodos y los InferencePool originales durante el lanzamiento para habilitar las reversiones si es necesario.

Por ejemplo, puedes crear un nuevo InferencePool llamado llm-new. Configura este grupo con la misma configuración del modelo que tu llm existente InferencePool. Implementa el grupo en un nuevo conjunto de nodos dentro de tu clúster. Usa un objeto HTTPRoute para dividir el tráfico entre el llm original y el nuevo llm-new InferencePool. Esta técnica te permite actualizar de forma incremental los nodos del modelo.

En el siguiente diagrama, se ilustra cómo GKE Inference Gateway realiza un lanzamiento de actualización de nodos.

Proceso de lanzamiento de la actualización de nodos
Figura: Proceso de lanzamiento de la actualización de nodos

Para implementar una actualización de nodos, sigue estos pasos:

  1. Guarda el siguiente manifiesto de muestra como routes-to-llm.yaml:

    apiVersion: gateway.networking.k8s.io/v1
kind: `HTTPRoute`
metadata:
  name: routes-to-llm
spec:
  parentRefs:
    - name: my-inference-gateway
  rules:
    backendRefs:
    - name: llm
      kind: InferencePool
      weight: 90
    - name: llm-new
      kind: InferencePool
      weight: 10

  2. Aplica el manifiesto de muestra a tu clúster:

    kubectl apply -f routes-to-llm.yaml

El llm InferencePool original recibe la mayor parte del tráfico, mientras que el llm-new InferencePool recibe el resto. Aumenta el peso del tráfico de forma gradual para que llm-new InferencePool complete el lanzamiento de la actualización del nodo.

Lanza un modelo base

Las actualizaciones del modelo base se lanzan en fases para un nuevo LLM base, lo que mantiene la compatibilidad con los adaptadores de LoRA existentes. Puedes usar los lanzamientos de actualizaciones del modelo base para actualizarte a arquitecturas de modelos mejoradas o abordar problemas específicos del modelo.

Para lanzar una actualización del modelo base, haz lo siguiente:

  1. Implementar infraestructura nueva: Crea nodos nuevos y un InferencePool nuevo configurado con el nuevo modelo base que elegiste.
  2. Configura la distribución del tráfico: Usa un HTTPRoute para dividir el tráfico entre el InferencePool existente (que usa el modelo base anterior) y el nuevo InferencePool (que usa el modelo base nuevo). El campo backendRefs weight controla el porcentaje de tráfico asignado a cada grupo.
  3. Mantén la integridad de InferenceModel: Mantén sin cambios la configuración de InferenceModel. Esto garantiza que el sistema aplique los mismos adaptadores de LoRA de manera coherente en ambas versiones del modelo base.
  4. Conserva la capacidad de reversión: Conserva los nodos originales y InferencePool durante el lanzamiento para facilitar una reversión si es necesario.

Creas un nuevo InferencePool llamado llm-pool-version-2. Este grupo implementa una nueva versión del modelo base en un nuevo conjunto de nodos. Si configuras un HTTPRoute, como se muestra en el ejemplo proporcionado, puedes dividir el tráfico de forma incremental entre el llm-pool original y llm-pool-version-2. Esto te permite controlar las actualizaciones del modelo base en tu clúster.

Para lanzar una actualización del modelo base, sigue estos pasos:

  1. Guarda el siguiente manifiesto de muestra como routes-to-llm.yaml:

    apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: routes-to-llm
spec:
  parentRefs:
    - name: my-inference-gateway
  rules:
    backendRefs:
    - name: llm-pool
      kind: InferencePool
      weight: 90
    - name: llm-pool-version-2
      kind: InferencePool
      weight: 10

  2. Aplica el manifiesto de muestra a tu clúster:

    kubectl apply -f routes-to-llm.yaml

El llm-pool original InferencePool recibe la mayor parte del tráfico, mientras que el llm-pool-version-2 InferencePool recibe el resto. Aumenta el peso del tráfico de forma gradual para el llm-pool-version-2 InferencePool y completar el lanzamiento de la actualización del modelo base.

Lanza actualizaciones de adaptadores de LoRA

Las implementaciones de actualizaciones de adaptadores de LoRA te permiten implementar nuevas versiones de modelos ajustados en fases, sin alterar el modelo base ni la infraestructura subyacentes. Usa las implementaciones de actualizaciones de adaptadores de LoRA para probar mejoras, correcciones de errores o funciones nuevas en tus adaptadores de LoRA.

Para actualizar un adaptador de LoRA, sigue estos pasos:

  1. Haz que los adaptadores estén disponibles: Asegúrate de que las nuevas versiones del adaptador de LoRA estén disponibles en los servidores de modelos. Para obtener más información, consulta Lanzamiento del adaptador.

  2. Modifica la configuración de InferenceModel: En tu configuración de InferenceModel existente, define varias versiones de tu adaptador de LoRA. Asigna un modelName único a cada versión (por ejemplo, llm-v1, llm-v2).

  3. Distribuye el tráfico: Usa el campo weight en la especificación de InferenceModel para controlar la distribución del tráfico entre las diferentes versiones del adaptador de LoRA.

  4. Mantén un poolRef coherente: Asegúrate de que todas las versiones del adaptador de LoRA hagan referencia al mismo InferencePool. Esto evita que se vuelvan a implementar nodos o InferencePool. Conserva las versiones anteriores del adaptador de LoRA en la configuración de InferenceModel para habilitar las reversiones.

En el siguiente ejemplo, se muestran dos versiones del adaptador de LoRA, llm-v1 y llm-v2. Ambas versiones usan el mismo modelo base. Defines llm-v1 y llm-v2 dentro del mismo InferenceModel. Asignas pesos para cambiar el tráfico de llm-v1 a llm-v2 de forma incremental. Este control permite realizar un lanzamiento controlado sin necesidad de cambiar los nodos ni la configuración de InferencePool.

Para lanzar actualizaciones del adaptador de LoRA, ejecuta el siguiente comando:

  1. Guarda el siguiente manifiesto de muestra como inferencemodel-sample.yaml:

    apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferenceModel
metadata:
  name: inferencemodel-sample
spec:
versions:
-   modelName: llm-v1
  criticality: Critical
  weight: 90
  poolRef:
    name: llm-pool
-   modelName: llm-v2
  criticality: Critical
  weight: 10
  poolRef:
    name: llm-pool

  2. Aplica el manifiesto de muestra a tu clúster:

    kubectl apply -f inferencemodel-sample.yaml

La versión llm-v1 recibe la mayor parte del tráfico, mientras que la versión llm-v2 recibe el resto. Aumenta el peso del tráfico de forma gradual para la versión llm-v2 y completar el lanzamiento de la actualización del adaptador de LoRA.

¿Qué sigue?