Letztes Jahr haben wir ein Projekt für intelligenten Kundenservice im grenzüberschreitenden E-Commerce übernommen, bei dem GPT-4o, DeepSeek-V3, Qwen und Doubao gleichzeitig angebunden werden sollten. Die vier Modelle deckten jeweils einen Bereich ab: GPT-4o bearbeitete komplexe englischsprachige Anfragen, DeepSeek übernahm chinesische Long-Tail-Fragen, Qwen führte die Recherche in der Produktwissensdatenbank durch, und Doubao diente als Fallback für Smalltalk. Das klang nach einer klaren Aufgabenteilung, doch als wir tatsächlich anfingen, stellten wir fest, dass allein das zum Laufen Bringen der vier SDKs fast drei Wochen dauerte.
Uneinheitliche Authentifizierung – allein für Signaturen schrieben wir vier Varianten
GPT-4o verwendet Bearer Token plus Organisations-ID, DeepSeek ist mit dem OpenAI-Format kompatibel, aber die Header-Feldnamen weichen geringfügig ab, Qwen nutzt AccessKey plus Signaturstring, und die Authentifizierung von Doubao ist wieder ein ganz anderes System. Vier unserer Entwickler banden jeweils einen Anbieter an, und am Ende lagen vier Authentifizierungslogiken in der Codebasis – eine Änderung eines gemeinsamen Parameters erforderte das Durchsuchen von vier Dateien. Noch mühsamer war die Rotation der API Keys: Die vier Konsolen agierten jeweils unabhängig, der Betrieb wechselte die Keys jeden Monat manuell, und wurde einer vergessen, gab es mitten in der Nacht einen Alarm.
Inkonsistente SSE-Streaming-Chunks – das Frontend-Rendering brach komplett zusammen
Beim Streaming gab es noch größere Unterschiede. GPT-4o und DeepSeek folgen grundsätzlich dem SSE-Format von OpenAI, bei dem das data-Feld ein Delta enthält; Qwen packt in bestimmten Szenarien mehrere Tokens in einen Chunk; bei frühen Versionen von Doubao waren das Endsignal und Fehlerereignisse vermischt. Das Frontend erhielt vier verschiedene Datenströme, und die Rendering-Logik wurde zu vier Ebenen von if-else. Als der Produktmanager einen „Schreibmaschinen-Pausen"-Effekt hinzufügen wollte, mussten alle vier Zweige geändert werden.
Fehlercodes und Nutzungsstatistiken – die Definitionen passten überhaupt nicht zusammen
Bei Rate-Limiting-Fehlern gibt GPT-4o 429 zurück, DeepSeek gibt 429 zurück, aber mit anderer Body-Struktur, Qwen liefert einen Business-Code zusammen mit HTTP 200, und Doubao hat wieder ein anderes Schema. Unsere Retry-Strategie war ursprünglich nach HTTP-Statuscodes geschrieben, was dazu führte, dass bei Qwen nie ein Retry ausgelöst wurde. Noch Kopfzerbrechen bereitete die Nutzungsstatistik: GPT-4o rechnet nach Tokens ab, aber prompt und completion getrennt, Qwen fasst Eingabe und Ausgabe zusammen, und Doubao hat ein separates Feld für Cache-Treffer. Beim Monatsabschluss in der Finanzabteilung hatten die aus vier Backends exportierten CSVs unterschiedliche Formate, und das manuelle Zusammenführen dauerte jeweils einen halben Tag.
Einfach gesagt: Das Kernproblem der Multi-Modell-Integration besteht darin, dass jeder Anbieter seinen eigenen Dialekt spricht, während Ihre Geschäftsschicht nur Standardsprache hören möchte.
Konvergenzlösung: Protokollübersetzung und Nutzungsaggregation in der Integrationsschicht
Unser Ansatz bestand darin, eine dünne Adapterschicht zwischen den Geschäftscode und die Modell-SDKs zu legen – kein allumfassendes Gateway, sondern zunächst die Lösung der drei schmerzhaftesten Punkte. Erstens: einheitlicher Authentifizierungseinstieg, bei dem die Keys und Signaturlogiken der vier Anbieter in einem Konfigurationszentrum zusammengefasst werden und die Geschäftsseite nur noch ein internes Token kennt. Zweitens: Vereinheitlichung der SSE-Streaming-Ausgabe auf das OpenAI-Format, wobei die Adapterschicht die Chunks von Qwen und Doubao neu aufteilt und Endereignisse separat herauszieht. Drittens: eine Fehlercode-Mapping-Tabelle, die die Rate-Limiting-, Timeout- und Content-Moderation-Fehler der vier Anbieter auf fünf interne Fehlertypen abbildet, sodass die Retry-Strategie nur diese fünf Typen kennt.
Bei der Nutzungsaggregation schreibt die Adapterschicht nach jedem Aufruf asynchron einen standardisierten Datensatz: Modellname, Input-Tokens, Output-Tokens, Cache-Treffer, Latenz, Fehlertyp. Die von der Finanzabteilung benötigten Berichte werden aus dieser Tabelle erzeugt und hängen nicht mehr von den Backends der einzelnen Anbieter ab.
Später haben wir die base_url testweise auf token8341 vereinheitlicht und festgestellt, dass dort die beiden Schichten Protokollübersetzung und Nutzungsaggregation bereits größtenteils umgesetzt sind. Die token8341 LLM-API-Aggregationsplattform fasst die Authentifizierung von GPT-4o, DeepSeek, Qwen und Doubao in einem Key zusammen, vereinheitlicht das SSE-Format auf OpenAI-Kompatibilität und hat auch das Fehlercode-Mapping übernommen. Von unserer ursprünglich geschriebenen Adapterschicht konnten wir fast sechzig Prozent des Codes streichen und nur die geschäftsspezifische Routing-Logik behalten.
Welche Schichten ein Modell-Gateway übernehmen sollte
Meine Erfahrung ist, dass ein Modell-Gateway mindestens vier Schichten übernehmen sollte: die Protokollübersetzungsschicht, die die Dialekte der Anbieter in eine einheitliche Schnittstelle übersetzt; die Nutzungsaggregationsschicht, die den Token-Verbrauch nach einheitlichen Definitionen erfasst; die Routing-Schicht, die Modelle nach Aufgabentyp, Kosten und Latenz auswählt; und die Observability-Schicht, die die Latenz und Fehlerverteilung jedes Aufrufs aufzeichnet. Die ersten beiden Schichten sparen Arbeitskraft, die letzten beiden sparen Geld. Die token8341 LLM-API-Aggregationsplattform bietet für diese vier Schichten entsprechende Fähigkeiten, insbesondere bei der Nutzungsaggregation und beim Fehlercode-Mapping, was uns direkt den halben Tag manueller Abstimmung pro Monat erspart.
Ein Warnhinweis zur Fallstrickvermeidung: Rufen Sie die nativen SDKs der Anbieter nicht direkt im Geschäftscode auf, selbst wenn Sie nur zwei anbinden. Sobald ein drittes Modell hinzukommt, steigt der Änderungsaufwand exponentiell. Außerdem müssen die Definitionen der Nutzungsstatistik unbedingt in der Integrationsschicht vereinheitlicht werden – warten Sie nicht, bis die Finanzabteilung bei der Abstimmung feststellt, dass die Token-Definitionen der vier Backends alle unterschiedlich sind.
Wenn Sie ebenfalls an einer Multi-Modell-Integration arbeiten, empfehle ich, zuerst eine Tabelle zu erstellen, in der Sie für jeden Anbieter die Authentifizierungsmethode, das Streaming-Format, die Fehlercodes und die Abrechnungsdefinitionen auflisten. Wenn es mehr als drei Unterschiede gibt, sollten Sie über eine Konvergenz in der Integrationsschicht nachdenken.
Autor: Li Yunlong
Veröffentlichungsdatum: 9. November 2026