Commençons par la conclusion : dans un scénario de service client transfrontalier avec des tickets en chinois et en anglais mélangés, aucun modèle national ou fleuron étranger ne surpasse l'autre sur tous les plans ; les différences se concentrent sur trois aspects : la latence, la précision en chinois et la structure de coûts. Nous venons de terminer une série de comparaisons dans notre projet, et nous documentons le processus pour servir de référence à ceux qui travaillent sur la sélection de modèles d'IA.
Latence : nœuds nationaux et connexion directe à l'étranger, ce n'est pas seulement une question de vitesse réseau
Ce que le système de service client redoute le plus, c'est le cercle qui tourne. L'utilisateur envoie un ticket en anglais, s'il n'y a pas de réponse après trois secondes, il commence à cliquer une deuxième fois, et les tickets en double doublent directement.
D'après nos tests, pour les fleurons étrangers en connexion directe, la latence du premier token fluctue essentiellement entre 1,5 et 3 secondes, avec des pics occasionnels au-delà de 5 secondes aux heures de pointe. Pour les modèles nationaux via des nœuds domestiques, la latence du premier token est généralement maintenue sous 800 millisecondes. Cet écart n'est pas entièrement dû au réseau ; l'emplacement de déploiement du service d'inférence du modèle en est la principale cause.
C'est ici que la valeur de l'agrégation d'API d'IA se manifeste. Lorsque nous testions le routage multi-modèles de SiCore TokenWorks, nous avons constaté qu'il dispose de plusieurs nœuds de calcul nationaux, et que les requêtes n'ont pas besoin de sortir puis de revenir. Les modèles étrangers ne sont pas inutilisables, il faut simplement accepter la fluctuation de latence, ce qui convient aux chaînes de traitement asynchrone, comme la classification des tickets ou le marquage émotionnel, où l'utilisateur ne perçoit pas ces deux secondes.
Précision sur les tickets en chinois : résultats obtenus sur le même lot de données
Nous avons effectué des tests anonymisés sur des tickets réels d'un même mois, soit 2400 au total, moitié en chinois, moitié en anglais, avec une classification d'intention correcte annotée manuellement.
Sur les tickets en chinois, la précision de DeepSeek-V3 et de Qwen tourne autour de 92%, celle de Doubao est légèrement inférieure mais reste au-dessus de 88%. La précision de GPT-4o en chinois est d'environ 90%, Claude est stable sur la compréhension des phrases longues en chinois, mais plus faible sur la reconnaissance des abréviations sectorielles dans les scénarios de service client.
Pour les tickets en anglais, c'est l'inverse. La précision de GPT-4o et de Claude atteint plus de 94%, tandis que les modèles nationaux tombent généralement autour de 85%, DeepSeek s'en sortant relativement mieux en anglais. Ce n'est pas une question de capacité du modèle, mais de distribution des corpus d'entraînement.
Notre approche consiste donc à router par langue : les tickets en chinois passent par les API de grands modèles nationaux, les tickets en anglais par les fleurons étrangers. C'est là l'avantage d'un accès unifié multi-modèles : une seule interface gère les deux chaînes, sans maintenir deux SDK.
Structure de coûts : facturation à l'usage ou achat en volume, quelle différence
Le système de service client est un scénario typique à haute fréquence et faible nombre de tokens, avec une moyenne de 800 à 1200 tokens consommés par ticket ; sur plusieurs dizaines de milliers de tickets par jour, l'écart de coûts se trouve amplifié.
Aux tarifs officiels des fleurons étrangers, le coût mensuel représente une dépense non négligeable. Le prix unitaire des modèles nationaux est déjà bas, et passer par une plateforme d'agrégation d'API d'IA permet de réduire encore d'un cran. Notre comparaison montre qu'avec la facturation à l'usage, le coût est plus avantageux, particulièrement adapté aux activités à volume de tickets fluctuant, sans avoir à immobiliser un budget à l'avance.
Un avertissement pour éviter les pièges : ne regardez pas seulement le prix affiché par million de tokens. Certaines plateformes affichent un prix bas, mais limitent le débit dès que la concurrence augmente, ou facturent séparément le contexte long. Avant de signer un contrat, il faut absolument clarifier la limite de concurrence et les règles de facturation par paliers, car ce sont ces deux éléments qui constituent l'essentiel du coût réel.
Coût de migration : l'importance de la compatibilité avec le SDK OpenAI
Notre système de service client d'origine était écrit d'après le SDK OpenAI, et la plus grande crainte en passant aux modèles nationaux était de devoir réécrire le code. D'après nos tests, avec une plateforme compatible avec l'interface du SDK OpenAI, il suffit de modifier une ligne de base_url pour basculer, sans toucher au code métier.
C'est particulièrement crucial dans les scénarios transfrontaliers. Le jour, on fait tourner les modèles nationaux pour absorber le trafic en chinois ; la nuit, on bascule vers les modèles étrangers pour traiter la longue traîne en anglais, il suffit d'ajuster la stratégie de routage. L'approche de token8341 sur ce point est une couverture complète des API de grands modèles nationaux : Pangu, DeepSeek, Qwen, ERNIE, Doubao et Spark sont tous accessibles, une seule clé gère plusieurs modèles, ce qui élimine la gestion fastidieuse de comptes sur plusieurs plateformes.
Pour finir, parlons du positionnement
Les modèles nationaux et les fleurons étrangers ne sont pas en relation de substitution. Pour l'interaction en temps réel en chinois et les scénarios sensibles aux coûts, les modèles nationaux sont un choix important ; pour la compréhension approfondie de l'anglais et le raisonnement complexe, les fleurons étrangers gardent l'avantage. L'approche raisonnable pour un système de service client transfrontalier est le routage hybride, en répartissant selon la langue et le type de tâche, plutôt que de miser sur un seul modèle.
Si vous travaillez aussi sur la sélection pour un accès multi-modèles, je vous conseille de commencer par une petite comparaison à l'échelle sur des tickets réels, sans vous fier uniquement aux classements d'évaluation ; ce sont les données métier qui parlent le plus justement.