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 incrémental, 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é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 perturbation de service minimale. 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 d'identité et de comptes GKE, ainsi qu'aux développeurs qui souhaitent effectuer des opérations de déploiement pour le GKE Inference Gateway.

Les cas d'utilisation suivants sont acceptés:

Mettre à jour le déploiement d'un nœud

Le déploiement des mises à jour de nœuds permet de migrer de manière sécurisée les charges de travail d'inférence vers de nouvelles configurations de matériel 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 des déploiements de mises à jour de nœuds pour minimiser les perturbations 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 matérielles ou de nœud mises à jour.

  2. Répartir le trafic à l'aide d'un HTTPRoute: configurez un HTTPRoute pour distribuer 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. Maintenir une InferenceModel cohérente: conservez la configuration InferenceModel existante pour assurer 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 afin de pouvoir effectuer des 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 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 vos nœuds de modèle de manière incrémentielle.

Le schéma suivant montre comment GKE Inference Gateway déploie une mise à jour de nœud.

Processus de déploiement de la mise à jour des 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

Le InferencePool llm d'origine reçoit la majeure partie du trafic, tandis que le InferencePool llm-new reçoit le reste du trafic. Augmentez progressivement le poids du trafic pour le InferencePool llm-new 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 mises à jour de modèles de base pour passer à des architectures de modèles améliorées ou pour résoudre des problèmes spécifiques au modèle.

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

  1. Déployez 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 distribution du trafic: utilisez un HTTPRoute pour répartir le trafic entre l'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 votre configuration InferenceModel inchangée. Cela garantit que le système applique les mêmes adaptateurs LoRA de manière cohérente sur les deux versions du modèle de base.
  4. Conserver la possibilité de rollback: conservez les nœuds et les InferencePool d'origine lors du 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 le 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 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
  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

Le InferencePool llm-pool d'origine reçoit la majeure partie du trafic, tandis que le 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

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

Pour mettre à jour un adaptateur LoRA, procédez comme suit:

  1. Mettre les adaptateurs à disposition: assurez-vous que les nouvelles versions des adaptateurs LoRA sont disponibles sur les serveurs de modèles. Pour en savoir plus, consultez la section Déploiement des adaptateurs.

  2. Modifier 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. Répartir 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. Maintenez une poolRef cohérente: assurez-vous que toutes les versions de l'adaptateur LoRA référencent le même InferencePool. Cela évite le redéploiement de nœuds ou de InferencePool. Conservez les versions précédentes de l'adaptateur LoRA dans la configuration InferenceModel pour permettre les rollbacks.

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 poids 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 modification de vos nœuds ni de votre 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