GKE Inference Gateway mit llm-d bereitstellen

In diesem Dokument wird beschrieben, wie Sie das GKE-Inferenz-Gateway bereitstellen.

Dieses Dokument 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:

• Informationen zum GKE Inference Gateway
• KI‑/ML-Orchestrierung in GKE.
• Glossar zu generativer KI
• Load-Balancing in Google 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

Das GKE Inference Gateway erweitert das Google Kubernetes Engine (GKE)-Gateway, um die Bereitstellung generativer 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.

Hinweis

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 diese Aufgabe 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 dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.

• Aktivieren Sie bei Bedarf die Compute Engine API, die Kubernetes 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. Das Deployment schlägt fehl, wenn der Zugriff nicht gewährt wurde.

  • Lizenz-Einwilligungsvereinbarung unterzeichnen:Sie müssen die Einwilligungsvereinbarung unterzeichnen, um das Llama 3.1-Modell 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 Mein Profil > Einstellungen > Zugriffstokens auf, erstellen Sie ein neues Token mit mindestens Leseberechtigungen und kopieren Sie es in die Zwischenablage.

• Konfigurieren Sie ein reines Proxy-Subnetz für Ihr VPC-Netzwerk. Für den Gateway-Controller ist ein aktives Nur-Proxy-Subnetz in der Region erforderlich, um den Application Load Balancer bereitzustellen.

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

• 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.
• Ein InferencePool kann maximal acht targetPorts haben.

GKE Inference Gateway konfigurieren

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

Der allgemeine Workflow für die Konfiguration des GKE Inference Gateways ist wie folgt:

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

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.

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 Referenzeinrichtung für die Bereitstellung mit einem Klick finden Sie im cluster-toolkit gke-a3-highgpu-Beispiel.
   • 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 Deployment-Manifeste, die auf Ihrem ausgewählten Beschleuniger, Modell und Ihren Leistungsanforderungen basieren.

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

   • Für GKE-Versionen 1.34.0-gke.1626000 oder höher ist die InferencePool-CRD standardmäßig enthalten. Installieren Sie daher nur die Alpha-CRD 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
     

   • Bei GKE-Versionen vor 1.34.0-gke.1626000 müssen Sie sowohl die v1-InferencePool- als auch die Alpha-CRDs InferenceObjective installieren:

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

     Weitere Informationen finden Sie in der Kompatibilitätsmatrix.

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. Legen Sie die folgenden Umgebungsvariablen fest:

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

6. Installieren Sie die benutzerdefinierten Ressourcendefinitionen (CRDs) der Gateway API Inference Extension, die vom llm-d-Endpunkt-Picker (EPP) benötigt werden:

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

7. Erstellen Sie den Ziel-Namespace:

   kubectl create namespace ${NAMESPACE}
   

Modell-Server 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. Die Bereitstellung ist mit dem Label 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 Modell-Servercontainer, Ihr eigenes Modell, Ihren Bereitstellungsport und Ihren 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 vLLM-Modellserver mit dem GKE-spezifischen Kustomize-Overlay aus dem Leitfaden zur optimierten Baseline für llm-d bereit. Wenn Sie INFRA_PROVIDER=gke festlegen, werden GKE-spezifische Konfigurationen angewendet, einschließlich der Cloud Monitoring-Integration:

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

Hinweis:GKE bietet standardmäßig automatisches Anwendungsmonitoring. Der llm-d-Monitoring-Stack ist für GKE nicht erforderlich, kann aber verwendet werden.

Wenn Ihr Modellserver mehrere Ports benötigt, müssen Sie dafür sorgen, dass jeder Port in der Containerspezifikation verfügbar gemacht wird. Im folgenden Beispiel wird ein Deployment definiert, in dem der Container drei Ports freigibt:

Beispiel für die Bereitstellung über mehrere Ports

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

Inferenzpool erstellen

Die benutzerdefinierte Kubernetes-Ressource „InferencePool“ definiert eine Gruppe von Pods mit einem gemeinsamen Large Language Model (LLM) und einer gemeinsamen Rechenkonfiguration. Im Feld selector wird angegeben, welche Pods zu diesem Pool gehören. Die Labels in diesem Selektor müssen genau mit den Labels übereinstimmen, die auf Ihre Modellserver-Pods angewendet werden. Das Feld targetPorts definiert die Ports, die der Modell-Server in den Pods verwendet. Sie können bis zu acht Ports angeben. Das Feld extensionRef verweist auf einen Erweiterungsdienst, der zusätzliche Funktionen für den Inferenzpool bietet. Mit dem InferencePool kann das GKE Inference Gateway Traffic an die Pods Ihres Modellservers weiterleiten.

Das folgende InferencePool-Manifest gibt mehrere targetPorts an, die den von der Modell-Server-Bereitstellung bereitgestellten Ports entsprechen:

Beispiel für 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

Achten Sie vor dem Erstellen des InferencePool darauf, dass die Modell-Server-Pods, die vom InferencePool ausgewählt werden, bereits ausgeführt werden.

Klonen Sie die Rezepte und Empfehlungen für den InferencePool aus dem GitHub-Repository llm-d. Dieser Schritt ist erforderlich:

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

Führen Sie die folgenden Schritte aus, um einen InferencePool und einen Endpoint Picker mit Helm zu erstellen:

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

Ersetzen Sie Folgendes:

• GAIE_VERSION: die Version des Helm-Charts. Beispiel: v1.5.0.
• LLM_D_REGISTRY_PATH: der OCI-Registrierungspfad für das Helm-Chart. Beispiel: registry.k8s.io/gateway-api-inference-extension/charts/inferencepool.

Ändern Sie in der Datei guides/recipes/scheduler/base.values.yaml das folgende Feld so, dass es mit dem Label Ihres Modellbereitstellungs-Pods übereinstimmt:

• inferencePool.modelServers.matchLabels: Der Schlüssel und der Wert des Labels, das zum Auswählen der Modell-Server-Pods verwendet wird.

  Hinweis: Der Schlüssel und der Wert stimmen mit dem Beispiel im optimized-baseline-Leitfaden überein. Wir ersetzen ihn, damit er mit den Labels Ihres Bereitstellungs-Pods übereinstimmt.

Für das Monitoring ist das Erfassen von Messwerten für Google Cloud Managed Service for Prometheus standardmäßig aktiviert.

• Wenn Sie diese Funktion deaktivieren möchten, fügen Sie dem Befehl das Flag --set inferenceExtension.monitoring.prometheus.enabled=false hinzu.
• Wenn Sie die Standardüberwachung in einem GKE Autopilot-Cluster verwenden, müssen Sie auch das Flag --set provider.gke.autopilot=true hinzufügen.

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 erstellt: vllm-llama3-8b-instruct, das auf die Modellendpunktdienste in den Pods verweist. Außerdem wird für diesen erstellten InferencePool ein Deployment des Endpoint Picker mit dem Namen app:vllm-llama3-8b-instruct-epp erstellt.

Endpunktauswahl mit Hochverfügbarkeit bereitstellen

Durch die Bereitstellung von Endpoint Picker (EPP) mit bevorzugten Backends wird eine Aktiv/Passiv-Routingtopologie ermöglicht, die von Cloud Load Balancing unterstützt wird.

Wenn Sie die Endpunktauswahl mit bevorzugten Back-Ends verwenden, können Sie Folgendes erreichen:

• Statuskonsistenz: Cloud Load Balancing leitet 100% des ext_proc-Traffics im stabilen Zustand an das primäre Endpoint Picker-Replikat (epp-0) weiter. So werden der KV-Cache-Status (Schlüssel/Wert-Cache) und der Kontext der Anfragenplanung beibehalten.
• Failover ohne Ausfallzeiten: Wenn der primäre Endpoint Picker-Pod abstürzt oder gewartet wird, erkennt Cloud Load Balancing den Fehler mithilfe aktiver gRPC-Systemdiagnosen und leitet den Traffic sofort an das Standby-Replikat (epp-1) weiter.
• Fail-Open-Resilienz: In Kombination mit failureMode: FailOpen werden vorübergehende Routingfehler umgangen und Anfragen können direkt an Modellserver weitergeleitet werden, ohne dass Nutzeranfragen verloren gehen.

Wenn Sie bevorzugte Back-Ends aktivieren, ändert GKE die Architektur und das Routing auf folgende Weise:

• StatefulSet-Architektur für die Endpunktauswahl: Die Endpunktauswahl wird als StatefulSet anstelle einer Bereitstellung bereitgestellt. Pod-Ordnungszahlen geben die Replikatrollen an: Die Ordnungszahl epp-0 dient als primäres Replikat, das an die Backend-Ebene PREFERRED angepinnt ist, und die Ordnungszahl epp-1 dient als Standby-Replikat, das an die Ebene DEFAULT angepinnt ist.
• Routing-Status bleibt zentralisiert: Der ext_proc-Traffic im Steady State wird ausschließlich an die primäre Endpoint Picker-Replica (epp-0) weitergeleitet, um den Status für die KV-Cache-Verfolgung und die Anforderungsplanung zu zentralisieren. Wenn epp-0 fehlerhaft wird, leitet Cloud Load Balancing den Traffic zur Standby-Replikatinstanz (epp-1) um.
• Dual-Service-Architektur: Das Helm-Chart erstellt einen primären Dienst (Service/${GUIDE_NAME}-epp) und einen Standby-Sicherungsdienst (Service/${GUIDE_NAME}-epp-backup). Die InferencePool-Ressource ist deklarativ auf den Standby-Sicherungsdienst ausgerichtet. Wenn Sie die deklarative Gateway-Inhaberschaft an den Standby-Dienst binden, wird verhindert, dass die Abgleichsschleifen des GKE Gateway-Controllers die primären Netzwerkendpunktgruppen (NEGs) trennen, die Sie an den Backend-Dienst anhängen.

Führen Sie die folgenden Schritte aus, um einen InferencePool und einen Endpoint Picker mit Hochverfügbarkeit mit Helm zu erstellen:

1. Stellen Sie den InferencePool und die Endpunktauswahl mit bevorzugten Back-Ends mit Helm bereit:

   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
   

   Ersetzen Sie Folgendes:

   • GAIE_VERSION: Die GAIE-Version (Gateway API Inference Extension) des Helm-Charts. Beispiel: v1.5.0 Für bevorzugte Back-Ends ist die Helm-Diagramm-Version v1.5.0 oder höher erforderlich.
   • LLM_D_REGISTRY_PATH: der OCI-Registrierungspfad für das Helm-Diagramm. Beispiel: registry.k8s.io/gateway-api-inference-extension/charts/inferencepool

   Eine vollständige Liste der Parameter finden Sie unter values.yaml.

2. Hängen Sie die primäre NEG an BackendService an:

   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
   

   Ersetzen Sie Folgendes:

   • PROJECT_ID: Projekt-ID in Google Cloud .
   • REGION: die Google Cloud Region Ihres Clusters und Backend-Dienstes.

Nachdem zonale NEGs an die Google Cloud BackendService angehängt wurden, ist für das Skalieren der Anzahl der Replikate (preferredReplicas oder defaultReplicas) oder das Neustarten von Pods kein erneutes Ausführen von gcloud-Befehlen erforderlich. Der GKE-NEG-Controller synchronisiert automatisch einzelne Pod-IP-Adressen mit den registrierten zonalen NEGs.

Wenn Sie die übergeordnete Gateway- oder InferencePool-Ressource löschen und neu erstellen, erstellt der GKE Gateway-Controller die zugrunde liegende Google Cloud-BackendService mit einer neuen Cloud-ID neu. Führen Sie in diesem Fall den vorherigen Workflow zum Anhängen aus, um primäre zonale NEGs an die neu erstellte BackendService anzuhängen.

HTTPRoute erstellen

Die HTTPRoute-Ressource definiert, wie das GKE Gateway eingehende HTTP-Anfragen an Back-End-Dienste wie Ihren 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 verwenden, um eingehende Anfragen abzugleichen. 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
   

Inferenzziele angeben

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

Im Feld metadata.name der InferenceObjective-Ressource wird der Name des Inference Objective angegeben, im Feld Priority die Wichtigkeit der Bereitstellung und im Feld poolRef der InferencePool, auf dem das Modell bereitgestellt wird.

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"

Ersetzen Sie Folgendes:

• NAME: der Name Ihres Inferencing-Zielvorhabens. 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. Beispiel: 10.
• INFERENCE_POOL_NAME: Der Name des InferencePool, den Sie im vorherigen Schritt erstellt haben. Beispiel: vllm-llama3-8b-instruct

So erstellen Sie eine 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 den vllm-llama3-8b-instruct-Inferenzpool mit einer Priorität von 10 konfiguriert. Mit der zweiten wird das llama3-base-model-Zielvorhaben für die Inferenz 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 inference-objectives.yaml
   

Deployment prüfen

Führen Sie die folgenden Befehle aus, um zu prüfen, ob alle Komponenten ausgeführt werden:

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

Inferenzanfrage senden

Nachdem Sie das 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 application-default print-access-token)' -d '{
    "model": "food-review-1",
    "prompt": "What is the best pizza in the world?",
    "max_tokens": 2048,
    "temperature": 0
}'

Beachten Sie die folgenden Verhaltensweisen:

• 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 geeignete 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 in Ihre Anfragen die entsprechenden Header ein, z. B. Authorization.

Kompatibilitätsmatrix

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

Inferenz-Backend mit Backend-TLS sichern

Mit Backend-TLS kann der GKE Gateway-Load-Balancer die Identität der Inference-Backends überprüfen, mit denen er eine Verbindung herstellt. Backend-TLS fügt während des TLS-Handshakes zwischen dem Gateway und dem Backend-Pod einen expliziten Bestätigungsschritt hinzu. Diese Überprüfung trägt dazu bei, dass das Gateway nur mit vertrauenswürdigen Modellservern kommuniziert.

Wenn Sie Backend-TLS für Ihre Inferenz-Arbeitslasten konfigurieren möchten, hängen Sie eine BackendTLSPolicy an eine InferencePool- oder GCPInferencePoolImport-Ressource an.

Weitere Informationen finden Sie unter Backend-TLS konfigurieren.

Nächste Schritte

• GKE Inference Gateway-Konfiguration anpassen
• Textkörperbasiertes Routing konfigurieren
• LLM mit GKE Inference Gateway bereitstellen
• Vorhersagebasierte Latenz für das Routing mit GKE Inference Gateway verwenden