Alternativas ao LiteLLM (2026) — gateways hospedados, planos de controle com sua própria chave e quando continuar usando-o

O LiteLLM é um proxy de código aberto compatível com OpenAI que você executa por conta própria: ele fica na frente das suas próprias contas de fornecedores e oferece ao seu código um endpoint e um formato de chave únicos entre eles (sua documentação). As equipes procuram alternativas por dois motivos sem relação entre si. Operacional: um proxy hospedado por você é mais um serviço para atualizar, escalar e monitorar. Cadeia de suprimentos: em 24 de março de 2026, um invasor publicou duas versões comprometidas do LiteLLM no PyPI, e o incidente colocou diante de muitas equipes a superfície de ataque de “um pacote na sua compilação”, algo que elas não haviam contabilizado. Esta comparação relaciona cada motivação à ferramenta que realmente a atende — incluindo o caso de continuar usando o LiteLLM, que é mais forte do que as sete listas de fornecedores desta pesquisa sugerem.

Viés declarado desde o início: o Kunavo é nosso produto e aparece primeiro. Todos os demais produtos abaixo recebem uma recomendação genuína; os detalhes que verificamos estão nas páginas de comparação, e os dois produtos que não avaliamos são descritos apenas no nível declarado pelos próprios sites.

A lista curta

A distinção que resolve a maior parte da questão

O LiteLLM faz duas coisas ao mesmo tempo, e a maioria das substituições faz apenas uma. Ele é um proxy (um endpoint para vários fornecedores) e uma ferramenta BYO-key (as contas dos fornecedores continuam sendo suas). Um gateway de inferência hospedado — Kunavo, OpenRouter — substitui ambos: não há proxy para executar nem conta de fornecedor para manter, porque o gateway mantém as credenciais upstream e cobra você pelo uso. Um plano de controle hospedado — Portkey, TrueFoundry — substitui apenas o primeiro: você deixa de operar o proxy, mas mantém as contas. Saber qual metade você está substituindo resolve a maior parte desta lista. O padrão em si é explicado no guia de gateways de LLM.

O que realmente levou as pessoas a pesquisar

O principal resultado desta pesquisa não é uma lista — é uma discussão no Reddit sobre o ataque à cadeia de suprimentos. Eis o que aconteceu, segundo a própria atualização de segurança do LiteLLM: em 24 de março de 2026, um invasor publicou litellm==1.82.7 e litellm==1.82.8 no PyPI com código malicioso injetado nos wheels distribuídos. Eles ficaram disponíveis a partir das 10:39 UTC por aproximadamente 40 minutos, antes de o PyPI colocá-los em quarentena. O comprometimento foi rastreado até a dependência Trivy no fluxo de trabalho de análise de segurança de CI/CD do LiteLLM; o invasor contornou o fluxo oficial de lançamento e fez o upload diretamente para o PyPI. Segundo a SecurityWeek, mais de 2.500 organizações foram afetadas.

A correção do LiteLLM está registrada e é substancial: os pacotes comprometidos foram removidos, as credenciais dos mantenedores foram rotacionadas, a Mandiant foi contratada para a perícia e a v1.83.0 foi lançada por meio de um pipeline de CI/CD reconstruído, com ambientes de compilação isolados, controles de lançamento mais fortes e imagens Docker assinadas com cosign. Se você está na 1.83.0 ou posterior e não executava uma versão comprometida durante aquela janela de 40 minutos, o incidente está encerrado para você.

O motivo pelo qual isso ainda leva as pessoas a esta pesquisa é estrutural, não específico do LiteLLM. Um proxy hospedado por você é um pacote na sua compilação, o que coloca seu CI/CD e seu cluster dentro do raio de impacto dele. Essa é a frase que vale a pena considerar — ela também é verdadeira para todas as alternativas hospedadas por você nesta página, inclusive o MLflow AI Gateway, e é a única coisa que um endpoint hospedado remove: você chama uma URL HTTPS, portanto não há pacote para comprometer nem nada do gateway sendo executado dentro da sua rede.

A outra metade, honestamente: um gateway hospedado não é mais seguro; sua exposição é diferente. Sua chave de API e o texto dos seus prompts passam pela infraestrutura de outra pessoa, e você assume o risco de violação dela em lugar do risco de aplicar seus próprios patches. Se o texto dos prompts não puder sair da sua infraestrutura, hospedar a solução por conta própria é a resposta correta, e o restante desta página trata de uma troca que você não deve fazer.

1. Kunavo — sem proxy, sem contas de fornecedores

O Kunavo é um gateway de inferência hospedado: uma base URL compatível com OpenAI, uma chave sk-kn-, um saldo pré-pago conforme o uso, e nós mantemos as credenciais dos fornecedores upstream, não você. Em comparação com o LiteLLM, isso representa uma divisão de responsabilidades diferente — você não executa um proxy nem mantém contas separadas na Anthropic, no Google e na OpenAI.

Preço: a maior parte do catálogo aparece abaixo das tarifas oficiais dos fornecedores — Claude Sonnet 4.6 a $2.10 / $10.50 por 1M de tokens, em comparação com as tarifas da Anthropic de $3.00 / $15.00. O LiteLLM não aplica acréscimo porque não revende nada; o que você paga é o valor do seu próprio acordo com o fornecedor, portanto a comparação é entre nossa tarifa e sua tarifa direta, não com zero. Cobertura: modelos de chat, imagem, vídeo e música na mesma chave e no mesmo saldo. O que ele não faz: rotear suas próprias chaves de fornecedores — essa é a metade BYO-key que o LiteLLM mantém e nós não substituímos. Detalhes: Kunavo vs LiteLLM.

2. OpenRouter — o catálogo mais amplo

O outro gateway de inferência hospedado, e a escolha certa quando a amplitude do catálogo importa mais do que o preço unitário: centenas de modelos de um grande conjunto de fornecedores em uma única carteira, além de planos gratuitos e roteamento com sua própria chave, algo que o Kunavo não oferece. Se você está deixando o LiteLLM porque quer parar de manter contas, OpenRouter e Kunavo são as duas opções realistas. Kunavo vs OpenRouter coloca os dois lado a lado, e a comparação do OpenRouter cobre o restante desse campo.

3. Portkey — mantenha suas chaves e elimine a operação

Um plano de controle hospedado sobre contas de fornecedores que você já possui: roteamento, fallbacks, guardrails e observabilidade, sem precisar executar seu próprio proxy. Esta é a substituição mais próxima se você escolheu o LiteLLM pelos recursos de roteamento e orçamento e a única coisa que realmente quer abandonar é a operação. Detalhes: Kunavo vs Portkey.

4. Helicone — se observabilidade era o único motivo

Muitas implantações do LiteLLM existem porque alguém precisava de logs de solicitações e atribuição de custos por equipe, e o proxy era a forma de obtê-los. Se esse for o seu caso, uma camada de observabilidade sobre suas chamadas existentes aos fornecedores é muito menor para operar do que um gateway. Detalhes: Kunavo vs Helicone.

5. TrueFoundry — quando o setor de compras precisa de um fornecedor

Ocupa a posição 2 nesta pesquisa com sua própria comparação com o LiteLLM. É um gateway de IA empresarial vendido com base em sobrecarga de latência, flexibilidade de implantação, SLAs, governança e controles prontos para auditoria (sua página de produto). Não o avaliamos, portanto esta entrada é uma referência, não uma recomendação: se o seu impedimento é que um proxy de código aberto não tem contrato de suporte, esta é a categoria que resolve isso, e vale ler a comparação sabendo que foi escrita por eles.

6. MLflow AI Gateway — a substituição de código aberto equivalente

Posição 3, e o recurso desta página mais próximo do próprio LiteLLM: um gateway de código aberto, hospedado por você, que coloca suas próprias chaves de fornecedores atrás de um endpoint e é mantido como parte do projeto MLflow. Vale dizer claramente: trocar um proxy hospedado por você por outro mantém o modelo de implantação e, portanto, mantém a superfície de ataque descrita acima. É uma escolha legítima — é o que você quer se o problema era o projeto, não o modelo.

7. Cloudflare AI Gateway — cache e limites na borda

Um proxy fino na frente das contas de fornecedores que você já possui: cache de respostas, limitação de taxa, novas tentativas e análises, sem revenda de inferência. Ele se combina com qualquer fonte de inferência, em vez de substituí-la, inclusive Kunavo ou OpenRouter. Detalhes: Kunavo vs Cloudflare AI Gateway.

Quando o LiteLLM ainda é a escolha certa

• O texto dos prompts não pode sair da sua infraestrutura. Dados regulamentados, ambientes isolados ou uma política que um gateway hospedado simplesmente não consegue atender. Hospedar a solução por conta própria é a resposta, e a única questão é qual proxy hospedado por você escolher.
• Você tem contratos negociados com fornecedores. Compromissos de gastos ou tarifas empresariais na Anthropic, OpenAI ou Google valem mais do que qualquer preço listado por um revendedor, e as ferramentas BYO-key permitem continuar usando-os.
• Você usa os orçamentos por chave e o roteamento por equipe. Esses recursos são o motivo pelo qual muitas implantações do LiteLLM existem; verifique se a substituição os cobre antes de presumir que uma troca de base URL seja toda a migração.
• Você quer um código-fonte que possa ler e corrigir. Um proxy de código aberto sob seu controle é uma propriedade real, e o incidente de março de 2026 não a elimina — foi um comprometimento do pipeline de lançamento, já corrigido, não uma falha no próprio proxy.

Mudar exige duas linhas

Todas as alternativas desta página que revendem inferência usam o protocolo de comunicação da OpenAI, portanto sair de um proxy LiteLLM é uma troca de base_url e de chave — os formatos de solicitação e resposta permanecem inalterados:

# Before: your own LiteLLM proxy, your own provider keys,
# your own container to patch.
client = OpenAI(
    api_key=os.environ["LITELLM_MASTER_KEY"],
    base_url="http://litellm.internal:4000",
)

# After: a hosted endpoint. No package in your build, no proxy to run.
client = OpenAI(
    api_key=os.environ["KUNAVO_API_KEY"],
    base_url="https://api.kunavo.com/v1",
)

resp = client.chat.completions.create(
    model="claude-sonnet-5",
    messages=[{"role": "user", "content": "Hello"}],
)
print(resp.choices[0].message.content)

A parte que não cabe em duas linhas é tudo o que o LiteLLM fazia além do roteamento: orçamentos por chave, distribuição por equipe e callbacks personalizados. Faça esse inventário primeiro. Os detalhes no nível do protocolo estão no guia da API compatível com OpenAI, e o que um gateway deve fazer por você apresenta o conjunto de recursos que você deve verificar na substituição.

Perguntas frequentes