any-llm - uma interface única para diversos provedores de LLM

 (github.com/mozilla-ai)
7 pontos por xguru 2025-07-25 | 3 comentários | Compartilhar no WhatsApp
  • Biblioteca Python criada pela equipe Mozilla AI que permite usar mais de 20 provedores de LLM com uma única função
    • Ao trocar modelos de OpenAI, Anthropic, Google, Mistral, AWS Bedrock e outros, basta mudar provider_id/model_id
  • Prioriza o uso dos SDKs oficiais dos provedores para minimizar problemas de compatibilidade e pode ser usada imediatamente após a instalação via pip, sem necessidade de instalar separadamente um servidor de proxy/gateway
  • Voltada para desenvolvedores, com dicas de tipo completas na IDE, tratamento de exceções intuitivo, exceções personalizadas, documentação e guia rápido
  • Com um roteador leve, é independente de framework e não exige servidor separado de proxy/gateway (basta ter a API Key para usar imediatamente)
  • Resolve problemas de soluções existentes e está em manutenção ativa: já é usado em produtos reais, como o any-agent da Mozilla
    • LiteLLM: implementação própria em vez de usar SDK oficial → pode haver preocupações com compatibilidade/bugs
    • AISuite: estrutura modular, mas com gerenciamento e tipagem insuficientes
    • Dependentes de framework: acabam se fragmentando novamente em cada projeto
    • Somente proxy: exigem servidor separado, aumentando a complexidade

Documentação relacionada

Leituras relacionadas

3 comentários

 
kaydash 2025-07-26

Vai ser preciso gerenciar as chaves de cada provedor de LLM.
 
GN⁺ 2025-07-25
Comentários do Hacker News
  • Não acho necessariamente um problema que o LiteLLM implemente diretamente a interface do provedor em vez de usar os SDKs oficiais
    Nas APIs de texto, não enfrentei grandes problemas de compatibilidade, e entendo que, para padronizar várias APIs, é preciso implementar a própria interface
    Esse processo é indispensável para criar um roteador específico
    • Na prática, o LiteLLM não parece ter nada de leve (lite)
      Cheguei a usá-lo experimentalmente como biblioteca, mas no fim migrei para o llm do Simon. Meus agradecimentos ao Simon
    • Para usos padrão como conclusão de texto, as duas abordagens funcionam bem
      As diferenças aparecem mais em casos de borda, como comportamento de streaming, tratamento de timeout e introdução de novos recursos
      Nós também recriamos interfaces para normalizar APIs, e usar ou não um SDK é apenas uma questão de em que camada você separa isso
      Adotar um SDK costuma ser mais uma preferência de manutenção do que um defeito fundamental da abordagem do LiteLLM
    • Até SDKs oficiais às vezes trazem problemas de dependência
      O SDK da Together chegou a incluir uma dependência de 60 MB chamada Apache Arrow, e eu mesmo fiz um patch para torná-la opcional
      Se a biblioteca força versões específicas de dependências, isso pode entrar em conflito com meu projeto
      Acho melhor usar só OpenAPI/REST do que uma biblioteca que arrasta muitas dependências
    • O LiteLLM também acumulou bastante experiência prática no geral
      Usar o SDK oficial por si só não resolve todos os problemas de compatibilidade, e o any_llm também vai precisar manter compatibilidade diretamente com os SDKs oficiais
      É difícil dizer com clareza que uma abordagem é superior à outra
    • Pessoalmente, eu uso o Litellm como gateway de IA
      Do ponto de vista do usuário, não há diferença prática de uso entre o proxy usar ou não o SDK oficial
      Para quem desenvolve o proxy, isso pode trazer vantagens
      Por exemplo, recentemente o Litellm teve um problema no tratamento do Deepseek Reasoning, e a parte de reasoning chegou a sumir tanto nas respostas síncronas quanto nas em streaming
  • No post do blog, dizem que o LiteLLM é popular por oferecer suporte a vários provedores de LLM, mas na prática o criticam por “não usar os SDKs oficiais e implementar tudo diretamente, o que pode causar problemas de compatibilidade”
    Pela minha experiência, o LiteLLM funciona de forma muito robusta na prática
    Os provedores costumam avisar com antecedência quando vão alterar a API, e nunca vi o LiteLLM ter problemas por causa disso
    Supostas desvantagens negativas relacionadas a LLM só aparecem neste texto
    Também falaram de OpenRouter e Portkey como soluções de proxy/gateway, mas na prática o OpenRouter não exige que o usuário suba o próprio servidor; basta fazer chamadas de API diretamente ao endpoint
    Neste texto, o OpenRouter foi entendido de forma errada como um proxy self-hosted
    E o AISuite é um produto criado por Andrew NG, mas o blog disse que ele está “sem manutenção desde dezembro de 2024”; na prática, só não há tags de release, e projetos comunitários pequenos muitas vezes nem fazem tagging
    Achei problemático publicar esse tipo de coisa num blog sem checagem de fatos
    Se não fosse pela marca Mozilla, eu poderia até achar que era golpe ou malware
    O nome também é parecido demais com Anything-LLM, o que torna tudo confuso
  • Estou animado com o novo projeto any-llm
    Até agora eu vinha usando o LiteLLM, mas olhando a implementação interna de perto, ela era muito complexa e problemática
    Por exemplo, nos últimos meses o Structured Output do item Ollama ficou completamente quebrado e abandonado, e a documentação também estava totalmente desorganizada
  • O projeto parece interessante e bem apresentado
    Imagino que tenham escolhido Python porque a maioria dos SDKs é baseada em Python
    Ainda assim, acho que seria realmente revolucionário se fosse algo portável para várias linguagens sem interpretador
    • Essa é a pergunta central. Muitas ferramentas tentam resolver um problema de nível de sistema (execução de modelos entre linguagens) na camada de aplicação (biblioteca Python)
      Para criar uma solução realmente universal, seria preciso separar completamente o runtime do modelo e a linguagem, o que é um problema muito mais difícil, mas um grande avanço
    • Para JS/TS já existe o Vercel AISDK; para C++, o ai-sdk-cpp da ClickHouse; e para Flutter/ReactNative/Kotlin, o Cactus. Já existem SDKs utilizáveis em várias linguagens, com objetivo parecido com este projeto
    • Nós mesmos criamos diretamente um gateway como serviço, não um SDK. Referência: projeto Portkey-AI Gateway
  • Fico curioso sobre qual seria o diferencial em relação ao projeto llm do SimonW
    • O projeto do SimonW é centrado em OpenAI e modelos compatíveis, e para usar algo como Amazon Bedrock, por exemplo, é preciso implantar manualmente o *gateway/proxy adicional*
      Já o projeto da Mozilla (incluindo o LiteLLM) tem como ponto forte suportar várias interfaces e permitir o uso imediato de vários modelos
      É possível conectar-se diretamente a vários provedores de LLM sem precisar de um servidor extra de proxy/gateway. Não conheço o LiteLLM bem o suficiente para comparar
  • Eu também estou criando um projeto open source de camada de abstração de LLM para Python
    Comecei a desenvolvê-lo porque precisava disso no meu trabalho de pesquisa
    Peguei ideias de projetos existentes e fiz algo para uso mais geral
    https://github.com/proxai/proxai
    https://proxai.co/
  • Achei o timing realmente curioso
    Eu também lancei recentemente uma camada de abstração de LLM parecida
    Dá para usar facilmente com pip install, e o foco é na compatibilidade com Langchain, para facilitar a substituição em sistemas existentes
    Além disso, também permite failover automático via provedor virtual quando o limite de taxa é excedido
  • Hoje em dia estão surgindo várias opções de camada de gateway/proxy para LLM, como LiteLLM, OpenRouter, Arch e any-llm. A essa altura, talvez todos nós devêssemos procurar um problema novo para resolver
    • Acho o LiteLLM um pouco complexo. Pode servir bem para uso simples em contêiner Docker num projeto pessoal, mas para uso real em produção não me agradou muito
    • Mesmo com 80% dos provedores de modelo oferecendo endpoints compatíveis com OpenAI, várias soluções diferentes continuam surgindo
    • Também quero mencionar o Portkey. Ele pode ser usado com JS e open source
    • Estamos aplicando roteamento de modelos em pesquisa acadêmica e em chatbots de PDF. Gostaria de ouvir opiniões
  • Acho que esse tipo de solução precisa muito de uma imagem Docker. Não me parece que Docker tenha sido mencionado, e eu quero evitar conflitos com pip ou com versões do Python
  • Eu continuo usando o Litellm Proxy em Docker até no ambiente de desenvolvimento
    Os recursos de Usage/Logs ajudam bastante a visualizar o uso real de LLM, e o recurso de cache também é muito útil para reduzir custos em testes repetidos
 
egirlasm 2025-07-26

Ótimo texto, obrigado. Justamente hoje eu estava refatorando pela 27ª vez, por sinal.
Comecei em C++, depois fui para JavaScript, e agora de novo em Rust...