any-llm - una interfaz única para diversos proveedores de LLM

 (github.com/mozilla-ai)
7 puntos por xguru 2025-07-25 | 3 comentarios | Compartir por WhatsApp
  • Biblioteca de Python creada por el equipo de Mozilla AI que permite usar más de 20 proveedores de LLM con una sola función
    • Al cambiar entre modelos de OpenAI, Anthropic, Google, Mistral, AWS Bedrock y otros, basta con cambiar provider_id/model_id
  • Prioriza el uso de los SDK oficiales de los proveedores para minimizar los problemas de compatibilidad, y no requiere instalar por separado un servidor proxy/gateway, por lo que se puede usar de inmediato tras instalar con pip
  • Pensada para desarrolladores, con sugerencias de tipos completas en el IDE, manejo intuitivo de excepciones, excepciones personalizadas, documentación y una guía rápida
  • Con un router liviano, es independiente del framework y no requiere un servidor proxy/gateway adicional (se puede usar de inmediato con solo una API Key)
  • Resuelve problemas de soluciones existentes y cuenta con mantenimiento activo: ya se usa en productos reales como any-agent de Mozilla
    • LiteLLM: implementación propia en lugar de usar el SDK oficial → puede haber preocupaciones de compatibilidad/errores
    • AISuite: estructura modular, pero con deficiencias en administración y tipado
    • Dependientes de frameworks: vuelven a fragmentarse según cada proyecto
    • Solo proxy: requieren un servidor aparte, lo que aumenta la complejidad

Documentación relacionada

Lecturas relacionadas

3 comentarios

 
kaydash 2025-07-26

Supongo que habría que administrar una clave para cada proveedor de LLM.
 
GN⁺ 2025-07-25
Comentarios de Hacker News
  • No creo que sea necesariamente un problema que LiteLLM implemente directamente la interfaz del proveedor en lugar de usar los SDK oficiales
    No he experimentado grandes problemas de compatibilidad con las APIs de texto, y entiendo que para estandarizar distintas APIs hay que implementar una interfaz propia
    Este proceso es necesario si quieres construir un router específico
    • Siento que en LiteLLM en realidad no hay nada ligero (lite)
      Lo probé de forma experimental como librería, pero al final me cambié a llm de Simon. Mi agradecimiento para Simon
    • Para usos estándar como completado de texto, ambos enfoques funcionan bien
      Las diferencias se notan más en casos límite como el comportamiento de streaming, el manejo de timeouts o la incorporación de funciones nuevas
      Nosotros también rehacemos interfaces para normalizar APIs, y usar o no un SDK es solo una diferencia de dónde separas las capas
      Adoptar un SDK suele ser más una preferencia de mantenimiento que un defecto fundamental del enfoque de LiteLLM
    • Incluso los SDK oficiales a veces generan problemas de dependencias
      El SDK de Together llegó a incluir una dependencia de 60 MB llamada Apache Arrow, y tuvimos que parchearla para volverla opcional
      Si fuerzan una versión fija de una dependencia, puede entrar en conflicto con mi proyecto
      Me parece mejor usar solo OpenAPI/REST que una librería que arrastra demasiadas dependencias
    • LiteLLM también tiene bastante experiencia acumulada en producción
      Usar el SDK oficial tampoco resuelve automáticamente todos los problemas de compatibilidad, y any_llm al final también necesita trabajo directo para mantener la compatibilidad con los SDK oficiales
      Es difícil decir claramente que un enfoque sea superior al otro
    • En lo personal uso LiteLLM como gateway de IA
      Desde la perspectiva del usuario, no hay una diferencia práctica de uso entre que el proxy use o no el SDK oficial
      Puede haber ventajas para quien desarrolla el proxy
      Por ejemplo, hace poco LiteLLM tuvo un problema con el manejo de Deepseek Reasoning, y la parte de reasoning llegó a omitirse tanto en respuestas síncronas como en streaming
  • En el post del blog se menciona que LiteLLM es popular por su soporte para varios proveedores de LLM, pero luego se le critica porque “no usa los SDK oficiales y puede causar problemas de compatibilidad”
    En mi experiencia, LiteLLM en realidad funciona de forma muy sólida
    Los proveedores suelen avisar con anticipación cuando habrá cambios en la API, y LiteLLM nunca me ha causado problemas por eso
    Los supuestos defectos negativos relacionados con LLM solo aparecen en este artículo
    También hablaron de OpenRouter y Portkey como soluciones de proxy/gateway, pero en realidad OpenRouter no requiere que el usuario levante su propio servidor: solo haces llamadas API directamente al endpoint
    En este artículo entendieron mal OpenRouter como si fuera un proxy autohospedado
    Y AISuite es un producto creado por Andrew NG, pero el blog decía que “no tiene mantenimiento desde diciembre de 2024”; en realidad solo no tiene tags de release, y en proyectos comunitarios pequeños a veces ni siquiera se acostumbra etiquetar releases
    Me pareció problemático publicar eso en un blog sin verificar los hechos
    Si no llevara la marca Mozilla, habría pensado que era una estafa o malware
    Además, el nombre se parece demasiado a Anything-LLM, así que también resulta confuso
  • Tengo expectativas por el nuevo proyecto any-llm
    He usado LiteLLM hasta ahora, pero al ver su implementación interna parecía muy complejo y lleno de problemas
    Por ejemplo, durante los últimos meses el Structured Output del apartado de Ollama estuvo completamente roto, y la documentación tampoco estaba nada organizada
  • El proyecto se ve interesante porque da una buena impresión
    Supongo que eligieron Python porque la mayoría de los SDK están basados en Python
    Aun así, creo que habría sido realmente innovador si hubiera tenido una forma portable a varios lenguajes sin intérprete
    • Esa es la pregunta clave. Muchas herramientas intentan resolver un problema a nivel sistema (ejecución de modelos entre distintos lenguajes) desde la capa de aplicación (una librería de Python)
      Para construir una solución verdaderamente universal, habría que separar por completo el runtime del modelo y el lenguaje, lo cual es un problema mucho más difícil, pero un gran avance
    • Para JS/TS está Vercel AISDK, para C++ está ai-sdk-cpp de ClickHouse, y para Flutter/ReactNative/Kotlin está Cactus; ya existen SDK utilizables en varios lenguajes. El objetivo es parecido al de este proyecto
    • Nosotros no hicimos un SDK, sino directamente un gateway como servicio. Referencia: proyecto Portkey-AI Gateway
  • Me pregunto cuál es la diferencia frente al proyecto llm de SimonW
    • El proyecto de SimonW se enfoca en soporte para OpenAI y modelos compatibles, y por ejemplo, para usar modelos como Amazon Bedrock hay que desplegar por cuenta propia un *gateway/proxy adicional*
      El punto fuerte del proyecto de Mozilla (incluido LiteLLM) es que ya soporta varias interfaces, así que puedes usar múltiples modelos de inmediato
      Es posible conectarse directamente con varios proveedores de LLM sin un servidor proxy/gateway aparte. No conozco lo suficiente LiteLLM como para compararlos bien
  • Yo también estoy creando un proyecto open source de capa de abstracción de LLM para Python
    Empecé a desarrollarlo porque lo necesitaba en mi trabajo de investigación
    Tomé ideas de proyectos existentes y lo hice para un uso más general
    https://github.com/proxai/proxai
    https://proxai.co/
  • De verdad siento que el timing es curioso
    Yo también lancé hace poco una capa de abstracción de LLM similar
    Se puede usar fácilmente con pip install, y está enfocada en la compatibilidad con Langchain para que sea sencillo reemplazar sistemas existentes
    Además, permite failover automático mediante proveedores virtuales cuando se excede automáticamente el rate limit
  • Últimamente están apareciendo muchas opciones para la capa gateway/proxy de LLM, como LiteLLM, OpenRouter, Arch, any-llm. A estas alturas quizá todos tengamos que empezar a buscar un problema nuevo que resolver
    • Creo que LiteLLM es un poco complejo. Puede estar bien para usarlo fácil en un proyecto personal dentro de un contenedor Docker, pero para uso real en producción no me deja satisfecho
    • Aunque el 80% de los proveedores de modelos soporta endpoints compatibles con OpenAI, siguen apareciendo varias soluciones distintas
    • También quiero mencionar Portkey. Se puede usar con JS y open source
    • Estamos aplicando el enrutamiento de modelos a investigación académica y chatbots para PDF. Me gustaría escuchar opiniones
  • Creo que este tipo de soluciones realmente necesita una imagen de Docker. No parece que hayan mencionado Docker, y yo querría evitar conflictos con pip o con versiones de Python
  • Yo también sigo usando Litellm Proxy con Docker incluso en el entorno de desarrollo
    Las funciones de Usage/Logs ayudan a visualizar el uso real de LLM, y la función de cache también sirve mucho para reducir costos en pruebas repetidas
 
egirlasm 2025-07-26

Gracias por el buen artículo. Justo hoy estaba haciendo la refactorización número 27, de hecho.
Empecé en C++, luego pasé a JavaScript y ahora otra vez en Rust...