GKE Inference Gateway bereitstellen

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

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

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

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

Hinweise

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

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für 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 gcloud components update ab.

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

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

Anforderungen für GKE Gateway Controller

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

Limits und Einschränkungen

Es gelten die folgenden Einschränkungen:

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

GKE Inference Gateway konfigurieren

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

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

  1. Umgebung vorbereiten: Richten Sie die erforderliche Infrastruktur und die erforderlichen Komponenten ein.
  2. Inferenzpool erstellen: Definieren Sie einen Pool von Modellservern mit der benutzerdefinierten InferencePool-Ressource.
  3. Ziele für die Modellbereitstellung angeben: Geben Sie Modellziele mit der benutzerdefinierten Ressource InferenceModel an.
  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.

Umgebung vorbereiten

  1. Installieren Sie Helm.

  2. Erstellen Sie einen GKE-Cluster.

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

  3. Führen Sie den folgenden Befehl aus, um die benutzerdefinierten Ressourcendefinitionen (Custom Resource Definitions, CRDs) InferencePool und InferenceModel in Ihrem GKE-Cluster zu installieren:

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

    Ersetzen Sie VERSION durch die Version der CRDs, die Sie installieren möchten (z. B. v0.3.0).

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

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/refs/heads/main/config/crd/networking.gke.io_gcptrafficextensions.yaml
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/refs/heads/main/config/crd/networking.gke.io_gcproutingextensions.yaml

  5. Um die Autorisierung zum Extrahieren von Messwerten einzurichten, erstellen Sie das Secret inference-gateway-sa-metrics-reader-secret:

    kubectl apply -f - <<EOF
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: inference-gateway-metrics-reader
rules:
- nonResourceURLs:
  - /metrics
  verbs:
  - get
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: inference-gateway-sa-metrics-reader
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: inference-gateway-sa-metrics-reader-role-binding
  namespace: default
subjects:
- kind: ServiceAccount
  name: inference-gateway-sa-metrics-reader
  namespace: default
roleRef:
  kind: ClusterRole
  name: inference-gateway-metrics-reader
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: Secret
metadata:
  name: inference-gateway-sa-metrics-reader-secret
  namespace: default
  annotations:
    kubernetes.io/service-account.name: inference-gateway-sa-metrics-reader
type: kubernetes.io/service-account-token
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: inference-gateway-sa-metrics-reader-secret-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["inference-gateway-sa-metrics-reader-secret"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gmp-system:collector:inference-gateway-sa-metrics-reader-secret-read
  namespace: default
roleRef:
  name: inference-gateway-sa-metrics-reader-secret-read
  kind: ClusterRole
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gmp-system
  kind: ServiceAccount
EOF

Modellserver und Modellbereitstellung erstellen

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

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

  1. Erstellen Sie ein Kubernetes-Secret zum Speichern Ihres Hugging Face-Tokens. Mit diesem Token wird auf 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. 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: 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 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

  3. Wenden Sie das Beispielmanifest auf Ihren Cluster an:

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

Nachdem Sie das Manifest angewendet haben, sollten Sie die folgenden Schlüsselfelder und ‑parameter berücksichtigen:

  • replicas: Gibt die Anzahl der Pods für das Deployment an.
  • image: Gibt das Docker-Image für den Modellserver an.
  • command: Gibt den Befehl an, der beim Start des Containers ausgeführt wird.
  • args: Gibt die Argumente an, die an den Befehl übergeben werden sollen.
  • env: Gibt Umgebungsvariablen für den Container an.
  • ports: Gibt die vom Container freigegebenen Ports an.
  • resources: Gibt die Ressourcenanforderungen und ‑limits für den Container an, z. B. GPU.
  • volumeMounts: Gibt an, wie Volumes im Container bereitgestellt werden.
  • initContainers: Gibt Container an, die vor dem Anwendungscontainer ausgeführt werden.
  • restartPolicy: Gibt die Neustartrichtlinie für die Pods an.
  • terminationGracePeriodSeconds: Gibt die Kulanzfrist für die Pod-Beendigung an.
  • volumes: Gibt die von den Pods verwendeten Volumes an.

Sie können diese Felder an Ihre spezifischen Anforderungen anpassen.

Inferenzpool erstellen

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

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

So erstellen Sie ein InferencePool mit Helm:

helm install vllm-llama3-8b-instruct \
  --set inferencePool.modelServers.matchLabels.app=vllm-llama3-8b-instruct \
  --set provider.name=gke \
  --version 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.

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 eine Bereitstellung der Endpunktauswahl mit dem Namen app:vllm-llama3-8b-instruct-epp für diese erstellte InferencePool erstellt.

Ziele für die Modellbereitstellung angeben

Die benutzerdefinierte Ressource InferenceModel definiert ein bestimmtes Modell, das bereitgestellt werden soll, einschließlich Unterstützung für LoRA-optimierte Modelle und deren Bereitstellungskritikalität. Sie müssen definieren, welche Modelle auf einem InferencePool bereitgestellt werden, indem Sie InferenceModel-Ressourcen erstellen. Diese InferenceModel-Ressourcen können auf Basismodelle oder LoRA-Adapter verweisen, die von den Modellservern in der InferencePool unterstützt werden.

Das Feld modelName gibt den Namen des Basismodells oder LoRA-Adapters an. Das Feld Criticality gibt die Wichtigkeit des Modells für die Bereitstellung an. Das Feld poolRef gibt die InferencePool an, auf der dieses Modell bereitgestellt wird.

So erstellen Sie ein 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: VALUE
  poolRef:
    name: INFERENCE_POOL_NAME

    Ersetzen Sie Folgendes:

    • MODEL_NAME: der Name Ihres Basismodells oder LoRA-Adapters. Beispiel: food-review.
    • VALUE: 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.

  2. 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 so konfiguriert, dass es mit dem Prioritätsniveau Critical bereitgestellt 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 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

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 GATEWAY_NAME durch einen eindeutigen Namen für Ihre Gateway-Ressource (z. B. inference-gateway) und GATEWAY_CLASS durch die Gateway-Klasse, die Sie verwenden möchten (z. B. gke-l7-regional-external-managed).

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f gateway.yaml

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

HTTPRoute erstellen

Die HTTPRoute-Ressource definiert, wie das GKE Gateway eingehende HTTP-Anfragen an Backend-Dienste weiterleitet. In diesem Kontext sind das Ihre InferencePool. 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.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

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f httproute.yaml

Inferenzanfrage senden

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

So senden Sie Inferenzanfragen:

  1. 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 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 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 print-access-token)' \
-d '{
    "model": "MODEL_NAME",
    "prompt": "PROMPT_TEXT",
    "max_tokens": MAX_TOKENS,
    "temperature": "TEMPERATURE"
}'

    Ersetzen Sie Folgendes:

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

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

curl -i -X POST ${IP}:${PORT}/v1/completions -H 'Content-Type: application/json' -H 'Authorization: Bearer $(gcloud auth print-access-token)' -d '{
    "model": "food-review",
    "prompt": "What is the best pizza in the world?",
    "max_tokens": 2048,
    "temperature": "0"
}'

Beachten Sie Folgendes:

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

Nächste Schritte