Sobre o gateway de inferência do GKE

Nesta página, explicamos os principais conceitos e recursos do Inference Gateway do Google Kubernetes Engine (GKE), uma extensão do GKE Gateway para veiculação otimizada de aplicativos de IA generativa.

Nesta página, consideramos que você esteja familiarizado com o seguinte:

Esta página é destinada aos seguintes perfis:

  • Engenheiros de machine learning (ML), administradores e operadores de plataforma e especialistas em dados e IA interessados em usar os recursos de orquestração de contêineres do Kubernetes para veiculação de cargas de trabalho de IA/ML.
  • Arquitetos de nuvem e especialistas Rede que interagem com redes do Kubernetes.

Visão geral

O gateway de inferência do GKE é uma extensão do gateway do GKE que oferece roteamento e balanceamento de carga otimizados para disponibilizar cargas de trabalho de inteligência artificial (IA) generativa. Ele simplifica a implantação, o gerenciamento e a capacidade de observação das cargas de trabalho de inferência de IA.

Recursos e benefícios

O GKE Inference Gateway oferece os seguintes recursos principais para veicular com eficiência modelos de IA generativa para aplicativos de IA generativa no GKE:

  • Balanceamento de carga otimizado para inferência: distribui solicitações para otimizar a performance de veiculação do modelo de IA. Ele usa métricas de servidores de modelos, como KVCache Utilization e queue length of pending requests, para usar aceleradores (como GPUs e TPUs) de maneira mais eficiente em cargas de trabalho de IA generativa.
  • Disponibilização de modelos ajustados dinâmicos de LoRA: oferece suporte à disponibilização de modelos ajustados dinâmicos de LoRA em um acelerador comum. Isso reduz o número de GPUs e TPUs necessárias para veicular modelos, multiplexando vários modelos LoRA refinados em um modelo de base e um acelerador comuns.
  • Escalonamento automático otimizado para inferência: o escalonador automático horizontal de pods (HPA) do GKE usa métricas do servidor de modelos para escalonar automaticamente, o que ajuda a garantir o uso eficiente de recursos de computação e a otimizar a performance de inferência.
  • Roteamento com reconhecimento de modelo: direciona solicitações de inferência com base nos nomes de modelo definidos nas especificações OpenAI API no cluster do GKE. É possível definir políticas de roteamento do gateway, como divisão de tráfego e espelhamento de solicitações, para gerenciar diferentes versões de modelos e simplificar os lançamentos. Por exemplo, é possível direcionar solicitações para um nome de modelo específico a diferentes objetos InferencePool, cada um atendendo a uma versão diferente do modelo.
  • Disponibilização específica do modelo Criticality: permite especificar a disponibilização Criticality de modelos de IA. Priorize solicitações sensíveis à latência em vez de jobs de inferência em lote tolerantes à latência. Por exemplo, é possível priorizar solicitações de aplicativos sensíveis à latência e descartar tarefas menos sensíveis ao tempo quando os recursos estão limitados.
  • Segurança de IA integrada: integra-se ao Trusted Cloud Model Armor, um serviço que aplica verificações de segurança de IA a comandos e respostas no gateway. O Model Armor fornece registros de solicitações, respostas e processamento para análise e otimização retrospectivas. As interfaces abertas do GKE Inference Gateway permitem que provedores e desenvolvedores terceirizados integrem serviços personalizados ao processo de solicitação de inferência.
  • Observabilidade de inferência: fornece métricas de observabilidade para solicitações de inferência, como taxa de solicitação, latência, erros e saturação. Monitore a performance e o comportamento dos seus serviços de inferência.

Entenda os principais conceitos

O GKE Inference Gateway aprimora o GKE Gateway atual, que usa objetos GatewayClass. O gateway de inferência do GKE apresenta as seguintes novas definições de recursos personalizados (CRDs) da API Gateway, alinhadas com a extensão da API Gateway do Kubernetes OSS para inferência:

  • Objeto InferencePool: representa um grupo de pods (contêineres) que compartilham a mesma configuração de computação, tipo de acelerador, modelo de linguagem de base e servidor de modelo. Isso agrupa e gerencia logicamente os recursos de serviço do modelo de IA. Um único objeto InferencePool pode abranger vários pods em diferentes nós do GKE e oferece escalonabilidade e alta disponibilidade.
  • Objeto InferenceModel: especifica o nome do modelo de serviço do InferencePool de acordo com a especificação OpenAI API. O objeto InferenceModel também especifica as propriedades de veiculação do modelo, como o Criticality do modelo de IA. O gateway de inferência do GKE dá preferência a cargas de trabalho classificadas como Critical. Isso permite multiplexar cargas de trabalho de IA sensíveis e tolerantes à latência em um cluster do GKE. Também é possível configurar o objeto InferenceModel para veicular modelos ajustados com LoRA.
  • Objeto TargetModel: especifica o nome do modelo de destino e o objeto InferencePool que atende ao modelo. Isso permite definir políticas de roteamento do gateway, como divisão de tráfego e espelhamento de solicitações, e simplificar os lançamentos de versões de modelos.

O diagrama a seguir ilustra o gateway de inferência do GKE e a integração dele com a segurança de IA, a capacidade de observação e a veiculação de modelos em um cluster do GKE.

A relação entre os objetos `InferencePool` e `InferenceModel` do GKE Inference Gateway
Figura: modelo de recurso do GKE Inference Gateway

O diagrama a seguir ilustra o modelo de recursos que se concentra em duas novas personas focadas em inferência e os recursos que elas gerenciam.

O modelo de recursos para personas focadas em inferência e os recursos delas
Figura: modelo de recurso do GKE Inference Gateway

Como funciona o gateway de inferência do GKE

O GKE Inference Gateway usa extensões da API Gateway e lógica de roteamento específica do modelo para processar solicitações de clientes a um modelo de IA. As etapas a seguir descrevem o fluxo de solicitação.

Como funciona o fluxo de solicitação

O GKE Inference Gateway encaminha solicitações do cliente da solicitação inicial para uma instância de modelo. Nesta seção, descrevemos como o GKE Inference Gateway processa solicitações. Esse fluxo de solicitação é comum para todos os clientes.

  1. O cliente envia uma solicitação, formatada conforme descrito na especificação da API do OpenAI, para o modelo em execução no GKE.
  2. O gateway de inferência do GKE processa a solicitação usando as seguintes extensões de inferência:
    1. Extensão de roteamento com base no corpo: extrai o identificador do modelo do corpo da solicitação do cliente e o envia para o gateway de inferência do GKE. Em seguida, o GKE Inference Gateway usa esse identificador para rotear a solicitação com base nas regras definidas no objeto HTTPRoute da API Gateway. O roteamento do corpo da solicitação é semelhante ao roteamento com base no caminho do URL. A diferença é que o roteamento do corpo da solicitação usa dados do corpo da solicitação.
    2. Extensão de segurança: usa o Model Armor ou soluções de terceiros compatíveis para aplicar políticas de segurança específicas do modelo que incluem filtragem de conteúdo, detecção de ameaças, limpeza e geração de registros. A extensão de segurança aplica essas políticas aos caminhos de processamento de solicitação e resposta. Isso permite que a extensão de segurança higienize e registre solicitações e respostas.
    3. Extensão do seletor de endpoints: monitora as principais métricas dos servidores de modelos no InferencePool. Ele rastreia a utilização do cache de valor-chave (KV-cache), o comprimento da fila de solicitações pendentes e os adaptadores LoRA ativos em cada servidor de modelo. Em seguida, ele encaminha a solicitação para a réplica do modelo ideal com base nessas métricas para minimizar a latência e maximizar a taxa de transferência para inferência de IA.
  3. O GKE Inference Gateway encaminha a solicitação para a réplica do modelo retornada pela extensão do seletor de endpoints.

O diagrama a seguir ilustra o fluxo de solicitação de um cliente para uma instância de modelo pelo GKE Inference Gateway.

O fluxo de solicitação de um cliente para uma instância de modelo pelo gateway de inferência do GKE
Figura: fluxo de solicitação do GKE Inference Gateway

Como funciona a distribuição de tráfego

O GKE Inference Gateway distribui dinamicamente as solicitações de inferência para servidores de modelo no objeto InferencePool. Isso ajuda a otimizar a utilização de recursos e manter o desempenho em condições de carga variadas. O GKE Inference Gateway usa os dois mecanismos a seguir para gerenciar a distribuição de tráfego:

  • Seleção de endpoint: seleciona dinamicamente o servidor de modelo mais adequado para processar uma solicitação de inferência. Ele monitora a carga e a disponibilidade do servidor e toma decisões de roteamento.

  • Enfileiramento e redução: gerencia o fluxo de solicitações e evita a sobrecarga de tráfego. O GKE Inference Gateway armazena as solicitações recebidas em uma fila, prioriza as solicitações com base em critérios definidos e descarta as solicitações quando o sistema está sobrecarregado.

O GKE Inference Gateway é compatível com os seguintes níveis de Criticality:

  • Critical: essas cargas de trabalho têm prioridade. O sistema garante que essas solicitações sejam atendidas mesmo em caso de restrições de recursos.
  • Standard: essas cargas de trabalho são atendidas quando os recursos estão disponíveis. Se os recursos forem limitados, essas solicitações serão descartadas.
  • Sheddable: essas cargas de trabalho são atendidas de forma oportunista. Se os recursos forem escassos, essas solicitações serão descartadas para proteger as cargas de trabalho do Critical.

Quando o sistema está sob pressão de recursos, as solicitações Standard e Sheddable são descartadas imediatamente com um código de erro 429 para proteger as cargas de trabalho Critical.

Inferência em streaming

O GKE Inference Gateway oferece suporte à inferência de streaming para aplicativos como chatbots e tradução simultânea, que exigem atualizações contínuas ou quase em tempo real. A inferência de streaming entrega respostas em partes ou segmentos incrementais, em vez de uma única saída completa. Se ocorrer um erro durante uma resposta de streaming, o stream será encerrado, e o cliente vai receber uma mensagem de erro. O gateway de inferência do GKE não repete respostas de streaming.

Conheça exemplos de aplicativos

Esta seção fornece exemplos para abordar vários cenários de aplicativos de IA generativa usando o GKE Inference Gateway.

Exemplo 1: disponibilizar vários modelos de IA generativa em um cluster do GKE

Uma empresa quer implantar vários modelos de linguagem grandes (LLMs) para atender a diferentes cargas de trabalho. Por exemplo, talvez eles queiram implantar um modelo Gemma3 para uma interface de chatbot e um modelo Deepseek para um aplicativo de recomendação. A empresa precisa garantir o desempenho ideal de veiculação para esses LLMs.

Com o GKE Inference Gateway, é possível implantar esses LLMs no cluster do GKE com a configuração de acelerador escolhida em um InferencePool. Em seguida, é possível encaminhar solicitações com base no nome do modelo (como chatbot e recommender) e na propriedade Criticality.

O diagrama a seguir ilustra como o GKE Inference Gateway roteia solicitações para diferentes modelos com base no nome do modelo e em Criticality.

Encaminhar solicitações para diferentes modelos com base no nome e na gravidade
Figura : exibição de vários modelos de IA generativa em um cluster do GKE usando o GKE Inference Gateway

Exemplo 2: veicular adaptadores LoRA em um acelerador compartilhado

Uma empresa quer veicular LLMs para análise de documentos e se concentra em públicos-alvo em vários idiomas, como inglês e espanhol. Eles têm modelos ajustados para cada idioma, mas precisam usar a capacidade de GPU e TPU de maneira eficiente. É possível usar o gateway de inferência do GKE para implantar adaptadores dinâmicos de ajuste refinado de LoRA para cada idioma (por exemplo, english-bot e spanish-bot) em um modelo de base comum (por exemplo, llm-base) e um acelerador. Isso permite reduzir o número de aceleradores necessários ao compactar vários modelos em um acelerador comum.

O diagrama a seguir ilustra como o GKE Inference Gateway atende a vários adaptadores LoRA em um acelerador compartilhado.

Como veicular vários adaptadores LoRA em um acelerador compartilhado
Figura: veiculação de adaptadores LoRA em um acelerador compartilhado

A seguir