any-llm – Eine einheitliche Schnittstelle für verschiedene LLM-Provider

 (github.com/mozilla-ai)
7 Punkte von xguru 2025-07-25 | 3 Kommentare | Auf WhatsApp teilen
  • Eine von Mozillas AI-Team entwickelte Python-Bibliothek, mit der sich mehr als 20 LLM-Provider über eine einzige Funktion nutzen lassen
    • Beim Wechsel zwischen Modellen von OpenAI, Anthropic, Google, Mistral, AWS Bedrock usw. muss nur provider_id/model_id geändert werden
  • Nutzt vorrangig die offiziellen Provider-SDKs, um Kompatibilitätsprobleme zu minimieren. Ein separater Proxy-/Gateway-Server ist nicht nötig, sodass die Bibliothek direkt nach der Installation per pip verwendet werden kann
  • Entwicklerfreundlich mit vollständigen IDE-Type-Hinweisen, intuitivem Exception-Handling, benutzerdefinierten Exceptions sowie Dokumentation und Schnellstart-Anleitung
  • Mit leichtgewichtigem Router framework-unabhängig und ohne separaten Proxy-/Gateway-Server nutzbar (mit API Key sofort einsatzbereit)
  • Behebt die Probleme bestehender Lösungen und wird aktiv gepflegt: bereits in realen Produkten wie Mozillas any-agent im Einsatz
    • LiteLLM: direkte Eigenimplementierung statt offizieller SDKs → mögliche Kompatibilitäts-/Bug-Risiken
    • AISuite: modulare Struktur, aber schwach bei Verwaltung und Typisierung
    • Framework-abhängige Lösungen: erneute Fragmentierung je Projekt
    • Nur-Proxy-Lösungen: separater Server erforderlich, höhere Komplexität

Zugehörige Dokumente

Verwandte Beiträge

3 Kommentare

 
kaydash 2025-07-26

Man muss wohl für jeden LLM-Provider den jeweiligen Key verwalten.
 
GN⁺ 2025-07-25
Hacker-News-Kommentare
  • Ich halte es nicht unbedingt für ein Problem, dass LiteLLM die Provider-Schnittstellen selbst implementiert statt die offiziellen SDKs zu verwenden
    Bei Text-APIs habe ich keine großen Kompatibilitätsprobleme erlebt, und ich verstehe, dass man die Schnittstellen selbst implementieren muss, wenn man verschiedene APIs standardisieren will
    Wenn man einen bestimmten Router bauen möchte, ist dieser Prozess unverzichtbar
    • Bei LiteLLM fühlt es sich so an, als gäbe es eigentlich nichts Leichtgewichtiges (lite) daran
      Ich habe es testweise als Bibliothek verwendet, bin am Ende aber zu Simons llm gewechselt. Vielen Dank an Simon
    • Für standardmäßige Nutzung wie Textvervollständigung funktionieren beide Ansätze gut
      Die Unterschiede zeigen sich eher bei Randbedingungen wie Streaming-Verhalten, Timeout-Behandlung oder der Einführung neuer Features
      Auch wir bauen für die API-Normalisierung Schnittstellen neu auf; ob man ein SDK verwendet, ist nur eine Frage davon, wo man die Layer trennt
      Die Entscheidung für ein SDK ist meist eine Wartungspräferenz und kein grundlegender Mangel des LiteLLM-Ansatzes
    • Auch offizielle SDKs können Abhängigkeitsprobleme verursachen
      Das SDK von Together enthielt beispielsweise eine 60-MB-Abhängigkeit namens Apache Arrow, die wir selbst gepatcht und optional gemacht haben
      Wenn Abhängigkeitsversionen hart festgelegt werden, kann das mit meinem Projekt kollidieren
      Ich halte es für besser, nur OpenAPI/REST zu verwenden, statt eine Bibliothek mit vielen Abhängigkeiten hereinzuziehen
    • Auch LiteLLM hat insgesamt ziemlich viel Praxiserfahrung gesammelt
      Allein durch die Nutzung offizieller SDKs werden nicht alle Kompatibilitätsprobleme gelöst, und any_llm muss am Ende ebenfalls die Kompatibilität zu den offiziellen SDKs direkt aufrechterhalten
      Es ist schwer, klar zu sagen, welcher Ansatz überlegen ist
    • Ich persönlich nutze Litellm als AI-Gateway
      Aus Nutzersicht macht es in der Praxis keinen Unterschied, ob der Proxy offizielle SDKs verwendet oder nicht
      Für Proxy-Entwickler kann das Vorteile haben
      Zum Beispiel hatte Litellm kürzlich ein Problem bei der Deepseek-Reasoning-Verarbeitung, bei dem der Reasoning-Teil sowohl in synchronen als auch in Streaming-Antworten fehlte
  • Im Blogpost wird erwähnt, dass LiteLLM wegen der Unterstützung vieler LLM-Provider beliebt sei, zugleich aber kritisiert, dass es „die offiziellen SDKs nicht nutzt, sondern selbst implementiert und dadurch Kompatibilitätsprobleme verursachen kann“
    Meiner Erfahrung nach funktioniert LiteLLM tatsächlich sehr robust
    Provider kündigen API-Änderungen zuverlässig im Voraus an, und ich habe nicht erlebt, dass LiteLLM dadurch Probleme bekommen hätte
    Solche negativen hypothetischen Nachteile rund um LLMs tauchen nur in diesem Artikel auf
    Als Proxy-/Gateway-Lösungen wurden auch OpenRouter und Portkey erwähnt, aber tatsächlich muss man bei OpenRouter keinen eigenen Server aufsetzen; man kann einfach direkt API-Aufrufe an den Endpoint schicken
    In diesem Artikel wurde OpenRouter fälschlich als selbstgehosteter Proxy verstanden
    Und AISuite ist ein Produkt von Andrew NG, aber im Blog steht, es werde „seit Dezember 2024 nicht mehr gepflegt“, obwohl es in Wirklichkeit nur keine Release-Tags gibt; kleine Community-Projekte taggen oft einfach nicht sauber
    Solche Dinge ohne Faktencheck in einen Blogpost zu schreiben, fand ich problematisch
    Wäre nicht die Marke Mozilla dahinter gewesen, hätte ich es für Betrug oder Malware halten können
    Der Name ist außerdem Anything-LLM viel zu ähnlich, was ebenfalls verwirrend ist
  • Ich freue mich auf das neue any-llm-Projekt
    Bisher habe ich LiteLLM verwendet, aber wenn man sich die interne Implementierung ansieht, ist sie sehr komplex und voller Probleme
    Ein Beispiel: In den letzten Monaten war Structured Output beim Ollama-Eintrag komplett kaputt, und auch die Dokumentation war überhaupt nicht aufgeräumt
  • Das Projekt sieht cool aus und ist interessant
    Die Wahl von Python liegt vermutlich daran, dass die meisten SDKs auf Python basieren
    Trotzdem denke ich, dass es wirklich innovativ gewesen wäre, wenn es sich ohne Interpreter in viele Sprachen portieren ließe
    • Das ist die Kernfrage. Viele Tools versuchen, Probleme auf Systemebene (sprachübergreifende Modellausführung) auf der Anwendungsebene (Python-Bibliothek) zu lösen
      Um eine wirklich universelle Lösung zu bauen, müsste man Runtime und Sprache des Modells vollständig entkoppeln; das ist ein viel schwierigeres Problem, aber ein großer Fortschritt
    • Für JS/TS gibt es das Vercel AISDK, für C++ ClickHouse ai-sdk-cpp und für Flutter/ReactNative/Kotlin Cactus; es existieren also bereits SDKs für viele Sprachen. Das Ziel ist diesem Projekt ähnlich
    • Wir haben kein SDK, sondern direkt ein Gateway als Service gebaut. Siehe dazu das Projekt Portkey-AI Gateway
  • Ich frage mich, worin der Unterschied zum bestehenden llm-Projekt von SimonW liegt
    • Das Projekt von SimonW konzentriert sich auf die Unterstützung von OpenAI und kompatiblen Modellen, und um beispielsweise Modelle wie Amazon Bedrock zu nutzen, muss man *ein zusätzliches Gateway/einen zusätzlichen Proxy* selbst deployen
      Das Mozilla-Projekt (einschließlich LiteLLM) hat den Vorteil, dass es bereits viele verschiedene Schnittstellen unterstützt und man dadurch sofort mehrere Modelle nutzen kann
      Man kann ohne separaten Proxy-/Gateway-Server direkt mehrere LLM-Provider anbinden. Mit LiteLLM habe ich nicht genug Erfahrung, um es gut zu vergleichen
  • Ich entwickle ebenfalls ein Open-Source-Projekt für eine LLM-Abstraktionsschicht in Python
    Ich habe damit angefangen, weil ich es für meine Forschungsarbeit brauchte
    Inspiriert von bestehenden Projekten habe ich es für allgemeinere Einsatzfälle gebaut
    https://github.com/proxai/proxai
    https://proxai.co/
  • Das Timing ist wirklich erstaunlich
    Ich habe kürzlich ebenfalls eine ähnliche LLM-Abstraktionsschicht veröffentlicht
    Sie lässt sich einfach per pip install verwenden und wurde mit Fokus auf Langchain-Kompatibilität gebaut, sodass sie sich leicht in bestehende Systeme einsetzen lässt
    Außerdem ist automatisches Failover über einen virtuellen Provider möglich, wenn Rate Limits überschritten werden
  • In letzter Zeit gibt es viele Optionen für LLM-Gateway-/Proxy-Layer wie LiteLLM, OpenRouter, Arch, any-llm. Langsam kommt man an den Punkt, an dem wir vielleicht gemeinsam nach neuen Problemen suchen müssen
    • Ich finde LiteLLM etwas kompliziert. Für den einfachen Einsatz als Docker-Container in einem privaten Projekt ist es vielleicht okay, aber für den echten Produktionseinsatz bin ich nicht zufrieden
    • Obwohl 80 % der Modellanbieter OpenAI-kompatible Endpoints unterstützen, tauchen weiterhin viele verschiedene Lösungen auf
    • Ich möchte auch Portkey erwähnen. Es kann mit JS verwendet werden und ist Open Source
    • Wir setzen Modell-Routing in der akademischen Forschung und im Bereich PDF-Chatbots ein. Ich würde gerne Meinungen dazu hören
  • Ich denke, solche Lösungen brauchen unbedingt ein Docker-Image. Soweit ich sehe, wurde Docker nicht erwähnt, aber ich möchte Konflikte mit pip oder Python-Versionen vermeiden
  • Ich nutze den Litellm Proxy auch in meiner Entwicklungsumgebung weiterhin mit Docker
    Die Funktionen Usage/Logs machen den tatsächlichen LLM-Verbrauch sichtbar, und die Cache-Funktion hilft sehr dabei, bei wiederholten Tests Kosten zu sparen
 
egirlasm 2025-07-26

Vielen Dank für den guten Beitrag. Ausgerechnet heute war ich gerade beim 27. Refactoring.
Ich habe mit C++ angefangen, dann JavaScript, und jetzt wieder Rust ...