En esta página, se muestra cómo realizar operaciones de lanzamiento incremental, que implementan gradualmente versiones nuevas de tu infraestructura de inferencia para GKE Inference Gateway. Esta puerta de enlace te permite realizar actualizaciones seguras y controladas en tu infraestructura de inferencia. Puedes actualizar nodos, modelos base y adaptadores LoRA con una interrupción mínima del servicio. En esta página, también se proporcionan 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 quieran realizar operaciones de lanzamiento para GKE Inference Gateway.
Se admiten los siguientes casos de uso:
- Lanzamiento de actualización de nodos (acelerador de procesamiento)
- Lanzamiento de la actualización del modelo base
Actualiza el lanzamiento de un nodo
Las 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 las actualizaciones de nodos para minimizar la interrupción del servicio durante las actualizaciones de hardware, de controladores o de resolución de problemas de seguridad.
Crea un
InferencePoolnuevo: Implementa unInferencePoolconfigurado con las especificaciones actualizadas del nodo o hardware.Divide el tráfico con un
HTTPRoute: Configura unHTTPRoutepara distribuir el tráfico entre los recursosInferencePoolexistentes y nuevos. Usa el campoweightenbackendRefspara administrar el porcentaje de tráfico dirigido a los nodos nuevos.Mantén un
InferenceObjectivecoherente: Conserva la configuración deInferenceObjectiveexistente para garantizar un comportamiento uniforme del modelo en ambas configuraciones de nodos.Conserva los recursos originales: Mantén activos los nodos y los recursos
InferencePooloriginales 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 conjunto nuevo de nodos dentro 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 ilustra cómo GKE Inference Gateway realiza un lanzamiento de actualización de nodos.
Para realizar un lanzamiento de actualización de nodos, sigue estos pasos:
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 group: gateway.networking.k8s.io kind: Gateway rules: - backendRefs: - name: llm group: inference.networking.k8s.io kind: InferencePool weight: 90 - name: llm-new group: inference.networking.k8s.io kind: InferencePool weight: 10Aplica el manifiesto de muestra 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. Aumenta el peso del tráfico de forma gradual
para que llm-new InferencePool complete el lanzamiento de la actualización de nodos.
Lanza un modelo de base
Las actualizaciones del modelo base se lanzan en fases para un nuevo LLM base, lo que mantiene la compatibilidad con los adaptadores LoRA existentes. Puedes usar las actualizaciones de lanzamiento 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:
- Implementar infraestructura nueva: Crea nodos nuevos y un
InferencePoolconfigurado con el nuevo modelo base que elegiste. - Configura la distribución del tráfico: Usa un
HTTPRoutepara dividir el tráfico entre elInferencePoolexistente (que usa el modelo base anterior) y el nuevoInferencePool(que usa el modelo base nuevo). El campobackendRefs weightcontrola el porcentaje de tráfico asignado a cada grupo. - Mantén la integridad de
InferenceObjective: No modifiques la configuración deInferenceObjective. Este enfoque ayuda a garantizar que el sistema aplique los mismos adaptadores LoRA de manera coherente en ambas versiones del modelo base. - Conservar la capacidad de reversión: Conserva los nodos originales y
InferencePooldurante el lanzamiento para facilitar una reversión si es necesario.
Creas un InferencePool nuevo 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 implementar una actualización del modelo base, sigue estos pasos:
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 group: gateway.networking.k8s.io kind: Gateway rules: - backendRefs: - name: llm-pool group: inference.networking.k8s.io kind: InferencePool weight: 90 - name: llm-pool-version-2 group: inference.networking.k8s.io kind: InferencePool weight: 10Aplica el manifiesto de muestra 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 de forma gradual para el llm-pool-version-2 InferencePool para completar el lanzamiento de la actualización del modelo base.