Como avaliar e escolher um LLM gateway para sua empresa

A empresa que já roda múltiplos modelos em produção não está escolhendo um LLM gateway. Está escolhendo entre três coisas que não são a mesma: construir uma camada interna, contratar um serviço gerenciado ou delegar o problema a um roteador de modelo. As três cobram a mesma decisão num ponto diferente do balanço, e a maioria decide pela primeira sem nunca ter sabido que a terceira existia. Este post é o critério de desempate.

Por que escolher um gateway é a pergunta errada

Escolher um LLM gateway começa errado porque a palavra "gateway" nomeia pelo menos duas coisas com custos diferentes. Um proxy de endpoint único redireciona chamadas para uma API; um roteador com classificação de intenção decide, por request, qual modelo atende qual carga. A primeira questão é uma decisão de engenharia; a segunda, uma de margem contabilizada mês a mês.

O post de awareness do tema, já publicado no blog, explica o que um gateway faz e por que uma empresa que roda IA em produção chega a ele. Aqui a pergunta muda de assunto: não "o que é", e sim "qual dos vários entra, e quanto custa a escolha errada". E a escolha errada raramente é o fornecedor. Quase sempre é a categoria.

Basta olhar o que acontece no Brasil quando a decisão ignora o custo efetivo. Uma fatura de US$100 mil em tokens sai do caixa como até US$155 mil depois de IRRF, CIDE, PIS, COFINS, ISS, IOF e o spread do câmbio. Nenhum benchmark de latência captura isso. O quesito que decide a seleção tem que ser o billing em moeda local, e ele entra como último item da planilha, quando entra.

O que separa um roteador de um proxy

Um proxy de endpoint único faz uma coisa: pega o request e coloca na frente de uma API, às vezes de várias, e devolve a resposta. Um roteador faz outra: normaliza o request, classifica a intenção, escolhe o modelo por custo, latência e contexto, distribui a carga e normaliza a resposta. Os dois vendem sob o mesmo nome de "gateway", e a conta de produção final é completamente diferente entre eles.

O erro nasce daí. Uma equipe de plataforma que adota um proxy acreditando ter comprado roteamento descobre no primeiro pico de tráfego que o redirecionamento estático manda a carga mais pesada para o modelo mais caro, o tempo todo, porque ninguém ali tomou a decisão de rota. Nenhuma delas foi tomada. É o que o artigo sobre o modelo roteador como camada de middleware em escala descreve em detalhe: a inteligência de rota é o que separa a infraestrutura que escala da que apenas encaminha.

A diferença fica nítida numa tabela, e é ela que deveria abrir qualquer avaliação:

O nome mais perigoso do mercado é justamente esse: "gateway" usado para descrever as três coisas na mesma conversa. A avaliação que não separa proxy de roteador termina comparando preço de redirecionamento com preço de decisão de rota, e aí o vencedor é sempre o mais barato no dia um, nunca o mais barato no trimestre.

Os sete critérios de avaliação

Sete critérios bastam para separar um roteador de verdade de um proxy fantasiado de gateway. Eles se aplicam antes de qualquer POC, e cada um deles responde a uma pergunta de custo, não de recurso. A ordem importa menos que a presença: uma camada que falha em qualquer um dos sete deveria sair da lista, porque a falha vira uma conta no fim do mês.

1. Roteamento inteligente. A camada classifica a intenção de cada request e escolhe o modelo por custo, latência e contexto, em tempo real. Sem isso, a seleção de modelo é feita uma vez, no código, por alguém que não olha o balanço, e a decisão apodrece em três semanas, quando o ranking de preço e performance dos modelos já mudou.

2. Failover multi-camada. A queda de um fornecedor deveria migrar o tráfego em milissegundos, com fallback configurável e retry com backoff exponencial. Um gateway sem essa dobra de segurança deixa a falha do modelo virar a falha do produto, e a pós-morte da madrugada é sempre a mesma: ninguém era dono do failover.

3. Governança de custo por chave e projeto. Spend caps por API key, por projeto e por agente, com consumo em tempo real. É a diferença entre um orçamento que alguém revisa no fim do mês e um limite que o sistema impõe antes de o custo estourar.

4. Observabilidade completa. Logs, métricas, rastreamento de cada chamada, alertas e dashboards. Sem o rastro auditável de cada call, a economia prometida pelo roteamento não se prova, e um post específico do blog trata de como medir o custo operacional de um gateway de IA em produção.

5. Normalização de API. Uma única API compatível com OpenAI, trocando um endpoint por outro sem reintegração. É o que destrava a troca de modelo sem reescrever código, e o que transforma uma decisão de custo em uma mudança de uma variável.

6. Billing em moeda local com nota fiscal. A fatura em real, com nota fiscal e imposto de importação incluído. No Brasil esse critério vale mais que qualquer benchmark, porque o custo efetivo do token em moeda estrangeira carrega até 55% de carga entre tributos e câmbio, um número que a seleção por performance não enxerga.

7. Tempo de migração. O que custa trocar de gateway se a decisão se provar errada. Um roteador é trocável sem reintegração; um gateway como serviço prende o contrato e o lock-in; uma camada interna prende horas de engenharia que o negócio já gastou.

Esses sete critérios são também a lista que separa a decisão. Os quatro primeiros medem se a camada roteia ou apenas encaminha; os três últimos medem se a decisão sobrevive ao primeiro trimestre de produção real, quando o custo em moeda estrangeira e o custo de desfazer a escolha entram na conta.

Construir, comprar ou rotear

A pergunta que decide tudo não é sobre fornecedor, é sobre onde a camada de gateway mora na estrutura da empresa. A categoria decide. São três caminhos, e a resposta varia por porte e por caso de uso, não por opinião técnica.

Construir a camada internamente faz sentido para um time de plataforma dedicado que já mantém sua própria grade de modelos e precisa de controle fino sobre o roteamento. O custo real não é o código, que se escreve num trimestre; é carregar a disponibilidade, o failover, as atualizações de preço de centenas de modelos e a governança de custo, mês a mês, para sempre.

Comprar um gateway como serviço faz sentido para um time sem engenharia de plataforma que quer o problema tratado por terceiros. O corte é o custo efetivo: o serviço cobra a assinatura em moeda estrangeira, e no Brasil essa fatura carrega a mesma carga de tributos e câmbio que ele estava tentando evitar. O argumento de sair da dor da infraestrutura esbarra na dor da remessa.

Rotear delega a decisão a um roteador de modelo como camada de infraestrutura de IA. É o terceiro caminho, o que a maioria não sabia que existia ao iniciar a avaliação. Em vez de construir a inteligência de rota ou comprar a gestão dela, a empresa adota a camada que já roteia, já governa o custo por chave e já emite a fatura em real com nota fiscal. O artigo de prova do modelo roteador em produção detalha como essa economia se materializa em números, não em promessa.

A árvore abaixo resume o desempate em três linhas:

A conta de custo que ninguém faz antes do POC

Antes de qualquer prova de conceito, existe uma conta que quase nenhuma avaliação faz, e ela decide mais que as outras seis juntas. Os seis perdem. É o custo efetivo do token no Brasil, onde a fatura em dólar atravessa IRRF, CIDE, PIS, COFINS, ISS, IOF e o spread do câmbio antes de virar despesa real.

O número é específico, e o deck de economia da Nexforce Router o deixa explícito: uma fatura de US$100 mil em tokens custa até US$155 mil desembolsado no modelo direto, porque os tributos sobre remessa e a conversão adicionam até 55% em cima. A CIDE de 10% incide sobre SaaS como serviço técnico, conforme a SC Cosit 191/2017 e a 99/2018. A isenção do §1°-A do art. 2° da Lei 10.168 aplica-se somente a licença pura de software sem transferência de tecnologia, uma categoria distinta de SaaS.

A consequência é que o billing em moeda local deixa de ser um detalhe de conveniência e vira um critério de seleção. Uma camada que fatura em real, com nota fiscal e imposto incluído, muda a matemática inteira de um LLM gateway: a mesma conta que estoura em dólar vira uma despesa previsível, com crédito tributário que o caminho direto raramente captura. É por isso que o item seis da lista anterior não é um afterthought de compras, e sim a pergunta que reordena toda a planilha.

Para quem ainda não mediu o custo operacional da camada que já tem, o post sobre como medir o custo operacional de um gateway de IA em produção oferece o método de cálculo. A armadilha é achar que o custo do gateway é o preço da camada, quando ele é o preço da camada somado ao custo de cada token que ela deixa passar na rota errada, na moeda errada.

Como rodar a avaliação em 30 dias

A avaliação cabe em trinta dias, e o roteiro é um checklist de POC, não uma licitação. A regra é curta. Meça pouca coisa, meça em produção real e aborte cedo quando o critério falha.

Primeiro, fixe os sete critérios num scorecard antes de olhar qualquer fornecedor, para não acabar comparando preço de proxy com preço de roteador. Depois rode a mesma carga real, não um benchmark sintético, contra as camadas selecionadas, e meça o que o roteamento decide por request, o que o failover recupera em segundos e o que a governança cortou em custo no fim da semana.

O teste de que a camada é um roteador, não um proxy, é observável: mude o preço de um dos modelos no meio do teste e veja se a rota se ajusta sozinha. Se a resposta é que o ajuste exige mudar o código, você está diante de um endpoint único com um nome grandioso, e o POC já respondeu. Aborte no dia doze, não no dia trinta.

Por fim, rode a conta de custo efetivo em real com a fatura verdadeira, não com a estimativa. Uma camada que não emite nota fiscal em real deveria perder o critério seis mesmo que tivesse ganho os outros seis, porque ela exporta para o fornecedor o custo que a empresa estava decidindo absorver. A decisão final é de margem, não de engenharia.

FAQ

Um LLM gateway é a mesma coisa que um roteador de modelos?

Não. Um proxy de endpoint único redireciona chamadas; um roteador de modelos classifica a intenção e escolhe o modelo por custo e latência a cada request. Os dois são vendidos sob o nome comum de "gateway", mas a conta de produção e a inteligência de rota são diferentes.

Quando vale construir um LLM gateway internamente?

Vale quando a empresa mantém um time de plataforma dedicado, precisa de controle fino sobre o roteamento e aceita carregar para sempre o custo de manter failover, disponibilidade e a atualização de preço e performance de centenas de modelos. Abaixo desse perfil, não vale. O custo de manter a camada supera o custo de adotá-la.

Qual o custo de não adotar nenhuma camada?

O modelo mais caro atende a carga mais pesada por padrão, a queda de um fornecedor derruba o produto e a fatura em dólar carrega até 55% de tributos e câmbio. O custo não some. A ausência de gateway apenas o transfere para o token e para a madrugada de quem segura o incidente.

Quanto custa trocar de gateway depois de decidir mal?

Depende do tempo de migração que o critério sete mede. Um roteador compatível com a API muda de endpoint sem reintegração. Uma camada interna exige reescrever a integração. Um gateway como serviço prende o contrato e o lock-in, então o custo de desfazer a escolha vira o argumento decisivo para não fazer a escolha errada.

Como o billing em moeda local muda a avaliação?

Ele transforma o custo efetivo em real previsível, com nota fiscal e crédito tributário, em vez de uma fatura em dólar que atravessa IRRF, CIDE, PIS, COFINS, ISS, IOF e o spread do câmbio. No Brasil esse é o critério que reordena a planilha. A conversão adiciona até 55% ao token.

Referências e Leitura Complementar

• LLM Gateway: What It Is and Why Your Company Needs One é o post de awareness do tema, que define o que um gateway faz e por que uma empresa em produção chega a ele.
• Model Router: prove AI savings in production detalha a economia do roteamento em números de produção.

O que muda para quem decide com critério

A diferença entre quem adota um LLM gateway por inércia e quem escolhe por critério não aparece no dia da compra. Aparece no primeiro mês em que o scorecard sobrevive à produção real: o failover segurou a queda, a governança cortou o custo antes de estourar e a fatura veio em real com nota fiscal, sem a surpresa do câmbio.

Quem decide com critério não discute mais fornecedor. Discute categoria, e sabe nomear a decisão que tomou: construir a camada, comprar o serviço ou rotear via um roteador de modelo. A conta decide. A terceira opção é a que remove a decisão de rota do código e a move para a infraestrutura de IA, onde pertence.

O Nexforce Router é a resposta da terceira opção: um LLM gateway e roteador com classificação de intenção, failover automático, governança de custo por chave, observabilidade completa e billing em real com nota fiscal, com economia de até 50% no custo por token. A avaliação começa em um único critério que todos os outros escondem: quanto custa, em real, a escolha errada. Quem faz essa conta antes do POC já decidiu metade.