Disponibilizar um LLM com o GKE Inference Gateway

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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.

Assinar o contrato de consentimento de licença

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

1. Acesse a página de consentimento e confirme o consentimento para usar sua conta do Hugging Face.
2. 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:

1. Clique em Seu perfil > Configurações > Tokens de acesso.
2. Selecione Novo token.
3. Especifique um nome de sua escolha e um papel de pelo menos Read.
4. Selecione Gerar um token.
5. 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:

1. No console do Google Cloud, inicie uma sessão do Cloud Shell clicando em Ativar o Cloud Shell no console do Google Cloud. Isso inicia uma sessão no painel inferior do console do Google Cloud.

2. Defina as variáveis de ambiente padrão:

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

   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

Para criar os recursos necessários, siga estas instruções.

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.

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

1. Para configurar a autorização de coleta de métricas, crie o 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
   

Criar um secret do Kubernetes para as credenciais do Hugging Face

No Cloud Shell, faça o seguinte:

1. Para se comunicar com o cluster, configure kubectl:

     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 H100.
   • CLUSTER_NAME: o nome do cluster.

2. 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: o token do Hugging Face gerado anteriormente.
   • HF_SECRET: o nome do secret do Kubernetes. Por exemplo, hf-secret.

Instale os CRDs InferenceModel e InferencePool

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

Os CRDs estendem a API Kubernetes. Assim, você pode definir novos tipos de recursos. Para usar o GKE Inference Gateway, instale os CRDs InferencePool e InferenceModel no cluster do GKE executando o seguinte comando:

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

Implantar o servidor de modelo

Este exemplo implanta um modelo Llama3.1 usando um servidor de modelos do vLLM. A implantação é rotulada como app:vllm-llama3-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 e contêiner de modelo, porta de exibição e nome de implantação. Você pode configurar adaptadores LoRA na implantação ou implantar o modelo básico.

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

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

2. Aplique o manifesto ao cluster:

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

Criar um recurso InferencePool

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

O recurso personalizado InferencePool inclui os seguintes campos principais:

• selector: especifica quais pods pertencem a esse 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 gateway de inferência do GKE roteie o tráfego para seus pods de servidor de modelo.

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

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

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 de forma lógica a implantação do servidor de modelo e faz referência aos serviços de endpoint do modelo nos pods selecionados por Selector.

Criar um recurso InferenceModel com uma criticidade de veiculação

O recurso personalizado InferenceModel do Kubernetes define um modelo específico, incluindo modelos ajustados para LoRA, e a criticidade de veiculação.

O recurso personalizado InferenceModel inclui os seguintes campos principais:

• modelName: especifica o nome do modelo base ou do adaptador LoRA.
• Criticality: especifica a criticidade de veiculação do modelo.
• poolRef: faz referência ao InferencePool em que o modelo é veiculado.

O InferenceModel permite que o gateway de inferência do GKE roteie o tráfego para seus pods de servidor de modelo com base no nome e na criticidade do modelo.

Para criar um InferenceModel, siga estas etapas:

1. Salve o seguinte manifesto de amostra como inferencemodel.yaml:

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

   Substitua:

   • MODEL_NAME: o nome do modelo base ou do adaptador LoRA. Por exemplo, food-review.
   • CRITICALITY: a criticidade de veiculação escolhida. Escolha entre Critical, Standard ou Sheddable. Por exemplo, Standard.
   • INFERENCE_POOL_NAME: o nome do InferencePool que você criou na etapa anterior. Por exemplo, vllm-llama3-8b-instruct.

2. Aplique o manifesto de exemplo ao cluster:

   kubectl apply -f inferencemodel.yaml
   

O exemplo a seguir cria um objeto InferenceModel que configura o modelo food-review LoRA no vllm-llama3-8b-instruct InferencePool com uma criticidade de envio Standard. O objeto InferenceModel também configura o modelo base a ser veiculado com um nível de prioridade 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

Criar o gateway

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

O gateway de inferência do GKE oferece suporte à classe 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:

1. 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 de gateway. Por exemplo, inference-gateway.

2. Aplique o manifesto ao cluster:

   kubectl apply -f gateway.yaml
   

Criar o recurso HTTPRoute

Nesta seção, você cria um recurso HTTPRoute para definir como o gateway encaminha as solicitações HTTP recebidas para o InferencePool.

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

Para criar um HTTPRoute, siga estas etapas:

1. 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
         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 todos.
   • INFERENCE_POOL_NAME: o nome do recurso InferencePool para onde você quer encaminhar o tráfego. Por exemplo, vllm-llama3-8b-instruct.

2. 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, é possível enviar solicitações de inferência para o modelo implantado.

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

• Extraia o endpoint do gateway.
• Crie 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.

1. Para acessar o endpoint do gateway, execute o seguinte comando:

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

   Substitua:

   • GATEWAY_NAME: o nome do recurso de gateway.
   • PORT_NUMBER: o número da porta que você configurou no gateway.

2. Para enviar uma solicitação ao endpoint /v1/completions usando curl, execute o seguinte comando:

   curl -i -X POST https://${IP}:${PORT}/v1/completions \
   -H 'Content-Type: application/json' \
   -H 'Authorization: Bearer $(gcloud auth print-access-token)' \
   -d '{
       "model": "MODEL_NAME",
       "prompt": "PROMPT_TEXT",
       "max_tokens": MAX_TOKENS,
       "temperature": "TEMPERATURE"
   }'
   

   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 saída determinista ou um número maior para uma saída mais criativa.

Esteja ciente dos seguintes comportamentos:

• Corpo da solicitação: o corpo da solicitação pode incluir outros parâmetros, como stop e top_p. Consulte a especificação da API OpenAI para conferir uma lista completa de opções.
• Tratamento de erros: implemente o tratamento de erros adequado no código do cliente para processar 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 seu 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 do 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 Google Cloud pelos recursos criados neste guia, execute o seguinte comando:

gcloud container clusters delete CLUSTER_NAME \
    --region=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 H100.
• CLUSTER_NAME: o nome do cluster.

A seguir

• Leia sobre o Gateway de inferência do GKE.
• Leia sobre como implantar o gateway de inferência do GKE.