A primeira feature de LLM sai como uma chamada direta de um serviço para o Bedrock. A décima sai do mesmo jeito, a partir de dez serviços, com dez conjuntos de credenciais, dez políticas de retry, e nenhum lugar único para ver quanto cada um está gastando. É nesse momento que um time de plataforma descobre que precisa de um LLM gateway, geralmente um trimestre depois de quando teria sido barato construir um. Um gateway é a porta de entrada compartilhada por onde toda chamada de modelo passa, e ele existe para ser dono das quatro coisas que times individuais insistem em reinventar mal: autenticação, quota, roteamento e auditoria.

O reenquadramento útil é que um gateway não é uma feature de AI. É o mesmo control plane que você já coloca na frente de qualquer dependência compartilhada, medida e cara. Você não deixaria cada serviço carregar sua própria senha de admin do banco de dados e escolher seu próprio limite de conexões. O acesso a modelos não é diferente, exceto que a conta cresce mais rápido e os modos de falha são mais barulhentos.

O que o gateway realmente centraliza

O valor não está em fazer proxy da requisição. Está em ser dono das quatro preocupações transversais que não pertencem ao código da aplicação:

  • Autenticação. Quem chama apresenta uma identidade de serviço ao gateway. O gateway guarda a única credencial que fala com o Bedrock. Nenhuma aplicação jamais vê uma chave de modelo de longa duração, e girar essa chave é uma mudança, não vinte.
  • Quota. Orçamentos de tokens por time e por modelo ficam em um único lugar. Um loop descontrolado em um serviço bate no próprio teto em vez de consumir o limite compartilhado de tokens por minuto e throttlar todo mundo.
  • Roteamento. O gateway mapeia um nome de modelo lógico para um deployment concreto: qual região, qual provedor, qual fallback quando o primário sofre throttling. As aplicações pedem "o sumarizador", não um ID de modelo específico em uma região específica.
  • Auditoria. Toda requisição e resposta passa por um único ponto de estrangulamento, então atribuição de custo, logging de prompts e detecção de abuso têm uma única costura para se conectar. Sem isso, custo por feature é um projeto de arqueologia.

Note que nenhum desses é um problema de qualidade de modelo. São problemas de plataforma que só parecem novos porque a dependência é um modelo.

Build vs LiteLLM vs API Gateway

Existem três padrões honestos, e o certo depende de quanto do que foi listado acima você realmente precisa no primeiro dia.

Adotar o LiteLLM (ou um proxy similar)

Um proxy open-source como o LiteLLM te dá uma API unificada entre provedores, orçamentos por chave e roteamento básico pronto de fábrica. É a forma mais rápida de ter um gateway de verdade que já conhece as quatro preocupações. O trade-off é que você agora roda e faz patch de um serviço com estado que fica no caminho crítico de toda feature de AI, e as opiniões dele sobre roteamento e logging se tornam as suas opiniões. Para a maioria dos times colocando no ar sua segunda ou terceira feature de LLM, esse é o padrão correto. Você compra o control plane em vez de construí-lo.

Colocar no API Gateway mais Lambda

Se você já está fundo no AWS, o Amazon API Gateway na frente de um pequeno Lambda authorizer e uma função de proxy te dá auth, usage plans, throttling e logs de acesso a partir de primitivas que você já opera. Usage plans cuidam dos limites de taxa por chave; o authorizer cuida da identidade; o CloudWatch cuida da trilha de auditoria. O custo é que a lógica específica de modelo, streaming, contagem de tokens e fallback de provedor, é código que você escreve e mantém. Esse padrão vence quando seus requisitos de governança têm a cara do AWS e você prefere estender uma plataforma existente a introduzir uma nova dependência.

Construir um serviço sob medida

Construir o seu próprio só é certo quando seus requisitos de roteamento ou auditoria são genuinamente incomuns: políticas complexas de seleção de modelo, decisões de residência de dados por requisição, ou logging que precisa satisfazer um regulador em um formato específico. A maioria dos times que constrói do zero está, na verdade, reconstruindo o LiteLLM mais devagar. Recorra a isso por último, e só quando você conseguir nomear o requisito que a opção pronta não consegue atender.

O modo de falha que um gateway previne

Sem um gateway, a falha não é dramática, é lenta. Credenciais se espalham. Cada time define seu próprio timeout e retry, então uma soluço do provedor vira uma tempestade de retries que te empurra através da sua quota de tokens. Ninguém consegue responder "quanto custou a feature de sumarização de suporte no mês passado" sem fazer grep em logs espalhados por serviços. Aí uma revisão de segurança pergunta quem pode chamar qual modelo com quais dados, e a resposta honesta é "não temos certeza", que é a resposta que trava um lançamento.

Um gateway transforma tudo isso em configuração. É essa a proposta inteira: tirar as decisões transversais de vinte codebases e colocá-las em uma sobre a qual você consegue raciocinar.

Trace a linha no lugar certo

Mantenha o gateway magro. Ele deve cuidar de identidade, quota, roteamento e logging, e ficar fora da construção de prompts e da lógica de negócio. No momento em que o gateway começa a ser dono de prompts, ele vira uma biblioteca compartilhada com um salto de rede a mais, e todo time fica travado pelo ciclo de release dele. O design duradouro é um proxy monótono com opiniões fortes sobre governança e nenhuma opinião sobre o que você pergunta ao modelo.

A conclusão

Todo time de plataforma que coloca no ar mais de uma feature de LLM acaba construindo um gateway. A única escolha é se você o constrói deliberadamente, cedo, enquanto ele é um pequeno proxy, ou acidentalmente, tarde, como um projeto de limpeza depois que as credenciais se espalharam e a conta virou um mistério. Adote um proxy se puder, estenda o API Gateway se você é AWS-nativo, e construa do zero só contra um requisito que você consiga nomear. O gateway não é onde a AI acontece. É onde a governança que você ia precisar de qualquer jeito finalmente encontra um lar.

Leia isso a seguir

Para o lado de plataforma e infraestrutura de rodar um control plane compartilhado como esse, as notas de campo de cloud estão em ercan.cloud, e o hub fica em ercanermis.com.