LLM mit dem GKE-Inferenz-Gateway bereitstellen

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Zugriff auf das Modell erhalten

Wenn Sie das Llama3.1-Modell in GKE bereitstellen möchten, unterzeichnen Sie die Lizenzeinwilligungsvereinbarung und generieren Sie ein Hugging Face-Zugriffstoken.

Lizenz-Einwilligungsvereinbarung unterzeichnen

Sie müssen die Einwilligungsvereinbarung unterzeichnen, um das Llama3.1-Modell verwenden zu können. Gehen Sie dazu so vor:

1. Rufen Sie die Seite mit der Einwilligung auf und bestätigen Sie die Einwilligung zur Verwendung Ihres Hugging Face-Kontos.
2. Akzeptieren Sie die Modellbedingungen.

Zugriffstoken erstellen

Für den Zugriff auf das Modell über Hugging Face benötigen Sie ein Hugging Face-Token.

Führen Sie die folgenden Schritte aus, um ein neues Token zu generieren, falls Sie noch keines haben:

1. Klicken Sie auf Profil > Einstellungen > Zugriffstokens.
2. Wählen Sie Neues Token aus.
3. Geben Sie einen Namen Ihrer Wahl und eine Rolle von mindestens Read an.
4. Wählen Sie Token generieren aus.
5. Kopieren Sie das Token in die Zwischenablage.

Umgebung vorbereiten

In dieser Anleitung verwenden Sie Cloud Shell zum Verwalten von Ressourcen, die inGoogle Cloudgehostet werden. Die Software, die Sie für diese Anleitung benötigen, ist in Cloud Shell vorinstalliert, einschließlich kubectl und gcloud CLI.

So richten Sie Ihre Umgebung mit Cloud Shell ein:

1. Starten Sie in der Google Cloud -Konsole eine Cloud Shell-Sitzung. Klicken Sie dazu in der Google Cloud -Konsole auf Cloud Shell aktivieren. Dadurch wird im unteren Bereich der Google Cloud Console eine Sitzung gestartet.

2. Legen Sie die Standardumgebungsvariablen fest:

   gcloud config set project PROJECT_ID
   export PROJECT_ID=$(gcloud config get project)
   export REGION=REGION
   export CLUSTER_NAME=CLUSTER_NAME
   export HF_TOKEN=HF_TOKEN
   

   Ersetzen Sie die folgenden Werte:

   • PROJECT_ID: Ihre Google Cloud Projekt-ID.
   • REGION: eine Region, die den Beschleunigertyp unterstützt, den Sie verwenden möchten, z. B. us-central1 für H100-GPU.
   • CLUSTER_NAME: Der Name Ihres Clusters.
   • HF_TOKEN: das Hugging Face-Token, das Sie zuvor generiert haben.

Google Cloud -Ressourcen erstellen und konfigurieren

Folgen Sie dieser Anleitung, um die erforderlichen Ressourcen zu erstellen.

GKE-Cluster und -Knotenpool erstellen

LLMs auf GPUs in einem GKE-Cluster im Autopilot- oder Standardmodus bereitstellen Für eine vollständig verwaltete Kubernetes-Umgebung empfehlen wir die Verwendung eines Autopilot-Clusters. Informationen zum Auswählen des GKE-Betriebsmodus, der für Ihre Arbeitslasten am besten geeignet ist, finden Sie unter GKE-Betriebsmodus auswählen.

gcloud container clusters create-auto CLUSTER_NAME \
    --project=PROJECT_ID \
    --region=REGION \
    --release-channel=rapid \
    --cluster-version=1.32.3-gke.1170000

1. Erstellen Sie das Secret inference-gateway-sa-metrics-reader-secret, um die Autorisierung zum Scrapen von Messwerten einzurichten:

   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
   

Kubernetes-Secret für Hugging Face-Anmeldedaten erstellen

Gehen Sie in Cloud Shell so vor:

1. Konfigurieren Sie kubectl für die Kommunikation mit Ihrem Cluster:

     gcloud container clusters get-credentials CLUSTER_NAME \
         --location=REGION
   

   Ersetzen Sie die folgenden Werte:

   • REGION: eine Region, die den Beschleunigertyp unterstützt, den Sie verwenden möchten, z. B. us-central1 für H100-GPU.
   • CLUSTER_NAME: Der Name Ihres Clusters.

2. Erstellen Sie ein Kubernetes-Secret, das das Hugging Face-Token enthält:

     kubectl create secret generic HF_SECRET \
         --from-literal=token=HF_TOKEN \
         --dry-run=client -o yaml | kubectl apply -f -
   

   Ersetzen Sie Folgendes:

   • HF_TOKEN: das Hugging Face-Token, das Sie zuvor generiert haben.
   • HF_SECRET: der Name Ihres Kubernetes-Secrets. Beispiel: hf-secret.

InferenceModel- und InferencePool-CRDs installieren

In diesem Abschnitt installieren Sie die erforderlichen benutzerdefinierten Ressourcendefinitionen (CRDs) für das GKE Inference Gateway.

Mit CRDs wird die Kubernetes API erweitert. So können Sie neue Ressourcentypen definieren. Wenn Sie das GKE-Inferenz-Gateway verwenden möchten, installieren Sie die CRDs InferencePool und InferenceModel in Ihrem GKE-Cluster. Führen Sie dazu den folgenden Befehl aus:

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

Modellserver bereitstellen

In diesem Beispiel wird ein Llama3.1-Modell mit einem vLLM-Modellserver bereitgestellt. Die Bereitstellung ist mit app:vllm-llama3-8b-instruct gekennzeichnet. Bei dieser Bereitstellung werden außerdem zwei LoRA-Adapter mit den Namen food-review und cad-fabricator von Hugging Face verwendet. Sie können diese Bereitstellung mit Ihrem eigenen Modellserver und Modellcontainer, dem Bereitstellungsport und dem Bereitstellungsnamen aktualisieren. Sie können optional LoRA-Adapter in der Bereitstellung konfigurieren oder das Basismodell bereitstellen.

1. Wenn Sie die Bereitstellung auf einem nvidia-h100-80gb-Beschleunigertyp vornehmen möchten, speichern Sie das folgende Manifest als vllm-llama3-8b-instruct.yaml. Dieses Manifest definiert ein Kubernetes-Deployment mit Ihrem Modell und Ihrem Modellserver:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: vllm-llama3-8b-instruct
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: vllm-llama3-8b-instruct
     template:
       metadata:
         labels:
           app: vllm-llama3-8b-instruct
       spec:
         containers:
           - name: vllm
             image: "vllm/vllm-openai:latest"
             imagePullPolicy: Always
             command: ["python3", "-m", "vllm.entrypoints.openai.api_server"]
             args:
             - "--model"
             - "meta-llama/Llama-3.1-8B-Instruct"
             - "--tensor-parallel-size"
             - "1"
             - "--port"
             - "8000"
             - "--enable-lora"
             - "--max-loras"
             - "2"
             - "--max-cpu-loras"
             - "12"
             env:
               # Enabling LoRA support temporarily disables automatic v1, we want to force it on
               # until 0.8.3 vLLM is released.
               - name: VLLM_USE_V1
                 value: "1"
               - name: PORT
                 value: "8000"
               - name: HUGGING_FACE_HUB_TOKEN
                 valueFrom:
                   secretKeyRef:
                     name: hf-token
                     key: token
               - name: VLLM_ALLOW_RUNTIME_LORA_UPDATING
                 value: "true"
             ports:
               - containerPort: 8000
                 name: http
                 protocol: TCP
             lifecycle:
               preStop:
                 # vLLM stops accepting connections when it receives SIGTERM, so we need to sleep
                 # to give upstream gateways a chance to take us out of rotation. The time we wait
                 # is dependent on the time it takes for all upstreams to completely remove us from
                 # rotation. Older or simpler load balancers might take upwards of 30s, but we expect
                 # our deployment to run behind a modern gateway like Envoy which is designed to
                 # probe for readiness aggressively.
                 sleep:
                   # Upstream gateway probers for health should be set on a low period, such as 5s,
                   # and the shorter we can tighten that bound the faster that we release
                   # accelerators during controlled shutdowns. However, we should expect variance,
                   # as load balancers may have internal delays, and we don't want to drop requests
                   # normally, so we're often aiming to set this value to a p99 propagation latency
                   # of readiness -> load balancer taking backend out of rotation, not the average.
                   #
                   # This value is generally stable and must often be experimentally determined on
                   # for a given load balancer and health check period. We set the value here to
                   # the highest value we observe on a supported load balancer, and we recommend
                   # tuning this value down and verifying no requests are dropped.
                   #
                   # If this value is updated, be sure to update terminationGracePeriodSeconds.
                   #
                   seconds: 30
                 #
                 # IMPORTANT: preStop.sleep is beta as of Kubernetes 1.30 - for older versions
                 # replace with this exec action.
                 #exec:
                 #  command:
                 #  - /usr/bin/sleep
                 #  - 30
             livenessProbe:
               httpGet:
                 path: /health
                 port: http
                 scheme: HTTP
               # vLLM's health check is simple, so we can more aggressively probe it.  Liveness
               # check endpoints should always be suitable for aggressive probing.
               periodSeconds: 1
               successThreshold: 1
               # vLLM has a very simple health implementation, which means that any failure is
               # likely significant. However, any liveness triggered restart requires the very
               # large core model to be reloaded, and so we should bias towards ensuring the
               # server is definitely unhealthy vs immediately restarting. Use 5 attempts as
               # evidence of a serious problem.
               failureThreshold: 5
               timeoutSeconds: 1
             readinessProbe:
               httpGet:
                 path: /health
                 port: http
                 scheme: HTTP
               # vLLM's health check is simple, so we can more aggressively probe it.  Readiness
               # check endpoints should always be suitable for aggressive probing, but may be
               # slightly more expensive than readiness probes.
               periodSeconds: 1
               successThreshold: 1
               # vLLM has a very simple health implementation, which means that any failure is
               # likely significant,
               failureThreshold: 1
               timeoutSeconds: 1
             # We set a startup probe so that we don't begin directing traffic or checking
             # liveness to this instance until the model is loaded.
             startupProbe:
               # Failure threshold is when we believe startup will not happen at all, and is set
               # to the maximum possible time we believe loading a model will take. In our
               # default configuration we are downloading a model from HuggingFace, which may
               # take a long time, then the model must load into the accelerator. We choose
               # 10 minutes as a reasonable maximum startup time before giving up and attempting
               # to restart the pod.
               #
               # IMPORTANT: If the core model takes more than 10 minutes to load, pods will crash
               # loop forever. Be sure to set this appropriately.
               failureThreshold: 3600
               # Set delay to start low so that if the base model changes to something smaller
               # or an optimization is deployed, we don't wait unnecessarily.
               initialDelaySeconds: 2
               # As a startup probe, this stops running and so we can more aggressively probe
               # even a moderately complex startup - this is a very important workload.
               periodSeconds: 1
               httpGet:
                 # vLLM does not start the OpenAI server (and hence make /health available)
                 # until models are loaded. This may not be true for all model servers.
                 path: /health
                 port: http
                 scheme: HTTP
   
             resources:
               limits:
                 nvidia.com/gpu: 1
               requests:
                 nvidia.com/gpu: 1
             volumeMounts:
               - mountPath: /data
                 name: data
               - mountPath: /dev/shm
                 name: shm
               - name: adapters
                 mountPath: "/adapters"
         initContainers:
           - name: lora-adapter-syncer
             tty: true
             stdin: true
             image: us-central1-docker.pkg.dev/k8s-staging-images/gateway-api-inference-extension/lora-syncer:main
             restartPolicy: Always
             imagePullPolicy: Always
             env:
               - name: DYNAMIC_LORA_ROLLOUT_CONFIG
                 value: "/config/configmap.yaml"
             volumeMounts: # DO NOT USE subPath, dynamic configmap updates don't work on subPaths
             - name: config-volume
               mountPath:  /config
         restartPolicy: Always
   
         # vLLM allows VLLM_PORT to be specified as an environment variable, but a user might
         # create a 'vllm' service in their namespace. That auto-injects VLLM_PORT in docker
         # compatible form as `tcp://<IP>:<PORT>` instead of the numeric value vLLM accepts
         # causing CrashLoopBackoff. Set service environment injection off by default.
         enableServiceLinks: false
   
         # Generally, the termination grace period needs to last longer than the slowest request
         # we expect to serve plus any extra time spent waiting for load balancers to take the
         # model server out of rotation.
         #
         # An easy starting point is the p99 or max request latency measured for your workload,
         # although LLM request latencies vary significantly if clients send longer inputs or
         # trigger longer outputs. Since steady state p99 will be higher than the latency
         # to drain a server, you may wish to slightly this value either experimentally or
         # via the calculation below.
         #
         # For most models you can derive an upper bound for the maximum drain latency as
         # follows:
         #
         #   1. Identify the maximum context length the model was trained on, or the maximum
         #      allowed length of output tokens configured on vLLM (llama2-7b was trained to
         #      4k context length, while llama3-8b was trained to 128k).
         #   2. Output tokens are the more compute intensive to calculate and the accelerator
         #      will have a maximum concurrency (batch size) - the time per output token at
         #      maximum batch with no prompt tokens being processed is the slowest an output
         #      token can be generated (for this model it would be about 100ms TPOT at a max
         #      batch size around 50)
         #   3. Calculate the worst case request duration if a request starts immediately
         #      before the server stops accepting new connections - generally when it receives
         #      SIGTERM (for this model that is about 4096 / 10 ~ 40s)
         #   4. If there are any requests generating prompt tokens that will delay when those
         #      output tokens start, and prompt token generation is roughly 6x faster than
         #      compute-bound output token generation, so add 20% to the time from above (40s +
         #      16s ~ 55s)
         #
         # Thus we think it will take us at worst about 55s to complete the longest possible
         # request the model is likely to receive at maximum concurrency (highest latency)
         # once requests stop being sent.
         #
         # NOTE: This number will be lower than steady state p99 latency since we stop       receiving
         #       new requests which require continuous prompt token computation.
             # NOTE: The max timeout for backend connections from gateway to model servers should
         #       be configured based on steady state p99 latency, not drain p99 latency
         #
         #   5. Add the time the pod takes in its preStop hook to allow the load balancers have
         #      stopped sending us new requests (55s + 30s ~ 85s)
         #
         # Because the termination grace period controls when the Kubelet forcibly terminates a
         # stuck or hung process (a possibility due to a GPU crash), there is operational safety
         # in keeping the value roughly proportional to the time to finish serving. There is also
         # value in adding a bit of extra time to deal with unexpectedly long workloads.
         #
         #   6. Add a 50% safety buffer to this time since the operational impact should be low
         #      (85s * 1.5 ~ 130s)
         #
         # One additional source of drain latency is that some workloads may run close to
         # saturation and have queued requests on each server. Since traffic in excess of the
         # max sustainable QPS will result in timeouts as the queues grow, we assume that failure
         # to drain in time due to excess queues at the time of shutdown is an expected failure
         # mode of server overload. If your workload occasionally experiences high queue depths
         # due to periodic traffic, consider increasing the safety margin above to account for
         # time to drain queued requests.
         terminationGracePeriodSeconds: 130
         nodeSelector:
           cloud.google.com/gke-accelerator: "nvidia-h100-80gb"
         volumes:
           - name: data
             emptyDir: {}
           - name: shm
             emptyDir:
               medium: Memory
           - name: adapters
             emptyDir: {}
           - name: config-volume
             configMap:
               name: vllm-llama3-8b-adapters
   ---
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: vllm-llama3-8b-adapters
   data:
     configmap.yaml: |
         vLLMLoRAConfig:
           name: vllm-llama3.1-8b-instruct
           port: 8000
           defaultBaseModel: meta-llama/Llama-3.1-8B-Instruct
           ensureExist:
             models:
             - id: food-review
               source: Kawon/llama3.1-food-finetune_v14_r8
             - id: cad-fabricator
               source: redcathode/fabricator
   ---
   kind: HealthCheckPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: health-check-policy
     namespace: default
   spec:
     targetRef:
       group: "inference.networking.x-k8s.io"
       kind: InferencePool
       name: vllm-llama3-8b-instruct
     default:
       config:
         type: HTTP
         httpHealthCheck:
             requestPath: /health
             port: 8000
   

2. Wenden Sie das Manifest auf Ihren Cluster an:

   kubectl apply -f vllm-llama3-8b-instruct.yaml
   

InferencePool-Ressource erstellen

Die benutzerdefinierte Kubernetes-Ressource InferencePool definiert eine Gruppe von Pods mit einer gemeinsamen Basis-LLM und einer gemeinsamen Compute-Konfiguration.

Die benutzerdefinierte InferencePool-Ressource enthält die folgenden wichtigen Felder:

• selector: gibt an, welche Pods zu diesem Pool gehören. Die Labels in dieser Auswahl müssen genau mit den Labels übereinstimmen, die auf Ihre Modellserver-Pods angewendet werden.
• targetPort: Hier werden die Ports definiert, die vom Modellserver in den Pods verwendet werden.

Mit der InferencePool-Ressource kann das GKE Inference Gateway Traffic an Ihre Modellserver-Pods weiterleiten.

So erstellen Sie eine InferencePool mit Helm:

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

Ändern Sie das folgende Feld so, dass es zu Ihrer Bereitstellung passt:

• inferencePool.modelServers.matchLabels.app: Der Schlüssel des Labels, mit dem die Pods des Modellservers ausgewählt werden.

Mit diesem Befehl wird ein InferencePool-Objekt erstellt, das Ihre Modellserverbereitstellung logisch darstellt und auf die Modellendpunktdienste in den Pods verweist, die von Selector ausgewählt werden.

InferenceModel-Ressource mit einer Bereitstellungspriorität erstellen

Die benutzerdefinierte Kubernetes-Ressource InferenceModel definiert ein bestimmtes Modell, einschließlich LoRA-optimierter Modelle, und seine Dienstkritalität.

Die benutzerdefinierte InferenceModel-Ressource enthält die folgenden wichtigen Felder:

• modelName: Gibt den Namen des Basismodells oder LoRA-Adapters an.
• Criticality: Gibt an, wie wichtig das Modell für die Auslieferung ist.
• poolRef: verweist auf die InferencePool, auf der das Modell bereitgestellt wird.

Mit der InferenceModel kann das GKE-Inferenz-Gateway Traffic basierend auf dem Modellnamen und der Kritikalität an Ihre Modellserver-Pods weiterleiten.

So erstellen Sie eine InferenceModel:

1. Speichern Sie das folgende Beispielmanifest als inferencemodel.yaml:

   apiVersion: inference.networking.x-k8s.io/v1alpha2
   kind: InferenceModel
   metadata:
     name: inferencemodel-sample
   spec:
     modelName: MODEL_NAME
     criticality: CRITICALITY
     poolRef:
       name: INFERENCE_POOL_NAME
   

   Ersetzen Sie Folgendes:

   • MODEL_NAME: der Name Ihres Basismodells oder LoRa-Adapters. Beispiel: food-review.
   • CRITICALITY: die ausgewählte Dienstpriorität. Wählen Sie Critical, Standard oder Sheddable aus. Beispiel: Standard.
   • INFERENCE_POOL_NAME: der Name der InferencePool, die Sie im vorherigen Schritt erstellt haben. Beispiel: vllm-llama3-8b-instruct.

2. Wenden Sie das Beispielmanifest auf Ihren Cluster an:

   kubectl apply -f inferencemodel.yaml
   

Im folgenden Beispiel wird ein InferenceModel-Objekt erstellt, mit dem das food-review-LoRa-Modell auf dem vllm-llama3-8b-instruct InferencePool mit einer Standard-Dienstkritalität konfiguriert wird. Mit dem InferenceModel-Objekt wird auch das Basismodell so konfiguriert, dass es mit einer Prioritätsstufe von Critical ausgeliefert wird.

apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferenceModel
metadata:
  name: food-review
spec:
  modelName: food-review
  criticality: Standard
  poolRef:
    name: vllm-llama3-8b-instruct
  targetModels:
  - name: food-review
    weight: 100

---
apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferenceModel
metadata:
  name: llama3-base-model
spec:
  modelName: meta-llama/Llama-3.1-8B-Instruct
  criticality: Critical
  poolRef:
    name: vllm-llama3-8b-instruct

Gateway erstellen

Die Gateway-Ressource dient als Einstiegspunkt für externen Traffic in Ihren Kubernetes-Cluster. Hier werden die Listener definiert, die eingehende Verbindungen akzeptieren.

Das GKE-Inferenz-Gateway unterstützt die Gateway-Klassen gke-l7-rilb und gke-l7-regional-external-managed. Weitere Informationen finden Sie in der GKE-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: gke-l7-regional-external-managed
     listeners:
       - protocol: HTTP # Or HTTPS for production
         port: 80 # Or 443 for HTTPS
         name: http
   

   Ersetzen Sie GATEWAY_NAME durch einen eindeutigen Namen für die Gateway-Ressource. Beispiel: inference-gateway.

2. Wenden Sie das Manifest auf Ihren Cluster an:

   kubectl apply -f gateway.yaml
   

Ressource HTTPRoute erstellen

In diesem Abschnitt erstellen Sie eine HTTPRoute-Ressource, um zu definieren, wie das Gateway eingehende HTTP-Anfragen an Ihre InferencePool weiterleitet.

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

So erstellen Sie eine HTTPRoute:

1. Speichern Sie 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.x-k8s.io
         kind: InferencePool
   

   Ersetzen Sie Folgendes:

   • HTTPROUTE_NAME: Eindeutiger Name für die HTTPRoute-Ressource. Beispiel: my-route
   • GATEWAY_NAME: der Name der von Ihnen erstellten Gateway-Ressource. Beispiel: inference-gateway
   • PATH_PREFIX: Das Pfadpräfix, mit dem eingehende Anfragen abgeglichen werden. Beispiel: / für eine Übereinstimmung mit allen.
   • INFERENCE_POOL_NAME: der Name der InferencePool-Ressource, an die Sie den 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 das GKE Inference Gateway konfiguriert haben, können Sie Inferenzanfragen an Ihr bereitgestelltes Modell senden.

So senden Sie Anfragen zur Inferenz:

• Rufen Sie den Gateway-Endpunkt ab.
• Erstellen Sie eine korrekt formatierte JSON-Anfrage.
• Verwenden Sie curl, um die Anfrage an den Endpunkt /v1/completions zu senden.

So können Sie Text basierend auf Ihrem Eingabeprompt und den angegebenen Parametern generieren.

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

   IP=$(kubectl get gateway/GATEWAY_NAME -o jsonpath='{.status.addresses[0].address}')
   PORT=PORT_NUMBER # Use 443 for HTTPS, or 80 for HTTP
   

   Ersetzen Sie Folgendes:

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

2. Wenn Sie eine Anfrage mit curl an den Endpunkt /v1/completions senden möchten, führen Sie den folgenden Befehl aus:

   curl -i -X POST https://${IP}:${PORT}/v1/completions \
   -H 'Content-Type: application/json' \
   -H 'Authorization: Bearer $(gcloud auth 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 Eingabeprompt 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 eine deterministische Ausgabe oder eine höhere Zahl für eine kreativere Ausgabe.

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 ordnungsgemäße Fehlerbehandlung in Ihrem Clientcode, um potenzielle Fehler in der Antwort zu behandeln. 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: Schützen Sie Ihren API-Endpunkt bei Produktionsbereitstellungen mit Authentifizierungs- und Autorisierungsmechanismen. Fügen Sie die entsprechenden Header (z. B. Authorization) in Ihre Anfragen ein.

Beobachtbarkeit für Ihr Inferenz-Gateway konfigurieren

Das GKE Inference Gateway bietet Einblicke in den Zustand, die Leistung und das Verhalten Ihrer Inferenzarbeitslasten. So können Sie Probleme erkennen und beheben, die Ressourcennutzung optimieren und die Zuverlässigkeit Ihrer Anwendungen sicherstellen. Sie können diese Messwerte in Cloud Monitoring über den Metrics Explorer aufrufen.

Informationen zum Konfigurieren der Beobachtbarkeit für das GKE-Inferenz-Gateway finden Sie unter Beobachtbarkeit konfigurieren.

Bereitgestellte Ressourcen löschen

Führen Sie den folgenden Befehl aus, damit Ihrem Google Cloud -Konto die in dieser Anleitung erstellten Ressourcen nicht in Rechnung gestellt werden:

gcloud container clusters delete CLUSTER_NAME \
    --region=REGION

Ersetzen Sie die folgenden Werte:

• REGION: eine Region, die den Beschleunigertyp unterstützt, den Sie verwenden möchten, z. B. us-central1 für H100-GPU.
• CLUSTER_NAME: Der Name Ihres Clusters.

Nächste Schritte

• Weitere Informationen zum GKE-Inferenz-Gateway
• Weitere Informationen zum Bereitstellen eines GKE-Inferenz-Gateways