Sobre o GKE Inference Gateway com tecnologia llm-d

Nesta página, explicamos os principais conceitos e recursos do GKE Inference Gateway, uma extensão do GKE Gateway para disponibilização otimizada de aplicativos de IA generativa.

Esta página pressupõe que você tenha conhecimento sobre o seguinte:

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

Esta página é destinada às seguintes pessoas:

• 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 disponibilizar cargas de trabalho de IA/ML.
• Arquitetos de nuvem e especialistas em redes que interagem com a rede 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 observabilidade de cargas de trabalho de inferência de IA. O GKE Inference Gateway está disponível sem custo adicional. Você paga apenas pelos recursos subjacentes Cloud de Confiance by S3NS usados.

Para escolher a estratégia de balanceamento de carga ideal 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 de 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 modelo, como KV cache hits e o queue length of pending requests para consumir aceleradores (como GPUs e TPUs) com mais eficiência para cargas de trabalho de IA generativa. Isso permite o roteamento com reconhecimento de prefixo-cache, um recurso essencial 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 muito os cálculos redundantes e melhora o tempo até o primeiro token, tornando-o altamente eficaz para IA de conversação, geração aumentada por recuperação (RAG) e outras cargas de trabalho de IA generativa baseadas em modelo.
• Disponibilização de modelo ajustado dinâmico LoRA: oferece suporte à disponibilização de modelos ajustados dinâmicos LoRA em um acelerador comum. Isso reduz o número de GPUs e TPUs necessárias para disponibilizar modelos, multiplexando vários modelos ajustados LoRA em um modelo base e acelerador comuns.
• Escalonamento automático otimizado para inferência: o escalonador automático de pods horizontal (HPA, na sigla em inglês) do GKE usa métricas do servidor de modelo paraescalonar automaticamente, o que ajuda a garantir o uso eficiente de recursos de computação e a performance de inferência otimizada.
• Roteamento com reconhecimento de modelo: encaminha solicitações de inferência com base nos nomes de modelo definidos nas OpenAI API especificações 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 modelo e simplificar os lançamentos de modelo. Por exemplo, é possível encaminhar solicitações para um nome de modelo específico para diferentes objetos InferencePool, cada um disponibilizando uma versão diferente do modelo. Para mais informações sobre como configurar isso, consulte Configurar o roteamento baseado no corpo da solicitação.
• Segurança de IA integrada e filtragem de conteúdo: o GKE Inference Gateway se integra ao Cloud de Confiance Model Armor para aplicar verificações de segurança de IA e filtragem de conteúdo a comandos e respostas no gateway. Também é possível usar o NVIDIA NeMo Guardrails. 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 relação a 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 restritos.
• Roteamento baseado em latência prevista: encaminha 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 preciso do que 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 serviços de inferência usando o Cloud Monitoring e o Cloud Logging, aproveitando painéis pré-criados especializados para insights detalhados. Para mais informações, consulte Conferir o painel do GKE Inference Gateway.
• Configuração do CORS: oferece suporte ao compartilhamento de recursos entre origens (CORS, na sigla em inglês) em recursos HTTPRoute. O CORS ajuda aplicativos da Web executados em domínios diferentes a acessar com segurança seus endpoints de inferência. O CORS é compatível com gateways de cluster único.
• Gerenciamento avançado de APIs com a Apigee: integra-se à Apigee para melhorar o gateway de inferência com recursos como segurança de API, limitação de taxa e cotas. Para instruções detalhadas, consulte Configurar a Apigee para autenticação e gerenciamento de API s.
• Extensibilidade: criado em uma extensão de inferência da API Kubernetes Gateway extensível e de código aberto que oferece suporte a um algoritmo de seleção de endpoint (EPP) llm-d gerenciado pelo usuário, com tecnologia llm-d. O algoritmo llm-d Endpoint Picker (EPP), com tecnologia llm-d, fornece a inteligência de roteamento principal para essa extensão.
• Suporte a várias portas: oferece suporte a servidores de modelo que expõem várias portas, o que é essencial para cenários de disponibilização avançados como a atenção paralela de dados.
• Limites do grupo de endpoints de rede (NEG): tem um limite de 50 NEGs por Cloud de Confiance by S3NS 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 desse tipo 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 aprimora o GKE Gateway atual que usa GatewayClass objetos. O GKE Inference Gateway apresenta as seguintes novas definições de recursos personalizados (CRDs, na sigla em inglês) da API Gateway, alinhadas à extensão da API Kubernetes Gateway de código aberto 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 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 escalonabilidade e alta disponibilidade. É possível especificar até oito targetPorts em um recurso InferencePool para oferecer suporte a servidores de modelo que exigem várias portas.
• Objeto InferenceObjective: especifica o nome do modelo de disponibilizaçã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 a Priority do modelo de IA. O GKE Inference Gateway dá preferência a cargas de trabalho com um valor de prioridade maior. Isso permite multiplexar cargas de trabalho de IA sensíveis à latência e tolerantes à latência em um cluster do GKE. Também é possível configurar o objeto InferenceObjective para disponibilizar modelos ajustados 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 recurso que se concentra em duas novas personas focadas em inferência e nos recursos que elas gerenciam.

llm-d Router

O llm-d Router é o componente de roteamento de solicitações inteligente que o Inference Gateway usa para tomar decisões de endpoint por solicitação. Ele é composto por 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, em seguida, encaminha a solicitação diretamente para o pod do servidor de modelo selecionado.

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

• Infraestrutura compartilhada: um único GKE Gateway disponibiliza vários InferencePools junto com os serviços padrão do Kubernetes.
• Gerenciamento avançado de tráfego: HTTPRoute políticas oferecem suporte à 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 para um modelo de IA. As etapas a seguir descrevem o fluxo de solicitações.

Como o fluxo de solicitações funciona

O GKE Inference Gateway encaminha solicitações de clientes da solicitação inicial para uma instância de modelo. Esta seção descreve como o GKE Inference Gateway processa solicitações. Esse fluxo de solicitações é comum a todos os clientes.

1. O cliente envia uma solicitação, formatada conforme descrito na OpenAI API especificação, 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 baseado no corpo da solicitação: extrai o identificador do modelo do corpo da solicitação do cliente e o envia para o GKE Inference Gateway. O GKE Inference Gateway usa esse identificador para encaminhar a solicitação com base nas regras definidas no objeto HTTPRoute da API Gateway. O roteamento do corpo da solicitação é semelhante ao roteamento baseado 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, higienização e registro. A extensão de segurança aplica essas políticas aos caminhos de processamento de solicitação e resposta.
   3. llm-d Endpoint Picker (EPP): monitora as principais métricas dos servidores de modelo no InferencePool e encaminha a solicitação para a réplica de modelo ideal. 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 endpoint.

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

Como a distribuição de tráfego funciona

O GKE Inference Gateway distribui dinamicamente solicitações de inferência para servidores de modelo no objeto InferencePool. Isso ajuda a otimizar a utilização de recursos e mantém a performance em condições de carga variáveis. 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, em seguida, toma decisões de roteamento ideais calculando uma score para cada servidor, combinando várias heurísticas de otimização:

  • Roteamento com reconhecimento de prefixo-cache: o GKE Inference Gateway rastreia os índices de prefixo-cache disponíveis em cada servidor de modelo e atribui uma pontuação maior a um servidor com uma correspondência de prefixo-cache mais longa.
  • Roteamento com reconhecimento de carga: o GKE Inference Gateway monitora a carga do servidor (utilização de cache KV e profundidade da fila pendente) e atribui uma pontuação maior a um servidor com carga menor.
  • Roteamento com reconhecimento de LoRA: quando a disponibilização dinâmica de LoRA está ativada, o GKE Inference Gateway monitora os adaptadores LoRA ativos por servidor e atribui uma pontuação maior 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 anteriores é escolhido.

• Enfileiramento e descarte: 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 as solicitações 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. Essa Priority é um campo inteiro opcional definido pelo usuário para cada InferenceObjective. Um valor maior significa uma solicitação mais importante. Quando o sistema está sob pressão, as solicitações com uma 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, a Priority é 0. As solicitações só são descartadas devido à prioridade se a Priority estiver definida explicitamente como um valor menor que 0. Esse sistema permite priorizar o tráfego de inferência on-line sensível à latência em relação a 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 ao vivo, 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 fluxo será encerrado e o cliente receberá uma mensagem de erro. O GKE Inference Gateway não tenta novamente respostas de streaming.

Conheça exemplos de aplicativos

Esta seção fornece exemplos de como usar o GKE Inference Gateway para abordar 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 disponibilizar diferentes cargas de trabalho. Por exemplo, eles podem querer implantar um modelo Gemma3 para uma interface de chatbot e um modelo DeepSeek para um aplicativo de recomendação. A empresa precisa garantir a performance de disponibilização ideal para esses LLMs.

Usando 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 Priority.

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

Este diagrama ilustra como uma solicitação para um serviço GenAI em example.com/completions é processada pelo GKE Inference Gateway. A solicitação primeiro atinge um Gateway no namespace Infra. Esse Gateway encaminha a solicitação para um HTTPRoute no namespace GenAI Inference, que está configurado para processar solicitações de modelos de chatbot e sentimento. Para o modelo de chatbot, o HTTPRoute divide o tráfego: 90% é direcionado para um InferencePool que executa a versão atual do modelo (selecionada por {pool: gemma}) e 10% vai para um pool com uma versão mais recente ({pool: gemma-new}), normalmente para testes canary. Os dois pools estão vinculados a um InferenceObjective que atribui uma Priority de 10 a solicitações para o modelo de chatbot, garantindo que essas solicitações 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 em vários idiomas, como inglês e espanhol. Eles têm modelos ajustados para cada idioma, mas precisam usar com eficiência a capacidade de GPU e TPU. É possível usar o GKE Inference Gateway para implantar adaptadores ajustados dinâmicos LoRA para cada idioma (por exemplo, english-bot e spanish-bot) em um modelo base comum (por exemplo, llm-base) e acelerador. Isso permite reduzir o número de aceleradores necessários, compactando vários modelos em um acelerador comum.

O diagrama a seguir ilustra como o GKE Inference Gateway disponibiliza 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)