Publique um MDG com o GKE Inference Gateway

Este tutorial descreve como implementar um modelo de linguagem (conteúdo extenso) (MDL/CE) no Google Kubernetes Engine (GKE) com o GKE Inference Gateway. O tutorial inclui passos para a configuração do cluster, a implementação do modelo, a configuração do GKE Inference Gateway e o processamento de pedidos de MDIs.

Este tutorial destina-se a engenheiros de aprendizagem automática (ML), administradores e operadores de plataformas, e especialistas em dados e IA que querem implementar e gerir aplicações de MDI/CE no GKE com o GKE Inference Gateway.

Antes de ler esta página, familiarize-se com o seguinte:

Contexto

Esta secção descreve as principais tecnologias usadas neste tutorial. Para mais informações acerca dos conceitos e da terminologia de publicação de modelos, e como as capacidades de IA generativa do GKE podem melhorar e apoiar o desempenho da publicação de modelos, consulte o artigo Acerca da inferência de modelos no GKE.

vLLM

O vLLM é uma framework de serviço de LLM de código aberto altamente otimizada que aumenta a capacidade de processamento de serviço em GPUs. As principais funcionalidades incluem o seguinte:

  • Implementação do transformador otimizada com PagedAttention
  • Processamento em lote contínuo que melhora o débito geral da publicação
  • Paralelismo de tensores e serviço distribuído em várias GPUs

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

GKE Inference Gateway

O GKE Inference Gateway melhora as capacidades do GKE para publicar LLMs. Otimiza as cargas de trabalho de inferência com funcionalidades como as seguintes:

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

Para mais informações, consulte o artigo Acerca do GKE Inference Gateway.

Aceda ao modelo

Para implementar o modelo Llama3.1 no GKE, assine o contrato de consentimento de licença e gere uma chave de acesso da Hugging Face.

Tem de assinar o contrato de consentimento para usar o modelo Llama3.1. Siga estas instruções:

  1. Aceda à página de consentimento e valide o consentimento para utilizar a sua conta do Hugging Face.
  2. Aceite os termos do modelo.

Gere um token de acesso

Para aceder ao modelo através do Hugging Face, precisa de um token do Hugging Face.

Siga estes passos para gerar um novo token se ainda não tiver um:

  1. Clique em O seu perfil > Definições > Tokens de acesso.
  2. Selecione Novo token.
  3. Especifique um nome à sua escolha e uma função de, pelo menos, Read.
  4. Selecione Gerar um token.
  5. Copie o token gerado para a área de transferência.

Prepare o seu ambiente

Neste tutorial, vai usar o Cloud Shell para gerir recursos alojados no Google Cloud. O Cloud Shell é pré-instalado com o software necessário para este tutorial, incluindo kubectl e a CLI gcloud.

Para configurar o seu ambiente com o Cloud Shell, siga estes passos:

  1. Na Google Cloud consola, inicie uma sessão do Cloud Shell clicando em Ícone de ativação do Cloud Shell Ativar Cloud Shell na Google Cloud consola. Esta ação inicia uma sessão no painel inferior da consola. Google Cloud

  2. Defina as variáveis de ambiente predefinidas:

    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 seu Google Cloud ID do projeto.
    • REGION: uma região que suporta o tipo de acelerador que quer usar, por exemplo, us-central1 para a GPU H100.
    • CLUSTER_NAME: o nome do cluster.
    • HF_TOKEN: o token do Hugging Face que gerou anteriormente.

Crie e configure Google Cloud recursos

Crie um cluster e um node pool do GKE

Publique MDIs em GPUs num cluster do GKE Autopilot ou Standard. Recomendamos que use um cluster do Autopilot para uma experiência do Kubernetes totalmente gerida. Para escolher o modo de funcionamento do GKE mais adequado às suas cargas de trabalho, consulte o artigo Escolha um modo de funcionamento do GKE.

Piloto automático

No Cloud Shell, execute o seguinte 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 seu Google Cloud ID do projeto.
  • CONTROL_PLANE_LOCATION: a região do Compute Engine do plano de controlo do seu cluster. Indique uma região que suporte o tipo de acelerador que quer usar, por exemplo, us-central1 para a 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 implementadas.

Standard

  1. 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 seu Google Cloud ID do projeto.
    • CONTROL_PLANE_LOCATION: a região do Compute Engine do plano de controlo do seu cluster. Indique uma região que suporte o tipo de acelerador que quer usar, por exemplo, us-central1 para a GPU H100.
    • CLUSTER_NAME: o nome do cluster.

    A criação do cluster pode demorar vários minutos.

  2. Para criar um node pool com o tamanho do 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 node pool que contém uma GPU H100.

Configure a autorização para extrair métricas

Para configurar a autorização para extrair métricas, crie o segredo 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

Crie um segredo do Kubernetes para as credenciais do Hugging Face

No Cloud Shell, faça o seguinte:

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

      gcloud container clusters get-credentials CLUSTER_NAME \
      --location=CONTROL_PLANE_LOCATION

    Substitua os seguintes valores:

    • CONTROL_PLANE_LOCATION: a região do Compute Engine do painel de controlo do seu cluster.
    • CLUSTER_NAME: o nome do cluster.

  2. Crie um segredo do Kubernetes que contenha o token do Hugging Face:

      kubectl create secret generic hf-token \
      --from-literal=token=HF_TOKEN \
      --dry-run=client -o yaml | kubectl apply -f -

    Substitua HF_TOKEN pelo token do Hugging Face que gerou anteriormente.

Instale os CRDs InferenceObjective e InferencePool

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

Os CRDs expandem a API Kubernetes. Isto permite-lhe definir novos tipos de recursos. Para usar o GKE Inference Gateway, instale os CRDs InferencePool e InferenceObjective no seu 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

Implemente o servidor de modelos

Este exemplo implementa um modelo Llama3.1 através de um servidor de modelos vLLM. A implementação está etiquetada como app:vllm-llama3.1-8b-instruct. Esta implementação também usa dois adaptadores LoRA denominados food-review e cad-fabricator da Hugging Face. Pode atualizar esta implementação com o seu próprio servidor de modelos e contentor de modelos, porta de publicação e nome da implementação. Opcionalmente, pode configurar adaptadores LoRA na implementação ou implementar o modelo base.

  1. Para implementar num tipo de acelerador nvidia-h100-80gb, guarde o seguinte manifesto como vllm-llama3.1-8b-instruct.yaml. Este manifesto define uma implementação do Kubernetes com o seu modelo e servidor de modelos:

    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
          # Versions of vllm after v0.8.5 have an issue due to an update in NVIDIA driver path.
          # The following workaround can be used until the fix is applied to the vllm release
          # BUG: https://github.com/vllm-project/vllm/issues/18859
          image: "vllm/vllm-openai:latest"
          imagePullPolicy: Always
          command: ["sh", "-c"]
          args:
          - >-
            PATH=$PATH:/usr/local/nvidia/bin
            LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/nvidia/lib:/usr/local/nvidia/lib64
            python3 -m vllm.entrypoints.openai.api_server
            --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: 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

  2. Aplique o manifesto ao cluster:

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

Crie um recurso InferencePool

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

O recurso personalizado InferencePool inclui os seguintes campos principais:

  • selector: especifica a que agrupamentos pertence este conjunto. As etiquetas neste seletor têm de corresponder exatamente às etiquetas aplicadas aos pods do servidor do modelo.
  • targetPort: define as portas usadas pelo servidor de modelos nos pods.

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

Para criar um InferencePool com o Helm, siga estes passos:

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

Altere o campo seguinte para corresponder à sua implementação:

  • inferencePool.modelServers.matchLabels.app: a chave da etiqueta usada para selecionar os pods do servidor do modelo.

Este comando cria um objeto InferencePool que representa logicamente a implementação do servidor de modelos e faz referência aos serviços de ponto final do modelo nos pods que o Selector seleciona.

Crie um recurso InferenceObjective com uma criticidade de publicação

O recurso personalizado InferenceObjective define os parâmetros de publicação de um modelo, incluindo a respetiva prioridade. Tem de criar recursos InferenceObjective para definir que modelos são publicados num InferencePool. Estes recursos podem fazer referência a modelos base ou adaptadores LoRA suportados pelos servidores de modelos no InferencePool.

O campo metadata.name especifica o nome do modelo, o campo priority define a respetiva criticidade de publicação e o campo poolRef estabelece uma ligação ao InferencePool onde o modelo é publicado.

Para criar um InferenceObjective, siga estes passos:

  1. Guarde o seguinte manifesto de exemplo 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 o seguinte:

    • MODEL_NAME: o nome do modelo base ou do adaptador LoRA. Por exemplo, food-review.
    • VALUE: a prioridade do objetivo de inferência. Este é um número inteiro em que um valor mais elevado indica um pedido mais crítico. Por exemplo, 10.
    • INFERENCE_POOL_NAME: o nome do InferencePool que criou no passo anterior. Por exemplo, vllm-llama3.1-8b-instruct.

  2. Aplique o manifesto de exemplo ao seu cluster:

    kubectl apply -f inferenceobjective.yaml

O exemplo seguinte cria dois objetos InferenceObjective. A primeira configura o food-reviewmodelo LoRA no vllm-llama3.1-8b-instruct InferencePool com uma prioridade de 10. A segunda configuração define que o llama3-base-model seja publicado com uma prioridade mais elevada 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"

Crie o gateway

O recurso Gateway funciona como o ponto de entrada para o tráfego externo no seu cluster do Kubernetes. Define os ouvintes que aceitam ligações recebidas.

O GKE Inference Gateway suporta a 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 estes passos:

  1. Guarde o seguinte manifesto de exemplo 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

Crie o recurso HTTPRoute

Nesta secção, cria um recurso HTTPRoute para definir como o gateway encaminha os pedidos HTTP recebidos para o seu InferencePool.

O recurso HTTPRoute define como o GKE Gateway encaminha os pedidos HTTP recebidos para serviços de back-end, que é o seu InferencePool. 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 um HTTPRoute, siga estes passos:

  1. Guarde o seguinte manifesto de exemplo 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 o seguinte:

    • HTTPROUTE_NAME: um nome exclusivo para o seu recurso HTTPRoute. Por exemplo, my-route.
    • GATEWAY_NAME: o nome do recurso Gateway que criou. Por exemplo, inference-gateway.
    • PATH_PREFIX: o prefixo do caminho que usa para fazer corresponder pedidos recebidos. Por exemplo, / para corresponder a tudo.
    • INFERENCE_POOL_NAME: o nome do recurso InferencePool para o qual quer encaminhar o tráfego. Por exemplo, vllm-llama3.1-8b-instruct.

  2. Aplique o manifesto ao cluster:

    kubectl apply -f httproute.yaml

Envie um pedido de inferência

Depois de configurar o GKE Inference Gateway, pode enviar pedidos de inferência para o modelo implementado.

Para enviar pedidos de inferência, siga estes passos:

  • Obtenha o ponto final do gateway.
  • Construa um pedido JSON formatado corretamente.
  • Use curl para enviar o pedido para o ponto final /v1/completions.

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

  1. Para obter o ponto final 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 Gateway.

  2. Para enviar um pedido para o ponto final /v1/completions através do curl, execute o seguinte comando:

    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 o seguinte:

    • MODEL_NAME: o nome do modelo ou do adaptador LoRA a usar.
    • PROMPT_TEXT: o comando de entrada para o modelo.
    • MAX_TOKENS: o número máximo de tokens a gerar na resposta.
    • TEMPERATURE: controla a aleatoriedade do resultado. Use o valor 0 para uma saída determinística ou um número superior para uma saída mais criativa.

Tenha em atenção o seguinte:

  • Corpo do pedido: o corpo do pedido pode incluir parâmetros adicionais, como stop e top_p. Consulte a especificação da API OpenAI para ver uma lista completa de opções.
  • Processamento de erros: implemente o processamento de erros adequado no código do cliente para processar potenciais erros na resposta. Por exemplo, verifique o código de estado HTTP na resposta curl. Geralmente, um código de estado diferente de 200 indica um erro.
  • Autenticação e autorização: para implementações de produção, proteja o seu ponto final da API com mecanismos de autenticação e autorização. Inclua os cabeçalhos adequados (por exemplo, Authorization) nos seus pedidos.

Configure a observabilidade para o seu Inference Gateway

O GKE Inference Gateway oferece observabilidade sobre o estado, o desempenho e o comportamento das suas cargas de trabalho de inferência. Isto ajuda a identificar e resolver problemas, otimizar a utilização de recursos e garantir a fiabilidade das suas aplicações. Pode ver estas métricas de observabilidade no Cloud Monitoring através do Explorador de métricas.

Para configurar a observabilidade para o GKE Inference Gateway, consulte o artigo Configure a observabilidade.

Elimine os recursos implementados

Para evitar incorrer em cobranças na sua Google Cloud conta pelos recursos que criou a partir deste 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 controlo do seu cluster.
  • CLUSTER_NAME: o nome do cluster.

O que se segue?