GKE Inference Gateway bereitstellen

Auf dieser Seite wird beschrieben, wie Sie GKE Inference Gateway bereitstellen.

Diese Seite richtet sich an Netzwerkexperten, die für die Verwaltung der GKE-Infrastruktur verantwortlich sind, und an Plattformadministratoren, die KI-Arbeitslasten verwalten.

Machen Sie sich vor dem Lesen dieser Seite mit den folgenden Themen vertraut:

• GKE Inference Gateway
• KI‑/ML-Orchestrierung in GKE.
• Glossar zu generativer KI
• Load-Balancing inTrusted Cloud, insbesondere die Interaktion von Load-Balancern mit GKE.
• GKE Service Extensions. Weitere Informationen finden Sie in der Dokumentation zum GKE Gateway-Controller.
• GKE Gateway-Traffic mit Service Extensions anpassen

GKE Inference Gateway erweitert GKE Gateway, um die Bereitstellung von generativen KI-Anwendungen und ‑Arbeitslasten in GKE zu optimieren. Sie ermöglicht eine effiziente Verwaltung und Skalierung von KI-Arbeitslasten, ermöglicht arbeitslastspezifische Leistungsziele wie Latenz und verbessert die Ressourcennutzung, Beobachtbarkeit und KI-Sicherheit.

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

• Aktivieren Sie die Google Kubernetes Engine API.
Google Kubernetes Engine API aktivieren
• Wenn Sie die Google Cloud CLI für diesen Task verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.

• Aktivieren Sie bei Bedarf die Compute Engine API, die Network Services API und die Model Armor API.

  Rufen Sie Zugriff auf APIs aktivieren auf und folgen Sie der Anleitung.

• Sie benötigen die folgenden Rollen für das Projekt: roles/container.admin, roles/iam.serviceAccountAdmin.

• Prüfen Sie, ob Ihr Projekt ein ausreichendes Kontingent für H100-GPUs hat. Weitere Informationen finden Sie unter GPU-Kontingent planen und Zuteilungskontingente.

• Erstellen Sie ein Hugging Face-Konto, falls Sie noch keines haben. Sie benötigen sie, um auf die Modellressourcen für diese Anleitung zuzugreifen.

• Fordern Sie Zugriff auf das Llama 3.1-Modell an und generieren Sie ein Zugriffstoken. Für den Zugriff auf dieses Modell ist eine genehmigte Anfrage bei Hugging Face erforderlich. Die Bereitstellung schlägt fehl, wenn der Zugriff nicht gewährt wurde.

  • Lizenz-Einwilligungsvereinbarung unterzeichnen:Sie müssen die Einwilligungsvereinbarung unterzeichnen, um das Modell Llama 3.1 verwenden zu können. Rufen Sie die Seite des Modells auf Hugging Face auf, bestätigen Sie Ihr Konto und akzeptieren Sie die Nutzungsbedingungen.
  • Zugriffstoken generieren:Für den Zugriff auf das Modell benötigen Sie ein Hugging Face-Token. Rufen Sie in Ihrem Hugging Face-Konto Your Profile > Settings > Access Tokens auf, erstellen Sie ein neues Token mit mindestens Leseberechtigungen und kopieren Sie es in die Zwischenablage.

Anforderungen für GKE Gateway Controller

• GKE-Version 1.32.3 oder höher.
• Google Cloud CLI-Version 407.0.0 oder höher.
• Die Gateway API wird nur in VPC-nativen Clustern unterstützt.
• Sie müssen ein Nur-Proxy-Subnetz aktivieren.
• Für den Cluster muss das Add-on HttpLoadBalancing aktiviert sein.
• Wenn Sie Istio verwenden, müssen Sie Istio auf eine der folgenden Versionen aktualisieren:
  • 1.15.2 oder höher
  • 1.14.5 oder höher
  • 1.13.9 oder höher
• Wenn Sie eine freigegebene VPC verwenden, müssen Sie dem GKE-Dienstkonto für das Dienstprojekt im Hostprojekt die Rolle Compute Network User zuweisen.

Limits und Einschränkungen

Es gelten die folgenden Einschränkungen:

• Multi-Cluster-Gateways werden nicht unterstützt.
• GKE Inference Gateway wird nur für die GatewayClass-Ressourcen gke-l7-regional-external-managed und gke-l7-rilb unterstützt.
• Regionsübergreifende interne Application Load Balancer werden nicht unterstützt.

Kompatibilitätsmatrix

In der Tabelle sind die Kompatibilitäts- und Unterstützungsmatrix für die benutzerdefinierten Ressourcendefinitionen (CRDs) der Gateway API Inference Extension aufgeführt. Darin wird beschrieben, welche CRD-Versionen von GKE im Vergleich zum Open-Source-Projekt (OSS) „Gateway API Inference Extension“ unterstützt werden, einschließlich spezifischer Versionsanforderungen und Installationshinweise.

GKE Inference Gateway konfigurieren

Sehen Sie sich dieses Beispiel an, um das GKE Inference Gateway zu konfigurieren. Ein Team führt vLLM- und Llama3-Modelle aus und führt aktiv Tests mit zwei verschiedenen LoRA-feinabgestimmten Adaptern durch: „food-review“ und „cad-fabricator“.

Der allgemeine Workflow zum Konfigurieren von GKE Inference Gateway ist wie folgt:

1. Umgebung vorbereiten: Richten Sie die erforderliche Infrastruktur und die erforderlichen Komponenten ein.
2. Inferenzpool erstellen: Definieren Sie einen Pool von Modellservern mit der benutzerdefinierten InferencePool-Ressource.
3. Inferenzziele angeben: Inferenzziele mit der benutzerdefinierten Ressource InferenceObjective angeben
4. Gateway erstellen: Stellen Sie den Inferenzdienst über die Gateway API bereit.
5. HTTPRoute erstellen: Definieren Sie, wie HTTP-Traffic an den Inferenzdienst weitergeleitet wird.
6. Inferenzanfragen senden: Anfragen an das bereitgestellte Modell senden.

Umgebung vorbereiten

1. Installieren Sie Helm.

2. Erstellen Sie einen GKE-Cluster.

   • Erstellen Sie einen GKE Autopilot- oder Standardcluster mit Version 1.32.3 oder höher. Eine Anleitung finden Sie unter GKE-Cluster erstellen.
   • Konfigurieren Sie die Knoten mit der gewünschten Compute-Familie und dem gewünschten Beschleuniger.
   • Verwenden Sie die GKE Inference-Kurzanleitung für vorkonfigurierte und getestete Bereitstellungsmanifeste, die auf Ihrem ausgewählten Beschleuniger, Modell und Ihren Leistungsanforderungen basieren.

3. Installieren Sie die erforderlichen benutzerdefinierten Ressourcendefinitionen (CRDs) in Ihrem GKE-Cluster:

   • Führen Sie für GKE-Versionen vor 1.34.0-gke.1626000 den folgenden Befehl aus, um sowohl die v1-InferencePool- als auch die Alpha-InferenceObjective-CRDs zu installieren:

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

   • Bei GKE-Versionen 1.34.0-gke.1626000 oder höher installieren Sie nur die Alpha-InferenceObjective-CRD, indem Sie den folgenden Befehl ausführen:

   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. Wenn Sie eine GKE-Version vor v1.32.2-gke.1182001 verwenden und Model Armor mit GKE Inference Gateway nutzen möchten, müssen Sie die CRDs für Traffic und Routing installieren:

   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. Um die Autorisierung zum Extrahieren von Messwerten einzurichten, erstellen Sie das 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
   

Modellserver und Modellbereitstellung erstellen

In diesem Abschnitt wird beschrieben, wie Sie einen Modellserver und ein Modell bereitstellen. Im Beispiel wird ein vLLM-Modellserver mit einem Llama3-Modell verwendet. Das Deployment ist als app:vllm-llama3-8b-instruct gekennzeichnet. Bei diesem Deployment werden auch zwei LoRA-Adapter mit den Namen food-review und cad-fabricator von Hugging Face verwendet.

Sie können dieses Beispiel an Ihren eigenen Modellserver-Container und Ihr eigenes Modell, den Bereitstellungsport und den Bereitstellungsnamen anpassen. Sie können auch LoRA-Adapter in der Bereitstellung konfigurieren oder das Basismodell bereitstellen. In den folgenden Schritten wird beschrieben, wie Sie die erforderlichen Kubernetes-Ressourcen erstellen.

1. Erstellen Sie ein Kubernetes-Secret zum Speichern Ihres Hugging Face-Tokens. Mit diesem Token wird auf das Basismodell und die LoRA-Adapter zugegriffen:

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

   Ersetzen Sie HF_TOKEN durch Ihr Hugging Face-Token.

2. Stellen Sie den Modellserver und das Modell bereit. Mit dem folgenden Befehl wird ein Manifest angewendet, das ein Kubernetes-Deployment für einen vLLM-Modellserver mit einem Llama3-Modell definiert:

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

Inferenzpool erstellen

Die benutzerdefinierte Kubernetes-Ressource InferencePool definiert eine Gruppe von Pods mit einem gemeinsamen Large Language Model (LLM) und einer gemeinsamen Rechenkonfiguration. Das Feld selector gibt an, welche Pods zu diesem Pool gehören. Die Labels in dieser Auswahl müssen genau mit den Labels übereinstimmen, die auf die Pods Ihres Modellservers angewendet werden. Das Feld targetPort definiert die Ports, die der Modellserver in den Pods verwendet. Das Feld extensionRef verweist auf einen Erweiterungsdienst, der zusätzliche Funktionen für den Inferenzpool bietet. Das InferencePool ermöglicht dem GKE Inference Gateway, Traffic an Ihre Modellserver-Pods weiterzuleiten.

Bevor Sie die InferencePool erstellen, müssen die Pods, die von der InferencePool ausgewählt werden, bereits ausgeführt werden.

So erstellen Sie ein InferencePool mit Helm:

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

Ändern Sie das folgende Feld entsprechend Ihrem Deployment:

• inferencePool.modelServers.matchLabels.app: Der Schlüssel des Labels, das zum Auswählen der Pods Ihres Modellservers verwendet wird.

Bei der Helm-Installation werden automatisch die erforderliche Zeitüberschreitungsrichtlinie, die Endpunktauswahl und die für die Observability erforderlichen Pods installiert.

Dadurch wird ein InferencePool-Objekt vllm-llama3-8b-instruct erstellt, das auf die Modellendpunktdienste in den Pods verweist. Außerdem wird eine Bereitstellung der Endpunktauswahl mit dem Namen app:vllm-llama3-8b-instruct-epp für diese erstellte InferencePool erstellt.

Inferenzziele angeben

Mit der benutzerdefinierten Ressource InferenceObjective können Sie die Priorität von Anfragen angeben.

Das Feld metadata.name der InferenceObjective-Ressource gibt den Namen des Inference Objective an, das Feld Priority die Serving-Wichtigkeit und das Feld poolRef die InferencePool, auf der das Modell bereitgestellt wird.

```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"
```

Ersetzen Sie Folgendes:

• NAME: Der Name Ihres Inference Objective. Beispiel: food-review.
• VALUE: die Priorität für das Inference Objective. Dies ist eine Ganzzahl. Ein höherer Wert deutet auf eine kritischere Anfrage hin. Zum Beispiel 10.
• INFERENCE_POOL_NAME: der Name des InferencePool, den Sie im vorherigen Schritt erstellt haben. Beispiel: vllm-llama3-8b-instruct.

So erstellen Sie ein InferenceObjective:

1. Speichern Sie das folgende Manifest als inference-objectives.yaml. Mit diesem Manifest werden zwei InferenceObjective-Ressourcen erstellt. Mit der ersten wird das food-review-Inferenzzielvorhaben für die vllm-llama3-8b-instruct InferencePool mit einer Priorität von 10 konfiguriert. Mit der zweiten wird das llama3-base-model-Inferenzziel mit einer höheren Priorität von 20 konfiguriert.

   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. Wenden Sie das Beispielmanifest auf Ihren Cluster an:

   kubectl apply -f inferenceobjective.yaml
   

Gateway erstellen

Die Gateway-Ressource ist der Einstiegspunkt für externen Traffic in Ihren Kubernetes-Cluster. Sie definiert die Listener, die eingehende Verbindungen akzeptieren.

Das GKE Inference Gateway funktioniert mit den folgenden Gateway-Klassen:

• gke-l7-rilb: für regionale interne Application Load Balancer.
• gke-l7-regional-external-managed: für regionale externe Application Load Balancer.

Weitere Informationen finden Sie in der Dokumentation zu Gateway-Klassen.

So erstellen Sie ein Gateway:

1. Speichern Sie das folgende Beispielmanifest als 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
   

   Ersetzen Sie Folgendes:

   • GATEWAY_NAME: Ein eindeutiger Name für Ihre Gateway-Ressource. Beispiel: inference-gateway.
   • GATEWAY_CLASS: die Gateway-Klasse, die Sie verwenden möchten. Beispiel: gke-l7-regional-external-managed.

2. Wenden Sie das Manifest auf Ihren Cluster an:

   kubectl apply -f gateway.yaml
   

Hinweis: Weitere Informationen zum Konfigurieren von TLS zum Sichern Ihres Gateways mit HTTPS finden Sie in der GKE-Dokumentation unter TLS-Konfiguration.

HTTPRoute erstellen

Die HTTPRoute-Ressource definiert, wie das GKE Gateway eingehende HTTP-Anfragen an Back-End-Dienste wie Ihre InferencePool weiterleitet. Die HTTPRoute-Ressource gibt Abgleichsregeln (z. B. Header oder Pfade) und das Backend an, an das der Traffic weitergeleitet werden soll.

1. Speichern Sie zum Erstellen eines HTTPRoute das folgende Beispielmanifest als 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
   

   Ersetzen Sie Folgendes:

   • HTTPROUTE_NAME: Ein eindeutiger Name für Ihre HTTPRoute-Ressource. Beispiel: my-route
   • GATEWAY_NAME: der Name der von Ihnen erstellten Gateway-Ressource. Beispiel: inference-gateway
   • PATH_PREFIX: Das Pfadpräfix, das Sie zum Abgleichen eingehender Anfragen verwenden. Verwenden Sie beispielsweise /, um alle Elemente abzugleichen.
   • INFERENCE_POOL_NAME: der Name der InferencePool-Ressource, zu der Sie Traffic weiterleiten möchten. Beispiel: vllm-llama3-8b-instruct

2. Wenden Sie das Manifest auf Ihren Cluster an:

   kubectl apply -f httproute.yaml
   

Inferenzanfrage senden

Nachdem Sie GKE Inference Gateway konfiguriert haben, können Sie Inferenzanfragen an Ihr bereitgestelltes Modell senden. So können Sie Text auf Grundlage Ihres Eingabe-Prompts und der angegebenen Parameter generieren.

So senden Sie Inferenzanfragen:

1. Legen Sie die folgenden Umgebungsvariablen fest:

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

   Ersetzen Sie Folgendes:

   • GATEWAY_NAME: der Name Ihrer Gateway-Ressource.
   • PORT_NUMBER: die Portnummer, die Sie im Gateway konfiguriert haben.

2. Führen Sie den folgenden Befehl aus, um den Gateway-Endpunkt abzurufen:

   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. Führen Sie den folgenden Befehl aus, um eine Anfrage an den Endpunkt /v1/completions mit curl zu senden:

   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"
   }'
   

   Ersetzen Sie Folgendes:

   • MODEL_NAME: der Name des Modells oder LoRA-Adapters, der verwendet werden soll.
   • PROMPT_TEXT: Der Eingabe-Prompt für das Modell.
   • MAX_TOKENS: Die maximale Anzahl von Tokens, die in der Antwort generiert werden sollen.
   • TEMPERATURE: Steuert die Zufälligkeit der Ausgabe. Verwenden Sie den Wert 0 für deterministische Ausgaben oder eine höhere Zahl für kreativere Ausgaben.

Im folgenden Beispiel wird gezeigt, wie Sie eine Beispielanfrage an das GKE Inference Gateway senden:

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"
}'

Beachten Sie Folgendes:

• Anfragetext: Der Anfragetext kann zusätzliche Parameter wie stop und top_p enthalten. Eine vollständige Liste der Optionen finden Sie in der OpenAI API-Spezifikation.
• Fehlerbehandlung: Implementieren Sie eine angemessene Fehlerbehandlung in Ihrem Clientcode, um potenzielle Fehler in der Antwort zu verarbeiten. Prüfen Sie beispielsweise den HTTP-Statuscode in der curl-Antwort. Ein Statuscode, der nicht 200 ist, weist in der Regel auf einen Fehler hin.
• Authentifizierung und Autorisierung: Sichern Sie für Produktionsbereitstellungen Ihren API-Endpunkt mit Authentifizierungs- und Autorisierungsmechanismen. Fügen Sie Ihren Anfragen die entsprechenden Header hinzu, z. B. Authorization.

Nächste Schritte

• GKE Inference Gateway-Konfiguration anpassen
• Body-Based Routing konfigurieren
• LLM mit GKE Inference Gateway bereitstellen