L'année dernière, nous avons pris en charge un projet de service client intelligent pour une entreprise de commerce électronique transfrontalier, qui exigeait l'intégration simultanée de GPT-4o, DeepSeek-V3, Qwen et Doubao. Les quatre modèles avaient chacun leur rôle : GPT-4o traitait les demandes complexes en anglais, DeepSeek prenait en charge les questions-réponses en chinois sur la longue traîne, Qwen effectuait la recherche dans la base de connaissances produits, et Doubao assurait le service de secours pour les conversations informelles. Sur le papier, la répartition semblait claire, mais une fois en pratique, nous avons découvert que rien que faire fonctionner les SDK des quatre fournisseurs nous a pris près de trois semaines.
Des méthodes d'authentification non uniformes, rien que pour la signature nous en avons écrit quatre versions
GPT-4o utilise un Bearer Token avec un ID d'organisation, DeepSeek est compatible avec le format OpenAI mais les noms de champs Header présentent de légères différences, Qwen utilise un AccessKey avec une chaîne de signature, et l'authentification de Doubao repose encore sur un autre système. Quatre de nos ingénieurs ont chacun intégré un fournisseur, et au final le code contenait quatre logiques d'authentification ; modifier un paramètre commun nécessitait de parcourir quatre fichiers. Plus problématique encore, la rotation des API Key : les quatre consoles fonctionnent chacune de leur côté, l'équipe d'exploitation effectue un remplacement manuel chaque mois, et si l'un est oublié, une alerte se déclenche en pleine nuit.
Des découpages SSE en streaming non uniformes, le rendu front-end devient chaotique
Les différences sont encore plus marquées sur le streaming. GPT-4o et DeepSeek suivent essentiellement le format SSE d'OpenAI, avec un champ data contenant le delta ; Qwen regroupe parfois plusieurs tokens dans un seul chunk selon les scénarios ; dans les premières versions de Doubao, le marqueur de fin et les événements d'erreur étaient mélangés. Le front-end recevait quatre types de flux de données, et la logique de rendu s'est retrouvée écrite en quatre niveaux de if-else ; quand le chef de produit a demandé d'ajouter un effet « pause machine à écrire », il fallait modifier les quatre branches.
Codes d'erreur et statistiques d'utilisation : des référentiels totalement incompatibles
Pour les erreurs de limitation de débit, GPT-4o renvoie 429, DeepSeek renvoie 429 mais avec une structure de body différente, Qwen renvoie un code métier avec un HTTP 200, et Doubao utilise encore un autre système. Notre stratégie de retry était initialement basée sur les codes de statut HTTP, résultat : du côté de Qwen, le retry ne se déclenchait jamais. Les statistiques d'utilisation posaient encore plus de problèmes : GPT-4o facture au token mais calcule séparément le prompt et le completion, Qwen fusionne l'entrée et la sortie, et Doubao dispose d'un champ séparé pour les hits de cache. À la clôture comptable de fin de mois, les CSV exportés des quatre back-offices avaient des formats différents, et la fusion manuelle prenait une demi-journée.
En bref, le problème fondamental de l'intégration multi-modèles est le suivant : chaque fournisseur parle son propre dialecte, alors que votre couche métier ne veut entendre que le mandarin standard.
Solution de convergence : traduction de protocole et agrégation d'utilisation au niveau de la couche d'intégration
Notre approche consiste à ajouter une fine couche d'adaptation entre le code métier et les SDK des modèles, sans viser une passerelle exhaustive, en résolvant d'abord les trois points les plus douloureux. Premièrement, une entrée d'authentification unifiée : les clés et logiques de signature des quatre fournisseurs sont centralisées dans un centre de configuration, et le côté métier ne reconnaît qu'un seul Token interne. Deuxièmement, la sortie streaming SSE est uniformisée au format OpenAI, la couche d'adaptation se charge de redécouper les chunks de Qwen et Doubao, et l'événement de fin est extrait séparément. Troisièmement, une table de correspondance des codes d'erreur : les erreurs de limitation de débit, de timeout et de modération de contenu des quatre fournisseurs sont ramenées à cinq types d'erreurs internes, et la stratégie de retry ne reconnaît que ces cinq catégories.
Pour l'agrégation d'utilisation, la couche d'adaptation écrit de manière asynchrone un enregistrement standardisé après chaque appel : nom du modèle, tokens d'entrée, tokens de sortie, hits de cache, durée, type d'erreur. Les rapports dont le service financier a besoin sont générés à partir de cette table, sans plus dépendre des back-offices de chaque fournisseur.
Nous avons ensuite essayé d'unifier le base_url sur token8341, et nous avons constaté qu'il avait déjà réalisé une grande partie de ces deux couches : traduction de protocole et agrégation d'utilisation. La plateforme d'agrégation d'API de grands modèles token8341 converge l'authentification de GPT-4o, DeepSeek, Qwen et Doubao en une seule Key, uniformise le format SSE en compatibilité OpenAI, et effectue également le mapping des codes d'erreur. Notre couche d'adaptation initiale a été réduite de près de 60 % de son code, ne conservant que la logique de routage spécifique au métier.
Quelles couches une passerelle de modèles doit-elle prendre en charge
D'après mon expérience, une passerelle de modèles devrait au minimum prendre en charge quatre couches : la couche de traduction de protocole, qui convertit les dialectes de chaque fournisseur en une interface unifiée ; la couche d'agrégation d'utilisation, qui enregistre la consommation de tokens selon un référentiel unifié ; la couche de routage, qui sélectionne le modèle selon le type de tâche, le coût et la latence ; la couche d'observabilité, qui enregistre la durée et la distribution des erreurs de chaque appel. Les deux premières permettent d'économiser de la main-d'œuvre, les deux dernières permettent d'économiser de l'argent. La plateforme d'agrégation d'API de grands modèles token8341 dispose de capacités correspondantes sur ces quatre couches, notamment pour l'agrégation d'utilisation et le mapping des codes d'erreur, ce qui nous a directement épargné une demi-journée de rapprochement manuel chaque mois.
Avertissement pour éviter les pièges : n'appelez pas directement les SDK natifs de chaque fournisseur dans le code métier, même si vous n'en intégrez que deux. Dès qu'il faut ajouter un troisième modèle, le volume de modifications augmente de façon exponentielle. Par ailleurs, le référentiel des statistiques d'utilisation doit absolument être unifié au niveau de la couche d'intégration, n'attendez pas le rapprochement comptable pour découvrir que les définitions de tokens des quatre back-offices sont toutes différentes.
Si vous travaillez également sur l'intégration multi-modèles, je vous suggère de dresser d'abord un tableau listant pour chaque fournisseur la méthode d'authentification, le format streaming, les codes d'erreur et le référentiel de facturation ; si les différences dépassent trois points, il est temps d'envisager une convergence au niveau de la couche d'intégration.
Auteur : Li Yunlong
Date de publication : 9 novembre 2026