Men-deploy GKE Inference Gateway

Halaman ini menjelaskan cara men-deploy GKE Inference Gateway.

Halaman ini ditujukan untuk spesialis Jaringan yang bertanggung jawab mengelola infrastruktur GKE, dan administrator platform yang mengelola workload AI.

Sebelum membaca halaman ini, pastikan Anda memahami hal-hal berikut:

GKE Inference Gateway meningkatkan Google Kubernetes Engine (GKE) Gateway untuk mengoptimalkan penayangan aplikasi AI generatif. GKE Inference Gateway memungkinkan Anda mengoptimalkan penayangan workload AI generatif di GKE. Platform ini menyediakan pengelolaan dan penskalaan workload AI yang efisien, memungkinkan tujuan performa khusus workload seperti latensi, dan meningkatkan penggunaan resource, kemampuan observasi, dan keamanan AI.

Sebelum memulai

Sebelum memulai, pastikan Anda telah menjalankan tugas berikut:

  • Aktifkan Google Kubernetes Engine API.
    • Aktifkan Google Kubernetes Engine API
  • Jika ingin menggunakan Google Cloud CLI untuk tugas ini, instal lalu lakukan inisialisasi gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan gcloud components update.

  • Aktifkan Compute Engine API, Network Services API, dan Model Armor API jika diperlukan.

    Buka Mengaktifkan akses ke API dan ikuti petunjuknya.

Persyaratan GKE Gateway Controller

  • GKE versi 1.32.3.
  • Google Cloud CLI versi 407.0.0 atau yang lebih baru.
  • Gateway API hanya didukung di cluster native VPC.
  • Anda harus mengaktifkan subnet khusus proxy.
  • Cluster Anda harus mengaktifkan add-on HttpLoadBalancing.
  • Jika menggunakan Istio, Anda harus mengupgrade Istio ke salah satu versi berikut:
    • 1.15.2 atau yang lebih baru
    • 1.14.5 atau yang lebih baru
    • 1.13.9 atau yang lebih baru
  • Jika menggunakan VPC Bersama, di project host, Anda harus menetapkan peran Compute Network User ke Akun Layanan GKE untuk project layanan.

Batas dan pembatasan

Batasan dan pembatasan berikut berlaku:

  • Gateway multi-cluster tidak didukung.
  • GKE Inference Gateway hanya didukung di resource GatewayClass gke-l7-regional-external-managed dan gke-l7-rilb.
  • Load Balancer Aplikasi internal lintas region tidak didukung.

Mengonfigurasi GKE Inference Gateway

Untuk mengonfigurasi GKE Inference Gateway, pertimbangkan contoh ini. Tim menjalankan model vLLM dan Llama3 serta secara aktif bereksperimen dengan dua adaptor LoRA yang disesuaikan: "food-review" dan "cad-fabricator".

Alur kerja tingkat tinggi untuk mengonfigurasi GKE Inference Gateway adalah sebagai berikut:

  1. Menyiapkan lingkungan Anda: siapkan infrastruktur dan komponen yang diperlukan.
  2. Membuat kumpulan inferensi: menentukan kumpulan server model menggunakan Resource Kustom InferencePool.
  3. Menentukan tujuan penayangan model: tentukan tujuan model menggunakan Resource Kustom InferenceModel.
  4. Membuat Gateway: mengekspos layanan inferensi menggunakan Gateway API.
  5. Buat HTTPRoute: tentukan cara traffic HTTP dirutekan ke layanan inferensi.
  6. Mengirim permintaan inferensi: membuat permintaan ke model yang di-deploy.

Menyiapkan lingkungan Anda

  1. Instal Helm.

  2. Buat cluster GKE:

  3. Untuk menginstal Definisi Resource Kustom (CRD) InferencePool dan InferenceModel di cluster GKE Anda, jalankan perintah berikut:

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

    Ganti VERSION dengan versi CRD yang ingin Anda instal (misalnya, v0.3.0).

  4. Jika Anda menggunakan versi GKE yang lebih lama dari v1.32.2-gke.1182001 dan ingin menggunakan Model Armor dengan GKE Inference Gateway, Anda harus menginstal CRD ekstensi traffic dan perutean:

    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. Untuk menyiapkan otorisasi guna meng-scrap metrik, buat 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

Membuat server model dan deployment model

Bagian ini menunjukkan cara men-deploy server model dan model. Contoh ini menggunakan server model vLLM dengan model Llama3. Deployment diberi label sebagai app:vllm-llama3-8b-instruct. Deployment ini juga menggunakan dua adaptor LoRA bernama food-review dan cad-fabricator dari Hugging Face.

Anda dapat menyesuaikan contoh ini dengan penampung dan model server model Anda sendiri, port penyaluran, dan nama deployment. Anda juga dapat mengonfigurasi adaptor LoRA dalam deployment, atau men-deploy model dasar. Langkah-langkah berikut menjelaskan cara membuat resource Kubernetes yang diperlukan.

  1. Buat Secret Kubernetes untuk menyimpan token Hugging Face Anda. Token ini digunakan untuk mengakses adaptor LoRA:

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

    Ganti HF_TOKEN dengan token Hugging Face Anda.

  2. Untuk men-deploy pada jenis akselerator nvidia-h100-80gb, simpan manifes berikut sebagai vllm-llama3-8b-instruct.yaml. Manifes ini menentukan Deployment Kubernetes dengan model dan server model Anda:

    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: 600
            # 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. Terapkan manifes contoh ke cluster Anda:

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

Setelah Anda menerapkan manifes, pertimbangkan kolom dan parameter utama berikut:

  • replicas: menentukan jumlah Pod untuk Deployment.
  • image: menentukan image Docker untuk server model.
  • command: menentukan perintah yang akan dijalankan saat penampung dimulai.
  • args: menentukan argumen yang akan diteruskan ke perintah.
  • env: menentukan variabel lingkungan untuk penampung.
  • ports: menentukan port yang diekspos oleh penampung.
  • resources: menentukan permintaan dan batas resource untuk penampung, seperti GPU.
  • volumeMounts: menentukan cara volume dipasang ke penampung.
  • initContainers: menentukan penampung yang berjalan sebelum penampung aplikasi.
  • restartPolicy: menentukan kebijakan mulai ulang untuk Pod.
  • terminationGracePeriodSeconds: menentukan masa tenggang untuk penghentian Pod.
  • volumes: menentukan volume yang digunakan oleh Pod.

Anda dapat mengubah kolom ini agar sesuai dengan persyaratan spesifik Anda.

Membuat kumpulan inferensi

Resource kustom Kubernetes InferencePool menentukan grup Pod dengan konfigurasi komputasi dan model bahasa besar (LLM) dasar yang sama. Kolom selector menentukan Pod mana yang termasuk dalam kumpulan ini. Label dalam pemilih ini harus sama persis dengan label yang diterapkan ke Pod server model Anda. Kolom targetPort menentukan port yang digunakan server model dalam Pod. Kolom extensionRef mereferensikan layanan ekstensi yang menyediakan kemampuan tambahan untuk kumpulan inferensi. InferencePool memungkinkan GKE Inference Gateway merutekan traffic ke Pod server model Anda.

Sebelum membuat InferencePool, pastikan Pod yang dipilih InferencePool sudah berjalan.

Untuk membuat InferencePool menggunakan Helm, lakukan langkah-langkah berikut:

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

Ubah kolom berikut agar cocok dengan Deployment Anda:

  • inferencePool.modelServers.matchLabels.app: kunci label yang digunakan untuk memilih Pod server model Anda.

Penginstalan Helm akan otomatis menginstal kebijakan waktu tunggu yang diperlukan, pemilih endpoint, dan Pod yang diperlukan untuk visibilitas.

Tindakan ini akan membuat objek InferencePool: vllm-llama3-8b-instruct yang mereferensikan layanan endpoint model dalam Pod. Tindakan ini juga akan membuat deployment Pemilih Endpoint bernama app:vllm-llama3-8b-instruct-epp untuk InferencePool yang dibuat ini.

Menentukan tujuan penayangan model

Resource kustom InferenceModel menentukan model tertentu yang akan ditayangkan yang menyertakan dukungan untuk model yang disesuaikan LoRA dan tingkat kepentingan penayangannya. Anda harus menentukan model mana yang ditayangkan di InferencePool dengan membuat resource InferenceModel. Resource InferenceModel ini dapat mereferensikan model dasar, atau adaptor LoRA yang didukung oleh server model di InferencePool.

Kolom modelName menentukan nama model dasar atau adaptor LoRA. Kolom Criticality menentukan tingkat kepentingan penayangan model. Kolom poolRef menentukan InferencePool tempat model ini ditayangkan.

Untuk membuat InferenceModel, lakukan langkah-langkah berikut:

  1. Simpan manifes contoh berikut sebagai 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

    Ganti kode berikut:

    • MODEL_NAME: nama model dasar atau adaptor LoRA Anda. Contoh, food-review.
    • VALUE: tingkat kepentingan penayangan yang dipilih. Pilih dari Critical, Standard, atau Sheddable. Contoh, Standard.
    • INFERENCE_POOL_NAME: nama InferencePool yang Anda buat di langkah sebelumnya. Contohnya, vllm-llama3-8b-instruct.

  2. Terapkan manifes contoh ke cluster Anda:

    kubectl apply -f inferencemodel.yaml

Contoh berikut membuat objek InferenceModel yang mengonfigurasi model LoRA food-review di vllm-llama3-8b-instruct InferencePool dengan kritisitas penayangan Standard. Objek InferenceModel juga mengonfigurasi model dasar untuk ditayangkan dengan tingkat prioritas Critical.

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

Membuat Gateway

Resource Gateway adalah titik entri untuk traffic eksternal ke dalam cluster Kubernetes Anda. Class ini menentukan pemroses yang menerima koneksi masuk.

GKE Inference Gateway berfungsi dengan Class Gateway berikut:

  • gke-l7-rilb: untuk Load Balancer Aplikasi internal regional.
  • gke-l7-regional-external-managed

Untuk informasi selengkapnya, lihat dokumentasi Class Gateway.

Untuk membuat Gateway, lakukan langkah-langkah berikut:

  1. Simpan manifes contoh berikut sebagai 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

    Ganti GATEWAY_NAME dengan nama unik untuk resource Gateway Anda (misalnya inference-gateway), dan GATEWAY_CLASS dengan Class Gateway yang ingin Anda gunakan (misalnya, gke-l7-regional-external-managed).

  2. Terapkan manifes ke cluster Anda:

    kubectl apply -f gateway.yaml

Catatan: Untuk informasi selengkapnya tentang cara mengonfigurasi TLS untuk mengamankan Gateway dengan HTTPS, lihat dokumentasi GKE tentang konfigurasi TLS.

Membuat HTTPRoute

Resource HTTPRoute menentukan cara GKE Gateway merutekan permintaan HTTP masuk ke layanan backend, yang dalam konteks ini adalah InferencePool Anda. Resource HTTPRoute menentukan aturan pencocokan (misalnya, header atau jalur) dan backend tempat traffic harus diteruskan.

  1. Untuk membuat HTTPRoute, simpan contoh manifes berikut sebagai 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
      kind: InferencePool

    Ganti kode berikut:

    • HTTPROUTE_NAME: nama unik untuk resource HTTPRoute Anda. Misalnya, my-route.
    • GATEWAY_NAME: nama resource Gateway yang Anda buat. Misalnya, inference-gateway.
    • PATH_PREFIX: awalan jalur yang Anda gunakan untuk mencocokkan permintaan masuk. Misalnya, / untuk mencocokkan semua.
    • INFERENCE_POOL_NAME: nama resource InferencePool yang ingin Anda jadikan tujuan traffic. Misalnya, vllm-llama3-8b-instruct.

  2. Terapkan manifes ke cluster Anda:

    kubectl apply -f httproute.yaml

Mengirim permintaan inferensi

Setelah mengonfigurasi GKE Inference Gateway, Anda dapat mengirim permintaan inferensi ke model yang di-deploy. Hal ini memungkinkan Anda membuat teks berdasarkan perintah input dan parameter yang ditentukan.

Untuk mengirim permintaan inferensi, lakukan langkah-langkah berikut:

  1. Untuk mendapatkan endpoint Gateway, jalankan perintah berikut:

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

    Ganti kode berikut:

    • GATEWAY_NAME: nama resource Gateway Anda.
    • PORT_NUMBER: nomor port yang Anda konfigurasikan di Gateway.

  2. Untuk mengirim permintaan ke endpoint /v1/completions menggunakan curl, jalankan perintah berikut:

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

    Ganti kode berikut:

    • MODEL_NAME: nama model atau adaptor LoRA yang akan digunakan.
    • PROMPT_TEXT: perintah input untuk model.
    • MAX_TOKENS: jumlah maksimum token yang akan dibuat dalam respons.
    • TEMPERATURE: mengontrol keacakan output. Gunakan nilai 0 untuk output deterministik, atau angka yang lebih tinggi untuk output yang lebih kreatif.

Contoh berikut menunjukkan cara mengirim contoh permintaan ke GKE Inference Gateway:

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

Perhatikan perilaku berikut:

  • Isi permintaan: isi permintaan dapat menyertakan parameter tambahan seperti stop dan top_p. Lihat spesifikasi OpenAI API untuk mengetahui daftar lengkap opsi.
  • Penanganan error: terapkan penanganan error yang tepat dalam kode klien Anda untuk menangani potensi error dalam respons. Misalnya, periksa kode status HTTP dalam respons curl. Kode status non-200 umumnya menunjukkan error.
  • Autentikasi dan otorisasi: untuk deployment produksi, amankan endpoint API Anda dengan mekanisme autentikasi dan otorisasi. Sertakan header yang sesuai (misalnya, Authorization) dalam permintaan Anda.

Langkah berikutnya