One API vs New API: LLM-Gateway-Vergleich 2026

Constantin, Pexon Consulting | 7 Min. Lesezeit | 25.07.2026

TL;DR

One API und New API sind quelloffene, selbst gehostete LLM-Gateways für die zentrale Verwaltung von Tokens, Nutzern und Quotas über viele KI-Anbieter hinweg. Beide taugen für den internen Einsatz, scheitern aber an harter Enterprise-Governance. Pexon prüft, härtet und produktionalisiert dein LLM-Gateway sauber und nachvollziehbar als 6-Wochen-Pilot.

Warum ihr überhaupt ein LLM-Gateway braucht

Sobald mehr als ein Team im Unternehmen mit Sprachmodellen arbeitet, kippt die Kontrolle. Jede Abteilung holt sich einen eigenen OpenAI-Key, DeepSeek läuft nebenbei, ein Data-Science-Team testet Anthropic, niemand weiß, wer wie viel verbraucht. Am Monatsende liegt eine Kreditkartenabrechnung auf dem Tisch, die keiner erklären kann, und die Frage der Datenschutzabteilung, welche Daten an welchen Anbieter gehen, bleibt unbeantwortet.

Ein LLM-Gateway zieht diese Fäden zusammen. Es steht als einheitliche Schnittstelle vor allen Anbietern, verteilt Anfragen, zählt Tokens, setzt Limits und gibt dir einen Ort, an dem du siehst, was passiert. One API und New API sind zwei der bekanntesten quelloffenen Vertreter dieser Kategorie – und beide lassen sich auf eurer eigenen Infrastruktur betreiben, ohne dass eine Zeile Prompt-Text einen fremden SaaS-Anbieter berührt.

Was One API und New API sind

One API (songquanpeng/one-api) ist ein selbst gehostetes System zur Verwaltung und Weiterverteilung von LLM-Zugängen. Es bündelt OpenAI, Azure OpenAI, Anthropic, Google Gemini, DeepSeek und eine lange Liste chinesischer Modelle hinter einer OpenAI-kompatiblen API. Dazu kommen Token-Verwaltung, Nutzer- und Gruppenrechte, Quotas, Gutschein- und Guthaben-Logik sowie Gruppen-Tarife. Das Ganze kommt als einzelnes Binary oder Docker-Image, MIT-lizenziert. Laut GitHub liegt das Projekt bei rund 35.000 Sternen (Stand Juni 2026) und gehört damit zu den meistbeachteten Gateways überhaupt.

New API (Calcium-Ion/new-api) ist ein Fork genau dieses Projekts. Er übernimmt die Grundarchitektur, erweitert sie aber um zusätzliche Anbieter, mehr Abrechnungsfunktionen und eine deutlich modernere Oberfläche. Nach Angaben von GitHub steht New API bei über 38.000 Sternen und hat das Ursprungsprojekt in der reinen Popularität überholt. Beide teilen dieselbe DNA, weshalb ein Wechsel zwischen ihnen selten ein Bruch ist.

Unsere klare Position: Für einen internen Marktplatz, auf dem ihr Keys an Teams verteilt und den Verbrauch abrechnet, sind beide Werkzeuge ausgereift genug. Wer heute frisch startet und Wert auf UI und Feature-Breite legt, nimmt New API. Wer Stabilität über Neuerungen stellt, bleibt bei One API.

One API vs New API im Detail

Der Unterschied ist weniger technisch-grundlegend als kulturell. New API entwickelt sich schneller, integriert neue Anbieter früher und poliert die Bedienoberfläche. One API ist ruhiger, konservativer und für manche Betriebsteams gerade deshalb angenehmer. Beide sprechen die OpenAI-Schnittstelle, sodass eure bestehenden SDKs unverändert weiterlaufen – ihr tauscht nur die Basis-URL.

Wenn ihr ohnehin evaluiert, lohnt der Blick über den chinesischen Tellerrand hinaus. Ein gehosteter Aggregator wie OpenRouter im Unternehmenseinsatz nimmt euch den Betrieb komplett ab, kostet dafür aber Datenhoheit. Und wenn ihr die Kategorie grundsätzlich verstehen wollt, bevor ihr euch auf ein Produkt festlegt, hilft unsere Übersicht zum LLM-Gateway als Architekturbaustein beim Sortieren der Optionen.

So schnell habt ihr New API lokal am Laufen:

# docker-compose.yml - New API mit MySQL und Redis
# Startbefehl: docker compose up -d
services:
  new-api:
    image: calciumion/new-api:latest
    container_name: new-api
    ports:
      - "3000:3000"          # Weboberfläche und API-Endpunkt
    environment:
      # Verbindung zur Datenbank (Zugangsdaten anpassen!)
      - SQL_DSN=root:GeheimesPasswort@tcp(mysql:3306)/new-api
      - REDIS_CONN_STRING=redis://redis
      - TZ=Europe/Berlin     # Zeitzone für saubere Abrechnungszeiträume
    depends_on:
      - mysql
      - redis
    restart: always
  mysql:
    image: mysql:8
    environment:
      - MYSQL_ROOT_PASSWORD=GeheimesPasswort
      - MYSQL_DATABASE=new-api
    restart: always
  redis:
    image: redis:latest
    restart: always

Nach dem ersten Start meldet ihr euch mit dem Standard-Admin an, hinterlegt eure Anbieter-Keys als Kanäle und legt Nutzer-Tokens mit Quotas an. Das ist in einer Stunde eingerichtet – der schwierige Teil kommt danach.

Die ehrliche Falle: Governance und Herkunft

Hier wird es unbequem. Beide Projekte stammen aus dem chinesischen Ökosystem, und das schlägt auf zwei Ebenen durch. Erstens ist ein relevanter Teil der Dokumentation und der Issues auf Chinesisch. Wer Support braucht, kämpft gelegentlich mit Übersetzung und Kontext. Zweitens – und das wiegt schwerer – ist die Governance dünn. Es gibt keine ausgereifte, rollenbasierte Rechtevergabe auf Enterprise-Niveau, kein natives SSO, keine revisionssichere Audit-Spur, die einem Wirtschaftsprüfer standhält.

Der teurere Weg ist, das erst in der Produktion zu merken. Wir haben Teams gesehen, die ihr komplettes KI-Ökosystem auf ein self-hosted Gateway gebaut haben und dann bei der ersten Sicherheitsprüfung feststellten, dass sie nicht nachweisen können, wer wann welchen Prompt an welchen Anbieter geschickt hat. Für ein internes Tool ohne regulatorische Anforderungen ist das egal. Für eine Bank, einen Versicherer oder ein Unternehmen mit Berufsgeheimnisträgern ist es ein Ausschlusskriterium.

Das heißt nicht, dass die Projekte schlecht sind. Es heißt, dass ihr wissen müsst, wofür ihr sie einsetzt.

Praxis: Wann self-hosted, wann Enterprise

Unsere Faustregel ist einfach. Braucht ihr ein Gateway, um intern Kosten transparent zu machen, Teams Budgets zuzuweisen und Anbieter flexibel zu tauschen – und läuft das Ganze in einer Umgebung ohne strenge Compliance-Auflagen? Dann sind One API oder New API eine hervorragende, kostenlose Basis. Ihr behaltet die volle Datenhoheit und zahlt nur für die Modelle, die ihr tatsächlich nutzt.

Sobald aber Auditierbarkeit, SSO, feingranulare Rechte und Betriebsgarantien ins Spiel kommen, raten wir zu einem Werkzeug mit ausgereifter Governance-Schicht. Kommerzielle oder governance-starke Open-Source-Optionen setzen genau dort an, wo One API und New API aufhören. Das ist kein Widerspruch zur Self-Hosting-Idee – auch diese Werkzeuge lassen sich in der eigenen Cloud betreiben, sie bringen nur die Kontrollmechanismen mit, die ihr sonst selbst nachrüsten müsstet.

Der pragmatische Mittelweg, den wir am häufigsten empfehlen: Startet mit New API als Proof of Concept, um die Kategorie zu verstehen und euren tatsächlichen Bedarf zu messen. Entscheidet die Produktionsplattform erst dann – auf Basis echter Nutzungsdaten statt auf Basis von Sternen-Zahlen auf GitHub.

Häufig gestellte Fragen

Was ist der Unterschied zwischen One API und New API?

New API ist ein Fork von One API und erweitert das Original um zusätzliche Anbieter, mehr Abrechnungsfunktionen und eine modernere Oberfläche. One API ist ruhiger und stabiler, New API entwickelt sich schneller. Beide teilen dieselbe Architektur und sind MIT-lizenziert.

Sind One API und New API DSGVO-konform?

Von Haus aus nein – sie liefern keine revisionssichere Audit-Spur, kein natives SSO und keine feingranulare Rechtevergabe auf Enterprise-Niveau. Weil ihr sie aber selbst hostet, könnt ihr die technischen Voraussetzungen für DSGVO-Konformität schaffen. Genau dieses Härten ist Projektarbeit, kein Häkchen.

Was kostet der Betrieb von One API oder New API?

Die Software selbst ist quelloffen und kostenlos. Kosten entstehen für die Infrastruktur (ein kleiner Server plus Datenbank reicht für den Start) und für die tatsächlich genutzten Modell-Tokens der Anbieter. Der größte Posten ist meist nicht die Lizenz, sondern der Betriebsaufwand für Härtung, Monitoring und Support.

Kann ich mit einem Gateway zwischen OpenAI und anderen Anbietern wechseln?

Ja, das ist einer der Hauptvorteile. Beide Gateways sprechen die OpenAI-kompatible Schnittstelle, sodass ihr Anfragen ohne Code-Änderung an DeepSeek, Anthropic, Gemini oder ein selbst gehostetes Modell umleiten könnt. Ihr tauscht lediglich die konfigurierten Kanäle im Gateway.

Sind chinesische LLM-Gateways ein Sicherheitsrisiko?

Der Code ist quelloffen und prüfbar, ein verstecktes Risiko im Binary ist also unwahrscheinlich. Das eigentliche Risiko liegt in der dünnen Governance und der teils chinesischsprachigen Dokumentation, die Betrieb und Compliance erschweren. Wer die Software selbst auditiert und härtet, kann sie sicher betreiben.

Nächster Schritt

Wenn ihr wissen wollt, ob ein self-hosted Gateway oder eine governance-starke Enterprise-Plattform zu eurer Situation passt, schauen wir uns eure Anforderungen gemeinsam an.

Verwandte Themen