O que é um gateway de LLM?

O que é um gateway de LLM?

Um gateway de LLM é um serviço entre suas aplicações e os provedores de modelos. As aplicações chamam um único endpoint; o gateway encaminha cada requisição ao modelo configurado, traduz protocolos, guarda as chaves dos provedores e registra o uso. Ele não treina com o seu tráfego, não reescreve seus prompts e não substitui o modelo.

• •É infraestrutura, não um modelo — os modelos continuam nos provedores que você escolher.
• •Um mesmo endpoint atende aplicativos de chat, agentes de código, jobs em lote, voz em tempo real e chamadas de ferramentas MCP.
• •A linha útil: o gateway é dono do caminho da requisição, a aplicação é dona do prompt.

O que um gateway de LLM realmente faz?

Quatro tarefas: rotear cada requisição para o modelo certo, normalizar protocolos para que qualquer cliente fale com qualquer provedor, centralizar chaves e controle de acesso e registrar cada chamada para custo e auditoria. Cache, orçamentos e verificações de conteúdo são construídos sobre essas quatro, não no lugar delas.

• •Roteamento e fallback: modelo por papel de agente, nova tentativa em outro provedor em 5xx ou timeout, pool de chaves de origem.
• •Tradução de protocolos: quatro famílias de protocolos de chat nos dois sentidos, para o cliente manter o SDK que já usa.
• •Governança: grupos de chaves, admissão por cabeçalho, cotas por tenant, SSO e SCIM, logs de auditoria por requisição.
• •Observabilidade: séries de tokens e custo por chave, equipe e modelo com resolução de um minuto.

Por que as empresas colocam um gateway na frente dos modelos?

Porque o acesso a modelos deixa de ser o problema de uma equipe. Quando várias equipes, fornecedores e agentes chamam modelos, as perguntas passam a ser de compras: quem pode usar qual modelo, quanto custa por área, se os dados saíram da rede e quanto tempo de engenharia custa trocar de fornecedor. Um gateway responde com configuração, não com mudança de código.

• •Atribuição de custo: cada chamada leva chave e tag, o gasto se separa por equipe.
• •Caminho dos dados: o gateway roda na sua rede; as requisições vão apenas aos endpoints configurados.
• •Continuidade: falhas de fornecedor e trocas de modelo são tratadas na camada de roteamento.
• •Compras: auto-hospedagem com BYOK mantém chaves e tráfego sob seus contratos de fornecedor.

Quando você realmente precisa de um gateway de LLM?

Quando duas destas condições forem verdadeiras: mais de um provedor de modelos, mais de uma equipe consumidora, exigência de conformidade ou residência de dados, ou gasto que ninguém consegue explicar. Abaixo dessa linha, chamar as APIs dos provedores diretamente é mais simples e mais barato: um gateway é mais um serviço para operar.

• •Dois ou mais provedores, por capacidade, custo ou continuidade.
• •Relatórios de custo por equipe ou por cliente são um pedido recorrente.
• •Os dados não podem sair de uma rede, região ou tenant específicos.
• •Vários agentes e IDEs já compartilham uma ou duas chaves de API.

Quando um gateway é a escolha errada?

Quando você tem uma equipe, um provedor e uma aplicação. Um gateway adiciona um salto, um deployment e um plantão. Se o gasto mensal for previsível e a conformidade for simples, chame o provedor diretamente e reavalie quando o segundo provedor, a segunda equipe ou o primeiro pedido de auditoria chegar.

• •Um protótipo ou uma ferramenta interna única em um provedor não precisa de um.
• •Gestão de prompts e avaliação de modelos são outros produtos: um gateway não os substitui.
• •Nenhum gateway dispensa a leitura dos contratos dos seus provedores.

Como um gateway difere de um serviço de retransmissão ou do uso direto dos SDKs?

Um serviço de retransmissão encaminha o tráfego a um provedor por você, muitas vezes guardando sua chave e cobrando uma taxa. Um gateway que você opera mantém chaves e tráfego na sua rede e acrescenta roteamento, medição e políticas. Chamar os SDKs diretamente evita o intermediário, mas deixa a lógica de retentativa, protocolo e medição dentro de cada aplicação.

• •Para um protótipo, uma retransmissão pode bastar; o preço é que prompts e chaves saem da sua rede.
• •Só SDK é mais barato até o segundo provedor aparecer — aí cada aplicativo precisa do mesmo código de cola.
• •Das três opções, só o gateway consegue dizer quem gastou o quê.

O gateway deve ser auto-hospedado ou SaaS?

Auto-hospedado quando chaves, prompts ou logs não podem sair da sua rede, ou quando compras não aceita mais um subprocessador. SaaS ganha quando não há equipe de plataforma e você quer zero operação. A pergunta decisiva não é moda: é quem consegue ler o seu tráfego.

• •Auto-hospedar custa contêineres, atualizações e um runbook; SaaS custa assinatura e uma revisão de subprocessador.
• •Existe o híbrido: plano de dados auto-hospedado com plano de controle do fornecedor; os prompts ficam dentro, os metadados talvez não.
• •Peça o diagrama de fluxo de dados, não a página de marketing.

Como você deve escolher?

Pontue a pré-seleção em cinco pontos: onde roda, sobre o que a fatura se ancora, quais protocolos e SDKs fala nativamente, com que granularidade governa chaves e tenants, e se o fornecedor ainda será dono do produto no ano que vem. Depois verifique o que nenhuma matriz mostra: você consegue reproduzir hoje um relatório de custos de um mês atrás?

• •Deployment: auto-hospedado, SaaS ou híbrido — e se o plano de controle liga para casa.
• •Âncora de cobrança: por instância, por assento, por token ou percentual do gasto.
• •Protocolos: OpenAI, Anthropic, Gemini e DashScope nos dois sentidos, com streaming e chamadas de ferramentas realmente equivalentes.
• •Governança: grupos de chaves, ACL por cabeçalho, orçamentos, SSO e SCIM, exportação de auditoria.
• •Reprodutibilidade: mesmas entradas, mesmos números, meses depois.

Perguntas frequentes sobre gateways de LLM