Rede para disponibilização de modelos de inferência de IA em todos os back-ends

Last reviewed 2026-05-20 UTC

Este documento fornece uma arquitetura de referência para criar um front-end unificado para vários modelos de IA hospedados no local ou por qualquer provedor, incluindo terceiros e Google Cloud. Se todos os servidores de inferência estiverem hospedados no Google Kubernetes Engine (GKE), consulte Rede para disponibilização de modelos de inferência de IA no GKE.

Essa arquitetura foi projetada para permitir que os desenvolvedores selecionem modelos sem precisar especificar endereços IP individuais para cada um. Em vez disso, os desenvolvedores enviam solicitações da API OpenAI que incluem o nome do modelo para o endpoint do front-end. O sistema na arquitetura encaminha as solicitações para o back-end que hospeda o modelo especificado. O balanceador de carga de front-end na arquitetura fornece as seguintes funções administrativas centralizadas:

  • Endpoint de front-end único para todas as chamadas de modelo, independentemente de como você hospeda os modelos.
  • Funcionalidade de gerenciamento de APIs.
  • Ponto de verificação para proteções de IA.
  • Service Extensions ponto de inserção para extensibilidade futura.

Este documento é destinado a administradores de rede e de aplicativos de IA generativa que querem colocar modelos de IA generativa novos ou atuais atrás de um único endpoint de inferência. 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, como Cross-Cloud Network para aplicativos distribuídos aplicativos e com outros designs.

Arquitetura

O diagrama a seguir mostra uma arquitetura com um endpoint em uma rede de consumidor que aponta para um front-end do balanceador de carga de aplicativo interno regional. Esse balanceador de carga usa o nome do modelo especificado para encaminhar solicitações a conjuntos de réplicas de modelo hospedados no local ou por qualquer provedor. O balanceador de carga de front-end 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.
  • Balanceador de carga de aplicativo interno regional: nessa arquitetura, o balanceador de carga de front-end é um balanceador de carga de aplicativo interno regional. O balanceador de carga de front-end encaminha o tráfego para pools de réplicas com base no nome do modelo especificado na solicitação. Nessa arquitetura, o aplicativo do cliente faz chamadas da API OpenAI para o balanceador de carga. Se o servidor de inferência de back-end for compatível com a API OpenAI, as coisas funcionarão de maneira transparente. Se o servidor de inferência não for compatível com a API OpenAI, você precisará implementar um tradutor de API usando Service Extensions. Essa arquitetura de referência não inclui a implementação de um tradutor de API.
  • Service Extensions callouts: é possível usar chamadas para adicionar mais processamento a um balanceador de carga de aplicativo. A arquitetura neste design usa as seguintes chamadas:
    • **Roteador baseado no corpo**: o roteador baseado no corpo é implantado no Cloud Run. Ele lê o nome do modelo no corpo da solicitação de API OpenAI e o grava em um campo X-Gateway-Model-Name no cabeçalho. O mapa de URL do balanceador de carga usa o campo para encaminhar a solicitação ao serviço de back-end apropriado. A implantação do Terraform fornecida com essa arquitetura de referência inclui a configuração do roteador baseado no corpo.
    • Apigee: um gerenciador de APIs que 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 proteções 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 proteções de IA, mas ela também oferece suporte a outras opções, como NVIDIA NeMo Guardrails. A implantação do Terraform fornecida com essa arquitetura de referência inclui uma configuração básica do Model Armor.
  • Serviços de back-end: o balanceador de carga encaminha solicitações para serviços de back-end com base no nome do modelo na solicitação. O serviço de back-end contém um grupo de endpoints de rede (NEG).
  • 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. Na arquitetura, as réplicas de modelo estão contidas em um cluster do Google Kubernetes Engine (GKE) atrás de um GKE Inference Gateway, na Vertex AI, no Cloud Run, em um data center local ou de outra nuvem e atrás de um endpoint na Internet.

Configurações do conjunto de réplicas de modelo

Na arquitetura, o balanceador de carga de front-end direciona o tráfego para um serviço de back-end específico com base no nome do modelo. Os servidores de inferência para o modelo especificado podem ser hospedados em uma das configurações descritas na tabela a seguir.

Tipo de conjunto de réplicas Descrição Balanceamento de carga de réplicas
Vertex AI As réplicas de modelo são executadas na Vertex AI. Você publica um endpoint da Vertex AI como um grupo de endpoints de rede (NEG) do Private Service Connect. O balanceador de carga de front-end usa NEGs do Private Service Connect como back-ends para cada modelo distinto, com cada modelo estruturado como um serviço de back-end. A Vertex AI escalona e balanceia a carga internamente. A Vertex AI realiza o balanceamento de carga ponderado baseado em métricas e o roteamento baseado em cache de prefixo, o que otimiza a utilização de recursos e acelera a inferência. Para mais informações, consulte Implantar um modelo em um endpoint.
GKE Os servidores de inferência são executados como pods em um cluster do GKE na rede VPC do conjunto de réplicas do GKE. Várias réplicas de modelo no GKE formam coletivamente um back-end singular atrás de um gateway de inferência. O gateway de inferência publica um endpoint do Private Service Connect que o balanceador de carga de front-end acessa usando um NEG do Private Service Connect. O gateway de inferência fornece balanceamento de carga com reconhecimento de modelo para back-ends de inferência em um cluster do GKE. O gateway de inferência usa a correspondência de prefixo quando aplicável. Se não houver uma correspondência de prefixo, o gateway de inferência distribuirá as solicitações com base nas métricas de GPU ou TPU. Essa configuração oferece suporte ao escalonamento automático horizontal de pods.
Cloud Run Os servidores de inferência são executados no Cloud Run. O Cloud Run publica um endpoint que o balanceador de carga de front-end acessa usando um NEG sem servidor. O Cloud Run escalona automaticamente o número de réplicas com base no tráfego. Ele é limitado apenas a réplicas de nó único.
Híbrido Os servidores de inferência são executados no local ou em outra nuvem. Você configura um balanceador de carga de rede de proxy interno regional em uma rede VPC de roteamento. Esse balanceador de carga publica um endpoint do Private Service Connect que o balanceador de carga de front-end acessa usando um NEG do Private Service Connect. O balanceador de carga interno na rede VPC de roteamento, por sua vez, tem um back-end NEG híbrido que aponta para o endereço IP de um balanceador de carga local ou de outra nuvem na frente dos servidores de inferência locais. O mecanismo de balanceamento de carga do balanceador de carga externo é configurado pelos administradores da instalação externa.
Internet Servidores de inferência acessíveis de endereços IP públicos da Internet. O balanceador de carga de front-end tem um back-end NEG da Internet que aponta para o endereço IP de um modelo hospedado na Internet. O provedor de serviço gerenciado processa o escalonamento.

Fluxo da solicitação

O sistema encaminha 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 do modelo de um dos servidores de inferência hospedados.
  2. O endpoint do Private Service Connect encaminha a solicitação para o balanceador de carga de aplicativo interno de front-end.
  3. O balanceador de carga encaminha a solicitação para as Service Extensions.
  4. O código de roteamento baseado no corpo das Service Extensions lê o nome do modelo no corpo da solicitação e o grava em um X-Gateway-Model-Name cabeçalho.
  5. O balanceador de carga usa a chamada de extensão de tráfego do Service Extensions para enviar a solicitação ao sistema de gerenciamento de APIs para todos os serviços de gerenciamento de APIs necessários.
  6. O balanceador de carga usa uma chamada de extensão de tráfego do Service Extensions para enviar o comando ao Model Armor para triagem.
    • 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 vai editar as informações sensíveis e encaminhar o comando.
  7. Se a solicitação for permitida pelo Model Armor, o balanceador de carga consultará o mapa de URL e encaminhará a solicitação para um serviço de back-end com base no cabeçalho personalizado do nome do modelo. Se necessário, o mapa de URL reescreve o URL e o caminho da solicitação para corresponder ao que o back-end precisa.
  8. O serviço de back-end encaminha a solicitação para o balanceador de carga do conjunto de réplicas associado.
  9. O balanceador de carga do serviço de inferência específico atribui a solicitação a uma das réplicas.
  10. A réplica processa a solicitação e envia uma resposta.
  11. O balanceador de carga de aplicativo interno regional de front-end envia a resposta ao Model Armor para triagem.
  12. O balanceador de carga de aplicativo 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:

  • Gemma: todos os comandos são encaminhados para o conjunto de réplicas que hospeda o modelo Gemma.
  • Llama: o sistema balanceia a carga desses comandos igualmente 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.

Produtos usados

A arquitetura de referência neste documento usa os seguintes Google Cloud produtos:

  • Cloud Load Balancing: um portfólio de balanceadores de carga globais, regionais, escalonáveis, globais e de alto desempenho.
  • 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 baseada em agentes contra injeção de comandos, vazamentos de dados sensíveis e conteúdo nocivo.

Alternativas de design

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

Proteções 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. 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 proteções 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 proteção, como as proteções 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 para o cliente e uma rede voltada para a 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 para a 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 Framework Well-Architected.

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 à implantação, adicione Cloud Armor ao balanceador de carga de aplicativo interno regional de front-end.
  • Para adicionar uma camada de autenticação comum a todos os back-ends, implemente o Identity-Aware Proxy (IAP) para verificar a identidade e aplicar políticas de autorização.
  • Ao encaminhar o tráfego de um aplicativo da Web para um modelo da Vertex AI, é necessário escolher um modelo de identidade para autenticação:
    • Identidade da conta de serviço (recomendada para aplicativos da Web gerais): o aplicativo autentica o usuário final pelo IAP, mas chama a Vertex AI usando a identidade da carga de trabalho de serviços (como o Cloud Run, GKE ou usando uma identidade de terceiros). Essa implementação abstrai o Identity and Access Management (IAM) do usuário final, mas exige o registro em log no nível do aplicativo para acompanhar qual usuário gerou qual comando.
    • Passagem de identidade do usuário final (recomendada para auditabilidade estrita): o aplicativo captura o token de acesso OAuth do Google do usuário final e o transmite diretamente para a Vertex AI no cabeçalho Authorization: Bearer. Essa implementação fornece registro em log integrado dos Registros de auditoria do Cloud de ações do usuário, mas exige que cada usuário final seja provisionado com Google Cloud permissões do IAM (como roles/aiplatform.user).

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.

Eficiência operacional

  • Para monitorar fluxos de tráfego e identificar e corrigir problemas rapidamente, use registros do Cloud Logging para o balanceador de carga de aplicativo interno regional.
  • Para facilitar a descoberta dos modelos que sua organização oferece suporte, implemente uma lista que possa ser consultada para retornar modelos disponíveis. Por exemplo, é possível criar uma lista em um servidor que responde à chamada de API list models call.

Otimização de desempenho

Implantação

Para implantar um exemplo de implementação dessa arquitetura, use o exemplo de código de rede para disponibilização de modelos de inferência de IA disponível no GitHub.

Para informações sobre como implantar modelos de IA, consulte os seguintes recursos:

A seguir

Colaboradores

Autor: Victor Moreno | Gerente de produtos, Cloud Networking

Outros colaboradores: