Transformando Kong em um Gateway de IA no GCP: Gerenciando Tokens LLM, MCP e Tráfego Agentivo

A maioria das equipes de plataforma não se propôs a construir "infraestrutura de IA". Elas já tinham o Kong rodando na frente de centenas de serviços REST no GKE, lidando com autenticação, limitação de taxa e observabilidade da maneira que um gateway de API deve fazer. Então, as equipes de produto começaram a enviar recursos suportados por LLM, depois pipelines RAG, e então agentes autônomos que chamam ferramentas por conta própria, e de repente a camada de gateway que funcionava bem para tráfego CRUD começou a mostrar falhas. Um único pedido de chat pode custar 50 vezes mais que outro, dependendo do modelo e do comprimento do prompt. Um único "pedido de usuário" agora pode se desdobrar em uma dúzia de chamadas de ferramentas feitas por um agente sem intervenção humana. Nada disso se encaixa perfeitamente nos limites de taxa de contagem de pedidos ou regras de roteamento estáticas.

Esse é o problema que as capacidades do Kong AI Gateway foram construídas para resolver, e o GCP é um lugar natural para executá-lo: GKE para o próprio gateway, Cloud Load Balancing na borda, Vertex AI e Model Garden como backends de modelo de primeira classe ao lado de OpenAI, Anthropic e outros, e Memorystore para Redis apoiando o estado de limite de taxa distribuído. Abaixo está um passo a passo prático de como transformar uma implantação existente do Kong em um verdadeiro gateway de IA no GCP, cobrindo gerenciamento de tráfego ciente de tokens, suporte ao Protocolo de Contexto de Modelo (MCP) e o problema mais difícil de governar o tráfego agente que não se comporta como chamadas normais de API.

Por que um Gateway de API Regular Não é Suficiente para Tráfego LLM

Gateways tradicionais são construídos em torno de algumas suposições que falham com cargas de trabalho de IA generativa:

O custo não é proporcional à contagem de pedidos. Um pedido para um modelo pequeno com um prompt curto pode custar frações de centavo; um pedido de longo contexto para um modelo de ponta pode custar dólares. A limitação de taxa em pedidos por minuto não protege seu orçamento.

Os backends não são intercambiáveis. Roteando um pedido para GPT versus Gemini versus Claude não é apenas uma decisão de balanceamento de carga, muda o custo, a latência e até mesmo a qualidade da saída.

O "cliente" é cada vez mais uma máquina, não um humano. Agentes encadeiam múltiplas chamadas, tentam novamente de forma autônoma e podem entrar em loops que um humano nunca acionaria clicando em uma interface de usuário.

O protocolo em si está evoluindo. O MCP agora padroniza como os modelos descobrem e chamam ferramentas, e os gateways precisam falar isso nativamente em vez de tratá-lo como um payload HTTP opaco.

O Kong AI Gateway é essencialmente o mesmo núcleo do Kong Gateway, estendido com uma família de plugins específicos para IA — ai-proxy, ai-proxy-advanced, ai-rate-limiting-advanced, ai-semantic-cache, ai-prompt-compressor, ai-mcp-proxy e outros — que tornam o gateway fluente em tokens, prompts e chamadas de ferramentas em vez de apenas cabeçalhos e caminhos.

Passo 1: Colocar o Kong AI Gateway em Funcionamento no GKE

Se você já está executando o Kong Gateway (OSS ou Enterprise) no GKE, não precisa de uma nova plataforma — você precisa do conjunto de plugins do AI Gateway, que é enviado como parte do Kong Gateway 3.6+ e é mais completo a partir do 3.12 (que adicionou suporte de primeira classe ao MCP).

Uma pegada típica nativa do GCP se parece com isto:

O GKE hospeda os nós do plano de dados do Kong (e o plano de controle, se autogerenciado em vez de usar o Konnect).
O Cloud Load Balancing (LB HTTPS externo ou API Gateway) termina o TLS e frente ao serviço proxy do Kong.
O Memorystore para Redis apoia contadores distribuídos para os plugins de limitação de taxa de IA, para que os orçamentos de tokens sejam aplicados de forma consistente entre réplicas em vez de por pod.
O Secret Manager mantém as chaves de API do provedor (OpenAI, Anthropic, credenciais da conta de serviço do Vertex AI) e é montado no Kong via o driver CSI em vez de estar embutido no kong.yaml.
O Cloud Monitoring / Managed Prometheus coleta as métricas que os plugins de IA do Kong emitem — incluindo o uso de tokens e métricas específicas do MCP adicionadas via as extensões do plugin Prometheus.

A implantação em si é padrão Kong-on-Kubernetes: o Kong Ingress Controller ou os CRDs KongClusterPlugin/KongPlugin gerenciam a configuração do plugin de forma declarativa, o que funciona bem com GitOps se você já estiver executando Config Sync ou Argo CD no GKE.

Passo 2: Roteie para Vertex AI e Outros Provedores com ai-proxy

O plugin ai-proxy transforma uma Rota do Kong em um endpoint LLM. Você define o provedor, o modelo e quaisquer regras de transformação, e o Kong normaliza a forma de solicitação/resposta para que suas aplicações possam chamar uma API interna consistente, independentemente de qual modelo upstream realmente a atende:

plugins:
  - name: ai-proxy
    config:
      route_type: llm/v1/chat
      auth:
        header_name: Authorization
        header_value: Bearer ${{ env "VERTEX_AI_TOKEN" }}
      model:
        provider: gemini
        name: gemini-3.5-flash
        options:
          max_tokens: 1024
          temperature: 0.7

Para configurações de múltiplos provedores, roteando tráfego barato e insensível à latência para um modelo do Vertex AI enquanto envia pedidos premium para Claude ou GPT, o ai-proxy-advanced adiciona balanceamento de carga ponderado e roteamento semântico entre múltiplos alvos LLM por trás de uma única Rota do Kong. É também onde vivem padrões de otimização de custo: emparelhando ai-proxy-advanced com ai-semantic-cache (para pular chamadas LLM redundantes inteiramente para prompts quase duplicados) e ai-prompt-compressor (que usa compressão estilo LLMLingua para reduzir prompts antes de chegarem à API paga) pode cortar gastos de forma significativa sem tocar no código da aplicação.

Passo 3: Faça do Uso de Tokens uma Dimensão de Limitação de Taxa de Primeira Classe

Essa é a mudança central de "gateway de API" para "gateway de IA": a limitação de taxa por contagem de pedidos é quase sem sentido para o tráfego LLM. O plugin ai-rate-limiting-advanced lê o uso real de tokens retornado pelo provedor LLM em cada resposta e aplica orçamentos com base nisso — tokens de prompt, tokens de conclusão ou tokens totais, por consumidor ou grupo de consumidores, ao longo de uma janela deslizante:

plugins:
  - name: ai-rate-limiting-advanced
    consumer_group: standard-tier
    config:
      policies:
        - limits:
            - limit: 20000
              window_size: 60
              window_type: sliding
          identifier: consumer-group
          tokens_count_strategy: total_tokens
          strategy: redis
          redis:
            cluster_nodes:
              - ip: $