Diffuser un LLM avec GKE Inference Gateway

Ce tutoriel explique comment déployer un grand modèle de langage (LLM) sur Google Kubernetes Engine (GKE) avec la passerelle d'inférence GKE. Le tutoriel inclut des étapes pour la configuration du cluster, le déploiement du modèle, la configuration de GKE Inference Gateway et le traitement des requêtes LLM.

Ce tutoriel s'adresse aux ingénieurs en machine learning (ML), aux administrateurs et opérateurs de plate-forme, ainsi qu'aux spécialistes des données et de l'IA qui souhaitent déployer et gérer des applications LLM sur GKE avec GKE Inference Gateway.

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

GKE Inference Gateway améliore Google Kubernetes Engine (GKE) Gateway pour optimiser la mise en service des applications et 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
  • Pour utiliser Google Cloud CLI pour cette tâche, installez puis initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.

  • Activez l'API Compute Engine, l'API Kubernetes 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 et 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.
    • 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 à Votre profil > Param��tres > Jetons d'accès, créez un jeton avec au moins l'autorisation de lecture, puis copiez-le dans le presse-papiers.

  • Configurez un sous-réseau proxy uniquement pour votre réseau VPC. Le contrôleur Gateway nécessite un sous-réseau proxy réservé actif dans la région pour provisionner l'équilibreur de charge d'application.

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.
  • 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 version 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 :

  • 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 acceptés.
  • Un InferencePool peut comporter jusqu'à huit targetPorts.

Configurer GKE Inference Gateway

Pour configurer GKE Inference Gateway, 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éer la passerelle : exposez le service d'inférence à l'aide de l'API Gateway.
  5. Créez le 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é.

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.

GKE Inference Gateway 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 TLS.

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 une configuration de référence de déploiement en un clic, consultez l'exemple cluster-toolkit gke-a3-highgpu.
    • Configurez les nœuds avec la famille de calcul et l'accélérateur de votre choix.
    • Utilisez GKE Inference Quickstart 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 de GKE 1.34.0-gke.1626000 ou ultérieures, la CRD InferencePool est incluse par défaut. Par conséquent, installez uniquement le CRD alpha InferenceObjective :

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

    • Pour les versions de GKE antérieures à 1.34.0-gke.1626000, installez les CRD v1 InferencePool et alpha InferenceObjective :

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

      Pour en savoir plus, consultez la matrice de compatibilité.

  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. Définissez les variables d'environnement suivantes :

    export GAIE_VERSION=v1.5.0
export GUIDE_NAME="optimized-baseline"
export NAMESPACE=llm-d-optimized-baseline
export INFRA_PROVIDER=gke   # gke | base

  6. Installez les définitions de ressources personnalisées (CRD) de l'extension d'inférence de l'API Gateway requises par le sélecteur de points de terminaison (EPP) llm-d :

    kubectl apply -k \
  "https://github.com/kubernetes-sigs/gateway-api-inference-extension/config/crd?ref=${GAIE_VERSION}"

  7. Créez l'espace de noms cible :

    kubectl create namespace ${NAMESPACE}

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

Cette section explique comment déployer un serveur de modèles 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 expliquent comment créer les ressources Kubernetes nécessaires.

  1. Créez un secret Kubernetes pour stocker votre jeton Hugging Face. Ce jeton est utilisé pour 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 de modèle vLLM à l'aide du calque Kustomize spécifique à GKE à partir du guide de référence optimisé llm-d. Le paramètre INFRA_PROVIDER=gke applique des configurations spécifiques à GKE, y compris l'intégration de Cloud Monitoring :

    kubectl apply -n ${NAMESPACE} \
  -k guides/${GUIDE_NAME}/modelserver/gpu/vllm/${INFRA_PROVIDER}/

Remarque : GKE fournit une surveillance automatique des applications par défaut. La pile de surveillance llm-d n'est pas requise pour GKE, mais elle est disponible si vous préférez l'utiliser.

Si votre serveur de modèle nécessite plusieurs ports, assurez-vous que la spécification du conteneur expose chacun d'eux. L'exemple suivant définit un déploiement dans lequel le conteneur expose trois ports :

Exemple de déploiement multiport

apiVersion: apps/v1
kind: Deployment
metadata:
  name: multiport-model-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: multiport-model-server
  template:
    metadata:
      labels:
        app: multiport-model-server
    spec:
      containers:
      - name: model-server
        image: your-model-server-image
        ports:
        - containerPort: 8080
        - containerPort: 8081
        - containerPort: 9000

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 à vos pods de serveur de modèle. Le champ targetPorts définit les ports que le serveur de modèle utilise dans les pods. Vous pouvez spécifier jusqu'à huit ports. 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.

Le fichier manifeste InferencePool suivant spécifie plusieurs targetPorts qui correspondent aux ports exposés par le déploiement du serveur de modèle :

Exemple Multiport InferencePool

apiVersion: inference.networking.k8s.io/v1
kind: InferencePool
metadata:
  name: my-multiport-pool
  namespace: default
spec:
  selector:
    matchLabels:
      app: multiport-model-server
  targetPorts:
    - number: 8080
    - number: 8081
    - number: 9000

Avant de créer l'InferencePool, assurez-vous que les pods du serveur de modèle que l'InferencePool sélectionne sont déjà en cours d'exécution.

Clonez les recettes et les recommandations pour InferencePool à partir du dépôt GitHub llm-d. Cette étape est obligatoire :

git clone https://github.com/llm-d/llm-d -b v0.7.0 && cd llm-d

Pour créer un InferencePool et un sélecteur de points de terminaison à l'aide de Helm, procédez comme suit :

helm install ${GUIDE_NAME} \
  -f guides/recipes/scheduler/base.values.yaml \
  -f guides/${GUIDE_NAME}/scheduler/${GUIDE_NAME}.values.yaml \
  --set provider.name=gke \
  --set inferenceExtension.monitoring.gke.enabled=true \
  -n ${NAMESPACE} \
  --version ${GAIE_VERSION} \
  oci://LLM_D_REGISTRY_PATH

Remplacez les éléments suivants :

  • GAIE_VERSION : version du chart Helm. Exemple : v1.5.0.
  • LLM_D_REGISTRY_PATH : chemin d'accès au registre OCI pour le chart Helm. Exemple :registry.k8s.io/gateway-api-inference-extension/charts/inferencepool

Dans le fichier guides/recipes/scheduler/base.values.yaml, modifiez le champ suivant pour qu'il corresponde au libellé de votre pod de déploiement de modèle :

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

    Remarque : La clé et la valeur correspondent à l'exemple du guide optimized-baseline. Nous allons donc les remplacer pour qu'elles correspondent aux libellés de votre pod de déploiement.

Pour la surveillance, le scraping des métriques pour Google Cloud Managed Service pour Prometheus est activé par défaut.

  • Pour désactiver cette fonctionnalité, ajoutez l'option --set inferenceExtension.monitoring.prometheus.enabled=false à la commande.
  • Si vous utilisez la surveillance par défaut sur un cluster GKE Autopilot, vous devez également ajouter l'indicateur --set provider.gke.autopilot=true.

L'installation 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 pool d'inférence créé.

Déployer le sélecteur de point de terminaison avec haute disponibilité

Le déploiement du sélecteur de points de terminaison (EPP) avec des backends préférés permet une topologie de routage actif-passif soutenue par Cloud Load Balancing.

L'utilisation du sélecteur de points de terminaison avec les backends préférés vous permet d'effectuer les opérations suivantes :

  • Cohérence de l'état : Cloud Load Balancing redirige 100% du trafic ext_proc en état stable vers le réplica principal du sélecteur de points de terminaison (epp-0), ce qui préserve l'état du cache de paires clé-valeur (KV) et le contexte de planification des requêtes.
  • Basculement sans temps d'arrêt : si le pod Endpoint Picker principal plante ou fait l'objet d'une maintenance, Cloud Load Balancing détecte l'échec à l'aide de vérifications d'état gRPC actives et achemine immédiatement le trafic vers le réplica de secours (epp-1).
  • Résilience en cas d'échec de l'ouverture : lorsqu'il est associé à failureMode: FailOpen, les échecs de routage temporaires contournent le sélecteur de points de terminaison et permettent aux requêtes d'être transférées directement aux serveurs de modèles sans que les requêtes des utilisateurs soient abandonnées.

Lorsque vous activez les backends préférés, GKE modifie l'architecture et le routage de la manière suivante :

  • Architecture StatefulSet du sélecteur de point de terminaison : le sélecteur de point de terminaison est déployé en tant que StatefulSet au lieu d'un déploiement. Les ordinaux de pod désignent les rôles des instances répliquées : l'ordinal epp-0 sert d'instance répliquée principale épinglée au niveau de backend PREFERRED, et l'ordinal epp-1 sert d'instance répliquée de secours épinglée au niveau DEFAULT.
  • L'état du routage reste centralisé : le trafic ext_proc en état stable est routé exclusivement vers le réplica principal du sélecteur de points de terminaison (epp-0) pour que le suivi du cache de paires clé-valeur (KV) et l'état de planification des requêtes restent centralisés. Si epp-0 devient non opérationnel, Cloud Load Balancing transfère le trafic vers le réplica de secours (epp-1).
  • Architecture à double service : le graphique Helm crée un service principal (Service/${GUIDE_NAME}-epp) et un service de sauvegarde de secours (Service/${GUIDE_NAME}-epp-backup). La ressource InferencePool cible de manière déclarative le service de sauvegarde de secours. L'ancrage de la propriété déclarative de la passerelle au service de secours garantit que les boucles de réconciliation du contrôleur GKE Gateway ne détachent pas les groupes de points de terminaison réseau (NEG) principaux que vous associez au service de backend.

Pour créer un InferencePool et un sélecteur de points de terminaison à haute disponibilité à l'aide de Helm, procédez comme suit :

  1. Déployez InferencePool et Endpoint Picker avec les backends de votre choix à l'aide de Helm :

    helm install ${GUIDE_NAME} \
  -f guides/recipes/scheduler/base.values.yaml \
  -f guides/${GUIDE_NAME}/scheduler/${GUIDE_NAME}.values.yaml \
  --set provider.name=gke \
  --set inferenceExtension.monitoring.gke.enabled=true \
  --set provider.gke.preferredBackends.enabled=true \
  --set provider.gke.preferredBackends.preferredReplicas=1 \
  --set provider.gke.preferredBackends.defaultReplicas=1 \
  -n ${NAMESPACE} \
  --version ${GAIE_VERSION} \
  oci://LLM_D_REGISTRY_PATH

    Remplacez les éléments suivants :

    • GAIE_VERSION : version de l'extension d'inférence de l'API Gateway (GAIE) du graphique Helm. Exemple : v1.5.0. Les backends préférés nécessitent la version v1.5.0 ou ultérieure du graphique Helm.
    • LLM_D_REGISTRY_PATH : chemin d'accès au registre OCI pour le chart Helm. Exemple : registry.k8s.io/gateway-api-inference-extension/charts/inferencepool.

    Pour obtenir la liste complète des paramètres, consultez values.yaml.

  2. Associez le NEG principal à BackendService :

    export PROJECT_ID=PROJECT_ID
export REGION=REGION

export BACKEND_SERVICE=$(gcloud compute backend-services list --project=${PROJECT_ID} --format="value(name)" | grep "${GUIDE_NAME}-epp")

export PRIMARY_NEG=$(kubectl get svc ${GUIDE_NAME}-epp -n ${NAMESPACE} -o jsonpath='{.metadata.annotations.cloud\.google\.com/neg-status}' | jq -r '.network_endpoint_groups["9002"]')

for ZONE in $(kubectl get svc ${GUIDE_NAME}-epp -n ${NAMESPACE} -o jsonpath='{.metadata.annotations.cloud\.google\.com/neg-status}' | jq -r '.zones[]'); do
  gcloud compute backend-services add-backend ${BACKEND_SERVICE} \
    --network-endpoint-group=${PRIMARY_NEG} \
    --network-endpoint-group-zone=${ZONE} \
    --region=${REGION} \
    --project=${PROJECT_ID} \
    --balancing-mode=RATE \
    --max-rate-per-endpoint=100 \
    --preference=PREFERRED
  sleep 15
done

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de votre projet Google Cloud .
    • REGION : Google Cloud région de votre cluster et de votre service de backend.

Une fois les NEG zonaux associés à Google Cloud BackendService, la mise à l'échelle du nombre de répliques (preferredReplicas ou defaultReplicas) ou le redémarrage des pods ne nécessitent pas d'exécuter à nouveau les commandes gcloud. Le contrôleur NEG GKE synchronise automatiquement les adresses IP des pods individuels dans les NEG zonaux enregistrés.

Si vous supprimez et recréez la ressource parente Gateway ou InferencePool, le contrôleur GKE Gateway recrée le BackendService Google Cloudsous-jacent avec un nouvel identifiant cloud. Dans ce cas, exécutez le workflow de rattachement précédent pour associer les NEG zonaux principaux au BackendService nouvellement créé.

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. Exemple :vllm-llama3-8b-instruct

  2. Appliquez le fichier manifeste à votre cluster :

    kubectl apply -f httproute.yaml

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 l'InferencePool sur lequel le modèle est diffusé.

apiVersion: inference.networking.x-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 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 inference-objectives.yaml

Vérifier le déploiement

Pour vérifier que tous les composants sont en cours d'exécution, exécutez les commandes suivantes :

kubectl get inferencepool
kubectl get inferenceobjective
kubectl get pods -l app=vllm-llama3-8b-instruct-epp

Envoyer une requête d'inférence

Une fois GKE Inference Gateway configuré, 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 : prompt 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 à GKE Inference Gateway :

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": "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 la spécification de l'API OpenAI.
  • Gestion des erreurs : implémentez gestion des exceptions 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