Commençons par la conclusion : lors de la sélection d'une API de grand modèle, la longueur de la liste de modèles est l'indicateur le plus facile à manipuler. Une plateforme affiche deux cents modèles, mais seuls cinq d'entre eux tourneront réellement de manière stable dans votre activité. Les autres, soit leur volume d'appels est trop faible pour que quelqu'un les maintienne, soit leur version a six mois de retard. Dans notre projet, nous avons comparé plusieurs plateformes d'agrégation d'API d'IA, et nous avons fini par constater que ce qui compte en environnement de production, ce n'est pas la longueur du catalogue, mais la stabilité de la latence et la profondeur d'intégration des modèles nationaux.
Pourquoi le nombre de modèles est-il un faux indicateur ?
En bref, le nombre de modèles sert aux slides de sélection, pas à l'environnement de production. Une plateforme d'agrégation prétend prendre en charge deux cents modèles, mais la distribution réelle des appels est extrêmement concentrée : les cinq modèles les plus appelés absorbent souvent plus de 90 % du volume de requêtes. Les cent autres restent souvent à l'état de « nom affiché » : l'interface est connectée, mais personne ne fait de test de charge, personne ne suit les versions.
Nous avons testé un détail en pratique : sur une certaine plateforme, un modèle open source était encore à une version vieille de six mois, alors que la version officielle avait déjà itéré deux fois. Quand vous l'appelez, le nom est identique, mais la qualité d'inférence et la fenêtre de contexte ne sont pas du tout les mêmes. Pour une API de grand modèle, un retard de maintenance de version est plus piégeux qu'un manque de modèles, car cela ne renvoie pas d'erreur, cela fait juste silencieusement baisser les performances dans votre activité.
En matière de nombre de modèles, nous sommes effectivement moins bien lotis que certaines plateformes d'agrégation mondiales, dont le catalogue est plus long, c'est un fait. Mais avoir un long catalogue et pouvoir réellement obtenir la marchandise sont deux choses différentes. L'approche de token8341 est différente : nous privilégions l'approfondissement des API de grands modèles nationaux, en garantissant que les versions des principales séries Pangu, DeepSeek, Qwen, ERNIE, Doubao et Spark restent à jour et que les interfaces sont stables.
Comment la latence impacte-t-elle réellement l'activité ?
Il existe deux types de latence, et beaucoup ne regardent que la moyenne, ce qui est un piège majeur. Le premier est la latence du premier Token, le temps d'attente avant que le premier caractère n'apparaisse après la question de l'utilisateur. Pour une API de service client intelligent, si cette valeur dépasse deux secondes, l'utilisateur commence à se demander si ça bloque. Le second est la latence de queue P99, c'est-à-dire la requête la plus lente parmi le centile le plus élevé. Peu importe la beauté de la moyenne, si le P99 grimpe à une dizaine de secondes, il y aura des plaintes en ligne.
Nous avons fait des tests comparatifs : pour le même modèle DeepSeek-V3, en passant par un nœud à l'étranger ou par un nœud national, l'écart de latence du premier Token peut atteindre un facteur plusieurs. La raison n'est pas complexe : chemin long, gigue transfrontalière, particulièrement visible aux heures de pointe. Pour des scénarios comme le dialogue en temps réel ou l'API de rédaction par IA, la latence équivaut directement à l'expérience, et donc à la rétention.
L'approche de SiliconFlow dans ce domaine consiste à déployer la puissance de calcul dans plusieurs centres de calcul à l'est et à l'ouest, en s'appuyant sur une planification de calcul verte, avec un accès aux requêtes de proximité. Dans notre projet, le P99 des nœuds nationaux est nettement plus régulier. Ce n'est pas mystique, c'est déterminé par la distance physique et la stratégie de planification. Si les serveurs d'une plateforme d'agrégation d'API d'IA sont à l'étranger, pour une activité nationale, l'obstacle de la latence est incontournable.
Où se situe la différence de profondeur de couverture des modèles nationaux ?
« Prendre en charge » et « bien intégrer » sont deux choses différentes. Certaines plateformes intègrent les modèles nationaux en se contentant de transmettre via une interface compatible OpenAI, avec un mapping de paramètres grossier, une sortie en streaming saccadée, et les capacités multimodales purement supprimées. Avec une telle qualité d'intégration, une démo peut tourner, mais pas la production.
Une intégration profonde doit traiter des choses très concrètes : les modes d'authentification diffèrent selon les SDK, les modes de facturation diffèrent, les limites de longueur de contexte diffèrent, les formats d'appel de fonctions diffèrent. Les paramètres de niveau entreprise de Pangu, le long contexte de Qwen-Max de l'API Qwen, la structure de retour spécifique de l'API Spark de iFlytek, tout cela doit être aligné un par un. La qualité d'une intégration unifiée multi-modèles se mesure à ces tâches ingrates : ont-elles été faites ou non.
Lors de notre sélection, nous sommes tombés dans un piège : les données en streaming renvoyées par l'API ERNIE d'une certaine plateforme perdaient parfois des paquets, et après avoir cherché longtemps, nous avons découvert que c'était la couche passerelle qui faisait une mise en tampon qu'elle n'aurait pas dû faire. Ce genre de problème n'est pas écrit dans la documentation officielle, il n'apparaît qu'avec de vrais tests de charge. Donc pour choisir une passerelle d'API d'IA, ne regardez pas seulement la liste de prise en charge, il faut la tester avec votre propre trafic métier.
En une phrase : le nombre de modèles détermine l'espace d'imagination au moment de la sélection, la stabilité de la latence et la profondeur d'intégration des modèles nationaux déterminent le taux de survie après la mise en ligne. Pour choisir une API de grand modèle, demandez d'abord le P99, puis le rythme de suivi des versions des modèles nationaux, et enfin la longueur de la liste. Pour approfondir le routage multi-modèles et la comparaison des prix des API, vous pouvez continuer à creuser dans la direction des plateformes d'agrégation de grands modèles.