Sobre o GKE Inference Gateway com tecnologia llm-d

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:

• Orquestração de IA/ML no GKE
• Terminologia da IA generativa
• Conceitos de rede do GKE, incluindo serviços e a API GKE Gateway
• Balanceamento de carga em Google Cloud, especialmente como os balanceadores de carga interagem com o GKE

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 GKE Inference Gateway é uma extensão do GKE Gateway 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.

Para escolher a estratégia ideal de balanceamento de carga para suas cargas de trabalho de IA/ML, consulte Escolher uma estratégia de balanceamento de carga para inferência de IA no GKE.

Recursos e benefícios

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

• Métricas compatíveis:
  • KV cache hits: o número de pesquisas bem-sucedidas no cache de chave-valor (KV).
  • Utilização da GPU ou TPU: a porcentagem de tempo em que a GPU ou TPU está processando ativamente.
  • Comprimento da fila de solicitações: o número de solicitações aguardando processamento.
• Balanceamento de carga otimizado para inferência: distribui solicitações para otimizar a performance de disponibilização do modelo de IA. Ele usa métricas de servidores de modelos, como KV cache hits e queue length of pending requests, para consumir aceleradores (como GPUs e TPUs) de maneira mais eficiente para cargas de trabalho de IA generativa. Isso ativa o roteamento com reconhecimento de prefixo e cache, um recurso fundamental que envia solicitações com contexto compartilhado, identificado pela análise do corpo da solicitação, para a mesma réplica do modelo, maximizando os acertos de cache. Essa abordagem reduz drasticamente os cálculos redundantes e melhora o tempo até o primeiro token, tornando-a altamente eficaz para IA de conversação, geração aumentada por recuperação (RAG) e outras cargas de trabalho de IA generativa baseadas em modelos.
• Disponibilização de modelos dinâmicos de LoRA com ajuste refinado: permite disponibilizar modelos dinâmicos de LoRA com ajuste refinado em um acelerador comum. Isso reduz o número de GPUs e TPUs necessárias para disponibilizar modelos, multiplexando vários modelos LoRA refinados em um modelo base e acelerador comuns.
• Escalonamento automático otimizado para inferência: o Autoescalonador Horizontal de Pods (HPA) do GKE usa métricas do servidor de modelo 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: roteia 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 de gateway, como divisão de tráfego e espelhamento de solicitações, para gerenciar diferentes versões de modelos e simplificar os rollouts. Por exemplo, é possível encaminhar solicitações para um nome de modelo específico a diferentes objetos InferencePool, cada um atendendo a uma versão diferente do modelo. Para mais informações sobre como configurar isso, consulte Configurar o roteamento com base no corpo.
• Segurança de IA e filtragem de conteúdo integradas: o GKE Inference Gateway se integra ao Model Armor para aplicar verificações de segurança de IA e filtragem de conteúdo a comandos e respostas no gateway. Google CloudVocê também pode usar os NeMo Guardrails da NVIDIA. 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 de terceiros integrem serviços personalizados ao processo de solicitação de inferência.
• Disponibilização específica do modelo Priority: permite especificar a disponibilização Priority 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.
• Roteamento predito com base na latência: roteia solicitações de inferência usando um modelo XGBoost treinado continuamente no tráfego em tempo real, otimizando os objetivos de tempo até o primeiro token (TTFT) e tempo por token de saída (TPOT) por solicitação. Mais precisão do que as heurísticas estáticas em cargas de trabalho de alta variância. Consulte Usar o roteamento baseado em latência prevista com o GKE Inference Gateway.
• 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 com o Cloud Monitoring e o Cloud Logging, aproveitando painéis pré-criados especializados para insights detalhados. Para mais informações, consulte Ver o painel do GKE Inference Gateway.
• Gerenciamento avançado de APIs com a Apigee: integra-se à Apigee para aprimorar seu gateway de inferência com recursos como segurança de API, limitação de taxa e cotas. Para instruções detalhadas, consulte Configurar o Apigee para autenticação e gerenciamento de API.
• Extensibilidade: criado com base em uma extensão de inferência da API Gateway do Kubernetes extensível e de código aberto que oferece suporte a um algoritmo de seleção de endpoints (EPP) llm-d gerenciado pelo usuário, com tecnologia llm-d. O algoritmo llm-d Endpoint Picker (EPP), desenvolvido por llm-d, fornece a inteligência de roteamento principal para essa extensão.
• Suporte a várias portas: oferece suporte a servidores de modelos que expõem várias portas, o que é essencial para cenários avançados de veiculação, como a atenção paralela de dados.
• Limites de grupos de endpoints de rede (NEGs): há um limite de 50 NEGs por Google Cloud serviço de back-end. Ao usar um InferencePool de várias portas, cada porta em cada zona cria um NEG dedicado. Por exemplo, um InferencePool com oito portas em um cluster regional típico (três zonas) gera 24 NEGs. Portanto, um gateway de vários clusters só pode agregar um InferencePool de um máximo de dois clusters (dois clusters × 24 NEGs = 48 NEGs) antes de atingir o limite de 50 NEGs.

Entenda os principais conceitos

O GKE Inference Gateway melhora o GKE Gateway atual, que usa objetos GatewayClass. O GKE Inference Gateway 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 disponibilização do modelo de IA. Um único objeto InferencePool pode abranger vários pods em diferentes nós do GKE e oferece escalabilidade e alta disponibilidade. É possível especificar até oito targetPorts em um recurso InferencePool para oferecer suporte a servidores de modelos que exigem várias portas.
• Objeto InferenceObjective: especifica o nome do modelo de serviço do InferencePool de acordo com a especificação OpenAI API. O objeto InferenceObjective também especifica as propriedades de disponibilização do modelo, como o Priority do modelo de IA. O GKE Inference Gateway dá preferência a cargas de trabalho com um valor de prioridade mais alto. 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 InferenceObjective para disponibilizar modelos ajustados com LoRA.

O diagrama a seguir ilustra o GKE Inference Gateway e a integração dele com segurança de IA, observabilidade e disponibilização de modelos em um cluster do GKE.

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.

Roteador llm-d

O roteador llm-d é o componente inteligente de roteamento de solicitações que o Inference Gateway usa para tomar decisões de endpoint por solicitação. Ele é composto de dois subcomponentes:

Modo de gateway

O GKE Inference Gateway é o llm-d Router que opera no modo de gateway. No modo de gateway, o proxy é um gateway formal do Kubernetes provisionado e gerenciado separadamente do serviço EPP. O gateway chama o EPP por ext-proc para tomar decisões de roteamento e encaminha a solicitação diretamente para o pod do servidor do modelo selecionado.

Essa separação do gateway (plano de dados) do EPP (inteligência de roteamento) permite:

• Infraestrutura compartilhada: um único gateway do GKE atende a vários InferencePools junto com os serviços padrão do Kubernetes.
• Gerenciamento avançado de tráfego: as políticas de HTTPRoute oferecem suporte a divisão ponderada, lançamentos graduais e espelhamento de solicitações.
• Escalonamento independente: o serviço EPP é escalonado de forma independente do gateway.
• Integração nativa da nuvem: funciona com o controlador de gateway gerenciado do GKE, o Cloud Load Balancing e as ferramentas de observabilidade atuais.

Como o GKE Inference Gateway funciona

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 de clientes 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 OpenAI, para o modelo em execução no GKE.

2. O GKE Inference Gateway 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 GKE Inference Gateway. 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, o NVIDIA NeMo Guardrails 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.
   3. Seletor de endpoints (EPP) llm-d: monitora as principais métricas dos servidores de modelos no InferencePool e encaminha a solicitação para a réplica ideal do modelo. Para mais informações, consulte llm-d Router.

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.

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 a performance em diferentes condições de carga. 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 ideais calculando um score para cada servidor, combinando várias heurísticas de otimização:

  • Roteamento com reconhecimento de cache de prefixo: o GKE Inference Gateway rastreia os índices de cache de prefixo disponíveis em cada servidor de modelo e atribui uma pontuação mais alta a um servidor com uma correspondência de cache de prefixo mais longa.
  • Roteamento com reconhecimento de carga: o GKE Inference Gateway monitora a carga do servidor (utilização do cache KV e profundidade da fila pendente) e atribui uma pontuação mais alta a um servidor com carga menor.
  • Roteamento com reconhecimento de LoRA: quando o serviço dinâmico de LoRA está ativado, o GKE Inference Gateway monitora os adaptadores LoRA ativos por servidor e atribui uma pontuação mais alta a um servidor com o adaptador LoRA solicitado ativo ou espaço adicional para carregar dinamicamente o adaptador LoRA solicitado. Um servidor com a maior pontuação total de todos os itens anteriores é escolhido.

• 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 e prioriza com base na prioridade definida.

O GKE Inference Gateway usa um sistema numérico Priority, também conhecido como Criticality, para gerenciar o fluxo de solicitações e evitar sobrecarga. Esse Priority é um campo inteiro opcional definido pelo usuário para cada InferenceObjective. Um valor mais alto significa uma solicitação mais importante. Quando o sistema está sob pressão, as solicitações com um Priority menor que 0 são consideradas de menor prioridade e são descartadas primeiro, retornando um erro 429 para proteger cargas de trabalho mais críticas. Por padrão, o Priority é 0. As solicitações só serão descartadas devido à prioridade se o Priority delas for definido explicitamente como um valor menor que 0. Esse sistema permite priorizar o tráfego de inferência on-line sensível à latência em vez de jobs em lote menos sensíveis ao tempo.

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 GKE Inference Gateway não tenta novamente as respostas de streaming.

Conheça exemplos de aplicativos

Nesta seção, apresentamos exemplos de como usar o GKE Inference Gateway para resolver vários cenários de aplicativos de IA generativa.

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 rotear solicitações com base no nome do modelo (como chatbot e recommender) e na propriedade Priority.

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

Este diagrama ilustra como uma solicitação para um serviço de IA generativa em example.com/completions é processada pelo GKE Inference Gateway. A solicitação primeiro chega a um Gateway no namespace Infra. Esse Gateway encaminha a solicitação para um HTTPRoute no namespace GenAI Inference, que é configurado para processar solicitações de modelos de chatbot e de sentimentos. Para o modelo de chatbot, o HTTPRoute divide o tráfego: 90% são direcionados a um InferencePool que executa a versão atual do modelo (selecionada por {pool: gemma}), e 10% vão para um pool com uma versão mais recente ({pool: gemma-new}), geralmente para testes canário. Os dois pools estão vinculados a um InferenceObjective que atribui um Priority de 10 a solicitações do modelo de chatbot, garantindo que elas sejam tratadas como de alta prioridade.

Exemplo 2: disponibilizar adaptadores LoRA em um acelerador compartilhado

Uma empresa quer disponibilizar 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 com eficiência. É possível usar o GKE Inference Gateway 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 agrupar 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.

A seguir

• Implantar o GKE Inference Gateway
• Personalizar a configuração do GKE Inference Gateway
• Disponibilizar um LLM com o GKE Inference Gateway
• Usar o roteamento baseado em latência prevista com o GKE Inference Gateway(prévia)