Effectuer des opérations de déploiement pour GKE Inference Gateway

Cette page explique comment effectuer des opérations de déploiement progressif, qui déploient progressivement de nouvelles versions de votre infrastructure d'inférence, pour GKE Inference Gateway. Cette passerelle vous permet d'effectuer des mises à jour sécurisées et contrôlées de votre infrastructure d'inférence. Vous pouvez mettre à jour les nœuds, les modèles de base et les adaptateurs LoRA avec une interruption minimale du service. Cette page fournit également des conseils sur la répartition du trafic et les rollbacks pour garantir des déploiements fiables.

Cette page est destinée aux administrateurs de comptes et d'identités GKE et aux développeurs qui souhaitent effectuer des opérations de déploiement pour GKE Inference Gateway.

Les cas d'utilisation suivants sont pris en charge :

Déployer une mise à jour de nœud

Les mises à jour de nœuds migrent en toute sécurité les charges de travail d'inférence vers de nouvelles configurations matérielles ou d'accélérateur de nœuds. Ce processus se déroule de manière contrôlée sans interrompre le service de modèle. Utilisez les mises à jour de nœuds pour minimiser les interruptions de service lors des mises à niveau matérielles, des mises à jour de pilotes ou de la résolution de problèmes de sécurité.

  1. Créer un InferencePool : déployez un InferencePool configuré avec les spécifications de nœud ou matérielles mises à jour.

  2. Répartir le trafic à l'aide d'un HTTPRoute : configurez un HTTPRoute pour répartir le trafic entre les ressources InferencePool existantes et nouvelles. Utilisez le champ weight dans backendRefs pour gérer le pourcentage de trafic dirigé vers les nouveaux nœuds.

  3. Maintenir un InferenceObjective cohérent InferenceObjective : conservez la configuration existante pour garantir un comportement de modèle uniforme dans les deux configurations de nœuds.

  4. Conserver les ressources d'origine : conservez les nœuds et InferencePoolactifs pendant le déploiement pour permettre les rollbacks si nécessaire.

Par exemple, vous pouvez créer un InferencePool nommé llm-new. Configurez ce pool avec la même configuration de modèle que votre InferencePool llm existant. Déployez le pool sur un nouvel ensemble de nœuds dans votre cluster. Utilisez un HTTPRoute objet pour répartir le trafic entre le llm d'origine et le nouveau llm-new InferencePool. Cette technique vous permet de mettre à jour progressivement les nœuds de votre modèle.

Le diagramme suivant montre comment GKE Inference Gateway effectue un déploiement de mise à jour de nœud.

Processus de déploiement des mises à jour de nœuds
Figure : Processus de déploiement de la mise à jour de nœud

Pour effectuer un déploiement de mise à jour de nœud, procédez comme suit :

  1. Enregistrez l'exemple de fichier manifeste suivant sous le nom 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: 10

  2. Appliquez l'exemple de fichier manifeste à votre cluster :

    kubectl apply -f routes-to-llm.yaml

Le InferencePool llm d'origine reçoit la majeure partie du trafic, tandis que le InferencePool llm-new reçoit le reste. Augmentez progressivement la pondération du trafic pour le InferencePool llm-new afin de terminer le déploiement de la mise à jour de nœud.

Déployer un modèle de base

Les mises à jour de modèle de base sont déployées par phases vers un nouveau LLM de base, tout en conservant la compatibilité avec les adaptateurs LoRA existants. Vous pouvez utiliser les déploiements de mise à jour de modèle de base pour passer à des architectures de modèle améliorées ou pour résoudre des problèmes spécifiques aux modèles.

Pour déployer une mise à jour de modèle de base :

  1. Déployer une nouvelle infrastructure : créez des nœuds et un InferencePool configuré avec le nouveau modèle de base que vous avez choisi.
  2. Configurer la répartition du trafic : utilisez un HTTPRoute pour répartir le trafic entre le InferencePool existant (qui utilise l'ancien modèle de base) et le nouveau InferencePool (qui utilise le nouveau modèle de base). Le champ backendRefs weight contrôle le pourcentage de trafic alloué à chaque pool.
  3. Maintenir l'intégrité de InferenceObjective : conservez la configuration InferenceObjective inchangée. Cette approche permet de s'assurer que le système applique les mêmes adaptateurs LoRA de manière cohérente dans les deux versions du modèle de base.
  4. Conserver la fonctionnalité de rollback : conservez les nœuds et InferencePool d'origine pendant le déploiement pour faciliter un rollback si nécessaire.

Vous créez un InferencePool nommé llm-pool-version-2. Ce pool déploie une nouvelle version du modèle de base sur un nouvel ensemble de nœuds. En configurant un HTTPRoute, comme illustré dans l'exemple fourni, vous pouvez répartir progressivement le trafic entre le llm-pool d'origine et llm-pool-version-2. Cela vous permet de contrôler les mises à jour du modèle de base dans votre cluster.

Pour effectuer un déploiement de mise à jour de modèle de base, procédez comme suit :

  1. Enregistrez l'exemple de fichier manifeste suivant sous le nom 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: 10

  2. Appliquez l'exemple de fichier manifeste à votre cluster :

    kubectl apply -f routes-to-llm.yaml

Le InferencePool llm-pool d'origine reçoit la majeure partie du trafic, tandis que le InferencePool llm-pool-version-2 reçoit le reste. Augmentez progressivement la pondération du trafic pour le InferencePool llm-pool-version-2 afin de terminer le déploiement de la mise à jour du modèle de base.

Étape suivante