any-llm: ein Aufruf, viele Anbieter, und was die Extras kosten

Ein Problem, das erst ab dem zweiten Anbieter auftritt

Solange ein Projekt nur gegen OpenAI spricht, ist die Anbieterfrage keine Architekturfrage. Sobald aber ein zweites Modell zum Vergleich herangezogen wird, entstehen drei Baustellen gleichzeitig: unterschiedliche SDKs, unterschiedliche Parameternamen und unterschiedliche Antwortobjekte. any-llm setzt genau dort an. Die Bibliothek stellt eine Funktion completion() bereit, die laut README für alle unterstützten Anbieter identisch aufgerufen wird; geändert werden nur der Provider-Name und die Zugangsdaten. Die Zielgruppe ist damit enger umrissen, als der Projektname vermuten lässt. Angesprochen sind Python-Anwendungen, die mehrere Anbieter vergleichen, ausfallsicher betreiben oder evaluieren wollen, ohne für jeden Anbieter einen eigenen Adapter zu pflegen. Wer dauerhaft nur einen Anbieter nutzt und dessen SDK bereits kennt, gewinnt durch die Abstraktion wenig.

Offizielle SDKs hinter einem gemeinsamen Aufruf

Der wichtigste Architekturhinweis steht im README als Aufzählungspunkt: any-llm nutzt die offiziellen SDKs der Anbieter, statt HTTP-Endpunkte selbst nachzubauen. Das ist eine bewusste Entscheidung mit Folgen. Neue Parameter eines Anbieters kommen über dessen SDK an, sobald die Abhängigkeit aktualisiert wird; gleichzeitig erbt any-llm die Versionskonflikte dieser Pakete. Die Provider-Auswahl geschieht über Extras bei der Installation, das SDK selbst bringt also nicht alle Anbieter mit. Der Datenfluss ist geradlinig: Aufruf mit model, provider und messages, danach greift der Code auf response.choices[0].message.content zu. Für Anbieter mit OpenAI-kompatibler Responses-API existiert zusätzlich responses() mit einem input_data-Parameter, dessen Ergebnis über result.output_text gelesen wird. Das Antwortobjekt ist laut README ein OpenAI-kompatibles Alias, was den Umstieg erleichtert, aber auch bedeutet, dass sich die Struktur an OpenAI orientiert und nicht an einem anbieternetralen Schema.

Zwei Aufrufwege mit unterschiedlichem Verbindungsverhalten

any-llm bietet zwei Einstiegspunkte, und die README macht den Unterschied ausdrücklich an der Verbindungsverwaltung fest. Die Funktion completion() erzeugt pro Aufruf einen neuen Client und ist zustandslos; das passt zu Skripten, Notebooks und einzelnen Experimenten. Die Klasse AnyLLM wird über AnyLLM.create("mistral", api_key=...) instanziiert und verwendet den Client wieder, was in der Tabelle als connection pooling beschrieben wird. Für Produktionsanwendungen mit vielen Anfragen ist das der relevante Pfad. Beide Wege unterstützen laut README denselben Funktionsumfang, einschließlich Streaming, Tools und Responses API. Die Modellangabe ist auf zwei Arten möglich: getrennt als provider="mistral" und model="mistral-small-latest" oder kombiniert als model="mistral:mistral-small-latest". Die README empfiehlt die getrennte Schreibweise, was sinnvoll ist, weil der Doppelpunkt in Modellnamen anderer Anbieter vorkommen kann.

Installation: Extras statt Komplettpaket

Die Installation erfolgt über pip und ist aufgeteilt: pip install 'any-llm-sdk[openai]' für einen Anbieter, pip install 'any-llm-sdk[mistral,ollama]' für mehrere, pip install 'any-llm-sdk[all]' für alle. Voraussetzung ist Python 3.11 oder neuer, was ältere Umgebungen ausschließt. Die Zugangsdaten kommen über Umgebungsvariablen wie OPENAI_API_KEY, ANTHROPIC_API_KEY oder MISTRAL_API_KEY, alternativ direkt im Code. Der Quickstart prüft den Key mit einem assert, bevor der Aufruf erfolgt, ein Muster, das sich für lokale Experimente übernehmen lässt. Für Anbieter, die nicht in der Liste stehen, aber eine OpenAI-kompatible Schnittstelle anbieten, verweist die README auf einen eigenen Abschnitt zu Custom OpenAI-compatible Endpoints. Wer eine Gateway-Lösung betreibt, findet laut README in mozilla-ai/otari die Bereiche Budgetverwaltung, API-Key-Verwaltung, Nutzungsanalyse und Mandantenfähigkeit. Das SDK selbst deckt diese Punkte nicht ab.

Migration von LiteLLM als eigentliches Verkaufsargument

Der README-Abschnitt zur Migration ist der konkreteste Teil der Dokumentation. Vorhandene API-Keys und Umgebungsvariablen bleiben unverändert gültig. Geändert werden Import und Modellstring: aus from litellm import completion wird from any_llm import completion, und aus model="openai/gpt-4o" wird model="openai:gpt-4o". Der Schrägstrich weicht dem Doppelpunkt. Die README nennt das die vollständige Migration, ohne Proxy und ohne zusätzliche Konfiguration. Das ist eine überprüfbare Aussage über die Oberfläche, keine Aussage über das Verhalten im Betrieb. Wer bestehende Modell-Strings umstellt, sollte die Anbieterliste der Dokumentation heranziehen, weil dort die gültigen provider_id-Werte stehen. Ob sich Parameter jenseits der gezeigten Beispiele identisch verhalten, lässt sich aus dem vorliegenden Material nicht ableiten.

Wo die Abstraktion an ihre Grenzen stößt

Jede Vereinheitlichung verdeckt Unterschiede, und any-llm ist da keine Ausnahme. Die README führt eine Reihe von Fähigkeiten auf, die beide Aufrufwege teilen, nennt aber keine Matrix, welche Anbieter welche davon tatsächlich implementieren. Die Responses API wird ausdrücklich auf Anbieter eingeschränkt, die eine OpenAI-kompatible Variante anbieten; für alle anderen bleibt der klassische Chat-Pfad. Wer anbieterspezifische Funktionen wie eigene Caching-Optionen, Sicherheitsfilter oder besondere Sampling-Parameter benötigt, muss prüfen, ob any-llm sie durchreicht oder ob das offizielle SDK direkt der kürzere Weg ist. Ein weiterer Punkt ist der Fehlerpfad: Die README wirbt mit klaren Fehlermeldungen, beschreibt aber keine einheitliche Fehlerhierarchie über Anbieter hinweg. Anwendungen, die auf bestimmte Fehlercodes reagieren müssen, sollten das vor der Festlegung testen. Und für sehr einfache Fälle ist der Umweg über eine Abstraktion schlicht überflüssig.

LiteLLM, otari und die Frage der Zuständigkeit

Die naheliegende Alternative ist LiteLLM, und der Unterschied liegt weniger im Ziel als im Zuschnitt. any-llm positioniert sich als SDK ohne Proxy, mit Extras pro Anbieter und zwei Aufrufwegen, von denen einer gezielt auf Wiederverwendung der Verbindung ausgelegt ist. Die Migration von LiteLLM wird ausdrücklich als unterstützter Pfad beschrieben, was zugleich zeigt, dass beide Werkzeuge dieselbe Aufgabe adressieren. Für Budgets, Schlüsselverwaltung, Nutzungsanalyse und Mandantenfähigkeit verweist die README auf das separate Projekt otari, statt diese Funktionen im SDK anzubieten. Das ist eine klare Arbeitsteilung: any-llm kümmert sich um den Aufruf, otari um die Verwaltung darüber. Wer beides in einer Bibliothek erwartet, wird bei any-llm nicht fündig. Wer dagegen eine schmale Abhängigkeit sucht, die sich in bestehenden Code einfügt, findet hier einen kleineren Umfang als bei einer All-in-One-Lösung.

Pflegeaufwand, Lizenz und was vorher zu klären ist

Das Repository steht unter Apache-2.0, einer permissiven Lizenz, die kommerzielle Nutzung und Änderungen erlaubt und eine Patentgewährung enthält. Rechtliche Beratung ersetzt das nicht, und die Pflichten zur Beibehaltung von Copyright- und Lizenzhinweisen sollten vor der Weitergabe geprüft werden. Der Versionsverlauf zeigt Releases im Wochen- bis Monatsrhythmus, zuletzt 1.27.1 am 4. September 2026 nach 1.27.0 am Vortag und 1.26.0 Mitte August. Diese Taktung bedeutet: Wer die Abhängigkeit auf einen festen Versionsstand pinnt, muss regelmäßig nachziehen, sonst verpasst er neue Anbieter und Parameter. Wer nicht pinnt, holt sich Änderungen ungeprüft in den Build. Weil any-llm auf den offiziellen SDKs aufsetzt, kann ein Update eines Anbieter-SDKs eine Anpassung in any-llm nach sich ziehen, die nicht im eigenen Code sichtbar ist. Vor der Einführung lohnt deshalb ein Blick in die Anbieterliste der Dokumentation, um zu prüfen, ob die benötigten Anbieter und der geplante Modell-String dort abgedeckt sind, und ein Test des Fehlerverhaltens bei abgelaufenem API-Key, weil die README dazu keine Hierarchie beschreibt.

Redaktionelles Fazit

Für Teams, die zwei oder drei Anbieter vergleichen wollen und dafür keine Gateway-Infrastruktur betreiben möchten, ist any-llm die schlankere Wahl. Wer Provider-Routing, Retry-Logik oder Kostenkontrolle im Prozess braucht, sollte zuerst prüfen, ob otari als separates Projekt diese Aufgaben übernimmt, statt sie im SDK zu erwarten. Vor der Festlegung auf einen Modell-String lohnt ein Blick in die Anbieterliste der Dokumentation, weil die Provider-IDs dort definiert sind und nicht im Modellnamen stecken.

Offizielle Quellen

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