Rede para disponibilização de modelos de inferência de IA no GKE

Last reviewed 2026-05-20 UTC

Este documento fornece uma arquitetura de referência para criar um serviço de inferência de vários modelos usando o Google Kubernetes Engine (GKE). Na arquitetura, os pools de inferência hospedados no GKE são colocados atrás de um GKE Inference Gateway. Essa arquitetura oferece os seguintes benefícios:

  • Uma única interface para todas as suas solicitações de inferência.
  • O roteamento inteligente para cada solicitação ao modelo e ao servidor de inferência que pode processá-la com mais eficiência.
  • Autorização, segurança e outros serviços centralizados.

Este documento é destinado a arquitetos de rede responsáveis por unificar a implantação de servidores de inferência executados no GKE. Se nem todos os servidores de inferência estiverem hospedados no GKE, consulte Redes para disponibilização de modelos de inferência de IA em todos os back-ends. Neste documento, não fornecemos orientações sobre como projetar um aplicativo ou implantar um modelo de IA generativa individual. Para saber como implantar um modelo, consulte Criar e implantar modelos de IA generativa e de machine learning em uma empresa.

Essa arquitetura funciona com arquiteturas de rede de aplicativos Cross-Cloud Network para aplicativos distribuídos e outros designs.

Arquitetura

O diagrama a seguir mostra uma arquitetura que contém um Gateway de inferência na frente dos servidores de inferência hospedados no GKE. O gateway fornece serviços consolidados para todos os modelos hospedados.

Visão geral de alto nível da rede para inferência de IA.

A arquitetura no diagrama inclui os seguintes componentes:

  • Endpoint de inferência do Private Service Connect: um endpoint unificado para todos os modelos hospedados. O usuário final envia solicitações de inferência para o endereço IP do endpoint. O diagrama mostra um endpoint do Private Service Connect em uma única rede de nuvem privada virtual (VPC) do consumidor. É possível hospedar endpoints em várias redes VPC ou em uma rede VPC de serviços compartilhados.
  • Inference Gateway: o Inference Gateway melhora o GKE Gateway para otimizar a forma como o GKE disponibiliza aplicativos e cargas de trabalho de IA generativa. Ele roteia o tráfego para pools de inferência de réplicas de modelo com base no nome do modelo. O gateway usa a correspondência de prefixo para rotear o tráfego no pool de réplicas. Se não houver uma correspondência de prefixo, o processador de inferência do gateway usará métricas do Prometheus de GPU ou TPU para escolher a réplica menos carregada no pool. O processador de inferência também processa o armazenamento em cache de prefixo. Nessa arquitetura, o aplicativo voltado ao cliente faz chamadas da API OpenAI para acessar os modelos pelo gateway. O gateway é implantado com base em um balanceador de carga de aplicativo interno regional (gke-l7-rilb), portanto, não é acessível diretamente da Internet.
    • Gerenciamento de API: um gerenciador de API oferece autenticação, segurança, limitação de taxa, rastreamento de cota e outros serviços de gerenciamento de API. Essa arquitetura usa o Apigee, mas é compatível com outras opções. Para chamar o Apigee do balanceador de carga, a arquitetura e a implantação do Terraform usam uma extensão de tráfego do Service Extensions para chamar o processador de extensões do Apigee.
    • Model Armor: um sistema de barreiras de proteção de IA que realiza verificações de segurança em comandos de inferência antes que eles cheguem ao servidor de inferência. Em seguida, ele realiza verificações de segurança nas respostas enviadas. Essa arquitetura usa o Model Armor para guardrails de IA, mas também é compatível com outras opções, como os guardrails do NVIDIA Nemo. A implantação do Terraform fornecida com esta arquitetura de referência inclui uma configuração básica do Model Armor.
  • Pools de inferência: um pool de inferência contém réplicas do mesmo modelo. Quando o gateway recebe um comando, ele usa uma pesquisa HTTPRoute para selecionar um pool de inferência com base no identificador do modelo. Os pools têm um tamanho inicial, mas podem ser configurados para escalonamento automático.
  • Conjuntos de réplicas de modelos: uma réplica de modelo é uma cópia de um servidor de inferência implantada em uma ou mais GPUs ou TPUs. Uma réplica de modelo pode ser de nó único ou multinó. Um conjunto de réplicas é um grupo uniforme de réplicas de modelo que é apresentado por um balanceador de carga. Se o conjunto de réplicas tiver vários nós, as GPUs vão se conectar entre si por uma rede VPC RDMA de back-end. A rede oferece rede inter-GPU sem perdas e de baixa latência alinhada por rails.

Fluxo da solicitação

O sistema encaminha as solicitações de inferência da seguinte maneira:

  1. Um usuário final envia uma solicitação de API OpenAI para o endpoint do Private Service Connect. Essa solicitação contém o seguinte:
    • O comando.
    • O nome do modelo, que precisa corresponder ao nome de um dos servidores de inferência hospedados.
  2. O endpoint do Private Service Connect encaminha a solicitação para a versão regional interna do balanceador de carga de aplicativo do Inference Gateway.
  3. O gateway extrai o nome do modelo do corpo da solicitação e o injeta no cabeçalho da solicitação usando o roteamento com base no corpo.
  4. O gateway encaminha a solicitação para o sistema de gerenciamento de APIs para serviços de gerenciamento de APIs necessários.
  5. O gateway envia o comando para o Model Armor para triagem.
    • Se o comando contiver informações sensíveis que não podem ser ocultadas, ele será bloqueado, e o Model Armor vai retornar uma resposta indicando que uma violação da política foi encontrada.
    • Se o comando contiver informações sensíveis que podem ser ocultadas ou se não houver problemas, o Model Armor vai ocultar as informações sensíveis e encaminhar o comando.
  6. O gateway consulta HTTPRoute para uma lista de pools de inferência que correspondem ao modelo da solicitação. Nessa lista, o gateway escolhe uma opção com base em uma prioridade.
  7. O gateway consulta o cache de prefixo e a carga atual de todas as réplicas no pool e usa essas informações para escolher uma réplica.
  8. A réplica processa a solicitação e a envia de volta ao gateway.
  9. O gateway envia a resposta para o Model Armor para aprovação ou rejeição.
  10. O gateway envia a resposta de volta para o endpoint do Private Service Connect e para o usuário final.

O diagrama a seguir mostra uma visualização de roteamento de uma implantação de exemplo.

Fluxo de comandos para amostrar conjuntos de réplicas.

Neste exemplo, os comandos são processados dependendo do modelo selecionado pelo usuário:

  • Llama: o sistema faz o balanceamento de carga desses comandos em uma proporção de 90/10 entre dois conjuntos de réplicas que hospedam o modelo Llama. Esses dois conjuntos de réplicas não precisam ser hospedados da mesma forma. Por exemplo, um conjunto de réplicas pode ser hospedado na Gemini Enterprise Agent Platform e o outro no GKE.
  • LoRA-1-gemma ou LoRA-2-gemma: o sistema envia todos os comandos para o mesmo conjunto de réplicas, que pode processar os dois modelos.

Em todos os casos, o gateway usa uma combinação de correspondência de prefixo e menor carga para escolher uma réplica no pool relevante.

Produtos usados

Esta arquitetura de referência usa os seguintes produtos do Google Cloud:

  • Google Kubernetes Engine (GKE): um serviço do Kubernetes que pode ser usado para implantar e operar aplicativos conteinerizados em escala usando a infraestrutura do Google.
  • GKE Inference Gateway: uma extensão do Google Kubernetes Engine Gateway que oferece roteamento e balanceamento de carga otimizados para disponibilizar cargas de trabalho de IA generativa. Ele simplifica a implantação, o gerenciamento e a observabilidade das cargas de trabalho de inferência de IA.
  • Nuvem privada virtual (VPC): um sistema virtual que oferece funcionalidade de rede global e escalonável para suas cargas de trabalho do Google Cloud . A VPC inclui peering de rede VPC, Private Service Connect, acesso a serviços particulares e VPC compartilhada.
  • Private Service Connect: um recurso que permite que os consumidores acessem serviços gerenciados de maneira particular na rede VPC deles.
  • Cloud Run: uma plataforma de computação sem servidor que permite executar contêineres diretamente na infraestrutura escalonável do Google.
  • Apigee: uma ferramenta de gerenciamento de APIs que oferece controle granular sobre como as APIs são acessadas e usadas. Ele oferece segurança, limitação de taxa, aplicação de cotas e análises.
  • Model Armor: um serviço que protege seus recursos de IA generativa e baseada em agentes contra injeção de comandos, vazamentos de dados sensíveis e conteúdo prejudicial.

Alternativas de design

Nesta seção, descrevemos alternativas a algumas das proposições básicas desta arquitetura.

Barreiras de proteção de IA

Recomendamos o uso do Model Armor para proteções de IA. Para centralizar a administração, recomendamos que você o chame diretamente do balanceador de carga, como nesta arquitetura. Você também pode implementar o Model Armor destas outras maneiras:

  • Use uma política de gerenciamento de API para chamar o Model Armor.
  • Implante o Model Armor somente na réplica.

Se você implementar proteções de IA em outro lugar que não seja o endpoint do modelo, poderá desativar o Model Armor no balanceador de carga de front-end se não precisar dele. Se você não quiser usar o Model Armor, use as extensões de tráfego para implantar outras opções de proteção, como o NVIDIA NeMo Guardrails (em inglês).

Gerenciamento de APIs

A arquitetura neste documento usa o Apigee para gerenciamento de APIs, que é implantado usando uma extensão de serviço de balanceador de carga. Se a Apigee não atender às suas necessidades, use as Service Extensions para implantar outro serviço de gerenciamento de API.

Se a implantação do gerenciamento de API usando Service Extensions não atender às suas necessidades, talvez seja necessário implantar uma rede voltada para o cliente e outra voltada para a API. Nesse cenário, o serviço de gerenciamento de API atua como uma ponte entre as duas redes. Para informações sobre como implantar isso na Apigee, consulte Opções de rede da Apigee.

Como se conectar a outras redes

A arquitetura neste documento usa uma única rede VPC do consumidor. No entanto, é possível compartilhar o endpoint do Private Service Connect com muitas outras redes usando uma rede VPC de acesso a serviços em uma implantação de rede Cross-Cloud Network.

Considerações sobre o design

Ao criar a arquitetura para sua carga de trabalho, considere as práticas recomendadas e as recomendações do Google Cloud Well-Architected Framework.

segurança, privacidade e conformidade

Para adicionar proteção contra ataques distribuídos de negação de serviço (DDoS), funcionalidade de firewall de aplicativos da Web (WAF) e inspeção de endereços IP à sua implantação, adicione o Google Cloud Armor ao balanceador de carga de aplicativo interno regional de front-end.

Confiabilidade

Para se proteger contra falhas regionais, replique sua implantação em uma segunda região usando o Google Cloud arquétipo de implantação multirregional.

Otimização de custos

Para recomendações de otimização de custos do GKE, consulte Práticas recomendadas para executar aplicativos do Kubernetes otimizados para custo no GKE.

Eficiência operacional

Monitore a performance das solicitações de inferência do Inference Gateway usando o painel do Inference Gateway. O painel mostra erros e métricas como taxa de solicitação, latência e saturação. Use as descobertas no painel para otimizar sua implantação.

Otimização de desempenho

Siga as recomendações em Visão geral das práticas recomendadas de inferência no GKE.

Implantação

Para implantar um exemplo de implementação dessa arquitetura, use o exemplo de código Redes para serviços de modelo de inferência de IA disponível no GitHub.

A seguir

Colaboradores

Autor: Victor Moreno | Gerente de produtos, Cloud Networking

Outros colaboradores: