Chega de Hardcodar Endpoints de LLM o API Gateway do Google Cloud Agora Roteia Gemini, Claude e OpenAI

O problema: toda troca de modelo quebra seu código

Olha só, se você colocou uma feature de IA em produção no último ano, já viveu isso. Você hardcoda um endpoint. Seis meses depois aparece um modelo mais barato e mais rápido, e de repente você está refatorando auth, schema de payload e lógica de retry em todo serviço que chama o LLM. 😩

A resposta da indústria tem nome: padrão LLM gateway — um ingress centralizado e serverless que aceita requisições compatíveis com OpenAI e distribui para o backend que você quiser. O Google Cloud acabou de lançar model routing no API Gateway (Public Preview), e é uma abordagem genuinamente leve.

O que chama atenção não é o roteamento em si — proxy já faz isso há anos. É que o gateway transcodifica o payload para o schema nativo de cada backend e injeta o token de autenticação do Agent Platform pra você. Seu cliente continua falando OpenAI; o backend escuta Gemini ou Anthropic nativo.

근거자료: A Unified API for AI Model Routing

Como funciona: backends, routers e paths

Toda a configuração vive no seu spec OpenAPI 3.x, via a extensão x-google-api-management. Três conceitos fazem o trabalho todo:

• backends — alvos upstream nomeados (Gemini, Claude, OSS-GPT) com endereço, deadline e pathTranslation: CONSTANT_ADDRESS.
• routers — um defaultModel mais uma lista de rules que mapeia a string model pedida para um backend.
• paths — seus endpoints públicos, cada um marcado com x-google-model-router.

Aqui está o formato mínimo:

x-google-api-management:
  backends:
    gemini-35-flashlite:
      address: >-
        https://aiplatform.googleapis.com/v1/projects/YOUR_PROJECT_ID/locations/global/publishers/google/models/gemini-3.5-flash-lite:generateContent
      deadline: 60.0
      pathTranslation: CONSTANT_ADDRESS
    anthropic-claude-opus-47:
      address: >-
        https://aiplatform.googleapis.com/v1/projects/YOUR_PROJECT_ID/locations/global/publishers/anthropic/models/claude-opus-4-7:rawPredict
      deadline: 60.0
      pathTranslation: CONSTANT_ADDRESS
  ai:
    models:
      routing:
        routers:
          gemini-claude-router:
            defaultModel:
              backend: gemini-35-flashlite
              targetModel: google/gemini-3.5-flash-lite
            rules:
              - model: "claude-opus-4-7"
                backend: anthropic-claude-opus-47
                targetModel: anthropic/claude-opus-4-7

Depois é só expor como um path POST normal:

paths:
  /v1/chat/gemini-claude:
    post:
      summary: "Endpoint: padrão Gemini, Claude como opção."
      operationId: "chatGeminiClaude"
      x-google-model-router: gemini-claude-router
      responses:
        '200':
          description: "OK"

Deploya a config e seu código cliente nunca mais muda:

curl -X POST "https://my-gateway.example.com/v1/chat/gemini-claude" \
  -H "content-type: application/json" \
  -H "x-api-key: $API_KEY" \
  -d '{
    "model": "claude-opus-4-7",
    "messages": [{"role": "user", "content": "Se apresente em 5 palavras"}]
  }'

O gateway intercepta, transcodifica o corpo no formato OpenAI para o schema nativo da Anthropic, anexa o token do Agent Platform e roteia. Você recebe a resposta; nunca tocou em um proxy. 🚀

Comparativo: onde isso encaixa vs. fazer na mão

As limitações que você precisa saber

• Um host por router. Todos os backends de um router precisam compartilhar o mesmo host (ex.: aiplatform.googleapis.com). Não é um roteador multi-cloud genérico — ele roteia modelos e paths num host compartilhado do Agent Platform.
• Public Preview. Espere mudanças na API. Não coloque em caminho crítico de compliance ainda.
• Só baseado em regras. As decisões vêm do campo model e de regras estáticas — sem roteamento dinâmico por latência ou custo (ainda).
• O split de auth é feature, mas também é armadilha. Como o cliente autentica no gateway, e não no provedor do modelo, um gateway mal configurado vira ponto único de exposição de credencial. Trate a API key do gateway como segredo de produção.

Se você já está fundo no Apigee ou precisa de governança no nível de agente, o espectro mais amplo de AI gateway (Agent Gateway, Gemini Enterprise Agent Platform) é pra onde você vai migrar. Comece leve aqui; cresça conforme os requisitos aparecerem.

A moral da história

O padrão LLM gateway é a resposta pragmática pro churn de modelos há um tempo — a pergunta sempre foi quem opera isso. O model routing do Google Cloud API Gateway tira as partes chatas (transcodificação de schema, injeção de auth, rate limiting) das suas costas e te dá um endpoint estável compatível com OpenAI pra apontar suas apps.

Próximos passos pra aprender de verdade:

1. Faça deploy de um router único num projeto de dev e bata com curl — sinta a transcodificação acontecendo.
2. Adicione um segundo router e teste o override do campo model.
3. Estude o espectro maior de AI gateway (Apigee, Agent Gateway) pra saber quando migrar.

Se você ainda está construindo a camada de serving por baixo, as primitivas de comunicação distribuída importam igual — dá uma olhada no nosso mergulho em comunicação distribuída do PyTorch pra entender point-to-point e operações coletivas que fazem o treino multi-GPU funcionar. E se você acompanha o lado de hardware da stack de IA, o buildout de datacenters NVIDIA Rubin da Azure vale a leitura.