Neste artigo
O LiteLLM é um proxy que senta entre suas aplicações e qualquer provedor de LLM. E se você já passou pela situação de ter OpenAI em um serviço, Anthropic em outro, e mais um terceiro provedor aparecendo no roadmap, sabe exatamente por que isso importa.
Sem um gateway, você escala complexidade de forma linear. Uma chave de API aqui, outro SDK ali, outro jeito de lidar com rate limit ali na frente. Quando a conta chega no final do mês, você sabe o total mas não sabe qual feature gerou o gasto.
Coloquei o LiteLLM pra rodar no homelab antes de levar para um projeto no trabalho, e a diferença em termos de controle operacional foi imediata. Não é ferramenta de hype. É infraestrutura chata que resolve um problema real.
A seguir: como funciona, quando faz sentido subir, e como colocar em Docker sem enrolação.
Por que um gateway de LLM faz sentido
Quando você tem uma aplicação chamando direto a API da Anthropic, tudo parece simples. Depois vem OpenAI para um caso diferente. Depois Mistral para teste. Depois o time de dados precisa de Cohere.
De repente você tem quatro integrações separadas, quatro formatos de request e resposta, e nenhum ponto onde você consegue ver tudo que está sendo consumido. Rate limiting vira um samba: cada SDK trata de um jeito diferente.
A outra vantagem não óbvia é padronização. Quando toda a stack passa pelo mesmo proxy, você consegue aplicar políticas de forma centralizada: logging obrigatório, timeout padrão, budget máximo por request. Sem gateway, cada integração implementa (ou deixa de implementar) isso do jeito que quer.
Quando o LiteLLM faz sentido usar
Não é para qualquer setup. Se você tem uma aplicação chamando um único modelo com um único provedor e sem previsão de mudar, adicionar um gateway só gera overhead operacional.
Os sinais de que vale a pena:
- Você usa ou vai usar mais de um provedor de LLM na mesma stack
- Precisa de fallback automático se um provedor ficar fora
- Quer rastrear custo por usuário, endpoint ou feature
- Tem múltiplos times acessando LLMs e quer controle centralizado
- Quer rate limiting sem implementar isso dentro da aplicação
Se dois ou mais desses se aplicam, o LiteLLM paga o custo operacional de subir mais uma peça na infraestrutura.
Como o LiteLLM funciona na prática
Roteamento e fallback
O LiteLLM expõe uma API compatível com o formato da OpenAI. Qualquer cliente que já chama a OpenAI funciona sem mudança de código: você só aponta a base URL para o proxy.
No config você define quais modelos estão disponíveis e qual provedor cada um usa. Quer fallback? Define uma lista em ordem de prioridade. Se o primeiro falhar ou demorar demais, o proxy tenta o próximo automaticamente.
Um detalhe importante: o LiteLLM não transforma a saída de um modelo para corresponder ao outro. Se você tem fallback de Claude para GPT-4, e o seu sistema confia em comportamentos específicos de um deles, teste o fallback como se fosse um caso separado. Não é transparente do ponto de vista semântico, só da interface.
Rastreamento de uso e custo
Todo request que passa pelo LiteLLM pode ser rastreado: tokens consumidos, modelo usado, custo estimado, usuário ou tag associado.
Você pode configurar integração com o Langfuse self-hosted para ter uma interface visual com traces completos. A combinação dos dois é provavelmente o setup de observabilidade mais prático para quem não quer depender de SaaS pago para monitorar LLMs.
Subindo o LiteLLM com Docker
A forma mais direta é via Docker. Você vai precisar de um arquivo de configuração YAML com os modelos que quer expor e as chaves de API como variáveis de ambiente.
Comandos para subir o container:
- docker pull ghcr.io/berriai/litellm:main-latest
- docker run -e OPENAI_API_KEY=sua-chave -e ANTHROPIC_API_KEY=sua-chave -p 4000:4000 -v ./litellm_config.yaml:/app/config.yaml ghcr.io/berriai/litellm:main-latest –config /app/config.yaml
Dois comandos, container rodando na porta 4000. Para produção, o mais sensato é colocar isso dentro de um Docker Compose junto com os outros serviços, incluindo reverse proxy. Se você ainda não tem o proxy configurado, tem um artigo sobre Traefik com Docker Compose que cobre isso do zero.
Configurando os provedores no LiteLLM
O arquivo YAML define quais modelos estão disponíveis. Você lista os modelos, associa cada um a um provedor e define um alias para a aplicação chamar.
O ponto de atenção é o alias. Você pode chamar um modelo Anthropic de "gpt-4" internamente para facilitar a troca de provedor sem alterar código. Mas isso cria confusão quando alguém do time não sabe que o alias não corresponde ao modelo real. Prefiro aliases descritivos: "production-claude" ou "fast-openai" são melhores do que fingir que é GPT.
As variáveis de ambiente ficam fora do YAML, nunca dentro. Chave de API em arquivo de configuração versionado é o tipo de erro que aparece em scan de segurança mais cedo ou mais tarde.
LiteLLM vs chamar a API direto
A vantagem de chamar direto é zero overhead. Sem proxy, sem latência extra, sem mais uma peça para operar.
A desvantagem é que você escala complexidade de forma linear com o número de provedores. Terceiro provedor, terceiro SDK, terceira forma de tratar erro de rate limit.
O LiteLLM inverte isso: você adiciona um provedor no config, não no código da aplicação. O overhead de latência existe (milissegundos por hop local), mas em qualquer setup que chama LLM, o tempo de inferência vai dominar esse número com folga.
Quando a stack tem um único modelo sem previsão de mudança, chamar direto é mais simples. Quando já tem ou vai ter dois ou mais provedores, o gateway paga o custo em poucos sprints.
O custo de não ter controle centralizado
Sem um ponto centralizado, custo de LLM vira um mystery box. Você sabe quanto gastou no mês, mas não sabe qual feature ou usuário gerou o gasto. Quando a conta sobe, a investigação começa do zero.
O artigo sobre como monitorar custo e latência de LLMs cobre a camada de análise com mais detalhe. O LiteLLM resolve a coleta de dados. O que você faz com eles depois depende de como você monta os alertas e os dashboards.
Perguntas frequentes
LiteLLM é gratuito?
A versão open source é gratuita e cobre a maioria dos casos. Existe um plano Enterprise com SSO, audit log e controles mais granulares, mas você não vai precisar disso no começo.
Funciona com modelos locais via Ollama?
Funciona. O proxy tem suporte nativo ao Ollama, então você pode rotear requests entre um modelo local (para casos onde privacidade ou custo importam) e um modelo de API quando precisar de mais capacidade.
Precisa de Kubernetes para rodar em produção?
Não. Docker Compose resolve para a maioria dos setups. Kubernetes faz sentido se você precisa de escala horizontal automática ou já tem o cluster por outras razões. Para um time pequeno, Compose com restart policy é suficiente.
Tem suporte a streaming?
Tem. Streaming funciona transparentemente pelo proxy, incluindo para clientes que usam o SDK da OpenAI sem qualquer mudança de código.
E se o LiteLLM cair?
Você perde a capacidade de chamar qualquer LLM até o container voltar. Esse é o trade-off de ter um único ponto de entrada. Para mitigar: healthcheck configurado, restart automático no Compose e alerta de downtime. Trate o proxy com a mesma seriedade que qualquer outro componente crítico da stack.
Conclusão com LiteLLM
O LiteLLM é uma peça que simplifica de verdade quando o setup começa a crescer. Não é algo para instalar no primeiro dia, mas quando você passa a gerenciar dois ou mais provedores, a centralização compensa.
A documentação oficial do LiteLLM cobre todos os provedores suportados e opções avançadas, incluindo load balancing e controle de budget por usuário.
Se você já tem Docker Compose rodando na infraestrutura, subir o proxy é questão de horas. A parte que leva mais tempo é decidir quais modelos expor e como nomear os aliases de forma que faça sentido para o time inteiro.
O que fazer agora:
- Levante quais provedores de LLM a sua stack já usa ou vai usar em breve
- Suba o LiteLLM em ambiente local antes de levar para produção
- Conecte ao Langfuse para ter visibilidade completa de custo por request
