Por que as ferramentas de rastreamento de LLM agora estão criando gateways de IA

Em 2026, LangSmith, Langfuse, Opik e Braintrust adicionaram, todos, um gateway diante dos provedores de modelos. O principal motivo é o controle: uma ferramenta de rastreamento só pode registrar uma chamada ao modelo, enquanto um gateway pode impedi-la.

Duas ferramentas com funções distintas

Nos últimos dois anos, muitas equipes executaram aplicações de modelos de linguagem de grande porte (LLMs) usando duas ferramentas separadas. Um gateway ficava entre a aplicação e os provedores de modelos. Ele armazenava as chaves de API dos provedores, traduzia as chamadas entre as APIs dos provedores e tentava novamente as chamadas malsucedidas. LiteLLM, um proxy de código aberto, tornou-se uma opção comum para essa função. Ao lado da aplicação ficava uma ferramenta de rastreamento, como LangSmith ou Langfuse, que registrava cada chamada ao modelo, chamada de ferramenta e etapa de recuperação, para que os engenheiros pudessem ver o que um agente havia feito.

Essa divisão fazia sentido, pois um gateway precisa ser rápido e oferecer suporte à API de cada provedor, enquanto uma ferramenta de rastreamento precisa de uma boa interface, armazenamento para cargas úteis grandes e um SDK que encapsule o código da aplicação. A Langfuse ainda documenta essa configuração com duas ferramentas, incluindo uma integração do LiteLLM Proxy que encaminha cada chamada pelo proxy e para a Langfuse. Em 2026, os fornecedores de ferramentas de rastreamento começaram a criar seus próprios gateways.

Quatro lançamentos em seis meses

A LangChain anunciou o gateway de LLM da LangSmith em beta privado em maio de 2026 e o abriu para beta público em 30 de julho. Desde então, também o integrou às implantações do LangSmith em nuvem própria. A Braintrust descontinuou seu antigo proxy de IA e direcionou os usuários para um novo gateway, que está em versão de prévia e é gratuito até a disponibilidade geral. A Comet lançou o gateway de LLM da Opik como um endpoint beta que aceita solicitações no formato OpenAI. Em 4 de novembro, a Langfuse abriu seu gateway de IA em beta público, tanto na Langfuse Cloud quanto em implantações autogerenciadas. O gateway é licenciado sob a MIT e escrito em Rust.

MLflow, que começou como uma ferramenta para gerenciar o ciclo de vida do aprendizado de máquina, e não como uma ferramenta de rastreamento, oferece há mais tempo um gateway de IA, com alertas e limites de orçamento.

Os gateways existem há anos, e os riscos de operar um são bem documentados. Os novos gateways vêm de empresas cujo negócio era registrar chamadas a modelos, e que agora querem que todas as chamadas passem primeiro por elas.

Por que o orçamento exige estar no caminho da solicitação

Uma ferramenta de rastreamento registra uma chamada ao modelo depois que o provedor responde e os tokens já foram pagos. Esse registro basta para criar um gráfico de gastos, mas a ferramenta de rastreamento não pode impedir que os gastos continuem. Fazer cumprir o orçamento de uma equipe, bloquear um modelo ou remover um segredo de um prompt exige verificar a solicitação antes que ela chegue ao provedor. Só o componente que está no caminho da solicitação pode fazer isso.

A LangChain apresenta esse argumento em sua publicação de lançamento. Ela descreve equipes que combinam um gateway separado, um produto de proteções e uma ferramenta de observabilidade, e afirma que, para evitar problemas, é preciso aplicar políticas na camada das solicitações. Quando uma chamada ultrapassaria o orçamento, o gateway responde com o código de status HTTP 402, em vez de encaminhá-la ao provedor.

Um único ponto de entrada registra todas as chamadas

O segundo motivo é a cobertura. Um SDK registra apenas os caminhos de código que alguém instrumentou. É fora desses caminhos que as falhas dos agentes tendem a passar despercebidas. Um script em um laptop, um notebook ou um agente de programação que use uma chave de API copiada não deixa rastros. Um gateway que armazena as chaves dos provedores vê todas as chamadas, porque não há outra rota até o provedor.

A Langfuse desenvolve seu gateway com base nessa ideia. Segundo a documentação do gateway, cada chave do gateway pertence a um usuário ou a uma conta de serviço e pode incluir metadados, como uma equipe ou um centro de custos. Só o gateway armazena a credencial do provedor, e os administradores aprovam quais modelos cada credencial pode acessar. A LangSmith publica páginas de configuração para encaminhar Claude Code, Codex e Gemini CLI pelo gateway. Esses agentes chamam modelos a partir da máquina de um desenvolvedor, fora do código de rastreamento de qualquer aplicação.

O que o gateway de uma ferramenta de rastreamento acrescenta

Os fornecedores de ferramentas de rastreamento também apresentam o argumento inverso: um gateway independente não basta por si só. A publicação de lançamento da Langfuse afirma que um gateway independente só pode contabilizar tokens e custos, enquanto o gateway da própria Langfuse incorpora cada chamada a um rastreamento completo. O gateway da Langfuse aceita um cabeçalho W3C traceparent; assim, uma chamada feita por ele é incluída no rastreamento que a aplicação já iniciou. Por padrão, ele registra o uso e o custo, mas não o conteúdo dos prompts e das respostas.

Esse é o argumento técnico mais convincente para integrar o gateway à ferramenta de rastreamento. Um gateway independente vê uma lista simples de respostas geradas. Uma ferramenta de rastreamento já tem, por meio de seu SDK, as chamadas de ferramentas e as etapas de recuperação do agente e pode inserir cada chamada feita pelo gateway nessa estrutura.

Há também uma interpretação comercial que os fornecedores não expressam. Quem opera o gateway detém as chaves dos provedores e o relatório de gastos, que é consultado pelas equipes financeira e de plataforma. Isso torna um gateway mais difícil de substituir do que um visualizador de rastreamentos. LangSmith e Langfuse já aproveitam essa posição de maneiras diferentes: a LangSmith vende Gateway Credits, que permitem aos clientes chamar modelos hospedados, como Kimi, sem usar a própria chave de provedor, enquanto o FAQ da Langfuse informa que a empresa não revende tokens.

O que os gateways beta ainda não conseguem fazer

Esses gateways ainda são recentes, e os próprios fornecedores documentam suas limitações. Atualmente, o gateway da Langfuse é compatível apenas com OpenAI e Anthropic; Amazon Bedrock, Google Vertex AI e Google AI Studio estão no roteiro de desenvolvimento. Os mecanismos de fallback entre provedores e os limites rígidos de gastos por equipe, usuário ou chave estão planejados, mas ainda não foram lançados. Por enquanto, o gateway oferece um painel de gastos e alertas. A documentação não descreve limites de taxa nem armazenamento em cache de respostas.

O gateway da Langfuse não converte entre formatos de API, então um cliente OpenAI só pode chamar modelos OpenAI. A versão auto-hospedada chama apenas os URLs oficiais dos provedores, o que, por enquanto, exclui Azure OpenAI, Bedrock e um proxy interno. A Comet descreve o gateway Opik como projetado para desenvolvimento e testes. A Braintrust ainda não anunciou os preços de seu gateway.

O gateway da LangSmith já oferece mais recursos do que os demais. A documentação lista mecanismos de fallback, limites de gastos, limites de taxa e políticas de dados como recursos disponíveis atualmente; além disso, o gateway aceita os formatos OpenAI Chat Completions, OpenAI Responses e Anthropic Messages. Em maio, os mecanismos de fallback e os limites de taxa constavam como recursos planejados, portanto foram lançados durante a fase beta. O produto como um todo ainda é identificado como beta.

Os testes de carga revelam outro tipo de lacuna. Um benchmark auto-hospedado do gateway da Langfuse, do LiteLLM e do AcruxCore constatou que o gateway da Langfuse acrescentava menos latência por chamada do que o LiteLLM. No entanto, com as configurações padrão do Docker, ele falhou em 739 dos 1.000 fluxos simultâneos, pois o processo manteve o limite padrão do Docker de 1.024 arquivos abertos. Uma linha no arquivo Compose da Langfuse resolveu o problema.

Em comparação com esses produtos beta, o LiteLLM, um gateway independente que existe há anos, oferece suporte a mais de 100 provedores e já inclui chaves virtuais, monitoramento de gastos, proteções, balanceamento de carga e um painel de administração. O LiteLLM também está migrando o caminho das solicitações de Python para Rust. Seu gateway de IA em Rust está em fase beta, e a equipe do LiteLLM espera que as solicitações no formato /v1/messages, no estilo da Anthropic, sejam processadas de ponta a ponta em Rust até 1º de dezembro, com cerca de 20 vezes menos latência. Algumas plataformas de código aberto, como MLflow e AcruxCore, já oferecem gateway e rastreamento em um único produto.

Por que mantê-los separados

Integrar o gateway ao rastreador tem custos, e o principal deles é o acoplamento. Com um gateway separado, a equipe pode trocar de fornecedor de rastreamento alterando uma chamada de retorno de registro. Quando o rastreador também é o gateway, mudam também o URL base, as chaves e os identificadores de modelo de cada serviço. A Langfuse, por exemplo, registra os identificadores de modelo no formato credencial:modelo.

O rastreador também se torna uma dependência em tempo de execução. Se um backend de rastreamento ficar indisponível, a equipe perde os rastreamentos. Se um gateway ficar indisponível, as chamadas aos modelos falham. Um fornecedor de rastreamento que opera o gateway passa a precisar garantir a disponibilidade de uma infraestrutura crítica.

Os fornecedores de segurança querem ocupar o mesmo lugar no caminho das solicitações. A Palo Alto Networks concluiu a aquisição da Portkey, um gateway independente, em maio de 2026 e o tornou o gateway de IA de sua plataforma Prisma AIRS. Uma equipe de segurança pode preferir manter o gateway sob seu próprio controle, em vez de integrá-lo a uma ferramenta de observabilidade. Os gateways também se tornaram alvos de ataques, como mostrou a violação da cadeia de suprimentos do LiteLLM em março.

Como as equipes podem escolher

As equipes podem começar listando tudo o que precisa acontecer antes de uma chamada a um modelo. Se precisam apenas de visibilidade, basta usar um rastreador ao lado do caminho das solicitações, sem acrescentar uma dependência em tempo de execução. Se também precisam de orçamentos, políticas para chaves ou aprovação de modelos, precisam de algum tipo de gateway.

Em seguida, é preciso verificar a cobertura de provedores. A equipe deve anotar todos os provedores e formatos de API usados em produção, incluindo Azure OpenAI e Bedrock, e comparar essa lista com os recursos atualmente disponíveis em cada gateway, em vez de se basear no roteiro de desenvolvimento.

As equipes que já usam o LiteLLM têm poucos motivos para migrar enquanto um gateway beta não oferecer algo que lhes falte. O principal recurso que o gateway de um rastreador acrescenta é a inclusão da chamada ao gateway no rastreamento do agente, e isso precisa justificar a migração. As equipes que estão começando podem manter o gateway como uma camada independente, mesmo quando o mesmo fornecedor oferece ambos. Manter o URL base e as chaves em um único módulo de configuração permite que uma migração futura seja uma alteração de configuração, e não de código.

A maioria desses gateways está identificada como beta ou versão de prévia, então a lista de limitações diminuirá rapidamente. A questão em aberto é quem será responsável pelo caminho das solicitações dentro de uma empresa típica: a equipe de observabilidade, a equipe de plataforma que opera um gateway independente ou a equipe de segurança. Neste ano, LangSmith e Langfuse desenvolveram gateways próprios e a Palo Alto Networks comprou um, mas, em muitas arquiteturas, o caminho das solicitações ainda passa pelo LiteLLM.