En esta página se explica cómo realizar operaciones de lanzamiento incremental para desplegar gradualmente nuevas versiones de tu infraestructura de inferencia en 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 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:
- Implementación de la actualización de nodos (de computación y aceleradores)
- Lanzamiento de la actualización del modelo base
Actualizar un lanzamiento de nodos
Las 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 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.
Crea un
InferencePool
: implementa unInferencePool
configurado con las especificaciones de hardware o nodo actualizadas.Dividir el tráfico mediante un
HTTPRoute
: configura unHTTPRoute
para distribuir el tráfico entre los recursosInferencePool
actuales y los nuevos. Usa el campoweight
debackendRefs
para gestionar el porcentaje de tráfico dirigido a los nuevos nodos.Mantener una
InferenceObjective
coherente: conserva la configuración deInferenceObjective
para asegurar un comportamiento uniforme del modelo en ambas configuraciones de nodos.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.

Para llevar a cabo una implementación de actualización de nodos, sigue estos pasos:
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 group: inference.networking.k8s.io kind: InferenceGateway rules: backendRefs: - name: llm group: inference.networking.k8s.io kind: InferencePool weight: 90 - name: llm-new group: inference.networking.k8s.io kind: InferencePool weight: 10
Aplica el manifiesto de ejemplo a tu clúster:
kubectl apply -f routes-to-llm.yaml
La llm
original InferencePool
recibe la mayor parte del tráfico, mientras que la llm-new
InferencePool
recibe el resto. Aumenta el peso del tráfico gradualmente
para el 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:
- Implementar nueva infraestructura: crea nodos y un nuevo
InferencePool
configurado con el nuevo modelo base que has elegido. - Configurar la distribución del tráfico: usa un
HTTPRoute
para dividir el tráfico entre elInferencePool
que ya tienes (que usa el modelo base antiguo) y el nuevoInferencePool
(que usa el modelo base nuevo). El campobackendRefs weight
controla el porcentaje de tráfico asignado a cada grupo. - Mantener la integridad de
InferenceModel
: no cambie la configuración deInferenceModel
. De esta forma, el sistema aplica los mismos adaptadores LoRA de forma coherente en ambas versiones del modelo base. - 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:
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 group: inference.networking.k8s.io kind: InferenceGateway 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: 10
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.