Effectuer des opérations de déploiement pour la passerelle d'inférence GKE

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 la passerelle d'inférence GKE. Cette passerelle vous permet d'effectuer des mises à jour sûres 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 perturbation 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 s'adresse aux administrateurs de comptes et d'identité GKE, ainsi qu'aux développeurs qui souhaitent effectuer des opérations de déploiement pour GKE Inference Gateway.

Les cas d'utilisation suivants sont acceptés :

Mettre à jour un déploiement de nœud

Les déploiements de mise à 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 déploiements de 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 de matériel mises à jour.

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

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

  4. Conserver les ressources d'origine : conservez les InferencePool et les nœuds d'origine actifs pendant le déploiement pour permettre les annulations 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 llm InferencePool existant. Déployez le pool sur un nouvel ensemble de nœuds de votre cluster. Utilisez un objet HTTPRoute pour répartir le trafic entre le llm d'origine et le nouveau InferencePool llm-new. Cette technique vous permet de mettre à jour de manière incrémentielle les nœuds de votre modèle.

Le schéma suivant illustre la façon dont GKE Inference Gateway effectue le déploiement de la mise à jour d'un nœud.

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

Pour déployer une 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
  rules:
    backendRefs:
    - name: llm
      kind: InferencePool
      weight: 90
    - name: llm-new
      kind: InferencePool
      weight: 10

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

    kubectl apply -f routes-to-llm.yaml

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

Déployer un modèle de base

Les mises à jour du 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 du 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 du 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 InferenceModel : conservez la configuration de InferenceModel telle quelle. Cela garantit que le système applique les mêmes adaptateurs LoRA de manière cohérente aux deux versions du modèle de base.
  4. Préserver la capacité de rollback : conservez les nœuds d'origine et InferencePool lors du déploiement pour faciliter un rollback si nécessaire.

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 déployer une mise à jour du 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
  rules:
    backendRefs:
    - name: llm-pool
      kind: InferencePool
      weight: 90
    - name: llm-pool-version-2
      kind: InferencePool
      weight: 10

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

    kubectl apply -f routes-to-llm.yaml

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

Déployer les mises à jour des adaptateurs LoRA

Les déploiements de mises à jour d'adaptateurs LoRA vous permettent de déployer de nouvelles versions de modèles affinés par phases, sans modifier le modèle de base ni l'infrastructure sous-jacents. Utilisez les déploiements de mise à jour des adaptateurs LoRA pour tester les améliorations, les corrections de bugs ou les nouvelles fonctionnalités dans vos adaptateurs LoRA.

Pour mettre à jour un adaptateur LoRA :

  1. Rendre les adaptateurs disponibles : assurez-vous que les nouvelles versions des adaptateurs LoRA sont disponibles sur les serveurs de modèles. Pour en savoir plus, consultez Déploiement de l'adaptateur.

  2. Modifiez la configuration InferenceModel : dans votre configuration InferenceModel existante, définissez plusieurs versions de votre adaptateur LoRA. Attribuez un modelName unique à chaque version (par exemple, llm-v1, llm-v2).

  3. Distribuer le trafic : utilisez le champ weight dans la spécification InferenceModel pour contrôler la distribution du trafic entre les différentes versions de l'adaptateur LoRA.

  4. Conservez un poolRef cohérent : assurez-vous que toutes les versions de l'adaptateur LoRA font référence au même InferencePool. Cela empêche le redéploiement des nœuds ou des InferencePool. Conservez les versions précédentes de l'adaptateur LoRA dans la configuration InferenceModel pour permettre les rétrocessions.

L'exemple suivant montre deux versions d'adaptateur LoRA, llm-v1 et llm-v2. Les deux versions utilisent le même modèle de base. Vous définissez llm-v1 et llm-v2 dans le même InferenceModel. Vous attribuez des pondérations pour transférer progressivement le trafic de llm-v1 vers llm-v2. Ce contrôle permet un déploiement contrôlé sans nécessiter de modifications de vos nœuds ni de la configuration InferencePool.

Pour déployer les mises à jour de l'adaptateur LoRA, exécutez la commande suivante :

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

    kubectl apply -f inferencemodel-sample.yaml

La version llm-v1 reçoit la majeure partie du trafic, tandis que la version llm-v2 reçoit le reste. Augmentez progressivement le poids du trafic pour la version llm-v2 afin de terminer le déploiement de la mise à jour de l'adaptateur LoRA.

Étapes suivantes