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 solicitações de inferência.
  • 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 todos os servidores de inferência não estiverem hospedados no GKE, consulte Rede para disponibilização do modelo de inferência de IA em todos os back-ends. Este documento não fornece orientações sobre como projetar um aplicativo ou implantar um modelo de IA generativa individual. Para orientações sobre 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 Inference Gateway 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 aprimora o GKE Gateway para otimizar a maneira 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á as 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 prefixos. Nessa arquitetura, o aplicativo voltado ao cliente faz chamadas de API do 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 pela Internet.
    • Gerenciamento de APIs: um gerenciador de APIs fornece autenticação, segurança, limitação de taxa, acompanhamento de cotas e outros serviços de gerenciamento de APIs. Essa arquitetura usa a Apigee, mas também oferece suporte a outras opções. Para chamar a 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 da 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 de saída. Essa arquitetura usa o Model Armor para barreiras de proteção de IA, mas também oferece suporte a outras opções, como as barreiras de proteção do NVIDIA Nemo. A implantação do Terraform fornecida com essa 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 HTTPRoute pesquisa 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 modelo: uma réplica de modelo é uma cópia de um servidor de inferência implantado em uma ou mais GPUs ou TPUs. Uma réplica de modelo pode ser de nó único ou de vários nós. 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 for de vários nós, as GPUs se conectarão umas às outras por uma rede VPC RDMA de back-end. A rede fornece rede de baixa latência sem perdas entre GPUs alinhadas por rails.

Fluxo da solicitação

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

  1. Um usuário final envia uma solicitação de API do 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 do modelo de um dos servidores de inferência hospedados.
  2. O endpoint do Private Service Connect encaminha a solicitação para a versão do balanceador de carga de aplicativo interno regional 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 roteamento baseado no corpo.
  4. O gateway encaminha a solicitação para o sistema de gerenciamento de APIs para os serviços de gerenciamento de APIs necessários.
  5. O gateway envia o comando para o Model Armor para análise.
    • Se o comando contiver informações sensíveis que não podem ser editadas, ele será bloqueado e o Model Armor retornará uma resposta para indicar que uma violação de política foi encontrada.
    • Se o comando contiver informações sensíveis que podem ser editadas ou se não houver problemas, o Model Armor editará todas 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 um 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 ao Model Armor para aprovação ou rejeição.
  10. O gateway envia a resposta de volta ao endpoint do Private Service Connect e ao usuário final.

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

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 balanceia a 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 maneira. Por exemplo, um conjunto de réplicas pode ser hospedado na Vertex AI 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 carga mínima para escolher uma réplica no pool relevante.

Produtos usados

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

  • 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 de 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. 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 suas APIs são acessadas e usadas. Ela oferece segurança, limitação de taxa, aplicação de cotas e análises.
  • Model Armor: um serviço que oferece proteção para seus recursos de IA generativa e IA agêntica contra injeção de comando, vazamentos de dados sensíveis e conteúdo nocivo.

Alternativas de design

Esta seção descreve alternativas a algumas das suposições básicas dessa arquitetura.

Barreiras de proteção de IA

Recomendamos o uso do Model Armor para barreiras de proteção de IA. Para centralizar a administração, recomendamos que você o chame diretamente do balanceador de carga, como nesta arquitetura. Também é possível implementar o Model Armor destas maneiras alternativas:

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

Se você implementar barreiras de proteção de IA que não sejam no 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, poderá usar extensões de tráfego para implantar outras ofertas de barreiras de proteção, como as barreiras de proteção do NVIDIA NeMo.

Gerenciamento de APIs

A arquitetura neste documento usa a Apigee para gerenciamento de APIs, que é implantada usando uma extensão de serviço do balanceador de carga. Se a Apigee não atender às suas necessidades, você poderá usar as Service Extensions para implantar um serviço de gerenciamento de APIs diferente.

Se a implantação do gerenciamento de APIs usando Service Extensions não atender às suas necessidades, talvez seja necessário implantar uma rede voltada ao cliente e uma rede voltada à API. Nesse cenário, o serviço de gerenciamento de APIs 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 Cross-Cloud Network.

Considerações sobre o design

Ao criar a arquitetura para a carga de trabalho, considere as práticas recomendadas e as recomendações no 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ço IP à 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 a 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 o desempenho das solicitações de inferência do Inference Gateway usando o painel do Inference Gateway. O painel expõe 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 de disponibilização de modelos de inferência de IA disponível no GitHub.

A seguir

Colaboradores

Autor: Victor Moreno | Gerente de produtos, Cloud Networking

Outros colaboradores: