Como funciona um gateway de LLM? Um guia prático para equipes de engenharia

Um gateway de LLM fica entre seus aplicativos e os provedores de modelos que você conecta por meio dele, oferecendo um único lugar para gerenciar credenciais e acompanhar o uso.

“No momento, está uma m***a total”, escreveu um engenheiro no Reddit, no r/LLMDevs, em setembro de 2026.

“Cada um tem seu próprio conjunto de chaves para Claude, OpenAI, AWS Bedrock e todos os outros provedores de inferência que usamos.”

A cobertura da BigGo sobre o llm-proxy-tk, um gateway leve em FastAPI, compara a configuração a transformar os LLMs em “água encanada corporativa”, com o gateway como o registro geral do prédio.

Mas, antes de depositar tanta confiança no encanamento, vejamos o que você está instalando.

O que é um gateway de LLM?

Um gateway de LLM é um proxy reverso para chamadas de modelos. Seus aplicativos enviam solicitações para ele, em vez de diretamente para a OpenAI, a Anthropic, o Google ou quaisquer provedores de LLM que você use. O gateway encaminha essas solicitações, aplicando suas regras no caminho.

Cada provedor de LLM tem uma API, com seu próprio formato de solicitação, sua própria autenticação e sua própria forma de retornar erros. Cada um também tem limites de taxa e modos de falha distintos. Agora, se não houver uma camada compartilhada à frente deles, cada aplicativo que chama um provedor faz tudo por conta própria, e de um jeito um pouco diferente.

A analogia da água encanada só vai até certo ponto, mas vai até aqui: os provedores são ligados ao encanamento uma única vez, no gateway. A partir daí, cada aplicativo recebe sua própria conexão com medidor, para que você veja quem está usando o quê e feche qualquer ramal individual sem mexer nos outros.

Gateways de LLM, de IA, de MCP e de API: qual é a diferença?

Como funciona um gateway de LLM?

Acompanhe uma solicitação do seu aplicativo até o modelo e de volta.

1. A solicitação chega ao gateway: Seu aplicativo envia uma solicitação de chat aparentemente comum, muitas vezes em um formato compatível com a OpenAI, para o endpoint do gateway. Do ponto de vista do aplicativo, esse é o endereço que ele chama para acessar o modelo.
2. O gateway verifica quem está fazendo a solicitação e o que tem permissão para fazer: Antes de encaminhar a solicitação, ele valida as credenciais. Muitas vezes, trata-se de uma chave virtual emitida para uma equipe ou um produto. Se você tiver configurado guardrails de entrada, os prompts também podem ser analisados em busca de dados sensíveis ou de tentativas de anular as instruções do modelo.
3. O gateway verifica se já tem a resposta: Se o cache estiver ativado, uma solicitação correspondente elegível pode ser respondida a partir de uma resposta salva, sem outra chamada ao provedor. Alguns gateways também oferecem cache semântico, que busca solicitações consideradas suficientemente semelhantes, em vez de idênticas. Isso pode ser adequado para tráfego do tipo FAQ.
4. O gateway escolhe para onde a solicitação vai: A solicitação pode indicar um modelo específico ou um alias. O gateway procura a rota correspondente na sua configuração. Você também pode configurar uma rota de backup. Se o provedor A exceder o tempo limite, o gateway pode tentar o provedor B.
5. O gateway prepara a chamada e retorna a resposta: O gateway converte sua solicitação para o formato do provedor escolhido e autentica a chamada de saída. Assim que a resposta é recebida, ela é convertida para o formato que seu aplicativo exige.
6. O gateway registra o que aconteceu: Quando o registro em log está ativado, o gateway registra detalhes como quem fez a chamada, qual modelo a atendeu, contagem de tokens, latência e custo. Esse é o log que o engenheiro do Reddit citado na introdução não tinha.

As 4 coisas que você precisa saber antes de colocar um gateway em produção

Tudo o que foi descrito na seção acima é possível porque o gateway vê cada solicitação roteada por ele. Esse é o argumento de venda. Mas também é uma descrição da superfície de ataque e da dependência de fornecedor para as quais você precisa se planejar.

O gateway passa a ser a peça mais valiosa da sua stack de IA

O gateway centraliza o acesso. Por isso, ele também deixa muitas credenciais ao alcance de um único serviço. A equipe de segurança da Microsoft lista o que uma implantação do LiteLLM pode armazenar ou obter: chaves de API de provedores, sua própria chave mestra, registros de chaves virtuais, strings de conexão de banco de dados, configurações de roteamento e políticas de locatários.

Em outubro de 2026, a Check Point Research divulgou duas vulnerabilidades de alto risco no LiteLLM:

• A CVE-2026-35029 permitia que usuários autenticados, inclusive os somente leitura, acessassem funções administrativas e assumissem o controle da instância.
• A CVE-2026-59823 permitia que usuários redirecionassem solicitações para um servidor sob seu controle e capturassem chaves de provedores.

Ambas foram corrigidas na versão 1.83.9. Um aplicativo que usa o gateway não deveria conseguir alterar as configurações dele.

Seus guardrails precisam de uma política de falha

Uma análise da Pillar Security de 4 de outubro de 2026 documenta integrações de guardrails de terceiros nos principais gateways, incluindo LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management e Apigee. (A Pillar vende guardrails, então tenha isso em mente ao ler as recomendações dela.)

Um hook é um ponto no caminho da solicitação, normalmente antes de o prompt ir para o modelo ou depois de a resposta voltar, em que o gateway pode entregar o conteúdo a um scanner externo para obter um veredito. Uma verificação bloqueante aguarda esse veredito antes de deixar o tráfego seguir. A documentação do Portkey chama esses pontos de before_request_hooks e after_request_hooks; a TrueFoundry executa quatro, adicionando verificações antes e depois das chamadas de ferramentas de MCP.

Agora, há duas coisas a verificar:

• O que acontece se o próprio scanner falhar? Ao bloquear uma solicitação, você impede o tráfego não verificado, mas pode interromper seu aplicativo. Se deixá-la passar, seu aplicativo pode continuar sem essa verificação. O log de falhas mostra depois que a verificação não aconteceu, o que é útil, mas não equivale a tê-la executado.
• É possível substituir o scanner? Se outro provedor não for compatível, talvez você precise atualizar seu aplicativo ou usar outro proxy para se conectar.

Os hooks de MCP da TrueFoundry ampliam o alcance do gateway das solicitações a modelos para as chamadas de ferramentas. Mas ele só consegue inspecionar o tráfego que passa por ele. Um agente de programação executando um comando na máquina de um desenvolvedor pode estar fora desse campo de visão.

O Numbat, projeto de código aberto da Perplexity, atua desse lado. O Numbat se conecta a agentes compatíveis por meio de hooks locais e pode inspecionar ações planejadas, como comandos de shell ou gravações de arquivos, antes que sejam executadas. O recurso de bloqueio é opcional e vem desativado por padrão. O gateway vê o tráfego de modelos roteado por ele. O Numbat acrescenta visibilidade sobre o que o agente faz com a resposta.

Você precisa saber onde termina o controle do gateway

A Forkast News identifica três linhagens que chegam ao gateway por direções diferentes:

• Gateways focados em LLM: O LiteLLM e o Portkey começaram com chamadas de modelos: traduzindo entre provedores, roteando solicitações e contabilizando tokens. Agora estão adicionando controles para chamadas de ferramentas.
• Plataformas de gerenciamento de APIs: O Kong, o Apigee do Google e o Azure API Management começaram com autenticação, permissões e gerenciamento de tráfego e, depois, adicionaram suporte a modelos e a regras específicas de IA.
• Infraestrutura nativa para agentes: O agentgateway, por exemplo, foi criado em torno de agentes que se comunicam com modelos, ferramentas e outros agentes, inclusive via MCP e A2A.

A pergunta que define a escolha é o que você está roteando:

• Só chamadas de modelos? Um gateway voltado principalmente para LLMs é um bom ponto de partida.
• Chamadas de modelos dentro de uma empresa que já tem regras de API de sobra? Comece pela plataforma que você já tem.
• Agentes chamando ferramentas que chamam modelos? Verifique se essas conexões também estão cobertas.

Você cria um ponto único de falha

Digamos que seu chatbot de suporte use a OpenAI e sua ferramenta de pesquisa use a Anthropic, e ambos se conectem pelo mesmo gateway. Mas, se esse gateway parar de funcionar, as duas ferramentas perdem o acesso aos seus modelos, mesmo que a OpenAI e a Anthropic estejam funcionando normalmente.

Isso já aconteceu de verdade. A taxa de erros do AI Gateway da Cloudflare chegou a 97% durante a interrupção de 12 de junho de 2025. O gateway dependia do serviço de armazenamento Workers KV da Cloudflare para as configurações, e esse serviço estava falhando.

Se você mesmo opera o gateway, mantenha outra cópia em execução que possa assumir caso uma falhe. Se o gateway for hospedado por terceiros, pergunte como eles o mantêm funcionando durante falhas e o que acontece com suas solicitações durante a recuperação.

Os principais recursos a buscar em gateways de LLM

Você vai dar ao gateway acesso às credenciais de todo mundo, então deve ser exigente quanto ao que ele oferece em troca.

• Uma API à frente de vários provedores: Seu código usa um único formato, muitas vezes compatível com a OpenAI, e o gateway faz a tradução. Os provedores de LLM também fazem a parte deles. Por exemplo, a Agent API da Perplexity é compatível com a interface da Responses API da OpenAI, para que as equipes possam reutilizar as bibliotecas de cliente da OpenAI que já usam.
• Chaves virtuais com regras associadas: Cada equipe ou produto recebe a própria chave, com regras que definem os modelos permitidos, os limites de solicitações e os gastos.
• Roteamento e fallback: O gateway envia solicitações aos modelos com base nas suas configurações, que podem priorizar custo, velocidade ou um provedor específico. Se uma chamada falhar, ele pode tentar outro. A Agent API da Perplexity permite listar até cinco modelos, inclusive de provedores diferentes, na ordem de sua preferência.
• Cache: Uma resposta salva pode poupar outra chamada ao provedor. Alguns gateways identificam solicitações idênticas; outros também reconhecem solicitações com significado semelhante. Verifique se as respostas em cache podem ser separadas por usuário ou equipe e se é possível desativar o cache para respostas personalizadas ou sensíveis ao tempo.
• Streaming e erros consistentes: As respostas chegam à medida que são geradas, e os erros dos provedores são traduzidos para um formato que seu aplicativo consegue tratar. Verifique o que acontece quando você adiciona guardrails de IA.
• Registro em log e atribuição de custos: O gateway registra quem fez uma chamada, qual modelo a atendeu, quantos tokens ela usou, quanto tempo levou e seu custo estimado. Verifique se os logs incluem prompts e respostas e por quanto tempo são mantidos.
• Hooks de guardrails: São pontos no caminho da solicitação em que o gateway pode enviar conteúdo a um scanner externo para obter um veredito. Normalmente ficam antes de uma solicitação ao modelo ou depois da resposta dele. Verifique se as solicitações são interrompidas ou continuam quando o scanner falha e se é possível conectar outro scanner.
• Uma interface de administração que você possa proteger: O gateway gerencia o acesso às credenciais dos provedores e às regras que todos usam. Verifique se é possível restringir o acesso administrativo separadamente do tráfego dos aplicativos e se usuários somente leitura não conseguem alterar configurações. O registro geral precisa de um cadeado.

Quais ferramentas você pode usar para criar seu gateway de LLM?

As listas de recursos se sobrepõem em todo o mercado. Em um tópico do Reddit sobre acesso interno a modelos, o autor perguntou: qual gateway não vai exigir um engenheiro dedicado?

Na nossa opinião, essa é a pergunta certa, e ela tem quatro respostas, dependendo de quanto do trabalho você está disposto a assumir.

Crie o seu próprio

Um gateway mínimo cuida de uma lista curta de tarefas: aceitar solicitações, verificar a chave de quem chama, adicionar a credencial do provedor, encaminhar a chamada e registrar o resultado. Mas oferecer suporte a diferentes formatos de provedores dá mais trabalho. Assim como manter tudo funcionando.

Se você já usa o Envoy, o filtro de processamento externo dele permite conectar um serviço que inspeciona e modifica solicitações e respostas. Você ainda precisa criar e operar esse serviço.

Em um tópico do r/LLMDevs sobre se um gateway reduz custos, u/QuanTradin disse que registrar os tokens e uma flag de acerto de cache em cada chamada ajudou a encontrar dois jobs que pagavam o preço cheio por prompts idênticos.

“...corrigir isso valeu mais do que qualquer camada de roteamento teria valido.”

Esse é um relato de experiência, e um bom ponto de partida. Descubra pelo que você está pagando antes de criar formas elaboradas de rotear isso.

Hospede um gateway de código aberto por conta própria

O LiteLLM é uma escolha comum nesse caso: é compatível com a OpenAI, oferece suporte a uma ampla variedade de provedores e tem uma grande comunidade. O Bifrost é uma alternativa, criada para ter baixa sobrecarga por solicitação. O Helicone merece uma olhada se a observabilidade estiver no topo da sua lista de recursos.

O LiteLLM, como qualquer produto, tem limitações para algumas equipes. Em um tópico do r/aiagents sobre alternativas a criar a própria solução, u/Own_Bar_920 disse que o LiteLLM lidava bem com o roteamento, mas deixava a desejar em versionamento de prompts entre equipes e em avaliações contínuas ao trocar de modelo, o que os levou a uma ferramenta separada.

Esses recursos vão além do roteamento básico de um gateway, e é justamente esse o ponto: se o roteamento é a principal necessidade, o LiteLLM deu conta do recado para eles.

Você recebe uma lista de recursos pronta, com alguns recursos que dependem da edição, e mantém o gateway dentro da sua rede. Você também fica responsável pela aplicação de patches, algo que as divulgações da Check Point mencionadas antes tornaram concreto, e pela disponibilidade do gateway, como mostrou a seção sobre ponto único de falha.

Mas reserve orçamento para ter alguém responsável por isso. Uma das preocupações em um tópico do r/LLMDevs sobre gateways para acesso interno era a manutenção. u/Informal-Writer9685 queria algo que “não exija um engenheiro dedicado para manter” e perguntou se a instabilidade relatada nas atualizações do LiteLLM era um problema real na escala deles ou uma preocupação apenas para produção.

Use um gateway gerenciado

O Cloudflare AI Gateway, o Vercel AI Gateway, o OpenRouter e o gateway hospedado do Portkey operam o serviço para você. Para um aplicativo compatível, fazer a primeira solicitação passar pode exigir pouco mais do que trocar uma URL e uma chave de API.

A contrapartida é que agora cada prompt passa por um terceiro antes de chegar ao provedor. É mais um operador de dados na sua documentação de conformidade, e uma interrupção do próprio gateway é um incidente do fornecedor: não cabe a você corrigi-la.

Por exemplo, em 17 e 19 de fevereiro de 2026, o OpenRouter sofreu interrupções de 38 e 35 minutos, respectivamente, após a falha de uma dependência de cache. Alguns clientes receberam erros “User not found” e perderam tempo depurando chaves de API perfeitamente válidas. A falha estava na infraestrutura do gateway.

Mas, justiça seja feita, o OpenRouter publicou um postmortem detalhado e adicionou proteções para impedir que uma falha de cache sobrecarregue seu banco de dados. Um gateway gerenciado como o OpenRouter pode simplificar o acesso, mas, como u/QuanTradin aponta no r/LLMDevs, consolidar as faturas não reduz automaticamente os gastos.

Amplie o gateway de API que você já tem

Se o Kong, o Apigee ou o Azure API Management já ficam à frente dos seus serviços, cada um deles tem recursos específicos de IA: o Kong AI Gateway, as políticas de gateway de IA do Apigee e o gateway de IA do Azure API Management. Você pode aproveitar a autenticação, as regras de rede e os procedimentos operacionais que já tem, adicionando controles de modelos por meio de plugins ou políticas.

Esse pode ser o caminho de menor resistência organizacional em uma grande empresa. Os recursos de IA são mais recentes do que os dos gateways independentes. Não deixe de testar a limitação de taxa baseada em tokens e o streaming em todo o conjunto de plugins ou políticas que você pretende usar.

Então, sem dúvida, instale a válvula mestra — o todo-poderoso gateway. Ainda assim, o engenheiro da introdução tem razão. O acesso de uma empresa aos modelos não deveria depender de quem por acaso guarda a chave certa na gaveta.

Um gateway resolve isso colocando essas chaves sob controle centralizado, o que torna ainda mais arriscado deixar a gaveta aberta. É preciso saber de quem é a gaveta.

Perguntas frequentes sobre gateways de LLM

O gateway de LLM é gratuito?

Se você se refere à categoria, alguns gateways de LLM têm versões gratuitas.

Os gateways de LLM vão de softwares de código aberto gratuitos a planos pagos a partir de cerca de US$ 50 por mês, com preços personalizados para implantações corporativas. Já outros cobram uma porcentagem: o plano Standard do OpenRouter, por exemplo, acrescenta 5,5% ao valor das compras de créditos.

Qual é o melhor gateway de LLM?

Que trabalho você está disposto a assumir?

• Confira o Bifrost ou o Helicone se quiser hospedar a solução por conta própria e controlar a configuração.
• Uma opção gerenciada, como o OpenRouter ou o Vercel AI Gateway, é ideal para equipes que preferem deixar a operação do serviço a cargo de terceiros.
• Se você já usa o Kong ou o Azure API Management, verifique primeiro os recursos de IA que eles oferecem.

Teste as opções da sua lista final com suas próprias solicitações, incluindo o que acontece quando um provedor falha.

A AWS tem um gateway de LLM?

Sim. O Amazon Bedrock AgentCore Gateway oferece suporte a chamadas de modelo por meio do que a AWS chama de “inference targets” (destinos de inferência). Eles permitem que os aplicativos usem um único endpoint para acessar provedores como Amazon Bedrock, OpenAI e Anthropic, com o gateway cuidando das credenciais e do roteamento dos provedores.