any-llm : une seule fonction completion pour changer de fournisseur LLM

Le problème concret : le nom du fournisseur fuit dans le code métier

Chaque fournisseur a son SDK, ses noms de paramètres et son objet de réponse. Un script qui interroge OpenAI puis Anthropic finit avec deux imports, deux façons de passer les messages et deux structures à parcourir. any-llm attaque ce point précis : une fonction completion, un paramètre provider, un paramètre model, et la réponse exposée sous une forme compatible OpenAI, puisque l'exemple du README lit response.choices[0].message.content. Le public visé est celui qui écrit du Python pour comparer des modèles, prototyper un agent ou faire tourner un notebook. La bibliothèque se présente comme framework-agnostic, ce qui veut dire qu'elle ne cherche pas à remplacer un orchestrateur d'agents : elle remplace la couche d'appel réseau. Mozilla AI indique qu'elle alimente ses propres outils de production, notamment any-agent, mais il s'agit d'une affirmation de l'éditeur et non d'une mesure indépendante.

Deux façons d'appeler, deux gestions de connexion

Le README distingue explicitement les fonctions directes et la classe AnyLLM. La fonction completion crée un nouveau client à chaque appel : le tableau du README la décrit comme stateless et la recommande pour les scripts, les notebooks et les requêtes isolées. AnyLLM.create("mistral", api_key=...) renvoie un objet réutilisable, décrit comme conservant le client et donc le pool de connexions, ce qui est présenté comme l'option de production. Les deux chemins exposent les mêmes fonctionnalités selon la documentation : streaming, tools, responses API. Le choix n'est donc pas une question de capacité mais de cycle de vie. Un détail mérite attention : la syntaxe recommandée sépare provider et model, tandis qu'une syntaxe alternative accepte model="mistral:mistral-small-latest" au format provider_id:model_id. Le README qualifie la première de recommandée, la seconde d'alternative. Cette double entrée est pratique pour la migration, mais elle impose de vérifier laquelle votre base de code utilise réellement avant de généraliser un remplacement.

Installation par extras et variables d'environnement

L'installation passe par des extras pip qui correspondent aux fournisseurs voulus. Le README donne pip install 'any-llm-sdk[mistral,ollama]', pip install 'any-llm-sdk[openai]' et pip install 'any-llm-sdk[all]' pour tout installer. Le paquet PyPI s'appelle any-llm-sdk, alors que le module importé s'appelle any_llm : la distinction compte dans un fichier de dépendances. Les clés se placent dans des variables d'environnement nommées par fournisseur, par exemple export MISTRAL_API_KEY="your-key-here", export OPENAI_API_KEY ou export ANTHROPIC_API_KEY, et l'exemple de démarrage inclut un assert os.environ.get('MISTRAL_API_KEY') qui échoue tôt si la variable manque. Une clé peut aussi être passée directement dans le code, comme le montre AnyLLM.create("mistral", api_key="your-mistral-api-key"). Pour un serveur local ou une passerelle compatible OpenAI qui n'a pas d'entrée dédiée, le README renvoie vers une page de documentation sur les endpoints personnalisés. Prérequis annoncé : Python 3.11 ou plus récent.

Ce que la couche unifiée ne peut pas uniformiser

Une interface commune ne peut exposer que le sous-ensemble d'options que tous les fournisseurs partagent. Le README mentionne streaming, tools et responses API comme supportés par les deux modes d'appel, mais il ne détaille pas ce qui se passe quand un fournisseur ne propose pas une capacité donnée. La fonction responses est d'ailleurs présentée avec une restriction : elle s'adresse aux fournisseurs qui implémentent l'API Responses de style OpenAI, ce qui exclut par construction les autres. Autre point de friction, la migration depuis LiteLLM. Le README annonce que les clés et variables d'environnement sont reprises sans changement, mais le format de modèle diffère : litellm utilise model="openai/gpt-4o" et any-llm attend model="openai:gpt-4o". Le séparateur change, donc toute chaîne construite dynamiquement dans le code doit être revue. Enfin, la bibliothèque ne gère ni budget, ni quotas, ni analytics : le README renvoie vers le projet otari pour ces besoins. Si votre problème est la gouvernance des clés plutôt que la portabilité du code, any-llm n'est pas le bon outil.

Face à LiteLLM : même objectif, séparateur différent

LiteLLM est l'alternative la plus directement comparable, et c'est le projet que any-llm prend explicitement comme point de départ de migration. La différence décrite dans le README tient en deux éléments : le format de nommage des modèles, avec un point-virgule de séparation côté any-llm contre un slash côté LiteLLM, et l'absence de proxy. Le README insiste sur ce dernier point avec la formule "no proxy, no extra config". C'est un choix d'architecture : any-llm reste une bibliothèque in-process, là où LiteLLM propose aussi un serveur proxy qui centralise les clés et les quotas. any-llm délègue cette partie à otari, un projet distinct. Concrètement, une équipe qui veut un point d'entrée réseau unique pour plusieurs services ne trouvera pas cette réponse dans any-llm seul. Celle qui veut juste éviter de réécrire ses appels lors d'un changement de fournisseur y trouvera une couche plus légère, sans processus supplémentaire à déployer.

Cadence de publication et coût de suivi

Les versions récentes listées sont 1.27.1, 1.27.0 et 1.26.0, publiées entre le 17 août et le 4 septembre 2026, avec un dernier push sur main au 9 septembre 2026. Cette cadence, plusieurs publications par mois, indique un projet actif, et elle a une conséquence directe : le nombre de versions mineures à suivre est élevé pour une bibliothèque dont le rôle est justement de stabiliser une interface. Une équipe qui épingle sa dépendance devra prévoir du temps de mise à jour, ne serait-ce que pour vérifier que les extras de ses fournisseurs n'ont pas bougé. Le projet n'est pas archivé. La licence est Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et de l'avis de licence ; je ne donne pas d'avis juridique et un examen par votre service compétent reste nécessaire si vous redistribuez le paquet. Le README signale aussi un canal Discord et une documentation hébergée sur docs.mozilla.ai, deux points de contact à vérifier avant de vous engager sur un support.

Conclusion éditoriale

any-llm convient aux équipes qui écrivent des scripts, des notebooks ou des prototypes et qui veulent changer de fournisseur en modifiant une chaîne de caractères. Il ne convient pas à ceux qui ont besoin d'un proxy centralisé, de quotas partagés ou d'une couche de gouvernance réseau, cas pour lesquels Mozilla AI renvoie explicitement vers otari. Avant d'adopter, vérifiez deux choses concrètes : que votre fournisseur figure dans la liste des providers documentés, et que le format de modèle provider:model accepté par votre code correspond bien à la syntaxe attendue, différente de celle de LiteLLM.

Sources officielles

1. License: Apache-2.0
2. mozilla-ai/any-llm on GitHub
3. Project website
4. README
5. Releases