Bifrost statt LiteLLM? Ein Open-Source-AI-Gateway und seine 50-fach-Behauptung

Der Newsletter Alles nur geCloud (Ausgabe 254 vom 18. Oktober 2026) stellt unter den Link-Tipps Bifrost vor, ein Open-Source-Gateway mit einer OpenAI-kompatiblen API für alle Anbieter. Der Autor führt es als Konkurrenten zu LiteLLM auf und gibt wieder, laut eigener Website sei es 50-mal schneller. Wir fahren LiteLLM als Gateway vor unseren lokalen Modellen, deshalb haben wir nachgesehen, was hinter der Zahl steht.

Was Bifrost kann

Laut Repo ist Bifrost ein AI-Gateway, das sich als LLM-, MCP- oder Agent-Gateway betreiben lässt. Die Lizenz ist Apache 2.0. Der Sprachstack ist auf der Seite nicht ausdrücklich genannt, die Go-Installationsanweisung und der Dateiname core/bifrost.go deuten auf Go.

Die Funktionsliste liest sich wie die eines modernen Gateways:

• Eine OpenAI-kompatible API für mehr als 23 Anbieter, darunter OpenAI, Anthropic, AWS Bedrock und Google Vertex.
• Automatische Fallbacks zwischen Anbietern und Modellen, Lastverteilung über API-Schlüssel, semantischer Cache.
• Nutzungserfassung, Rate Limits, Zugriffssteuerung und Budgets über virtuelle Schlüssel, Teams und Kunden.
• Web-Oberfläche, API oder Dateikonfiguration; für Unternehmen OIDC mit Verzeichnisabgleich, Prometheus-Metriken, Tracing und Clustering.
• Als Ersatz für die SDKs von OpenAI, Anthropic und Google durch Ändern der Basis-URL.

Starten lässt es sich laut Seite mit npx -y @maximhq/bifrost oder mit docker run -p 8080:8080 maximhq/bifrost, die Oberfläche liegt dann auf Port 8080.

Was die Repo-Seite zur Geschwindigkeit sagt

Die 50-fach-Aussage steht auf der GitHub-Seite nicht. Dort heißt es, Bifrost füge bei 5.000 Anfragen pro Sekunde weniger als 200 Mikrosekunden Overhead hinzu. Die Messtabelle nennt bei 5.000 RPS 59 Mikrosekunden auf einer AWS t3.medium und 11 Mikrosekunden auf einer t3.xlarge, die Erfolgsrate liegt in beiden Fällen bei 100 Prozent. Die LiteLLM-Seite taucht im Repo nur als SDK-Integration auf, es gibt keinen Vergleichswert. Auch der Newsletter weist darauf hin, dass die Zahlen in README und Projektbeschreibung voneinander abweichen. Die Projektwebsite (getmaxim.ai/bifrost) nennt die 50-fach-Aussage tatsächlich, belegt sie mit eigenen Werten (P99 54-mal schneller bei 500 RPS, 20 Mikrosekunden Zusatzlatenz) und nennt an anderer Stelle selbst 11 Mikrosekunden; auch das sind Herstellerangaben.

In derselben Tabelle steht die mittlere Anfragelatenz einschließlich Anbieter: 2,12 Sekunden auf der t3.medium und 1,61 Sekunden auf der t3.xlarge. Zum Vergleich: 59 Mikrosekunden sind etwa ein 36.000stel davon. Das ist unsere Rechnung aus den beiden Herstellerzahlen. Selbst ein Gateway, das ein Vielfaches an Overhead hätte, würde im Alltag kaum auffallen. Ins Gewicht fällt der Overhead erst bei sehr hohem Durchsatz oder sehr kurzen Antworten.

Wie man es selbst prüft

Ob 50-fach stimmt, lässt sich nur mit eigener Last beantworten, und die Vorgaben dafür sind einfach: dieselben Modelle dahinter, dieselbe Hardware, dieselben Anfragen. Ein Plan:

Wichtiger als die Mikrosekunden sind bei einem Gateway die Dinge, die im Betrieb wehtun: Wie sicher ist die Standardkonfiguration, wie verlässlich greifen Budgets und Fallbacks, was passiert bei einem Update. Wir haben Bifrost nicht getestet und sprechen deshalb keine Empfehlung aus. Die Zahlen auf der Seite sind ein Grund, es auf der Testliste zu haben.

Weiterführende Quellen

• GitHub: maximhq/bifrost (Repo-Seite, abgerufen 20.10.2026)
• Alles nur geCloud, Ausgabe 254 (18.10.2026)
• Simple Icons: github.svg (Logo, CC0)
• Aus dem Haus: LiteLLM-Gateway im Eigenbetrieb, Update am Gateway vom 15. September