Déployer la passerelle d'inférence GKE

Cette page explique comment déployer GKE Inference Gateway.

Cette page s'adresse aux spécialistes de la mise en réseau chargés de gérer l'infrastructure GKE et aux administrateurs de plate-forme qui gèrent les charges de travail d'IA.

Avant de lire cette page, assurez-vous de connaître les éléments suivants :

• À propos de GKE Inference Gateway
• Orchestration d'IA/ML sur GKE
• Glossaire de l'IA générative
• Équilibrage de charge dansTrusted Cloud, en particulier l'interaction des équilibreurs de charge avec GKE.
• Extensions de service GKE. Pour en savoir plus, consultez la documentation sur le contrôleur GKE Gateway.
• Personnalisez le trafic GKE Gateway à l'aide des extensions de service.

GKE Inference Gateway améliore GKE Gateway pour optimiser la diffusion d'applications et de charges de travail d'IA générative sur GKE. Il permet de gérer et de faire évoluer efficacement les charges de travail d'IA, d'atteindre des objectifs de performances spécifiques aux charges de travail (comme la latence), et d'améliorer l'utilisation des ressources, l'observabilité et la sécurité de l'IA.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

• Activez l'API Google Kubernetes Engine.
Activer l'API Google Kubernetes Engine
• Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez précédemment installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update.

• Activez l'API Compute Engine, l'API Network Services et l'API Model Armor si nécessaire.

  Accédez à Activer l'accès aux API et suivez les instructions.

• Assurez-vous de disposer des rôles suivants sur le projet : roles/container.admin, roles/iam.serviceAccountAdmin.

• Assurez-vous que votre projet dispose d'un quota suffisant pour les GPU H100. Pour en savoir plus, consultez Planifier le quota de GPU et Quotas d'allocation.

• Créez un compte Hugging Face si vous n'en possédez pas. Vous en aurez besoin pour accéder aux ressources du modèle pour ce tutoriel.

• Demandez l'accès au modèle Llama 3.1 et générez un jeton d'accès. L'accès à ce modèle nécessite une demande approuvée sur Hugging Face. Le déploiement échouera si l'accès n'a pas été accordé.

  • Signez le contrat de consentement de la licence : vous devez signer le contrat de consentement pour utiliser le modèle Llama 3.1. Accédez à la page du modèle sur Hugging Face, validez votre compte et acceptez les conditions d'utilisation.
  • Générez un jeton d'accès : pour accéder au modèle, vous avez besoin d'un jeton Hugging Face. Dans votre compte Hugging Face, accédez à Your Profile > Settings > Access Tokens (Votre profil > Paramètres > Jetons d'accès), créez un jeton avec au moins des autorisations de lecture, puis copiez-le dans le presse-papiers.

Conditions requises pour le contrôleur GKE Gateway

• GKE version 1.32.3 ou ultérieure.
• Google Cloud CLI version 407.0.0 ou ultérieure.
• L'API Gateway n'est compatible qu'avec les clusters de VPC natif.
• Vous devez activer un sous-réseau proxy réservé.
• Le module complémentaire HttpLoadBalancing doit être activé sur votre cluster.
• Si vous utilisez Istio, vous devez mettre à niveau Istio vers l'une des versions suivantes :
  • 1.15.2 ou ultérieure
  • 1.14.5 ou ultérieure
  • 1.13.9 ou ultérieure
• Si vous utilisez un VPC partagé, vous devez attribuer le rôle Compute Network User au compte de service GKE du projet de service dans le projet hôte.

Restrictions et limitations

Les restrictions et limites suivantes s'appliquent :

• Les passerelles multicluster ne sont pas prises en charge.
• GKE Inference Gateway n'est compatible qu'avec les ressources GatewayClass gke-l7-regional-external-managed et gke-l7-rilb.
• Les équilibreurs de charge d'application internes interrégionaux ne sont pas compatibles.

Matrice de compatibilité

Le tableau décrit la matrice de compatibilité et de prise en charge pour les définitions de ressources personnalisées (CRD) de l'extension d'inférence de l'API Gateway. Il détaille les versions de CRD compatibles avec GKE par rapport au projet d'extension d'inférence de l'API Gateway Open Source (OSS), y compris les exigences spécifiques en termes de version et les notes d'installation.

Configurer GKE Inference Gateway

Pour configurer la passerelle d'inférence GKE, examinez cet exemple. Une équipe exécute les modèles vLLM et Llama3 et expérimente activement deux adaptateurs LoRA affinés distincts : "food-review" et "cad-fabricator".

Voici le workflow général pour configurer GKE Inference Gateway :

1. Préparez votre environnement : configurez l'infrastructure et les composants nécessaires.
2. Créez un pool d'inférence : définissez un pool de serveurs de modèles à l'aide de la ressource personnalisée InferencePool.
3. Spécifier les objectifs d'inférence : spécifiez les objectifs d'inférence à l'aide de la ressource personnalisée InferenceObjective.
4. Créez la passerelle : exposez le service d'inférence à l'aide de l'API Gateway.
5. Créez l'HTTPRoute : définissez la façon dont le trafic HTTP est acheminé vers le service d'inférence.
6. Envoyer des requêtes d'inférence : envoyer des requêtes au modèle déployé.

Préparer votre environnement

1. Installez Helm.

2. Créez un cluster GKE :

   • Créez un cluster GKE Autopilot ou Standard avec la version 1.32.3 ou ultérieure. Pour obtenir des instructions, consultez Créer un cluster GKE.
   • Configurez les nœuds avec la famille de calcul et l'accélérateur de votre choix.
   • Utilisez le guide de démarrage rapide de GKE Inference pour obtenir des manifestes de déploiement préconfigurés et testés, en fonction de l'accélérateur, du modèle et des besoins en termes de performances que vous avez sélectionnés.

3. Installez les définitions de ressources personnalisées (CRD) nécessaires dans votre cluster GKE :

   • Pour les versions GKE antérieures à 1.34.0-gke.1626000, exécutez la commande suivante pour installer les CRD v1 InferencePool et alpha InferenceObjective :

   kubectl apply -f  https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v1.0.0/experimental-manifests.yaml
   

   • Pour les versions 1.34.0-gke.1626000 ou ultérieures de GKE, n'installez que la CRD alpha InferenceObjective en exécutant la commande suivante :

   kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/raw/v1.0.0/config/crd/bases/inference.networking.x-k8s.io_inferenceobjectives.yaml
   

4. Si vous utilisez une version de GKE antérieure à v1.32.2-gke.1182001 et que vous souhaitez utiliser Model Armor avec GKE Inference Gateway, vous devez installer les CRD d'extension de trafic et de routage :

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/refs/heads/main/config/crd/networking.gke.io_gcptrafficextensions.yaml
   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/refs/heads/main/config/crd/networking.gke.io_gcproutingextensions.yaml
   

5. Pour configurer l'autorisation d'extraire les métriques, créez le secret inference-gateway-sa-metrics-reader-secret :

   kubectl apply -f - <<EOF
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: inference-gateway-metrics-reader
   rules:
   - nonResourceURLs:
     - /metrics
     verbs:
     - get
   ---
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: inference-gateway-sa-metrics-reader
     namespace: default
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: inference-gateway-sa-metrics-reader-role-binding
     namespace: default
   subjects:
   - kind: ServiceAccount
     name: inference-gateway-sa-metrics-reader
     namespace: default
   roleRef:
     kind: ClusterRole
     name: inference-gateway-metrics-reader
     apiGroup: rbac.authorization.k8s.io
   ---
   apiVersion: v1
   kind: Secret
   metadata:
     name: inference-gateway-sa-metrics-reader-secret
     namespace: default
     annotations:
       kubernetes.io/service-account.name: inference-gateway-sa-metrics-reader
   type: kubernetes.io/service-account-token
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: inference-gateway-sa-metrics-reader-secret-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["inference-gateway-sa-metrics-reader-secret"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: gmp-system:collector:inference-gateway-sa-metrics-reader-secret-read
     namespace: default
   roleRef:
     name: inference-gateway-sa-metrics-reader-secret-read
     kind: ClusterRole
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gmp-system
     kind: ServiceAccount
   EOF
   

Créer un serveur de modèle et un déploiement de modèle

Cette section explique comment déployer un serveur et un modèle. L'exemple utilise un serveur de modèles vLLM avec un modèle Llama3. Le déploiement est marqué comme app:vllm-llama3-8b-instruct. Ce déploiement utilise également deux adaptateurs LoRA nommés food-review et cad-fabricator de Hugging Face.

Vous pouvez adapter cet exemple avec votre propre conteneur de serveur de modèle et votre propre modèle, port de diffusion et nom de déploiement. Vous pouvez également configurer des adaptateurs LoRA dans le déploiement ou déployer le modèle de base. Les étapes suivantes décrivent comment créer les ressources Kubernetes nécessaires.

1. Créez un secret Kubernetes pour stocker votre jeton Hugging Face. Ce jeton permet d'accéder au modèle de base et aux adaptateurs LoRA :

   kubectl create secret generic hf-token --from-literal=token=HF_TOKEN
   

   Remplacez HF_TOKEN par votre jeton Hugging Face.

2. Déployez le serveur et le modèle. La commande suivante applique un fichier manifeste qui définit un déploiement Kubernetes pour un serveur de modèle vLLM avec un modèle Llama3 :

   kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api-inference-extension/release-1.0/config/manifests/vllm/gpu-deployment.yaml
   

Créer un pool d'inférence

La ressource personnalisée Kubernetes InferencePool définit un groupe de pods avec un grand modèle de langage (LLM) de base et une configuration de calcul communs. Le champ selector spécifie les pods qui appartiennent à ce pool. Les libellés de ce sélecteur doivent correspondre exactement à ceux appliqués aux pods de votre serveur de modèle. Le champ targetPort définit les ports que le serveur de modèle utilise dans les pods. Le champ extensionRef fait référence à un service d'extension qui fournit des fonctionnalités supplémentaires au pool d'inférence. InferencePool permet à GKE Inference Gateway de router le trafic vers les pods de votre serveur de modèle.

Avant de créer le InferencePool, assurez-vous que les pods sélectionnés par le InferencePool sont déjà en cours d'exécution.

Pour créer un InferencePool à l'aide de Helm, procédez comme suit :

helm install vllm-llama3-8b-instruct \
  --set inferencePool.modelServers.matchLabels.app=vllm-llama3-8b-instruct \
  --set provider.name=gke \
  --version v1.0.0 \
  oci://registry.k8s.io/gateway-api-inference-extension/charts/inferencepool

Modifiez le champ suivant pour qu'il corresponde à votre déploiement :

• inferencePool.modelServers.matchLabels.app : clé du libellé utilisé pour sélectionner les pods de votre serveur de modèle.

L'installation de Helm installe automatiquement la règle de délai avant expiration, le sélecteur de points de terminaison et les pods nécessaires à l'observabilité.

Cela crée un objet InferencePool : vllm-llama3-8b-instruct référençant les services de point de terminaison du modèle dans les pods. Il crée également un déploiement du sélecteur de points de terminaison nommé app:vllm-llama3-8b-instruct-epp pour ce InferencePool créé.

Spécifier les objectifs d'inférence

La ressource personnalisée InferenceObjective vous permet de spécifier la priorité des requêtes.

Le champ metadata.name de la ressource InferenceObjective spécifie le nom de l'objectif d'inférence, le champ Priority spécifie sa criticité de diffusion et le champ poolRef spécifie le InferencePool sur lequel le modèle est diffusé.

```yaml
apiVersion: inference.networking.k8s.io/v1alpha2
kind: InferenceObjective
metadata:
  name: NAME
spec:
  priority: VALUE
  poolRef:
    name: INFERENCE_POOL_NAME
    group: "inference.networking.k8s.io"
```

Remplacez les éléments suivants :

• NAME : nom de votre objectif d'inférence. Exemple :food-review
• VALUE : priorité de l'objectif d'inférence. Il s'agit d'un nombre entier. Plus la valeur est élevée, plus la demande est critique. Par exemple, 10.
• INFERENCE_POOL_NAME : nom de l'InferencePool que vous avez créé à l'étape précédente. Exemple : vllm-llama3-8b-instruct.

Pour créer un InferenceObjective, procédez comme suit :

1. Enregistrez le fichier manifeste suivant sous le nom inference-objectives.yaml. Ce fichier manifeste crée deux ressources InferenceObjective. La première configure l'objectif d'inférence food-review sur le InferencePool vllm-llama3-8b-instruct avec une priorité de 10. La seconde configure l'objectif d'inférence llama3-base-model pour qu'il soit diffusé avec une priorité plus élevée de 20.

   apiVersion: inference.networking.x-k8s.io/v1alpha2
   kind: InferenceObjective
   metadata:
     name: food-review
   spec:
     priority: 10
     poolRef:
       name: vllm-llama3-8b-instruct
       group: "inference.networking.k8s.io"
   ---
   apiVersion: inference.networking.x-k8s.io/v1alpha2
   kind: InferenceObjective
   metadata:
     name: llama3-base-model
   spec:
     priority: 20 # Higher priority
     poolRef:
       name: vllm-llama3-8b-instruct
   

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

   kubectl apply -f inferenceobjective.yaml
   

Créer la passerelle

La ressource Gateway est le point d'entrée du trafic externe dans votre cluster Kubernetes. Il définit les écouteurs qui acceptent les connexions entrantes.

La passerelle d'inférence GKE fonctionne avec les classes Gateway suivantes :

• gke-l7-rilb : pour les équilibreurs de charge d'application internes régionaux.
• gke-l7-regional-external-managed : pour les équilibreurs de charge d'application externes régionaux.

Pour en savoir plus, consultez la documentation sur les classes Gateway.

Pour créer une passerelle, procédez comme suit :

1. Enregistrez l'exemple de fichier manifeste suivant sous le nom gateway.yaml :

   apiVersion: gateway.networking.k8s.io/v1
   kind: Gateway
   metadata:
     name: GATEWAY_NAME
   spec:
     gatewayClassName: GATEWAY_CLASS
     listeners:
       - protocol: HTTP
         port: 80
         name: http
   

   Remplacez les éléments suivants :

   • GATEWAY_NAME : nom unique de votre ressource Gateway. Exemple :inference-gateway
   • GATEWAY_CLASS : classe Gateway que vous souhaitez utiliser. Exemple :gke-l7-regional-external-managed

2. Appliquez le fichier manifeste à votre cluster :

   kubectl apply -f gateway.yaml
   

Remarque : Pour en savoir plus sur la configuration de TLS afin de sécuriser votre passerelle avec HTTPS, consultez la documentation GKE sur la configuration de TLS.

Créer le HTTPRoute

La ressource HTTPRoute définit la manière dont GKE Gateway achemine les requêtes HTTP entrantes vers les services de backend, tels que votre InferencePool. La ressource HTTPRoute spécifie les règles de correspondance (par exemple, les en-têtes ou les chemins d'accès) et le backend vers lequel le trafic doit être transféré.

1. Pour créer un HTTPRoute, enregistrez l'exemple de fichier manifeste suivant sous le nom httproute.yaml :

   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: HTTPROUTE_NAME
   spec:
     parentRefs:
     - name: GATEWAY_NAME
     rules:
     - matches:
       - path:
           type: PathPrefix
           value: PATH_PREFIX
       backendRefs:
       - name: INFERENCE_POOL_NAME
         group: "inference.networking.k8s.io"
         kind: InferencePool
   

   Remplacez les éléments suivants :

   • HTTPROUTE_NAME : nom unique de votre ressource HTTPRoute. Par exemple, my-route.
   • GATEWAY_NAME : nom de la ressource Gateway que vous avez créée. Par exemple, inference-gateway.
   • PATH_PREFIX : préfixe de chemin d'accès que vous utilisez pour faire correspondre les requêtes entrantes. Par exemple, / pour tout faire correspondre.
   • INFERENCE_POOL_NAME : nom de la ressource InferencePool vers laquelle vous souhaitez acheminer le trafic. Par exemple, vllm-llama3-8b-instruct.

2. Appliquez le fichier manifeste à votre cluster :

   kubectl apply -f httproute.yaml
   

Envoyer une requête d'inférence

Une fois la passerelle d'inférence GKE configurée, vous pouvez envoyer des requêtes d'inférence à votre modèle déployé. Cela vous permet de générer du texte en fonction de votre requête et des paramètres spécifiés.

Pour envoyer des requêtes d'inférence, procédez comme suit :

1. Définissez les variables d'environnement suivantes :

   export GATEWAY_NAME=GATEWAY_NAME
   export PORT_NUMBER=PORT_NUMBER # Use 80 for HTTP
   

   Remplacez les éléments suivants :

   • GATEWAY_NAME : nom de votre ressource Gateway.
   • PORT_NUMBER : numéro de port que vous avez configuré dans la passerelle.

2. Pour obtenir le point de terminaison de la passerelle, exécutez la commande suivante :

   echo "Waiting for the Gateway IP address..."
   IP=""
   while [ -z "$IP" ]; do
     IP=$(kubectl get gateway/${GATEWAY_NAME} -o jsonpath='{.status.addresses[0].value}' 2>/dev/null)
     if [ -z "$IP" ]; then
       echo "Gateway IP not found, waiting 5 seconds..."
       sleep 5
     fi
   done
   
   echo "Gateway IP address is: $IP"
   PORT=${PORT_NUMBER}
   

3. Pour envoyer une requête au point de terminaison /v1/completions à l'aide de curl, exécutez la commande suivante :

   curl -i -X POST ${IP}:${PORT}/v1/completions \
   -H 'Content-Type: application/json' \
   -H 'Authorization: Bearer $(gcloud auth application-default print-access-token)' \
   -d '{
       "model": "MODEL_NAME",
       "prompt": "PROMPT_TEXT",
       "max_tokens": MAX_TOKENS,
       "temperature": "TEMPERATURE"
   }'
   

   Remplacez les éléments suivants :

   • MODEL_NAME : nom du modèle ou de l'adaptateur LoRA à utiliser.
   • PROMPT_TEXT : requête d'entrée pour le modèle.
   • MAX_TOKENS : nombre maximal de jetons à générer dans la réponse.
   • TEMPERATURE : contrôle le caractère aléatoire de la sortie. Utilisez la valeur 0 pour une sortie déterministe ou un nombre plus élevé pour une sortie plus créative.

L'exemple suivant montre comment envoyer un exemple de requête à la passerelle GKE Inference :

curl -i -X POST ${IP}:${PORT}/v1/completions -H 'Content-Type: application/json' -H 'Authorization: Bearer $(gcloud auth print-access-token)' -d '{
    "model": "food-review-1",
    "prompt": "What is the best pizza in the world?",
    "max_tokens": 2048,
    "temperature": "0"
}'

Tenez compte des comportements suivants :

• Corps de la requête : le corps de la requête peut inclure des paramètres supplémentaires tels que stop et top_p. Pour obtenir la liste complète des options, consultez les spécifications de l'API OpenAI.
• Gestion des erreurs : implémentez une gestion des erreurs appropriée dans votre code client pour gérer les erreurs potentielles dans la réponse. Par exemple, vérifiez le code d'état HTTP dans la réponse curl. Un code d'état autre que 200 indique généralement une erreur.
• Authentification et autorisation : pour les déploiements en production, sécurisez votre point de terminaison d'API avec des mécanismes d'authentification et d'autorisation. Incluez les en-têtes appropriés (par exemple, Authorization) dans vos requêtes.

Étapes suivantes

• Personnaliser la configuration de GKE Inference Gateway
• Configurer le routage basé sur le corps
• Diffuser un LLM avec GKE Inference Gateway