Esta página foi traduzida pela API Cloud Translation.

Disponibilizar um LLM com o gateway de inferência do GKE

Autopilot Standard

Este tutorial descreve como implantar um modelo de linguagem grande (LLM) no Google Kubernetes Engine (GKE) com o GKE Inference Gateway. O tutorial inclui etapas para configuração do cluster, implantação do modelo, configuração do gateway de inferência do GKE e processamento de solicitações de LLM.

Este tutorial é destinado a engenheiros de machine learning (ML), administradores e operadores de plataforma e especialistas em dados e IA que querem implantar e gerenciar aplicativos de LLM no GKE com o GKE Inference Gateway.

Antes de ler esta página, familiarize-se com os seguintes tópicos:

Contexto

Esta seção descreve as principais tecnologias usadas neste tutorial. Para mais informações sobre conceitos e terminologia de veiculação de modelos e como os recursos de IA generativa do GKE podem melhorar e apoiar a performance da veiculação de modelos, consulte Sobre a inferência de modelos no GKE.

vLLM

O vLLM é um framework de disponibilização de LLM de código aberto altamente otimizado que aumenta a capacidade de disponibilização em GPUs. Os principais recursos incluem:

Otimização da implementação do transformador com PagedAttention
Lotes contínuos que melhoram a capacidade geral de disponibilização
Paralelismo de tensor e exibição distribuída em várias GPUs

Para saber mais, consulte a documentação do vLLM.

GKE Inference Gateway

O gateway de inferência do GKE aumenta as capacidades do GKE para veicular LLMs. Ele otimiza as cargas de trabalho de inferência com recursos como:

Balanceamento de carga otimizado para inferência com base em métricas de carga.
Suporte para exibição densa de várias cargas de trabalho de adaptadores LoRA.
Roteamento com reconhecimento de modelo para operações simplificadas.

Para mais informações, consulte Sobre o GKE Inference Gateway.

Objetivos

Receber acesso ao modelo.
Preparar o ambiente.
Crie e configure Google Cloud recursos.
Instale os CRDs InferenceObjective e InferencePool.
Implante o servidor de modelo.
Configure a capacidade de observação para o gateway de inferência.

Antes de começar

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.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the required API.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the API

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

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the required API.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

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.
Acessar o IAM
Selecione o projeto.
Clique em Conceder acesso.
No campo Novos principais, digite seu identificador de usuário. Normalmente, é o endereço de e-mail de uma Conta do Google.
Na lista Selecionar papel, escolha um.
Para conceder outros papéis, adicione-os clicando em Adicionar outro papel.
Clique em Salvar.

Crie uma conta do Hugging Face caso ainda não tenha uma.
Verifique se o projeto tem cota suficiente para GPUs H100. Para saber mais, consulte Planejar a cota de GPU e Cotas de alocação.

Receber acesso ao modelo

Para implantar o modelo Llama3.1 no GKE, assine o contrato de consentimento de licença e gere um token de acesso do Hugging Face.

É necessário assinar o contrato de consentimento para usar o modelo Llama3.1. Siga estas instruções:

Acesse a página de consentimento e verifique se você autoriza o uso da sua conta do Hugging Face.
Aceite os termos do modelo.

Gerar um token de acesso

Para acessar o modelo pelo "Rosto abraçado", você vai precisar de um token de rosto abraçado.

Siga as etapas abaixo para gerar um novo token, caso ainda não tenha um:

Clique em Seu perfil > Configurações > Tokens de acesso.
Selecione Novo token.
Especifique um nome de sua escolha e uma função de pelo menos Read.
Selecione Gerar um token.
Copie o token gerado para a área de transferência.

Preparar o ambiente

Neste tutorial, você vai usar o Cloud Shell para gerenciar recursos hospedados no Google Cloud. O Cloud Shell vem pré-instalado com o software necessário para este tutorial, incluindo kubectl e gcloud CLI.

Para configurar o ambiente com o Cloud Shell, siga estas etapas:

No console do Google Cloud , inicie uma sessão do Cloud Shell clicando em Ativar o Cloud Shell no console doGoogle Cloud . Isso inicia uma sessão no painel inferior do console Google Cloud .
Defina as variáveis de ambiente padrão:
```
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
```
Substitua os seguintes valores:
- PROJECT_ID: o Google Cloud ID do projeto.
- REGION: uma região compatível com o tipo de acelerador que você quer usar, por exemplo, us-central1 para GPU H100.
- CLUSTER_NAME: o nome do cluster.
- HF_TOKEN: o token do Hugging Face gerado anteriormente.

Criar e configurar recursos Google Cloud

Criar um cluster do GKE e um pool de nós

Disponibilize LLMs em GPUs em um cluster do GKE Autopilot ou Standard. Recomendamos que você use um cluster do Autopilot para ter uma experiência totalmente gerenciada do Kubernetes. Para escolher o modo de operação do GKE mais adequado para suas cargas de trabalho, consulte Escolher um modo de operação do GKE.

Piloto automático

No Cloud Shell, execute este comando:

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

Substitua os seguintes valores:

PROJECT_ID: o Google Cloud ID do projeto.
CONTROL_PLANE_LOCATION: a região do Compute Engine do plano de controle do cluster. Forneça uma região que ofereça suporte ao tipo de acelerador que você quer usar, por exemplo, us-central1 para GPU H100.
CLUSTER_NAME: o nome do cluster.

O GKE cria um cluster do Autopilot com nós de CPU e GPU conforme solicitado pelas cargas de trabalho implantadas.

Padrão

No Cloud Shell, execute o seguinte comando para criar um cluster Standard:
```
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
```
Substitua os seguintes valores:
- PROJECT_ID: o Google Cloud ID do projeto.
- CONTROL_PLANE_LOCATION: a região do Compute Engine do plano de controle do cluster. Forneça uma região que ofereça suporte ao tipo de acelerador que você quer usar, por exemplo, us-central1 para GPU H100.
- CLUSTER_NAME: o nome do cluster.
A criação do cluster pode levar vários minutos.

Para criar um pool de nós com o tamanho de disco adequado para executar o modelo Llama-3.1-8B-Instruct, execute o seguinte comando:

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 \

O GKE cria um único pool de nós contendo uma GPU H100.

Configurar a autorização para coletar métricas

Para configurar a autorização para coletar métricas, crie o secret inference-gateway-sa-metrics-reader-secret.

Salve o seguinte manifesto como metrics-auth.yaml:

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

Aplique o manifesto:
```
kubectl apply -f metrics-auth.yaml
```

Criar um secret do Kubernetes para as credenciais do Hugging Face

No Cloud Shell, faça o seguinte:

Configure kubectl para que ele possa se comunicar com o cluster:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=REGION
```
Substitua os seguintes valores:
- REGION: uma região compatível com o tipo de acelerador que você quer usar, por exemplo, us-central1 para GPU L4.
- CLUSTER_NAME: o nome do cluster.

Crie um secret do Kubernetes que contenha o token do Hugging Face:

kubectl create secret generic hf-secret \
    --from-literal=hf_api_token=${HF_TOKEN} \
    --dry-run=client -o yaml | kubectl apply -f -

Substitua HF_TOKEN pelo token do Hugging Face que você gerou anteriormente.

Instale os CRDs `InferenceObjective` e `InferencePool`.

Nesta seção, você instala as definições de recursos personalizados (CRDs) necessárias para o GKE Inference Gateway.

Os CRDs estendem a API Kubernetes. Isso permite definir novos tipos de recursos. Para usar o GKE Inference Gateway, instale os CRDs InferencePool e InferenceObjective no cluster do GKE executando o seguinte comando:

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

Implantar o servidor de modelo

Este exemplo implanta um modelo Llama3.1 usando um servidor de modelos vLLM. A implantação é rotulada como app:vllm-llama3.1-8b-instruct. Essa implantação também usa dois adaptadores LoRA chamados food-review e cad-fabricator do Hugging Face. É possível atualizar essa implantação com seu próprio servidor de modelo e contêiner de modelo, porta de serviço e nome de implantação. É possível configurar adaptadores LoRA na implantação ou implantar o modelo de base.

Para implantar em um tipo de acelerador nvidia-h100-80gb, salve o manifesto a seguir como vllm-llama3.1-8b-instruct.yaml. Esse manifesto define uma implantação do Kubernetes com seu modelo e servidor de modelo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-llama3.1-8b-instruct
spec:
  replicas: 3
  selector:
    matchLabels:
      app: vllm-llama3.1-8b-instruct
  template:
    metadata:
      labels:
        app: vllm-llama3.1-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"
          - "--compilation-config"
          - '{"cudagraph_specialize_lora": "False"}' # As workaround for https://github.com/vllm-project/vllm/issues/29049
          env:
            - name: PORT
              value: "8000"
            - name: HUGGING_FACE_HUB_TOKEN
              valueFrom:
                secretKeyRef:
                  name: hf-secret
                  key: hf_api_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"
      # This is the second container in the Pod, a sidecar to the vLLM container.
      # It watches the ConfigMap and downloads LoRA adapters.
        - name: lora-adapter-syncer
          image: us-central1-docker.pkg.dev/k8s-staging-images/gateway-api-inference-extension/lora-syncer:main
          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 10ms TPOT at a max
      #      batch size around 50, or 100 tokens/sec)
      #   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 / 100 ~ 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 40% to the time from above (40s +
      #      16s = 56s)
      #
      # Thus we think it will take us at worst about 56s 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 to
      #      stop sending us new requests (56s + 30s = 86s).
      #
      # 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 (86s * 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.1-8b-adapters
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: vllm-llama3.1-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.k8s.io"
    kind: InferencePool
    name: vllm-llama3.1-8b-instruct
  default:
    config:
      type: HTTP
      httpHealthCheck:
          requestPath: /health
          port: 8000

Aplique o manifesto ao cluster:

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

Criar um recurso `InferencePool`

O recurso personalizado do Kubernetes InferencePool define um grupo de pods com um LLM de base e uma configuração de computação comuns.

O recurso personalizado InferencePool inclui os seguintes campos principais:

selector: especifica quais pods pertencem a este pool. Os rótulos nesse seletor precisam corresponder exatamente aos rótulos aplicados aos pods do servidor de modelo.
targetPort: define as portas usadas pelo servidor de modelo nos pods.

O recurso InferencePool permite que o GKE Inference Gateway roteie o tráfego para os pods do servidor de modelos.

Para criar um InferencePool usando o Helm, siga estas etapas:

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

Mude o seguinte campo para corresponder à sua implantação:

inferencePool.modelServers.matchLabels.app: a chave do rótulo usado para selecionar os pods do servidor de modelo.

Esse comando cria um objeto InferencePool que representa logicamente a implantação do servidor de modelo e faz referência aos serviços de endpoint do modelo nos pods selecionados pelo Selector.

Criar um recurso `InferenceObjective` com uma gravidade de veiculação

O recurso personalizado InferenceObjective define os parâmetros de veiculação de um modelo, incluindo a prioridade dele. É necessário criar recursos InferenceObjective para definir quais modelos são veiculados em um InferencePool. Esses recursos podem fazer referência a modelos de base ou adaptadores LoRA compatíveis com os servidores de modelo no InferencePool.

O campo metadata.name especifica o nome do modelo, o campo priority define a criticidade de exibição e o campo poolRef vincula ao InferencePool em que o modelo é veiculado.

Para criar um InferenceObjective, siga estas etapas:

Salve o seguinte manifesto de amostra como inferenceobjective.yaml:
```
apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferenceObjective
metadata:
  name: MODEL_NAME
spec:
  priority: VALUE
  poolRef:
    name: INFERENCE_POOL_NAME
    kind: "InferencePool"
```
Substitua:
- MODEL_NAME: o nome do modelo de base ou adaptador LoRA. Por exemplo, food-review.
- VALUE: a prioridade para o objetivo de inferência. É um número inteiro em que um valor maior indica uma solicitação mais crítica. Por exemplo, 10.
- INFERENCE_POOL_NAME: o nome do InferencePool que você criou na etapa anterior. Por exemplo, vllm-llama3.1-8b-instruct.

Aplique o manifesto de amostra ao cluster:

kubectl apply -f inferenceobjective.yaml

O exemplo a seguir cria dois objetos InferenceObjective. O primeiro configura o modelo LoRA food-review no vllm-llama3.1-8b-instruct InferencePool com uma prioridade de 10. A segunda configura o llama3-base-model para ser veiculado com uma prioridade mais alta de 20.

apiVersion: inference.networking.k8s.io/v1alpha1
kind: InferenceObjective
metadata:
  name: food-review
spec:
  priority: 10
  poolRef:
    name: vllm-llama3.1-8b-instruct
    kind: "InferencePool"
---
apiVersion: inference.networking.k8s.io/v1alpha1
kind: InferenceObjective
metadata:
  name: llama3-base-model
spec:
  priority: 20
  poolRef:
    name: vllm-llama3.1-8b-instruct
    kind: "InferencePool"

Criar o gateway

O recurso Gateway atua como o ponto de entrada do tráfego externo no seu cluster do Kubernetes. Ele define os listeners que aceitam conexões de entrada.

O GKE Inference Gateway é compatível com as classes de gateway gke-l7-rilb e gke-l7-regional-external-managed. Para mais informações, consulte a documentação do GKE sobre classes de gateway.

Para criar um gateway, siga estas etapas:

Salve o seguinte manifesto de amostra como 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

Substitua GATEWAY_NAME por um nome exclusivo para o recurso Gateway. Por exemplo, inference-gateway.

Aplique o manifesto ao cluster:
```
kubectl apply -f gateway.yaml
```

Criar o recurso `HTTPRoute`

Nesta seção, você vai criar um recurso HTTPRoute para definir como o gateway roteia solicitações HTTP recebidas para seu InferencePool.

O recurso HTTPRoute define como o gateway do GKE encaminha solicitações HTTP de entrada para serviços de back-end, que é seu InferencePool. Ele especifica regras de correspondência (por exemplo, cabeçalhos ou caminhos) e o back-end para o qual o tráfego deve ser encaminhado.

Para criar uma HTTPRoute, siga estas etapas:

Salve o seguinte manifesto de amostra como httproute.yaml:
```
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: HTTPROUTE_NAME
spec:
  parentRefs:
  - name: GATEWAY_NAME
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: PATH_PREFIX
    backendRefs:
    - name: INFERENCE_POOL_NAME
      group: inference.networking.k8s.io
      kind: InferencePool
```
Substitua:
- HTTPROUTE_NAME: um nome exclusivo para o recurso HTTPRoute. Por exemplo, my-route.
- GATEWAY_NAME: o nome do recurso Gateway que você criou. Por exemplo, inference-gateway.
- PATH_PREFIX: o prefixo de caminho usado para corresponder às solicitações recebidas. Por exemplo, / para corresponder a tudo.
- INFERENCE_POOL_NAME: o nome do recurso InferencePool para onde você quer encaminhar o tráfego. Por exemplo, vllm-llama3.1-8b-instruct.
Aplique o manifesto ao cluster:
```
kubectl apply -f httproute.yaml
```

Enviar uma solicitação de inferência

Depois de configurar o gateway de inferência do GKE, você pode enviar solicitações de inferência para o modelo implantado.

Para enviar solicitações de inferência, siga estas etapas:

Recupere o endpoint do gateway.
Construa uma solicitação JSON formatada corretamente.
Use curl para enviar a solicitação ao endpoint /v1/completions.

Isso permite gerar texto com base no comando de entrada e nos parâmetros especificados.

Para receber o endpoint do gateway, execute o seguinte comando:
```
IP=$(kubectl get gateway/GATEWAY_NAME -o jsonpath='{.status.addresses[0].value}')
PORT=80
```
Substitua GATEWAY_NAME pelo nome do recurso de gateway.
Para enviar uma solicitação ao endpoint /v1/completions usando curl, execute o comando a seguir:
```
curl -i -X POST http://${IP}:${PORT}/v1/completions \
-H "Content-Type: application/json" \
-d '{
    "model": "MODEL_NAME",
    "prompt": "PROMPT_TEXT",
    "max_tokens": MAX_TOKENS,
    "temperature": "TEMPERATURE"
}'
```
Substitua:
- MODEL_NAME: o nome do modelo ou adaptador LoRA a ser usado.
- PROMPT_TEXT: o comando de entrada para o modelo.
- MAX_TOKENS: o número máximo de tokens a serem gerados na resposta.
- TEMPERATURE: controla a aleatoriedade da saída. Use o valor 0 para uma saída determinista ou um número maior para uma saída mais criativa.

Lembre-se:

Corpo da solicitação: pode incluir outros parâmetros, como stop e top_p. Consulte a especificação da API da OpenAI para ver uma lista completa de opções.
Tratamento de erros: implemente o tratamento de erros adequado no código do cliente para lidar com possíveis erros na resposta. Por exemplo, verifique o código de status HTTP na resposta curl. Um código de status diferente de 200 geralmente indica um erro.
Autenticação e autorização: para implantações de produção, proteja o endpoint de API com mecanismos de autenticação e autorização. Inclua os cabeçalhos apropriados (por exemplo, Authorization) nas suas solicitações.

Configurar a observabilidade para o gateway de inferência

O gateway de inferência do GKE oferece observabilidade sobre a integridade, o desempenho e o comportamento das cargas de trabalho de inferência. Isso ajuda a identificar e resolver problemas, otimizar a utilização de recursos e garantir a confiabilidade dos aplicativos. É possível conferir essas métricas de observabilidade no Cloud Monitoring pelo Metrics Explorer.

Para configurar a observabilidade do GKE Inference Gateway, consulte Configurar a observabilidade.

Excluir os recursos implantados

Para evitar cobranças na sua conta do Google Cloud pelos recursos criados neste guia, execute o seguinte comando:

gcloud container clusters delete CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

Substitua os seguintes valores:

CONTROL_PLANE_LOCATION: a região do Compute Engine do plano de controle do cluster.
CLUSTER_NAME: o nome do cluster.

A seguir

Leia sobre o GKE Inference Gateway.
Leia sobre Como implantar o GKE Inference Gateway.

Disponibilizar um LLM com o gateway de inferência do GKE Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Contexto

vLLM

GKE Inference Gateway

Objetivos

Antes de começar

Check for the roles

Grant the roles

Receber acesso ao modelo

Assinar o contrato de consentimento de licença

Gerar um token de acesso

Preparar o ambiente

Criar e configurar recursos Google Cloud

Criar um cluster do GKE e um pool de nós

Piloto automático

Padrão

Configurar a autorização para coletar métricas

Criar um secret do Kubernetes para as credenciais do Hugging Face

Instale os CRDs InferenceObjective e InferencePool.

Implantar o servidor de modelo

Criar um recurso InferencePool

Criar um recurso InferenceObjective com uma gravidade de veiculação

Criar o gateway

Criar o recurso HTTPRoute

Enviar uma solicitação de inferência

Configurar a observabilidade para o gateway de inferência

Excluir os recursos implantados

A seguir

Disponibilizar um LLM com o gateway de inferência do GKE

Instale os CRDs `InferenceObjective` e `InferencePool`.

Criar um recurso `InferencePool`

Criar um recurso `InferenceObjective` com uma gravidade de veiculação

Criar o recurso `HTTPRoute`