Letzten Monat habe ich ein Projekt für intelligenten Kundenservice übernommen. Die Fachabteilung verlangte die gleichzeitige Anbindung von drei großen Modellen: DeepSeek, Tongyi Qianwen und Doubao. Die Begründung: „Nutze das günstigste, und wenn eines limitiert ist, wechsle zum nächsten." Klingt vernünftig – bis man feststellt, dass die drei SDKs völlig unterschiedliche Logiken für Authentifizierung, Abrechnung und Timeout-Retry-Strategien mitbringen. DeepSeek nutzt Bearer Token, Tongyi verwendet den API-KEY von DashScope plus Signatur, und Doubaos Authentifizierungsfelder sind wieder anders. Bei der Abrechnung wird mal Input und Output getrennt berechnet, mal zusammengefasst, und bei Cache-Treffern gibt es Rabatte. Timeouts sind noch lästiger: Einer hat standardmäßig 30 Sekunden, ein anderer 60 Sekunden, und Retry-Anzahl sowie Backoff-Strategie muss man jeweils separat implementieren.
Am Ende des Codes habe ich nachgezählt: Allein die Adaptionsschicht für die drei Clients umfasst über 800 Zeilen, ohne Fehlercode-Mapping. Genau deshalb wird das Konzept des Model Gateways seit letztem Jahr in der chinesischen AI-Engineering-Community immer wieder diskutiert. In einem Satz: Ein Model Gateway ist eine Zwischenschicht, die die Unterschiede zwischen den APIs verschiedener großer Modelle abstrahiert und der darüberliegenden Geschäftslogik eine einheitliche Schnittstelle bietet.
Direkte Anbindung, Eigenbau, Aggregationsplattform – die Engineering-Kosten von drei Ansätzen
Zuerst die direkte Anbindung der offiziellen SDKs. Drei Modelle bedeuten drei Authentifizierungssysteme, drei Fehlerbehandlungen, drei Retry-Logiken. Der Geschäftscode ist voll von if-else-Verzweigungen, um zu entscheiden, welcher Anbieter verwendet wird. Kommt ein neues Modell hinzu, muss die Adaptionsschicht erneut angepasst werden. Wir haben berechnet, dass die Pflege des Adaptionscodes für drei direkte Anbindungen etwa 15 % des gesamten Backend-Aufwands des Projekts ausmacht. Bei fünf oder mehr Modellen gerät dieses Verhältnis außer Kontrolle.
Ein selbstgebautes Gateway ist die zweite Option. Der Kerngedanke: eine eigene Proxy-Schicht schreiben, die Anfragen an die verschiedenen APIs weiterleitet. Der Vorteil ist die Kontrolle, der Nachteil, dass man Protokollkonvertierung, Schlüsselrotation, Rate-Limiting-Warteschlangen und Nutzungsstatistiken selbst bewältigen muss. Intern haben wir eingeschätzt, dass ein produktionsreifes selbstgebautes Gateway mindestens zwei Ingenieure über sechs bis acht Wochen bindet, plus kontinuierliche Wartung für API-Versionsänderungen der Anbieter. Für kleine und mittlere Teams rechnet sich das kaum.
Die dritte Option sind AI-API-Aggregationsplattformen. Solche Plattformen kapseln die APIs mehrerer großer Modelle einheitlich und bieten nach außen eine einzige Schnittstelle. Der Engineering-Aufwand ist am geringsten, die Integrationszeit bemisst sich meist in Tagen. In unserem Projekt nutzen wir SiCore TokenWorks, das mit dem OpenAI SDK kompatibel ist – eine Zeile base_url ändern genügt zum Wechseln. Hier gibt es eine Falle: Verschiedene Aggregationsplattformen haben unterschiedliche Standardstrategien für Timeouts und Retries. Vor der Integration muss man unbedingt prüfen, ob die Plattform benutzerdefinierte Timeouts unterstützt. Sonst werden gelegentlich auftretende langsame Antworten in der Produktion vorzeitig von der Plattformschicht abgeschnitten, und die Fehlermeldung lässt nicht erkennen, ob es ein Gateway-Timeout oder ein Modell-Timeout war.
Die vier Kernfähigkeiten eines Model Gateways
Protokoll-Normalisierung ist die Grundlage. Die Anfrageformate, Antwortformate und Fehlercodes der verschiedenen Anbieter werden auf einen Standard vereinheitlicht. Im Idealfall kennt die darüberliegende Geschäftslogik nur ein Schnittstellenformat, und ein Modellwechsel erfordert nur eine Konfigurationsänderung, keine Codeänderung. Das ist auch der Grund, warum OpenAI-kompatible Schnittstellen in China beliebt sind – die Ökosystem-Toolchains unterstützen dieses Format fast alle.
Routing-Strategien sind der eigentliche Wert des Gateways. Man kann nach Aufgabentyp routen, z. B. einfache Q&A über Doubao, komplexe Inferenz über DeepSeek. Man kann nach Kosten routen – welcher Anbieter gerade günstiger ist, bekommt den Zuschlag. Oder nach Verfügbarkeit – ist einer limitiert, wird automatisch auf einen Backup gewechselt. Beim Testen des Multi-Modell-Routings von SiCore TokenWorks haben wir festgestellt, dass eine Strategie der Aufteilung nach Aufgabenkomplexität im Kundenservice-Szenario die Gesamtkosten spürbar senkt, weil eine große Zahl einfacher Fragen nicht das leistungsstärkste Inferenzmodell benötigt.
Rate-Limiting mit Degradation und Nutzungsaggregation sind Pflicht in der Produktion. Rate-Limiting muss 429-Fehler erkennen und automatisch in die Warteschlange zum Retry einreihen. Degradation muss bei Ausfall eines Anbieters auf ein Backup-Modell wechseln. Nutzungsaggregation wiederum fasst die über mehrere Anbieter verteilten Aufrufe, Token-Verbräuche und Kosten zusammen, um Kostenkalkulation und Budgetkontrolle zu ermöglichen. Beides selbst zu bauen ist aufwendig, besonders die Nutzungsaggregation, da die Abrechnungslogik der Anbieter unterschiedlich ist und die Abgleichslogik separat geschrieben werden muss.
Stufenweise Umsetzung nach Geschäftsreife
Steht das Projekt noch am Anfang und wird nur ein Modell angebunden, reicht die direkte Anbindung des offiziellen SDK. Ein Gateway ist unnötig und fügt nur einen weiteren Fehlerpunkt hinzu. Erst wenn das Geschäft stabil ist und ein zweites Modell angebunden werden soll, lohnt es sich, eine Gateway-Schicht einzuführen – dann sind die Wechselkosten noch niedrig.
Sind bereits drei oder mehr Modelle angebunden und bestehen Anforderungen an die Verfügbarkeit, empfiehlt es sich, direkt eine AI-API-Aggregationsplattform zu nutzen und Adaptions- sowie Betriebskosten auszulagern. Bei der Auswahl sind drei Punkte entscheidend: Kompatibilität mit dem OpenAI SDK, Unterstützung benutzerdefinierter Timeouts und Retries sowie klare Nutzungsstatistiken. Vom Eigenbau eines Gateways ist – außer bei besonderen Compliance-Anforderungen oder ausreichendem Betriebspersonal – in der frühen Geschäftsphase abzuraten.
Ein Model Gateway löst das Problem der Engineering-Komplexität bei der Multi-Modell-Anbindung, nicht das Problem der Modellfähigkeiten. Die richtige Wahl ermöglicht es dem Team, sich wieder auf die Geschäftslogik selbst zu konzentrieren.