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

Um gateway de LLM situa-se entre as suas aplicações e os fornecedores de modelos que liga através dele, oferecendo-lhe um único local para gerir credenciais e acompanhar a utilização.

«Neste momento, é uma m***a completa», escreveu um engenheiro no Reddit, no r/LLMDevs, em setembro de 2026.

«Cada pessoa tem o seu próprio conjunto de chaves para o Claude, a OpenAI, o AWS Bedrock e todos os outros fornecedores de inferência que utilizamos.»

A cobertura da BigGo sobre o llm-proxy-tk, um gateway leve em FastAPI, compara esta configuração a transformar os LLM em «água canalizada empresarial», com o gateway no papel de válvula principal do edifício.

Mas, antes de depositar tanta confiança na canalização, vejamos o que está a instalar.

O que é um gateway de LLM?

Um gateway de LLM é um proxy inverso para chamadas a modelos. As suas aplicações enviam os pedidos para ele, em vez de os enviarem diretamente à OpenAI, à Anthropic, à Google ou a quaisquer outros fornecedores de LLM que utilize. O gateway reencaminha esses pedidos, aplicando as suas regras pelo caminho.

Cada fornecedor de LLM tem a sua API, com o seu próprio formato de pedido, a sua própria autenticação e a sua própria forma de devolver erros. Cada um tem também limites de taxa e modos de falha distintos. Ora, se não houver uma camada partilhada à frente deles, cada aplicação que chama um fornecedor faz tudo sozinha, e de forma ligeiramente diferente.

A analogia da água canalizada só vai até certo ponto, mas leva-nos até aqui: os fornecedores são ligados uma única vez, no gateway. A partir daí, cada aplicação tem a sua própria ligação com contador, pelo que pode ver quem está a usar o quê e cortar qualquer linha individual sem mexer nas restantes.

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

Como funciona um gateway de LLM?

Acompanhe um pedido desde a sua aplicação até ao modelo e de volta.

1. O pedido chega ao gateway: A sua aplicação envia um pedido de chat com aspeto normal, muitas vezes num formato compatível com a OpenAI, para o endpoint do gateway. Do ponto de vista da aplicação, este é o endereço que chama para chegar ao modelo.
2. O gateway verifica quem está a pedir e o que tem permissão para fazer: Antes de reencaminhar o pedido, valida as credenciais. Muitas vezes, trata-se de uma chave virtual atribuída a uma equipa ou a um produto. Se tiver configurado salvaguardas 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 a cache estiver ativada, um pedido correspondente elegível pode ser respondido a partir de uma resposta guardada, sem nova chamada ao fornecedor. Alguns gateways oferecem também cache semântica, que procura pedidos considerados suficientemente semelhantes, em vez de idênticos. Isso pode ser adequado para tráfego do tipo «perguntas frequentes».
4. O gateway escolhe para onde vai o pedido: O pedido pode indicar um modelo específico ou um alias. O gateway procura a rota correspondente na sua configuração. Também pode configurar uma rota de recurso. Se o fornecedor A exceder o tempo limite, o gateway pode tentar o fornecedor B.
5. O gateway prepara a chamada e devolve a resposta: O gateway converte o seu pedido no formato do fornecedor escolhido e autentica a chamada de saída. Assim que a resposta é recebida, é convertida no formato de que a sua aplicação necessita.
6. O gateway regista o que aconteceu: Quando o registo está ativado, o gateway regista detalhes como quem fez a chamada, que modelo a serviu, as contagens de tokens, a latência e o custo. Este é o registo que o engenheiro do Reddit da introdução não tinha.

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

Tudo o que foi descrito na secção anterior é possível porque o gateway vê todos os pedidos encaminhados através dele. É esse o argumento de venda. Mas é também uma descrição da superfície de ataque e da dependência do fornecedor para as quais tem de se preparar.

O gateway é agora a peça mais valiosa da sua stack de IA

O gateway centraliza o acesso. Por isso, também coloca muitas credenciais ao alcance de um único serviço. A equipa de segurança da Microsoft enumera o que uma implementação do LiteLLM pode guardar ou obter: chaves de API dos fornecedores, a sua própria chave mestra, registos de chaves virtuais, cadeias de ligação a bases de dados, definições de encaminhamento e políticas de inquilinos.

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

• A CVE-2026-35029 permitia que utilizadores autenticados, incluindo os que tinham apenas permissões de leitura, acedessem a funções administrativas e assumissem o controlo da instância.
• A CVE-2026-59823 permitia que os utilizadores redirecionassem pedidos para um servidor sob o seu controlo e capturassem chaves de fornecedores.

Ambas foram corrigidas na versão 1.83.9. Uma aplicação que utiliza o gateway não deve conseguir alterar as definições deste.

As suas salvaguardas precisam de uma política de falha

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

Um hook é um ponto no percurso do pedido, normalmente antes de o prompt seguir para o modelo ou depois de a resposta regressar, em que o gateway pode entregar o conteúdo a um analisador externo para obter um veredicto. Uma verificação bloqueante aguarda esse veredicto antes de deixar o tráfego prosseguir. A documentação da Portkey chama-lhes before_request_hooks e after_request_hooks; a TrueFoundry executa quatro, acrescentando verificações antes e depois das chamadas de ferramentas MCP.

Agora, há duas coisas a verificar:

• O que acontece se o próprio analisador falhar? Se bloquear o pedido, trava o tráfego não verificado, mas pode interromper a sua aplicação. Se o deixar passar, a sua aplicação pode continuar sem essa verificação. O registo de falhas mostra-lhe depois que a verificação não foi feita, o que é útil, mas não é o mesmo que tê-la executado.
• É possível substituir o analisador? Se outro fornecedor não for suportado, poderá ter de atualizar a sua aplicação ou utilizar outro proxy para estabelecer a ligação.

Os hooks de MCP da TrueFoundry alargam o alcance do gateway, dos pedidos aos modelos às chamadas de ferramentas. Mas o gateway só consegue inspecionar o tráfego que passa por ele. Um agente de programação que execute um comando no computador de um programador pode estar fora desse campo de visão.

O Numbat, a ferramenta de código aberto da Perplexity, atua desse lado. O Numbat liga-se aos agentes suportados através de hooks locais e pode inspecionar ações planeadas, como comandos de shell ou escritas em ficheiros, antes de serem executadas. A funcionalidade de bloqueio é opcional e está desativada por predefinição. O gateway vê o tráfego dos modelos encaminhado através dele. O Numbat acrescenta visibilidade sobre o que o agente faz com a resposta.

Precisa de saber onde termina o controlo do gateway

A Forkast News identifica três linhagens que se aproximam do gateway a partir de direções diferentes:

• Gateways focados em LLM: O LiteLLM e o Portkey começaram pelas chamadas a modelos: tradução entre fornecedores, encaminhamento de pedidos e contabilização de tokens. Agora estão a acrescentar controlos para chamadas de ferramentas.
• Plataformas de gestão de APIs: O Kong, o Apigee da Google e o Azure API Management começaram pela autenticação, pelas permissões e pela gestão de tráfego e, depois, acrescentaram suporte para modelos e regras específicas de IA.
• Infraestrutura nativa para agentes: O agentgateway, por exemplo, foi concebido em torno de agentes que comunicam com modelos, ferramentas e outros agentes, incluindo através de MCP e A2A.

A pergunta que permite decidir é o que está a encaminhar:

• Apenas chamadas a modelos? Um gateway centrado em LLM é um bom ponto de partida.
• Chamadas a modelos numa empresa já repleta de regras de API? Comece pela plataforma que já tem.
• Agentes que chamam ferramentas que chamam modelos? Verifique se essas ligações também estão abrangidas.

Está a introduzir um ponto de falha partilhado

Imagine que o seu chatbot de apoio ao cliente utiliza a OpenAI e a sua ferramenta de investigação utiliza a Anthropic, e que ambos se ligam através do mesmo gateway. Se esse gateway deixar de funcionar, ambas as ferramentas perdem o acesso aos respetivos modelos, mesmo que a OpenAI e a Anthropic estejam a funcionar normalmente.

Isto aconteceu mesmo. A taxa de erros do AI Gateway da Cloudflare atingiu um pico de 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 definições, e esse serviço estava a falhar.

Se gerir o gateway por conta própria, mantenha outra cópia em execução que possa assumir o serviço caso a primeira falhe. Se o seu gateway for alojado por terceiros, pergunte como o mantêm em funcionamento durante as falhas e o que acontece aos seus pedidos durante a recuperação.

As principais funcionalidades a procurar num gateway de LLM

Vai dar ao gateway acesso às credenciais de toda a gente, por isso deve ser exigente quanto ao que ele oferece em troca.

• Uma única API à frente de vários fornecedores: O seu código utiliza um único formato, muitas vezes compatível com a OpenAI, e o gateway faz a tradução. Os fornecedores de LLM também dão um passo nesse sentido. Por exemplo, a Agent API da Perplexity suporta a interface da Responses API da OpenAI, pelo que as equipas podem reutilizar as bibliotecas cliente da OpenAI que já utilizam.
• Chaves virtuais com regras associadas: Cada equipa ou produto recebe a sua própria chave, com regras que definem os modelos permitidos, os limites de pedidos e os gastos.
• Encaminhamento e recurso a alternativas: O gateway envia os pedidos para os modelos com base nas suas definições, que podem privilegiar o custo, a velocidade ou um fornecedor específico. Se uma chamada falhar, pode tentar outro. A Agent API da Perplexity permite-lhe indicar até cinco modelos, incluindo modelos de fornecedores diferentes, pela ordem que preferir.
• Cache: Uma resposta guardada pode poupar-lhe uma nova chamada ao fornecedor. Alguns gateways fazem corresponder pedidos idênticos; outros conseguem também fazer corresponder pedidos com significados semelhantes. Verifique se as respostas em cache podem ser separadas por utilizador ou equipa e se pode desativar a cache para respostas personalizadas ou dependentes do momento.
• Streaming e erros consistentes: As respostas chegam à medida que são geradas, e os erros dos fornecedores são traduzidos para um formato que a sua aplicação consegue processar. Verifique o que acontece quando acrescenta salvaguardas de IA.
• Registo e atribuição de custos: O gateway regista quem fez uma chamada, que modelo a serviu, quantos tokens utilizou, quanto tempo demorou e o seu custo estimado. Verifique se os registos incluem prompts e respostas e durante quanto tempo são conservados.
• Hooks de salvaguardas: São pontos no percurso do pedido em que o gateway pode enviar conteúdo a um analisador externo para obter um veredicto. Normalmente, situam-se antes de um pedido ao modelo ou depois da respetiva resposta. Verifique se os pedidos param ou continuam quando o analisador falha e se pode ligar um analisador diferente.
• Uma interface de administração que possa proteger: O gateway gere o acesso às credenciais dos fornecedores e às regras que todos utilizam. Verifique se consegue restringir o acesso de administração separadamente do tráfego das aplicações e se os utilizadores com permissões só de leitura não podem alterar definições. A válvula principal precisa de um cadeado.

Que ferramentas pode utilizar para criar o seu gateway de LLM?

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

Na nossa opinião, é a pergunta certa, e tem quatro respostas, consoante a parte do trabalho que está disposto a assumir.

Crie o seu próprio gateway

Um gateway mínimo trata de uma lista curta de tarefas: aceitar pedidos, verificar a chave de quem faz a chamada, acrescentar a credencial do fornecedor, reencaminhar a chamada e registar o resultado. Mas suportar diferentes formatos de fornecedores dá trabalho adicional. Tal como manter tudo em funcionamento.

Se já utiliza o Envoy, o respetivo filtro de processamento externo permite-lhe ligar um serviço que inspeciona e altera pedidos e respostas. Continua a ter de desenvolver e executar esse serviço.

Num tópico do r/LLMDevs sobre se um gateway reduz custos, u/QuanTradin disse que registar os tokens e um indicador de acerto na cache em cada chamada lhe permitiu encontrar duas tarefas que pagavam o preço total por prompts idênticos.

«...corrigir isso valeu mais do que qualquer camada de encaminhamento alguma vez teria valido.»

Trata-se de uma experiência relatada e de um bom ponto de partida. Descubra o que está a pagar antes de criar formas elaboradas de o encaminhar.

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

O LiteLLM é uma escolha comum neste caso: é compatível com a OpenAI, suporta uma grande variedade de fornecedores e tem uma comunidade numerosa. O Bifrost é uma alternativa, concebida para uma baixa sobrecarga por pedido. O Helicone merece atenção se a observabilidade estiver no topo da sua lista de funcionalidades.

O LiteLLM, como qualquer produto, tem limitações para algumas equipas. Num tópico do r/aiagents sobre alternativas a desenvolver uma solução própria, u/Own_Bar_920 disse que o LiteLLM tratava bem do encaminhamento, mas ficava aquém das suas necessidades no controlo de versões de prompts entre equipas e nas avaliações contínuas ao trocar de modelos, o que motivou a adoção de uma ferramenta separada.

Essas necessidades vão além do encaminhamento básico de um gateway, e é precisamente essa a questão: se o encaminhamento for a principal necessidade, o LiteLLM correspondeu às expectativas deste utilizador.

Obtém uma lista de funcionalidades já pronta, algumas das quais dependem da edição, e mantém o gateway dentro da sua rede. Também fica responsável pela aplicação de patches, algo que as divulgações da Check Point referidas anteriormente tornaram bem concreto, e pela disponibilidade do gateway, como ilustrou a secção sobre o ponto único de falha.

Mas preveja no orçamento alguém que fique responsável por ele. Uma das preocupações num 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 fazer a manutenção» e perguntou se a instabilidade nas atualizações do LiteLLM que tinha sido relatada era um problema real à sua escala ou uma preocupação apenas em produção.

Utilize um gateway gerido

O Cloudflare AI Gateway, o Vercel AI Gateway, o OpenRouter e o gateway alojado da Portkey gerem o serviço por si. Para uma aplicação compatível, fazer passar o primeiro pedido pode exigir pouco mais do que alterar um URL e uma chave de API.

A contrapartida é que cada prompt passa agora por um terceiro antes de chegar ao fornecedor. É mais um subcontratante de dados para a sua documentação de conformidade, e uma falha do próprio gateway é um incidente do fornecedor: não é a si que cabe resolvê-lo.

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

Mas, justiça lhe seja feita, o OpenRouter publicou uma análise pós-incidente detalhada e acrescentou proteções para impedir que uma falha da cache sobrecarregue a sua base de dados. Um gateway gerido como o OpenRouter pode simplificar o acesso, mas, como salienta u/QuanTradin no r/LLMDevs, consolidar as faturas não reduz automaticamente a despesa.

Expanda o gateway de API que já tem

Se o Kong, o Apigee ou o Azure API Management já estiverem à frente dos seus serviços, cada um deles tem capacidades específicas para IA: o Kong AI Gateway, as políticas de gateway de IA do Apigee e o gateway de IA do Azure API Management. Pode tirar partido da autenticação, das regras de rede e dos procedimentos operacionais que já tem, acrescentando controlos de modelos através de plugins ou políticas.

Numa grande empresa, este pode ser o caminho com menor resistência organizacional. As funcionalidades de IA são mais recentes do que as dos gateways autónomos. Certifique-se de que testa a limitação de taxa baseada em tokens e o streaming com todo o conjunto de plugins ou políticas que tenciona utilizar.

Por isso, instale sem reservas 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 deve depender de quem, por acaso, tem a chave certa numa gaveta.

Um gateway resolve isso ao colocar essas chaves sob controlo centralizado, o que torna bem mais grave deixar a gaveta aberta. É preciso saber de quem é a gaveta.

Perguntas frequentes sobre gateways de LLM

O gateway de LLM é gratuito?

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

Os gateways de LLM vão desde software de código aberto gratuito a planos pagos a partir de cerca de 50 dólares por mês, com preços personalizados para implementações empresariais. E alguns cobram antes uma percentagem; por exemplo, o plano Standard do OpenRouter acrescenta 5,5% às compras de créditos.

Qual é o melhor gateway de LLM?

Que trabalho está disposto a assumir?

• Veja o Bifrost ou o Helicone se quiser alojar o gateway na sua própria infraestrutura e controlar a configuração.
• Uma opção gerida, como o OpenRouter ou o Vercel AI Gateway, adequa-se a equipas que preferem que seja um terceiro a operar o serviço.
• Se já utiliza o Kong ou o Azure API Management, verifique primeiro as respetivas capacidades de IA.

Teste as opções pré-selecionadas com os seus próprios pedidos, incluindo o que acontece quando um fornecedor falha.

A AWS tem um gateway de LLM?

Sim. O Amazon Bedrock AgentCore Gateway suporta chamadas a modelos através daquilo a que a AWS chama «destinos de inferência» (inference targets). Estes permitem que as aplicações utilizem um único endpoint para aceder a fornecedores como o Amazon Bedrock, a OpenAI e a Anthropic, ficando o gateway responsável pelas credenciais dos fornecedores e pelo encaminhamento.