Phase 17 - Lesson 19

Gateways de IA — LiteLLM, Portkey, Kong AI Gateway, Bifrost

Um gateway fica posicionado entre suas aplicações e os provedores de modelos. Suas principais funcionalidades são roteamento de provedor, fallback, tentativas (retries), limitação de taxa (rate limiting), referências a segredos (secrets), observabilidade e guardrails. Divisão de mercado em 2026: LiteLLM é de código aberto sob licença MIT, com suporte a mais de 100 provedores, compatível com OpenAI, mas apresenta falhas em torno de ~2000 RPS (8 GB de memória, gerando falhas em cascata em benchmarks publicados); ideal para Python, <500 RPS e desenvolvimento/prototipagem. Portkey foca no plano de controle (guardrails, redação de PII, detecção de jailbreak, trilhas de auditoria), tornou-se open-source sob licença Apache 2.0 em março de 2026, com um overhead de latência de 20-40 ms e plano de produção de $49/mês. Kong AI Gateway é construído com base no Kong Gateway — o benchmark do próprio Kong em hardware equivalente de 12 CPUs mostrou-se 228% mais rápido do que o Portkey e 859% mais rápido do que o LiteLLM; preço de

00/modelo/mês (máximo de 5 no plano Plus); ideal para empresas que já utilizam o Kong. Bifrost (Maxim AI) — retries automáticos com backoff configurável, com fallback para Anthropic se a OpenAI retornar erro 429. Gateways de IA da Cloudflare / Vercel — gerenciados, sem necessidade de operação (zero-ops) e com retries básicos. A residência dos dados impulsiona a decisão de auto-hospedar (self-host); Portkey e Kong ficam no meio termo com versões de código aberto (OSS) + serviço gerenciado opcional.

Type: Learn Languages: Python (stdlib, simulador simples de roteamento de gateway) Prerequisites: Phase 17 · 01 (Managed LLM Platforms), Phase 17 · 16 (Model Routing) Time: ~60 minutos

Objetivos de Aprendizado

  • Enumerar as seis principais funcionalidades de um gateway (roteamento, fallback, retries, limites de taxa, segredos, observabilidade, guardrails).
  • Associar os quatro gateways de 2026 (LiteLLM, Portkey, Kong AI, Bifrost) a limites de escala e casos de uso.
  • Citar o benchmark do Kong (228% vs Portkey, 859% vs LiteLLM) e explicar por que ele é relevante para cargas >500 RPS.
  • Escolher entre soluções auto-hospedadas e gerenciadas considerando a residência de dados e o orçamento operacional.

O Problema

Seu produto faz chamadas para a OpenAI, Anthropic e uma instância local do Llama. Cada provedor possui um SDK, modelo de erro, limite de taxa e esquema de autenticação diferentes. Você deseja implementar tolerância a falhas (se a OpenAI retornar 429, tentar a Anthropic), um único armazenamento de credenciais, observabilidade unificada e limites de taxa por tenant.

Reinventar isso na camada de aplicação acopla todos os serviços a todos os provedores. Uma camada de gateway consolida tudo isso em um único processo com uma única API (geralmente compatível com OpenAI) que faz a distribuição para os provedores.

O Conceito

Seis funcionalidades principais

  1. Roteamento de provedores — OpenAI, Anthropic, Gemini, auto-hospedados, etc. por trás de uma única API.
  2. Fallback — em caso de erro 429, 5xx ou falha de qualidade, tenta em outro lugar.
  3. Tentativas (retries) — recuo exponencial (exponential backoff) com limite de tentativas.
  4. Limitação de taxa (rate limits) — por tenant, por chave ou por modelo.
  5. Referências a segredos (secrets) — busca credenciais de cofres (vaults) em tempo de execução (nunca expostas no app).
  6. Observabilidade — OTel + atributos GenAI (Fase 17 · 13) + atribuição de custos.
  7. Guardrails — redação de PII, detecção de jailbreak, filtros de temas permitidos.

LiteLLM — MIT OSS, Python

  • Mais de 100 provedores, compatível com OpenAI, roteamento configurável, fallback, observabilidade básica.
  • Começa a apresentar problemas perto de 2000 RPS no benchmark da Kong; consome 8 GB de memória, com falhas em cascata sob carga contínua.
  • Melhor aplicação: aplicativos Python, <500 RPS, gateways de desenvolvimento/homologação e roteamento experimental.
  • Custo: $0 para a versão open-source; há plano gratuito em nuvem.

Portkey — foco no plano de controle

  • Open-source sob licença Apache 2.0 a partir de março de 2026. Guardrails, redação de PII, detecção de jailbreak, trilhas de auditoria.
  • Overhead de latência de 20-40 ms por requisição.
  • Plano de produção de $49/mês com retenção + SLA.
  • Melhor aplicação: indústrias reguladas que necessitam de guardrails + observabilidade integrados.

Kong AI Gateway — foco em escala

  • Construído sobre o Kong Gateway (um produto maduro de gateway de APIs, escrito em Lua + OpenResty).
  • Benchmark do próprio Kong em equivalente de 12 CPUs: 228% mais rápido que o Portkey, 859% mais rápido que o LiteLLM.
  • Preços:
    00/modelo/mês, com máximo de 5 no plano Plus.
  • Melhor aplicação: equipes que já utilizam o Kong; >1000 RPS; dispostos a adquirir licença.

Bifrost (Maxim AI)

  • Retries automáticos com recuo configurável.
  • Receita clássica: fallback para Anthropic quando a OpenAI retorna erro 429.
  • Solução comercial mais recente.

Cloudflare AI Gateway / Vercel AI Gateway

  • Serviços gerenciados, sem necessidade de operação (zero-ops). Retries e observabilidade básica.
  • Melhor aplicação: aplicativos JavaScript servidos na borda (edge) no Cloudflare/Vercel.
  • Funcionalidades limitadas de guardrails e limites de taxa em comparação com o Kong/Portkey.

Auto-hospedado vs gerenciado

A residência de dados é o fator decisivo. Setores de saúde e finanças priorizam soluções auto-hospedadas (LiteLLM, Portkey OSS ou Kong). Produtos de consumo utilizam soluções gerenciadas (Cloudflare AI Gateway) ou nível intermediário (Portkey gerenciado). Abordagem híbrida: auto-hospedado para tenants regulados e gerenciado para os demais.

Orçamento de latência

  • LiteLLM: overhead típico de 5-15 ms.
  • Portkey: overhead de 20-40 ms.
  • Kong: overhead de 3-8 ms.
  • Cloudflare/Vercel: overhead de 1-3 ms (vantagem de processamento na borda/edge).

A latência do gateway é adicionada diretamente ao TTFT. Para SLAs de TTFT P99 < 100 ms, utilize Kong ou Cloudflare. Para P99 < 500 ms, qualquer um atende.

A semântica dos limites de taxa importa

O algoritmo simples de balde de tokens (token-bucket) funciona bem até escala moderada. Cenários multi-tenant exigem janela deslizante (sliding-window) + tolerância a picos (bursts) + categorização por tenant. O LiteLLM fornece token-bucket; o Kong fornece janela deslizante; o Portkey fornece limites por níveis (tiered).

Gateway + observabilidade + roteamento se integram

A Fase 17 · 13 (observabilidade) + 16 (roteamento de modelos) + 19 (gateways) representam a mesma camada em produção. Escolha uma única ferramenta que cubra os três aspectos ou conecte-os com cuidado: a maioria das implantações de 2026 combina Helicone (observabilidade) ou Portkey (guardrails) com o Kong (escala) dividindo as funções.

Números que você deve lembrar

  • LiteLLM: falha a ~2000 RPS, consumo de 8 GB de memória.
  • Portkey: overhead de 20-40 ms; Apache 2.0 a partir de março de 2026.
  • Kong: 228% mais rápido que o Portkey, 859% mais rápido que o LiteLLM.
  • Preços do Kong:
    00/modelo/mês, máximo de 5 no plano Plus.
  • Cloudflare/Vercel: overhead de 1-3 ms na borda.

Use

code/main.py simula o roteamento do gateway com fallback entre 3 provedores sob injeção de erros 429/5xx. Relata latência, taxa de tentativas e taxa de acertos de fallback.

Coloque em Produção

Esta lição produz outputs/skill-gateway-picker.md. Dada a escala, postura de operação, conformidade e orçamento de latência, escolhe um gateway.

Exercícios

  1. Execute code/main.py. Configure o fallback de OpenAI→Anthropic→auto-hospedado. Qual é a taxa de acerto esperada com taxa de erro do provedor em 5%?
  2. Seu SLA exige TTFT P99 < 200 ms sobre um baseline de 300 ms. Quais gateways permanecem dentro do orçamento?
  3. Um cliente da área de saúde exige auto-hospedagem + redação de PII + trilhas de auditoria. Escolha entre Portkey OSS ou Kong.
  4. Compare LiteLLM vs Kong: em qual limite de RPS a equipe deve migrar?
  5. Projete uma política de limite de taxa para um SaaS multi-tenant: planos gratuito, de teste e pago. Balde de tokens ou janela deslizante?

Termos-Chave

Termo O que dizem O que realmente significa
Gateway "intermediário de APIs" Processo intermediando apps e provedores
LiteLLM "o da licença MIT" Python OSS, 100+ provedores, falha a 2K RPS
Portkey "gateway de guardrails" Plano de controle + observabilidade, Apache 2.0
Kong AI Gateway "o de escala" Construído sobre o Kong Gateway, líder em benchmarks
Bifrost "gateway da Maxim" Receita de retries + fallback para Anthropic
Cloudflare AI Gateway "gerenciado na borda" Gateway gerenciado implantado na borda, zero-ops
Redação de PII "limpeza de dados" Máscara via Regex + NER antes de enviar ao modelo
Detecção de jailbreak "proteção contra injeção de prompt" Classificador atuando sobre a entrada do usuário
Trilhas de auditoria "logs regulados" Registro imutável de todas as chamadas ao LLM
Balde de tokens "limite de taxa simples" Limitador baseado em recarga de tokens
Janela deslizante "limite de taxa preciso" Limitador baseado em janelas temporais; melhor equidade

Leituras Adicionais

0 lifetime access. Curriculum based on AI Engineering from Scratch by Rohit Ghumare (MIT, used under attribution).