OpenRouter vs acesso direto: como escolher a forma de chamar LLMs

As três formas de colocar uma chamada a um LLM em produção

1) API direta do provedor

Você integra sua aplicação ao endpoint de um único fornecedor e assume todo o resto: novas tentativas, alternativas em caso de falha, acompanhamento do uso, rotação de chaves e recuperação de falhas.

Esse é o caminho mais simples quando:

• você já sabe qual modelo quer,
• a latência importa,
• os requisitos de conformidade exigem uma cadeia menor de fornecedores,
• e seu tráfego é estável o suficiente para que você possa planejar considerando os limites de um único provedor.

2) Gateway / agregador / retransmissor

Você envia requisições a uma camada intermediária que as encaminha para um entre vários provedores. O OpenRouter é o exemplo mais conhecido, mas esse padrão vai além de qualquer empresa específica.

Essa opção é atraente quando:

• você quer poder escolher entre modelos com uma única integração,
• precisa de roteamento alternativo em caso de falha,
• faz experimentos frequentes com modelos,
• ou não quer gerenciar SDKs e contas de cobrança de vários fornecedores.

3) Hospedagem própria

Você executa um modelo aberto na sua própria infraestrutura, geralmente por trás do seu próprio roteador.

Essa opção leva vantagem quando:

• o controle dos dados é inegociável,
• o volume é alto o suficiente para manter o hardware ocupado,
• ou você precisa de custos previsíveis por token e consegue assumir a carga operacional.

O que muda na prática

Este é o ponto que as pessoas deixam passar: a melhor escolha geralmente não depende apenas do preço bruto dos tokens. Ela depende de toda a cadeia de falhas.

A tabela esconde uma verdade importante: um gateway raramente economiza dinheiro por mágica. Ele economiza quando evita complexidade desnecessária, reduz o tempo de indisponibilidade ou permite encaminhar tarefas automaticamente para o modelo mais barato que atenda aos requisitos.

Onde os custos realmente mudam

Se você usa um único modelo para tudo, chamá-lo diretamente costuma ser a opção mais simples e barata. Mas a maioria dos sistemas reais é mais complexa:

• o chat do produto usa um modelo premium,
• os rascunhos de respostas de suporte usam um modelo mais barato,
• a sumarização usa um modelo pequeno e rápido,
• e os picos de tráfego exigem capacidade adicional.

É aí que um intermediário pode ajudar. Não porque tenha preços de tabela mais baixos, mas porque permite centralizar as decisões de roteamento.

Uma política simples poderia ser assim:

{
  "primary": "anthropic/claude-sonnet-4.6",
  "fallbacks": [
    "openai/gpt-5.5",
    "google/gemini-3"
  ],
  "cheap_path": "openai/haiku-class",
  "timeout_ms": 8000,
  "retry_on": ["rate_limit", "timeout", "upstream_5xx"]
}

Essa configuração não é específica de um fornecedor; ela representa a estrutura de um roteador bem projetado. Na prática, a economia vem de evitar desperdícios:

• não envie toda tarefa de extração para seu modelo mais caro,
• não repita indefinidamente as tentativas com um provedor instável,
• não mantenha uma segunda integração apenas para os 2% de tráfego que aumentam nas sextas-feiras.

Uma armadilha comum: se seu aplicativo faz chamadas de ferramentas ou produz efeitos colaterais, novas tentativas podem duplicar ações. Se um gateway repetir uma solicitação após um tempo limite, o modelo poderá emitir novamente a mesma chamada de função. Sem chaves de idempotência e um projeto cuidadoso das ferramentas, uma “alternativa útil” se transforma em “ticket duplicado” ou “pagamento cobrado duas vezes”.

Quando um gateway realmente ajuda

Eu recorreria a um agregador ou intermediário quando uma ou mais destas condições fossem verdadeiras:

• Você ainda está entendendo a carga de trabalho. No início, você não sabe se GPT-5.5, Claude Opus 4.8, Sonnet 4.6, Gemini 3 ou um modelo aberto será a melhor opção para sua tarefa.
• Você quer roteamento por tarefa, não por fornecedor. Um classificador pode enviar prompts curtos para um modelo barato e rápido e tarefas com contexto longo para algo como Fable 5, quando essa for de fato a opção mais adequada.
• Você precisa de uma estratégia rápida de contingência. Se um provedor começar a limitar a taxa de solicitações, o intermediário poderá redirecionar o tráfego antes que seus usuários percebam.
• Você não quer cinco sistemas de faturamento. Uma única fatura e uma única integração são mais fáceis de gerenciar do que várias chaves, cotas e painéis de gastos.
• Você precisa de uma camada de abstração para produtos com múltiplos locatários. Um gateway permite trocar de provedor nos bastidores sem reescrever seu aplicativo.

Isso é especialmente útil se sua equipe é pequena. Já vi equipes de startups passarem mais tempo implementando lógica de novas tentativas específica de cada provedor do que gerando valor para o produto. Um intermediário pode concentrar esse trabalho em um só lugar.

Quando a integração direta é a melhor escolha

As APIs diretas dos provedores geralmente são a melhor opção quando você prioriza algum dos seguintes aspectos:

• Menor latência. Um salto a menos faz diferença quando o orçamento de latência do seu produto é apertado. Se você quer uma interação de 300 ms que “pareça instantânea”, a sobrecarga de rede e roteamento pode consumir uma parcela significativa desse tempo.
• Limites rígidos de conformidade. Cada processador adicional representa mais uma relação, mais um conjunto de regras de retenção e mais uma revisão contratual.
• Recursos específicos do fornecedor. Alguns provedores oferecem recursos que os agregadores acabam eliminando na padronização ou demoram a incorporar.
• Volume alto e previsível. Quando o uso se estabiliza, um roteamento personalizado pode sair mais barato do que pagar por uma camada intermediária.
• Canais de suporte mais claros. Quando algo falha, há menos troca de acusações.

O benefício oculto é a clareza operacional. Se o caminho da chamada é direto, fica mais fácil isolar a causa raiz de uma falha. Se houver uma falha, ela geralmente estará no seu código ou no provedor. Com um gateway, você também precisa investigar se a responsabilidade foi do intermediário, da camada de roteamento dele ou do provedor de destino.

Hospedar por conta própria é outra história

Hospedar modelos abertos por conta própria não é apenas ter uma “API mais barata, mas no meu servidor”. É um problema de sistemas.

Você precisa considerar:

• dimensionamento e utilização de GPUs,
• processamento em lotes,
• quantização,
• pressão sobre o cache KV,
• escalabilidade automática,
• inicializações com recursos já preparados,
• filtros de segurança,
• atualizações de modelos,
• e procedimentos de reversão.

A vantagem é o controle. Se sua carga de trabalho for estável e suficientemente alta, hospedar por conta própria pode ser economicamente atraente. Mas a conta só fecha quando você mantém o hardware ocupado. GPUs ociosas custam caro. O tempo de engenharia necessário para fazer uma infraestrutura de disponibilização de modelos funcionar sob pressão também.

Outra armadilha comum é a variação de qualidade. Um modelo aberto pode ser bom o suficiente para sumarização hoje, mas seus resultados nas avaliações podem desmoronar quando mudam o tamanho dos prompts, os requisitos de estilo ou o uso de ferramentas. Não presuma que “aberto” signifique automaticamente “barato o suficiente para substituir uma API gerenciada”.

Um padrão híbrido prático

Em sistemas reais, a melhor arquitetura costuma ser mista:

# direct path for latency-sensitive traffic
export LLM_ROUTE=direct
export LLM_PROVIDER=anthropic
export LLM_MODEL=claude-sonnet-4.6

# relay path for experimental or burst traffic
export LLM_ROUTE=gateway
export LLM_MODEL=openai/gpt-5.5

E dentro do aplicativo:

def choose_route(task_type, tenant_tier, prompt_tokens):
    if task_type == "tool_calling":
        return {"route": "direct", "model": "anthropic/claude-sonnet-4.6"}
    if prompt_tokens > 120_000:
        return {"route": "gateway", "model": "openai/gpt-5.5"}
    if tenant_tier == "free":
        return {"route": "gateway", "model": "openai/haiku-class"}
    return {"route": "direct", "model": "google/gemini-3"}

Esse padrão mantém o caminho crítico simples e ainda oferece flexibilidade de roteamento. Na minha experiência, é nesse ponto que as equipes costumam chegar após o primeiro mês em produção: integração direta para a experiência central do usuário, gateway para experimentação e capacidade adicional, e hospedagem própria apenas quando os benefícios econômicos ou de privacidade são incontestáveis.

Privacidade, latência e confiança

É aqui que a engenharia se transforma em política.

Privacidade

Um gateway altera seu limite de confiança. Mesmo que os prompts sejam encaminhados ao provedor de destino, você ainda precisa responder:

• O intermediário registra os prompts?
• Por quanto tempo eles são retidos?
• Quais subprocessadores podem acessá-los?
• É possível manter determinados locatários em um caminho restrito?
• Há suporte para fixar a região?

Para cargas de trabalho regulamentadas, “o provedor prometeu se comportar bem” não basta. Você precisa de um registro documental e de um projeto que esteja alinhado a ele.

Latência

Um intermediário acrescenta outro salto. Isso não torna o aplicativo automaticamente lento, mas adiciona incerteza. Se seu aplicativo faz muitas chamadas e o streaming de tokens é importante, cada camada extra pode tornar o tempo até o primeiro token menos previsível.

Limites de requisições

Integrações diretas expõem os limites do provedor sem intermediação. Gateways podem amenizar isso distribuindo o tráfego entre provedores, mas também podem introduzir suas próprias restrições de taxa. Em outras palavras: você pode trocar um limite por outro. O ganho é elasticidade, não imunidade.

A regra de decisão que uso

Se eu tivesse que resumir a escolha em uma frase: use a integração direta quando souber qual modelo usar e se importar com o caminho da chamada; use um gateway quando valorizar opções e resiliência; hospede por conta própria quando o controle e a utilização constante justificarem os custos operacionais.

Algumas regras práticas concretas:

• Comece com uma integração direta se estiver lançando seu primeiro recurso em produção e precisar de apenas um modelo.
• Adicione um gateway quando tiver pelo menos duas classes distintas de modelos ou quando a necessidade de alternância em caso de falha começar a aparecer nas análises de incidentes.
• Hospede por conta própria somente depois de ter dados reais de utilização e um motivo claro para assumir a infraestrutura.
• Use um gateway para experimentar com roteamento, mas mantenha seu caminho crítico idempotente.
• Meça o custo de ponta a ponta, não apenas o preço dos tokens.

Recomendações Práticas

• Prefira APIs diretas para obter a latência mais previsível, a depuração mais simples e o melhor suporte específico do fornecedor.
• Prefira um gateway/agregador quando precisar de roteamento entre vários modelos, cobertura de contingência ou uma única integração com vários provedores.
• Prefira hospedagem própria somente quando puder manter o hardware ocupado e aceitar a complexidade operacional.
• Implemente idempotência e disciplina nas novas tentativas antes de adicionar alternativas automáticas em caso de falha.
• Compare custo total: tokens, margem adicional, novas tentativas, tempo de engenharia e recuperação de incidentes.
• Mantenha privacidade e retenção na decisão desde o primeiro dia, não depois que o setor de compras perguntar.
• Use uma arquitetura híbrida se sua carga de trabalho tiver tanto fluxos premium quanto fluxos básicos.

Se quiser, posso transformar isso em uma versão com posicionamento mais definido para um público específico, como fundadores de startups, equipes de plataforma ou equipes empresariais com requisitos rigorosos de conformidade.