any-llm - une interface unique pour divers fournisseurs de LLM

 (github.com/mozilla-ai)
7 points par xguru 2025-07-25 | 3 commentaires | Partager sur WhatsApp
  • Bibliothèque Python créée par l’équipe Mozilla AI, permettant d’utiliser plus de 20 fournisseurs de LLM avec une seule fonction
    • Lors d’un changement de modèle entre OpenAI, Anthropic, Google, Mistral, AWS Bedrock, etc., il suffit de modifier provider_id/model_id
  • S’appuie en priorité sur les SDK officiels des fournisseurs pour réduire au minimum les problèmes de compatibilité, sans nécessiter l’installation séparée d’un serveur proxy/passerelle, ce qui permet une utilisation immédiate après installation via pip
  • Conçu pour être favorable aux développeurs avec des indications de type IDE complètes, une gestion intuitive des exceptions, des exceptions personnalisées, ainsi qu’une documentation et un guide rapide
  • Grâce à un routeur léger, il est indépendant de tout framework et ne nécessite aucun serveur proxy/passerelle dédié (une simple clé API suffit pour l’utiliser immédiatement)
  • Résout les problèmes des solutions existantes et fait l’objet d’une maintenance active : il est déjà utilisé dans de vrais produits comme any-agent de Mozilla
    • LiteLLM : implémentation directe au lieu d’utiliser les SDK officiels → risques de compatibilité et de bugs
    • AISuite : architecture modulaire mais gestion et typage insuffisants
    • Dépendants d’un framework : nouvelle fragmentation selon les projets
    • Proxy uniquement : nécessite un serveur séparé, complexité accrue

Documentation associée

À lire aussi

3 commentaires

 
kaydash 2025-07-26

Il faudra gérer les clés pour chaque fournisseur de LLM.
 
GN⁺ 2025-07-25
Commentaires sur Hacker News
  • Je ne pense pas que ce soit forcément un problème que LiteLLM implémente directement une interface fournisseur plutôt que d’utiliser les SDK officiels
    Je n’ai pas rencontré de gros problèmes de compatibilité avec les API texte, et je comprends que pour standardiser diverses API, il faut parfois implémenter soi-même l’interface
    C’est indispensable si l’on veut construire un routeur spécifique
    • J’ai l’impression qu’il n’y a en réalité rien de très léger (lite) dans LiteLLM
      Je l’ai utilisé expérimentalement comme bibliothèque, puis j’ai fini par passer à llm de Simon. Merci à Simon
    • Pour les usages standards comme la complétion de texte, les deux approches fonctionnent bien
      Les différences apparaissent surtout dans les cas limites comme le comportement du streaming, la gestion des timeouts ou l’introduction de nouvelles fonctionnalités
      Nous recréons nous aussi des interfaces pour normaliser les API, et la question de l’usage d’un SDK n’est au fond qu’une question de découpage des couches
      Si l’on adopte un SDK, c’est surtout pour des préférences de maintenance, pas à cause d’un défaut fondamental de l’approche de LiteLLM
    • Les SDK officiels peuvent eux aussi poser des problèmes de dépendances
      Le SDK de Together incluait par exemple une dépendance de 60 Mo, Apache Arrow, que nous avons dû patcher nous-mêmes pour la rendre optionnelle
      Si les versions des dépendances sont imposées de force, cela peut entrer en conflit avec mon projet
      Je pense qu’il vaut mieux n’utiliser qu’OpenAPI/REST plutôt qu’une bibliothèque qui traîne beaucoup de dépendances
    • LiteLLM a aussi accumulé pas mal d’expérience terrain
      Le fait d’utiliser les SDK officiels ne résout pas à lui seul tous les problèmes de compatibilité, et any_llm devra de toute façon lui aussi maintenir la compatibilité avec ces SDK
      Il est difficile de dire clairement qu’une méthode est supérieure à l’autre
    • Personnellement, j’utilise LiteLLM comme passerelle IA
      Du point de vue de l’utilisateur, qu’un proxy utilise ou non les SDK officiels ne change rien en pratique
      Cela peut en revanche apporter des avantages au développeur du proxy
      Par exemple, LiteLLM a récemment eu un problème dans la gestion du raisonnement de Deepseek, où la partie reasoning disparaissait à la fois dans les réponses synchrones et en streaming
  • Le billet de blog mentionne que LiteLLM est populaire pour sa prise en charge de nombreux fournisseurs de LLM, mais le critique en disant qu’il « n’utilise pas les SDK officiels et les réimplémente directement, ce qui peut créer des problèmes de compatibilité »
    D’après mon expérience, LiteLLM fonctionne en réalité de façon très robuste
    Les fournisseurs annoncent clairement à l’avance les changements d’API, et je n’ai jamais vu LiteLLM poser problème à cause de cela
    Les hypothétiques défauts négatifs liés aux LLM n’apparaissent que dans cet article
    L’article parle aussi d’OpenRouter et de Portkey comme solutions de proxy/passerelle, mais en réalité OpenRouter permet simplement aux utilisateurs d’appeler directement l’API via son endpoint, sans avoir à déployer eux-mêmes un serveur
    Cet article a mal compris OpenRouter comme un proxy auto-hébergé
    Et concernant AISuite, qui est un produit d’Andrew NG, le blog affirme que le projet « n’est plus maintenu depuis décembre 2024 », alors qu’en réalité il n’y a simplement pas de tags de release, ce qui est fréquent dans les petits projets communautaires
    J’ai trouvé problématique de publier cela sur un blog sans vérification des faits
    Sans la marque Mozilla, j’aurais pu croire à une arnaque ou à un malware
    Le nom est aussi trop proche de Anything-LLM, ce qui prête à confusion
  • Ce nouveau projet any-llm m’enthousiasme
    Jusqu’ici, j’utilisais LiteLLM, mais en regardant son implémentation interne, je l’ai trouvé très complexe et problématique
    Par exemple, la sortie structurée d’Ollama est restée complètement cassée pendant des mois, et la documentation n’était pas du tout maintenue
  • Le projet a l’air intéressant et bien présenté
    Le choix de Python vient probablement du fait que la plupart des SDK sont basés sur Python
    Mais j’aurais trouvé cela vraiment révolutionnaire si c’était portable vers plusieurs langages sans interpréteur
    • C’est la vraie question. Beaucoup d’outils essaient de résoudre un problème de niveau système (exécution interlangage des modèles) au niveau de la couche applicative (bibliothèque Python)
      Pour créer une solution vraiment universelle, il faut séparer complètement le runtime du modèle et le langage, ce qui est un problème bien plus difficile, mais aussi une avancée majeure
    • Il existe déjà plusieurs SDK utilisables dans différents langages, comme Vercel AISDK pour JS/TS, ai-sdk-cpp de ClickHouse pour C++, ou Cactus pour Flutter/ReactNative/Kotlin. L’objectif est similaire à celui de ce projet
    • Nous avons construit directement une passerelle en tant que service plutôt qu’un SDK. Référence : projet Portkey-AI Gateway
  • Je me demande quelle est la différence avec le projet llm de SimonW
    • Le projet de SimonW est surtout centré sur la prise en charge d’OpenAI et des modèles compatibles, et pour utiliser par exemple un modèle comme Amazon Bedrock, il faut déployer soi-même *une passerelle/un proxy supplémentaire*
      Le point fort du projet de Mozilla (comme LiteLLM) est qu’il prend déjà en charge plusieurs interfaces, ce qui permet d’utiliser immédiatement plusieurs modèles
      Il peut se connecter directement à plusieurs fournisseurs de LLM sans serveur proxy/passerelle séparé. Je connais moins bien LiteLLM, donc je ne peux pas trop comparer
  • Je développe moi aussi un projet open source de couche d’abstraction LLM pour Python
    Je l’ai créé par nécessité dans le cadre de mon travail de recherche
    Je me suis inspiré de projets existants pour en faire quelque chose de plus générique
    https://github.com/proxai/proxai
    https://proxai.co/
  • Le timing est vraiment étonnant
    J’ai moi aussi récemment lancé une couche d’abstraction LLM similaire
    On peut l’utiliser facilement avec pip install, et j’ai surtout mis l’accent sur la compatibilité Langchain, afin qu’il soit facile à remplacer dans un système existant
    En plus, il permet un basculement automatique via des fournisseurs virtuels en cas de dépassement automatique des limites de débit
  • En ce moment, il existe de plus en plus d’options pour les couches passerelle/proxy LLM, comme LiteLLM, OpenRouter, Arch, any-llm. À ce stade, il va peut-être falloir qu’on trouve tous ensemble un nouveau problème à résoudre
    • Je trouve LiteLLM un peu complexe. Pour un usage simple dans un projet personnel via un conteneur Docker, cela peut convenir, mais pour un usage réel en production, je ne suis pas satisfait
    • Même si 80 % des fournisseurs de modèles prennent en charge des endpoints compatibles OpenAI, diverses solutions continuent d’apparaître
    • J’aimerais aussi mentionner Portkey. Il est exploitable en JS et open source
    • Nous appliquons le routage de modèles à la recherche académique et aux chatbots PDF. J’aimerais avoir des retours
  • Je pense que ce genre de solution a absolument besoin d’une image Docker. Il ne me semble pas qu’elle soit mentionnée, alors que je veux éviter les conflits liés à pip ou aux versions de Python
  • J’utilise encore Litellm Proxy avec Docker même dans mon environnement de développement
    Les fonctions Usage/Logs rendent l’utilisation réelle des LLM visible, et la fonction de cache aide beaucoup à réduire les coûts lors des tests répétés
 
egirlasm 2025-07-26

Merci pour ce bon article. Justement, j’en étais aujourd’hui à ma 27e refactorisation.
J’ai commencé en C++, puis en JavaScript, et maintenant me revoilà en Rust...