Diese Seite wurde von der Cloud Translation API übersetzt.

LLM mit dem GKE-Inferenz-Gateway bereitstellen

Autopilot Standard

In dieser Anleitung wird beschrieben, wie Sie ein Large Language Model (LLM) in Google Kubernetes Engine (GKE) mit dem GKE Inference Gateway bereitstellen. Das Tutorial enthält Schritte zum Einrichten von Clustern, zum Bereitstellen von Modellen, zum Konfigurieren des GKE Inference Gateway und zum Verarbeiten von LLM-Anfragen.

Diese Anleitung richtet sich an ML-Entwickler, Plattformadministratoren und ‑operatoren sowie Daten- und KI-Spezialisten, die LLM-Anwendungen mit LLMs auf GKE mit GKE Inference Gateway bereitstellen und verwalten möchten.

Bevor Sie diese Seite lesen, sollten Sie sich mit Folgendem vertraut machen:

Hintergrund

In diesem Abschnitt werden die in dieser Anleitung verwendeten Schlüsseltechnologien beschrieben. Weitere Informationen zu Konzepten und Begriffen für das Bereitstellen von Modellen sowie dazu, wie die generativen KI-Funktionen von GKE die Leistung beim Bereitstellen von Modellen verbessern und unterstützen können, finden Sie unter Modellinferenz in GKE.

vLLM

vLLM ist ein hoch optimiertes Open-Source-LLM-Bereitstellungs-Framework, das den Bereitstellungsdurchsatz auf GPUs über Funktionen wie die Folgenden beschleunigen kann:

Optimierte Transformer-Implementierung mit PagedAttention
Kontinuierliche Batchverarbeitung zur Verbesserung des allgemeinen Bereitstellungsdurchsatzes
Tensor-Parallelität und verteilte Bereitstellung auf mehreren GPUs

Weitere Informationen finden Sie in der vLLM-Dokumentation.

GKE Inference Gateway

GKE Inference Gateway erweitert die Funktionen von GKE für die Bereitstellung von LLMs. Es optimiert Inferenzarbeitslasten mit Funktionen wie den folgenden:

Für die Inferenz optimiertes Load-Balancing auf Grundlage von Lastmesswerten.
Unterstützung für die dichte Bereitstellung mehrerer Arbeitslasten von LoRA-Adaptern.
Modellbasiertes Routing für vereinfachte Abläufe.

Weitere Informationen finden Sie unter GKE Inference Gateway.

Ziele

Zugriff auf das Modell erhalten
Umgebung vorbereiten
Google Cloud -Ressourcen erstellen und konfigurieren.
Installieren Sie die CRDs InferenceModel und InferencePool.
Modellserver bereitstellen.
Observability für Ihr Inference Gateway konfigurieren

Hinweise

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the required API.

Enable the API

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the required API.

Enable the API

Make sure that you have the following role or roles on the project: roles/container.admin, roles/iam.serviceAccountAdmin

Check for the roles

In the Google Cloud console, go to the IAM page.
Go to IAM
Select the project.
In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.
For all rows that specify or include you, check the Role column to see whether the list of roles includes the required roles.

Grant the roles

In the Google Cloud console, go to the IAM page.
IAM aufrufen
Wählen Sie das Projekt aus.
Klicken Sie auf Zugriffsrechte erteilen.
Geben Sie im Feld Neue Hauptkonten Ihre Nutzer-ID ein. Das ist in der Regel die E‑Mail-Adresse eines Google-Kontos.
Wählen Sie in der Liste Rolle auswählen eine Rolle aus.
Klicken Sie auf Weitere Rolle hinzufügen, wenn Sie weitere Rollen zuweisen möchten.
Klicken Sie auf Speichern.

Erstellen Sie ein Hugging Face-Konto, falls Sie noch keines haben.
Prüfen Sie, ob Ihr Projekt ein ausreichendes Kontingent für H100-GPUs hat. Weitere Informationen finden Sie unter GPU-Kontingent planen und Zuteilungskontingente.

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.

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

Rufen Sie die Einwilligungsseite auf und bestätigen Sie die Einwilligung zur Verwendung Ihres Hugging Face-Kontos.
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:

Klicken Sie auf Profil > Einstellungen > Zugriffstokens.
Wählen Sie Neues Token aus.
Geben Sie einen Namen Ihrer Wahl und eine Rolle von mindestens Read an.
Wählen Sie Token generieren aus.
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:

Starten Sie in der Google Cloud Console eine Cloud Shell-Sitzung. Klicken Sie dazu in der Google Cloud Console auf Cloud Shell aktivieren. Dadurch wird im unteren Bereich der Google Cloud console eine Sitzung gestartet.
Legen Sie die Standardumgebungsvariablen fest:
```
gcloud config set project PROJECT_ID
gcloud config set billing/quota_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 ist 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.

Autopilot

Führen Sie in Cloud Shell den folgenden Befehl aus:

gcloud container clusters create-auto CLUSTER_NAME \
    --project=PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --release-channel=rapid

Ersetzen Sie die folgenden Werte:

PROJECT_ID: Ihre Google Cloud Projekt-ID.
CONTROL_PLANE_LOCATION: die Compute Engine-Region der Steuerungsebene des Clusters. Geben Sie eine Region an, die den Beschleunigertyp unterstützt, den Sie verwenden möchten, z. B. us-central1 für H100-GPU.
CLUSTER_NAME: Der Name Ihres Clusters.

GKE erstellt einen Autopilot-Cluster mit CPU- und GPU-Knoten, wie von den bereitgestellten Arbeitslasten angefordert.

Standard

Führen Sie in Cloud Shell den folgenden Befehl aus, um einen Standardcluster zu erstellen:
```
gcloud container clusters create CLUSTER_NAME \
    --project=PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --release-channel=rapid \
    --num-nodes=1 \
    --enable-managed-prometheus \
    --monitoring=SYSTEM,DCGM \
    --gateway-api=standard
```
Ersetzen Sie die folgenden Werte:
- PROJECT_ID: Ihre Google Cloud Projekt-ID.
- CONTROL_PLANE_LOCATION: die Compute Engine-Region der Steuerungsebene des Clusters. Geben Sie eine Region an, die den Beschleunigertyp unterstützt, den Sie verwenden möchten, z. B. us-central1 für H100-GPU.
- CLUSTER_NAME: Der Name Ihres Clusters.
Die Erstellung eines Clusters kann einige Minuten dauern.

Führen Sie den folgenden Befehl aus, um einen Knotenpool mit der entsprechenden Festplattengröße für die Ausführung des Llama-3.1-8B-Instruct-Modells zu erstellen:

gcloud container node-pools create gpupool \
    --accelerator type=nvidia-h100-80gb,count=2,gpu-driver-version=latest \
    --project=PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --node-locations=CONTROL_PLANE_LOCATION-a \
    --cluster=CLUSTER_NAME \
    --machine-type=a3-highgpu-2g \
    --num-nodes=1 \
    --disk-type="pd-standard"

GKE erstellt einen einzelnen Knotenpool mit einer H100-GPU.

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

Kubernetes-Secret für Hugging Face-Anmeldedaten erstellen

Gehen Sie in Cloud Shell so vor:

Konfigurieren Sie kubectl für die Kommunikation mit Ihrem Cluster:
```
  gcloud container clusters get-credentials CLUSTER_NAME \
      --location=CONTROL_PLANE_LOCATION
```
Ersetzen Sie die folgenden Werte:
- CONTROL_PLANE_LOCATION: die Compute Engine-Region der Steuerungsebene des Clusters.
- CLUSTER_NAME: Der Name Ihres Clusters.
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 ist das Hugging Face-Token, das Sie zuvor generiert haben.
- HF_SECRET: der Name für Ihr Kubernetes-Secret. Beispiel: hf-secret.

Installieren Sie die CRDs `InferenceModel` und `InferencePool`.

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

CRDs erweitern die Kubernetes API. So können Sie neue Ressourcentypen definieren. Wenn Sie GKE Inference Gateway verwenden möchten, installieren Sie die CRDs InferencePool und InferenceModel in Ihrem GKE-Cluster, indem Sie den folgenden Befehl ausführen:

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. Das Deployment ist mit 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 diese Bereitstellung mit Ihrem eigenen Modellserver und Modellcontainer, Bereitstellungsport und Bereitstellungsnamen aktualisieren. Sie können optional LoRA-Adapter im Deployment konfigurieren oder das Basismodell bereitstellen.

Speichern Sie das folgende Manifest als vllm-llama3-8b-instruct.yaml, um es auf einem nvidia-h100-80gb-Beschleunigertyp bereitzustellen. Dieses Manifest definiert ein Kubernetes-Deployment mit Ihrem Modell und 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

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 Rechenkonfiguration.

Die benutzerdefinierte InferencePool-Ressource enthält die folgenden Schlüsselfelder:

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.
targetPort: Definiert die Ports, die vom Modellserver in den Pods verwendet werden.

Die InferencePool-Ressource ermöglicht es GKE Inference Gateway, Traffic an Ihre Modellserver-Pods weiterzuleiten.

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 \
  --set healthCheckPolicy.create=false \
  --version v0.3.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.

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

`InferenceModel`-Ressource mit Bereitstellungskritikalität erstellen

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

Die benutzerdefinierte InferenceModel-Ressource enthält die folgenden Schlüsselfelder:

modelName: Gibt den Namen des Basismodells oder LoRA-Adapters an.
Criticality: Gibt die Kritikalität des Modells für die Bereitstellung an.
poolRef: Verweist auf die InferencePool, auf der das Modell bereitgestellt wird.

Mit InferenceModel kann das GKE Inference Gateway Traffic basierend auf dem Modellnamen und der Kritikalität an die Pods Ihres Modellservers weiterleiten.

So erstellen Sie ein InferenceModel:

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 Kritikalität für die Bereitstellung. Wählen Sie Critical, Standard oder Sheddable aus. Beispiel: Standard.
- INFERENCE_POOL_NAME: der Name des InferencePool, den Sie im vorherigen Schritt erstellt haben. Beispiel: vllm-llama3-8b-instruct.
Wenden Sie das Beispielmanifest auf Ihren Cluster an:
```
kubectl apply -f inferencemodel.yaml
```

Im folgenden Beispiel wird ein InferenceModel-Objekt erstellt, das das food-review-LoRA-Modell auf dem vllm-llama3-8b-instruct InferencePool mit einer Standard-Serving-Kritikalität konfiguriert. Mit dem InferenceModel-Objekt wird auch das Basismodell für die Bereitstellung mit der Prioritätsstufe Critical konfiguriert.

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 fungiert als Einstiegspunkt für externen Traffic in Ihren Kubernetes-Cluster. Sie definiert die Listener, die eingehende Verbindungen akzeptieren.

GKE Inference Gateway unterstützt die Gateway-Klassen gke-l7-rilb und gke-l7-regional-external-managed. Weitere Informationen finden Sie in der GKE-Dokumentation unter Gateway-Klassen.

So erstellen Sie ein Gateway:

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 Ihre Gateway-Ressource. Beispiel: inference-gateway.

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 der Traffic weitergeleitet werden soll.

So erstellen Sie eine HTTPRoute:

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: 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
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 Inferenzanfragen:

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 Eingabeaufforderung und den angegebenen Parametern generieren.

Führen Sie den folgenden Befehl aus, um den Gateway-Endpunkt abzurufen:
```
IP=$(kubectl get gateway/GATEWAY_NAME -o jsonpath='{.status.addresses[0].value}')
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.
Führen Sie den folgenden Befehl aus, um eine Anfrage an den Endpunkt /v1/completions mit curl zu senden:
```
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 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.

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.

Beobachtbarkeit für Ihr Inference Gateway konfigurieren

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

Informationen zum Konfigurieren der Beobachtbarkeit für GKE Inference Gateway finden Sie unter Beobachtbarkeit konfigurieren.

Bereitgestellte Ressourcen löschen

Mit dem folgenden Befehl vermeiden Sie, dass Ihrem Google Cloud -Konto die in dieser Anleitung erstellten Ressourcen in Rechnung gestellt werden:

gcloud container clusters delete CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION