LiteLLM vs Portkey vs OpenRouter (2026)

Atualizado: 18 de agosto de 2026

Um LLM Gateway é uma camada intermediária que centraliza chamadas para múltiplos provedores de LLM (OpenAI, Anthropic, Google, modelos abertos) atrás de uma única API compatível com OpenAI, adicionando roteamento, fallback, cache, observabilidade e guardrails. Em 2026, as três opções que dominam decisões de produção são LiteLLM (open-source auto-hospedado), Portkey (SaaS focado em governança) e OpenRouter (marketplace hospedado com 300+ modelos). Este guia compara latência, custo, funcionalidades e casos de uso reais para você escolher com base em evidência, não em marketing. (Confesso: gastei um trimestre inteiro entre 2025 e 2026 testando os três em produção, então boa parte do que segue vem de dor real.)

LiteLLM é o padrão para times que querem controle total. Suporta 100+ provedores e adiciona 8–20ms de latência auto-hospedado; open-source com tier comercial para RBAC.
Portkey se diferencia em observabilidade e guardrails de produção: PII masking, jailbreak detection e cache semântico que reduz custos em 30–50% em cenários repetitivos.
OpenRouter é a rota mais rápida para experimentar 300+ modelos com uma chave, mas cobra 5,5% sobre créditos e adiciona 40–150ms de overhead. Bom para prototipagem, marginal para produção sensível a latência.
Latência do gateway não é opcional. Um fallback bem configurado pode salvar sua aplicação quando um provedor cai, mas cada milissegundo importa em UX conversacional.
Cache semântico só compensa quando suas requisições têm padrões repetitivos. Em agentes com function calling dinâmico, o hit-rate cai a menos de 5%.
Auto-hospedar LiteLLM em um único node satura acima de 500 RPS; para escala, use múltiplas réplicas atrás de um load balancer ou considere SaaS.

O que é um LLM Gateway e quando você precisa de um

Um LLM Gateway é um proxy HTTP que fica entre sua aplicação e um ou mais provedores de LLM. Em vez de importar o SDK da OpenAI aqui, o SDK da Anthropic ali e o cliente do Bedrock em outro lugar, você chama um único endpoint com o formato do chat.completions da OpenAI e o gateway resolve o resto: autenticação por provedor, tradução de payloads, roteamento por modelo, retries, fallbacks, cache e logging.

Na prática, você começa a precisar de um gateway assim que atende a pelo menos um destes critérios: (1) seu produto oferece escolha de modelo ao usuário final; (2) você precisa de failover automático quando a OpenAI ou a Anthropic tem incidente (e ambas tiveram outages significativos em 2025 e 2026); (3) times diferentes na empresa consomem LLMs e você precisa de budgets separados; (4) compliance exige que dados sensíveis nunca saiam da sua VPC; ou (5) você quer trocar Claude Sonnet por Haiku em rotas de baixa complexidade sem redeploy.

Se sua aplicação usa um único modelo, roda em baixa escala e não tem requisitos de auditoria, um gateway é overhead injustificado. Chamar diretamente o SDK oficial é mais simples, tem menos latência e menos peças móveis. Como regra prática: se você não consegue explicar em uma frase o problema que o gateway resolve, provavelmente não precisa dele ainda.

Comparação rápida: LiteLLM vs Portkey vs OpenRouter

A tabela abaixo resume as dimensões que costumo usar quando um time me pergunta qual escolher. Os números de latência refletem benchmarks independentes reportados em 2026 e variam com região, tamanho do prompt e infraestrutura de hospedagem.

Dimensão	LiteLLM	Portkey	OpenRouter
Modelo de entrega	Open-source (self-hosted) + tier Cloud pago	SaaS + Enterprise self-hosted	SaaS hospedado
Provedores suportados	100+	250+	300+ modelos
Latência adicionada (P95)	8–20 ms self-hosted	10–20 ms independentes	40–150 ms
Preço base	Gratuito (self-host)	Free tier + planos por logs	5,5% sobre créditos + $0,80 mín.
Cache semântico	Sim (Redis)	Sim (nativo, 30–50% economia relatada)	Não nativo
Guardrails/PII	Básico via integração	Nativo (PII, jailbreak, moderação)	Não
Observabilidade	Integra com Langfuse, OpenTelemetry	Dashboard próprio + export OTel	Painel simples de uso
RBAC e virtual keys	Tier comercial	Nativo	Chaves por projeto (básico)
Melhor para	Times com DevOps que querem controle	Governança e produção regulada	Prototipagem e apps consumer

LiteLLM em detalhes: proxy open-source com fallback

Honestamente, LiteLLM é dois projetos no mesmo repositório: uma biblioteca Python (litellm.completion(...)) que padroniza a chamada para 100+ provedores, e um proxy server em FastAPI que expõe uma API compatível com OpenAI e centraliza roteamento, fallbacks, budgets e logging. Em produção, o valor está no proxy. Ele desacopla o cliente do provedor e permite mudar de modelo por configuração.

A configuração vive em um único arquivo config.yaml. Aqui está um exemplo real que uso como ponto de partida para times novos, com fallback entre Anthropic e OpenAI e um alias que roteia "modelo-barato" para Haiku:

model_list:
  - model_name: modelo-barato
    litellm_params:
      model: anthropic/claude-haiku-4-5-20251001
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: modelo-barato
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY

router_settings:
  routing_strategy: simple-shuffle
  num_retries: 2
  timeout: 30
  fallbacks:
    - modelo-barato: [openai/gpt-4o-mini]

general_settings:
  master_key: sk-1234
  database_url: os.environ/DATABASE_URL

Você sobe o proxy com litellm --config config.yaml --port 4000 e passa a chamar http://localhost:4000/v1/chat/completions em vez do endpoint da OpenAI. Toda a lógica de fallback, retry e logging fica transparente para o código de aplicação. Se você já leu meu artigo sobre function calling em agentes de produção, a mesma definição de tools funciona sem alteração; LiteLLM traduz para o formato de cada provedor.

O ponto fraco é operacional. Em alta concorrência (500+ RPS), o overhead do Python começa a pesar e a P99 sobe rápido em um único node. Já apanhei nisso durante um Black Friday: a solução é rodar múltiplas réplicas atrás de um load balancer e usar Redis como backend de rate-limiting compartilhado. RBAC completo, workspaces e audit logs granulares estão no tier LiteLLM Enterprise, não na versão open-source. Vale conferir o repositório em GitHub antes de bater o martelo.

Portkey em detalhes: governança e cache semântico

Portkey nasceu como "control panel para IA em produção" e a diferença fica clara no que ele te dá de graça em relação ao LiteLLM: um dashboard que já mostra latência por rota, custo por usuário, tokens por feature, taxa de cache hit e violações de guardrail, sem precisar plugar Langfuse, OpenTelemetry e um dashboard próprio no Grafana. Para times que já sofreram para montar um stack de observabilidade de LLM em produção, o valor de "tudo já vem ligado" é real.

Onde Portkey brilha é em cache semântico. Ao contrário de cache exato (só bate se o prompt for byte-a-byte igual), o cache semântico usa embeddings para reconhecer requisições equivalentes. "Qual o horário de funcionamento?" e "Vocês abrem que horas?" viram um único hit. Em atendimento ao cliente com padrões repetitivos, times reportam 30–50% de redução de custo apenas com cache semântico ativado. É um complemento natural do prompt caching nativo dos provedores, que resolve o outro lado do problema (contexto grande e estável).

Guardrails são o segundo diferencial: detecção de PII, filtros de moderação, detecção de jailbreak e políticas de retenção, tudo aplicado no gateway antes do request chegar ao provedor. Para produtos que precisam falar com auditoria interna (saúde, financeiro, jurídico), essa camada evita ter que reconstruir a mesma lógica em cada microserviço.

O modelo de preço é peculiar. Cobra por logs registrados, não por requisição. Quando você excede o limite, o gateway continua roteando; você só perde observabilidade sobre o excedente. Em benchmarks independentes, o overhead de latência fica em 10–20ms, o que é competitivo. A documentação oficial em portkey.ai/docs tem exemplos maduros para os principais casos.

OpenRouter em detalhes: marketplace de modelos

OpenRouter tem uma proposta mais estreita e faz muito bem o que faz: te dá acesso a 300+ modelos, inclusive versões abertas hospedadas por parceiros como Fireworks, Together e DeepInfra, atrás de uma única chave e um único débito. Você paga o preço do modelo mais 5,5% de fee sobre créditos comprados, sem contrato, sem SLA formal para a maioria dos planos.

Para prototipagem e aplicações consumer que querem oferecer "escolha seu modelo" ao usuário, OpenRouter é imbatível em time-to-first-token do lado do desenvolvedor. Você lê o preço por milhão de tokens no catálogo do OpenRouter, seleciona o slug do modelo (anthropic/claude-sonnet-5, meta-llama/llama-4-maverick, etc.) e chama:

from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key="sk-or-...",
)

resp = client.chat.completions.create(
    model="anthropic/claude-sonnet-5",
    messages=[{"role": "user", "content": "Explique embeddings em 3 linhas."}],
    extra_headers={
        "HTTP-Referer": "https://meuapp.com",
        "X-Title": "Meu App",
    },
)
print(resp.choices[0].message.content)

Onde eu não uso OpenRouter é em produção sensível a latência. O overhead de 40–150ms (que vem tanto da distância geográfica dos edge nodes quanto do provisionamento em provedores parceiros) é aceitável para chat, mas mata UX em voz em tempo real, autocomplete e agentes que fazem múltiplas chamadas encadeadas. E como você depende do routing interno do OpenRouter para escolher o backend, debugar por que uma requisição foi para um provedor específico é mais difícil do que se você chamasse a Anthropic direto.

Qual é o melhor LLM Gateway para produção?

Não existe "melhor" absoluto: existe melhor para um perfil. Depois de instrumentar dezenas de deploys, esta é a heurística que aplico sem ficar pensando muito:

Startup ou time pequeno, foco em enviar produto: comece com OpenRouter para prototipar e valide se você realmente precisa de gateway. Se sim, migre para LiteLLM auto-hospedado. Dá 90% do valor por 0% do custo mensal.
Scale-up com equipe de plataforma dedicada: LiteLLM self-hosted em Kubernetes com Redis para rate-limit e Langfuse para traces. Adicione Portkey só se guardrails ou compliance forem requisito duro.
Empresa regulada (saúde, financeiro, jurídico): Portkey Enterprise ou LiteLLM Enterprise. A pergunta não é "qual é mais barato", é "qual passa no seu processo de fornecedor". Geralmente Portkey ganha por já ter SOC 2, ISO 27001 e opção de hospedagem em VPC.
Produto consumer com múltiplos modelos como feature: OpenRouter na produção, sem cerimônia. O overhead de latência costuma ser aceitável e o time-to-market compensa.

A pior escolha é postergar a decisão até estar em incêndio. Um gateway introduzido depois que a aplicação está monolítica com OpenAI hardcoded em 50 arquivos custa duas semanas de refactor. Introduzido no dia 1 do MVP, custa 30 minutos de configuração. Já vi os dois cenários, e o segundo é infinitamente mais divertido.

Como implementar fallback entre provedores

Fallback bem feito é o motivo número um para adotar um gateway. Sem ele, um incidente da OpenAI vira um incidente da sua aplicação. Com ele, você degrada de GPT-5 para Claude Sonnet ou Gemini 3 Pro em milissegundos e o usuário não percebe. A regra de ouro é: fallback só entre modelos que respondem para o mesmo schema. Se você depende de function calling, valide antes que o modelo alvo aceita as ferramentas no formato esperado.

Em LiteLLM, você define a cadeia por model_name. Isto usa Anthropic como primário, cai para OpenAI, e só então para Gemini se as duas primeiras falharem:

router_settings:
  fallbacks:
    - claude-sonnet-5:
        - openai/gpt-5
        - vertex_ai/gemini-3-pro
  num_retries: 2
  timeout: 20
  cooldown_time: 30
  allowed_fails: 3

Os parâmetros allowed_fails e cooldown_time implementam um circuit breaker. Depois de N falhas em janela, o gateway para de tentar aquele provedor por X segundos. Isso evita amplificar um incidente empilhando retries em cima de uma API já sobrecarregada.

Uma armadilha clássica: não faça fallback silencioso em rotas com function calling estruturado sem validar o output. Um provedor pode aceitar seu schema JSON mas retornar campos ligeiramente diferentes. Sem structured outputs com JSON Schema validado no cliente, você troca um erro visível (timeout) por um erro invisível (dados corrompidos silenciosamente). Já perdi umas boas horas caçando bug assim.

Custos, observabilidade e integração com evals

Todo LLM Gateway sério deve responder três perguntas em tempo real: quanto gastei, onde gastei e o que está falhando. LiteLLM+Langfuse, Portkey nativo e OpenRouter (limitado) atacam isso de formas diferentes.

Custos: Portkey tem breakdown por usuário, feature e modelo out-of-the-box. Em LiteLLM, você tem spend_logs em Postgres. Dá para plugar em Metabase ou Grafana e ter dashboards ricos, mas precisa de trabalho. OpenRouter mostra gasto agregado no painel dele, sem tags customizadas.

Observabilidade: para produção, exportar OpenTelemetry é o mínimo. LiteLLM emite spans OTel para qualquer backend compatível (Jaeger, Tempo, Datadog). Portkey exporta também. OpenRouter não tem export granular; se você precisa de tracing distribuído (correlacionar uma chamada LLM com o request HTTP que a originou), OpenRouter fica limitado.

Integração com evals: um gateway bem plugado alimenta seu pipeline de avaliação de LLMs com DeepEval e Ragas automaticamente. Faça sample de 1% das requisições de produção, rode offline evals (fidelidade, groundedness, tool-use correctness) e alerte quando uma métrica degradar. Fazer isso sem gateway é possível mas duplica código; com gateway, é um webhook.

Se você quer benchmark próprio antes de decidir, o padrão que uso é: 10.000 requisições reais anonimizadas do log de produção, replayed contra os três gateways em paralelo, medindo P50/P95/P99 de latência, taxa de sucesso e custo total. Publiquei o script no meu repositório e você pode adaptar em uma tarde.

Perguntas frequentes

LiteLLM é realmente gratuito?

Sim, a versão open-source é gratuita para uso comercial sob licença MIT. Você paga apenas pela infraestrutura onde hospeda o proxy (VPS, Kubernetes, Redis). O tier LiteLLM Enterprise, pago, adiciona RBAC granular, SSO, audit logs, suporte SLA e algumas integrações premium. Vale para times que precisam desses controles por compliance.

Qual a diferença entre OpenRouter e LiteLLM?

OpenRouter é um serviço hospedado que você consome como SaaS: não gerencia infra, paga 5,5% sobre créditos. LiteLLM é software que você hospeda (ou consome via LiteLLM Cloud); controla latência, roteamento e logs, mas assume operação. OpenRouter é mais rápido para começar; LiteLLM é mais barato e flexível para escala.

Portkey vale a pena para times pequenos?

Depende do problema. Se você precisa de guardrails de PII, cache semântico e um dashboard de observabilidade sem montar nada, o free tier já entrega valor. Se seu caso é só rotear entre dois provedores sem compliance apertado, LiteLLM auto-hospedado costuma ser suficiente e sai de graça.

Um LLM Gateway adiciona latência a ponto de comprometer UX?

Depende do gateway e da infra. LiteLLM self-hosted próximo dos provedores adiciona 8 a 20ms, imperceptível em chat. OpenRouter adiciona 40 a 150ms, perceptível em voz em tempo real e autocomplete. Sempre meça no seu ambiente antes de decidir; benchmarks de vendor raramente batem com o que sua aplicação vê.

Cache semântico realmente reduz custos de LLM?

Reduz sim, mas só quando suas requisições têm padrões repetitivos: FAQs, suporte, buscas em base de conhecimento. Em cenários com hit rate acima de 20%, economias de 30–50% são comuns. Em agentes com function calling dinâmico e contexto único por chamada, o hit rate cai abaixo de 5% e o overhead do lookup pode piorar a latência.