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 de tu infraestructura de inferencia. Puedes actualizar los nodos, los modelos base y los adaptadores 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á destinada a los administradores de cuentas y de identidades de GKE, así como a los desarrolladores que quieran realizar operaciones de lanzamiento para GKE Inference Gateway.

Se admiten los siguientes casos de uso:

Actualiza el lanzamiento de un nodo

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

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

  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 una InferenceModel coherente: Retén la configuración de InferenceModel existente para garantizar un comportamiento uniforme del modelo en ambas configuraciones de nodos.

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

Por ejemplo, puedes crear un InferencePool nuevo llamado llm-new. Configura este grupo con la misma configuración de modelo que tu llm InferencePool existente. 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 InferencePool llm-new nuevo. Esta técnica te permite actualizar de forma incremental los nodos de tu 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 realizar un lanzamiento de 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 ejemplo a tu clúster:

    kubectl apply -f routes-to-llm.yaml

El InferencePool llm original recibe la mayor parte del tráfico, mientras que el InferencePool llm-new recibe el resto del tráfico. Aumenta el peso del tráfico gradualmente 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 a un nuevo LLM base, lo que conserva la compatibilidad con los adaptadores LoRA existentes. Puedes usar los lanzamientos de actualizaciones de modelos base para actualizar a arquitecturas de modelos mejoradas o para abordar problemas específicos del modelo.

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

  1. Implementa una nueva infraestructura: Crea nodos nuevos y un nuevo InferencePool 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 InferencePool nuevo (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: No cambies la configuración de InferenceModel. Esto garantiza que el sistema aplique los mismos adaptadores LoRA de manera coherente en ambas versiones del modelo base.
  4. Preserva la capacidad de reversión: Conserva los nodos originales y InferencePool durante el lanzamiento para facilitar una reversión si es necesario.

Creas un InferencePool nuevo llamado llm-pool-version-2. Este grupo implementa una versión nueva del modelo base en un conjunto nuevo 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 realizar un lanzamiento de actualización de 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 ejemplo a tu clúster:

    kubectl apply -f routes-to-llm.yaml

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

Lanzamiento de actualizaciones del adaptador LoRA

Los lanzamientos de actualizaciones del adaptador LoRA te permiten implementar versiones nuevas de modelos ajustados en fases, sin alterar el modelo o la infraestructura de base subyacentes. Usa los lanzamientos de actualizaciones de adaptadores de LoRA para probar mejoras, correcciones de errores o funciones nuevas en tus adaptadores de LoRA.

Para actualizar un adaptador LoRA, sigue estos pasos:

  1. Cómo hacer que los adaptadores estén disponibles: Asegúrate de que las nuevas versiones de los adaptadores 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 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 InferenceModel para controlar la distribución del tráfico entre las diferentes versiones del adaptador LoRA.

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

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 dentro del mismo InferenceModel. Asigna ponderaciones para cambiar de forma incremental el tráfico de llm-v1 a llm-v2. Este control permite un lanzamiento controlado sin requerir ningún cambio en tus nodos ni en la configuración de InferencePool.

Para lanzar actualizaciones del adaptador 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 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 gradualmente para la versión llm-v2 para completar el lanzamiento de la actualización del adaptador LoRA.

¿Qué sigue?