Realizar operaciones de lanzamiento de GKE Inference Gateway

En esta página se explica cómo realizar operaciones de lanzamiento incremental, que despliegan gradualmente nuevas versiones de tu infraestructura de inferencia para GKE Inference Gateway. Esta pasarela te permite realizar actualizaciones seguras y controladas de tu infraestructura de inferencia. Puedes actualizar nodos, modelos base y adaptadores LoRA con una interrupción mínima del servicio. Esta página también ofrece directrices sobre la división del tráfico y las reversiones para ayudar a garantizar que las implementaciones sean fiables.

Esta página está dirigida a administradores de identidades y cuentas de GKE, así como a desarrolladores que quieran llevar a cabo operaciones de lanzamiento de GKE Inference Gateway.

Se admiten los siguientes casos prácticos:

Actualizar un lanzamiento de nodos

Las implementaciones de actualizaciones de nodos migran de forma segura las cargas de trabajo de inferencia a nuevo hardware de nodos o configuraciones de aceleradores. Este proceso se lleva a cabo de forma controlada sin interrumpir el servicio del modelo. Usa las 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: implementa un InferencePool configurado con las especificaciones de hardware o nodo actualizadas.

  2. Dividir el tráfico mediante un HTTPRoute: configura un HTTPRoute para distribuir el tráfico entre los recursos InferencePool actuales y los nuevos. Usa el campo weight de backendRefs para gestionar el porcentaje de tráfico dirigido a los nuevos nodos.

  3. Mantener una InferenceModel coherente: conserva la configuración de InferenceModel para asegurar un comportamiento uniforme del modelo en ambas configuraciones de nodos.

  4. Conservar los recursos originales: mantén activos los InferencePool y los nodos originales durante la implementación para poder revertir los cambios si es necesario.

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

En el siguiente diagrama se muestra cómo lleva a cabo GKE Inference Gateway una implementación de actualización de nodos.

Proceso de lanzamiento de actualizaciones de nodos
Imagen: proceso de lanzamiento de la actualización de nodos

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

  1. Guarda el siguiente archivo de manifiesto de ejemplo 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 ejemplo a tu clúster:

    kubectl apply -f routes-to-llm.yaml

La llm InferencePool original recibe la mayor parte del tráfico, mientras que la llm-new InferencePool recibe el resto. Aumenta el peso del tráfico gradualmente del llm-new InferencePool para completar la implementación de la actualización del nodo.

Lanzar un modelo base

Las actualizaciones del modelo base se lanzan por fases a un nuevo LLM base, manteniendo la compatibilidad con los adaptadores LoRA actuales. Puedes usar las implementaciones de actualizaciones de modelos base para cambiar a arquitecturas de modelos mejoradas o para solucionar problemas específicos de los modelos.

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

  1. Implementar nueva infraestructura: crea nodos y un nuevo InferencePool configurado con el nuevo modelo base que has elegido.
  2. Configurar la distribución del tráfico: usa un HTTPRoute para dividir el tráfico entre el InferencePool que ya tienes (que usa el modelo base antiguo) 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. Mantener la integridad de InferenceModel: no cambie la configuración de InferenceModel. De esta forma, el sistema aplica los mismos adaptadores LoRA de forma coherente en ambas versiones del modelo base.
  4. Conservar la capacidad de revertir: conserva los nodos y InferencePool originales durante el lanzamiento para facilitar la reversión si es necesario.

Crea un nuevo InferencePool llamado llm-pool-version-2. Este grupo despliega una nueva versión del modelo base en un nuevo conjunto de nodos. Si configura un HTTPRoute, como se muestra en el ejemplo, puede dividir el tráfico de forma incremental entre el llm-pool original y el llm-pool-version-2. De esta forma, puedes 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 archivo de manifiesto de ejemplo 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 ejemplo a tu clúster:

    kubectl apply -f routes-to-llm.yaml

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

Implementar actualizaciones del adaptador LoRA

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

Para actualizar un adaptador LoRA, sigue estos pasos:

  1. Poner a disposición los adaptadores: asegúrate de que las nuevas versiones del adaptador LoRA estén disponibles en los servidores del modelo. Para obtener más información, consulta Implementación de adaptadores.

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

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

  4. Mantener un poolRef coherente: asegúrate de que todas las versiones del adaptador LoRA hagan referencia al mismo InferencePool. De esta forma, se evitan las nuevas implementaciones de nodos o InferencePool. Conserva las versiones anteriores del adaptador LoRA en la configuración InferenceModel para habilitar las restauraciones.

En el siguiente ejemplo se muestran dos versiones del adaptador LoRA, llm-v1 y llm-v2. Ambas versiones usan el mismo modelo base. Define llm-v1 y llm-v2 en el mismo InferenceModel. Asigna pesos para cambiar el tráfico de llm-v1 a llm-v2 de forma incremental. Este control permite una implementación controlada sin necesidad de hacer cambios en los nodos ni en la configuración de InferencePool.

Para implementar las actualizaciones del adaptador LoRA, ejecuta el siguiente comando:

  1. Guarda el siguiente archivo de manifiesto de ejemplo 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 ejemplo 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 en la versión llm-v2 para completar el lanzamiento de la actualización del adaptador LoRA.

Siguientes pasos