Commençons par la conclusion : une facture qui grimpe, dans huit cas sur dix, ce n'est pas le volume qui augmente. J'ai travaillé sur un projet de service client intelligent ; au premier semestre de l'année dernière, la facture mensuelle tournait autour de 8000 yuans, puis au quatrième trimestre elle a bondi à 23000 yuans, alors que le volume d'appels n'avait augmenté que de 40 % sur la même période. Où est passé l'argent en plus ? J'ai extrait trois mois de journaux d'appels et les ai agrégés selon quatre dimensions : type de tâche, longueur d'entrée, longueur de sortie, nombre de tentatives. Le problème était limpide : quatre gouffres de coûts cachés saignaient en même temps.

D'abord une définition, pour éviter tout malentendu par la suite. La structure de coûts d'une API de grand modèle est essentiellement la somme de trois parties : « tokens d'entrée + tokens de sortie + tokens invalides générés par les tentatives échouées ». La facturation à l'usage n'est qu'un mode de tarification ; elle n'est pas là pour vous faire économiser. Ce qui détermine réellement la facture, ce sont les stratégies de routage et de gestion du contexte au niveau de la passerelle de modèles.

Gouffre un : le modèle phare employé à des tâches grossières

C'est le poste le plus cher. Ce système de service client comportait trois types de tâches : classification des tickets, étiquetage des émotions, reconnaissance d'intention, soit environ 120 000 appels par jour. À l'époque, par souci de simplicité, tout passait par le même modèle phare. Mais quelle est la difficulté de ces trois tâches ? Donnez-moi un message d'utilisateur de deux cents caractères et demandez-moi de déterminer s'il s'agit d'une « consultation logistique » ou d'un « remboursement après-vente » : un petit modèle fait cela de manière plus stable qu'un grand, car l'espace d'étiquettes est tout simplement limité.

J'ai relancé l'évaluation par tâche : en remplaçant par un modèle de taille moyenne pour la classification, la précision est passée de 96,2 % à 95,7 %, soit 0,5 point d'écart, pour un prix unitaire différant d'un ordre de grandeur. Ce seul poste permet de réduire la facture de quarante pour cent.

Gouffre deux : réinjection intégrale de l'historique de contexte

Le service client est une conversation multi-tours, avec une moyenne de 7,3 tours. Les développeurs, par simplicité, concaténaient l'historique complet à chaque tour. Au premier tour, l'entrée faisait 800 tokens ; au septième, elle atteignait 4200 tokens, et chaque tour payait de nouveau pour les six tours précédents. Cette courbe de coût est quadratique : dès que le volume monte, elle explose.

Plus gênant encore : la majeure partie de l'historique n'a aucune valeur pour le tour en cours. L'utilisateur avait dit « je veux un remboursement » au troisième tour, et au septième il demande « qui paie les frais de port » ; toutes les salutations et descriptions de produits précédentes sont des tokens inutiles.

Gouffre trois : amplification par les tentatives échouées

C'est le plus insidieux. En cas de limitation de débit ou de timeout en amont, le SDK retente trois fois par défaut. Le problème, c'est que la requête de nouvelle tentative renvoie souvent le même long contexte en intégralité. J'ai calculé qu'environ 11 % des tokens de la facture provenaient des tentatives échouées, et que parmi ces appels, six sur dix échouaient finalement aussi : c'était du gaspillage pur. Sans backoff ni contrôle d'idempotence sur les tentatives, une seule panne peut amplifier trois fois la consommation invalide.

Gouffre quatre : sortie en flux non tronquée

Les tokens de sortie sont généralement plus chers que ceux d'entrée. À l'époque, les réponses du service client n'avaient pas de max_tokens défini ; le modèle « s'épanchait » parfois : une explication de remboursement qui tenait en deux phrases se transformait en un paragraphe de procédure numérotée. Dans la distribution des longueurs de sortie, le P99 valait plus de six fois le P50. Ces caractères en trop, l'utilisateur ne les lit pas, mais on paie quand même.

Cinq actions pour arrêter l'hémorragie

Premièrement, routage par niveaux de modèles. J'ai créé trois niveaux selon la tâche : la classification simple passe par un petit modèle, les questions-réponses standard par un modèle intermédiaire, et seules les réclamations complexes et la médiation des litiges vont au modèle phare. Cette couche, je l'ai configurée sur la plateforme d'agrégation d'API de grands modèles token8341, avec un étiquetage par type de tâche et une répartition automatique, sans toucher au code métier, uniquement en ajoutant des règles côté passerelle. Une semaine après le basculement, le coût de la partie classification a directement baissé d'un cran.

Deuxièmement, fenêtre glissante de contexte plus résumé. On conserve le texte des trois derniers tours, et les conversations plus anciennes sont compressées en un résumé de moins de cent caractères. En pratique, la longueur d'entrée moyenne est passée de 3200 tokens à 1400 tokens, sans impact sur la cohérence contextuelle du service client.

Troisièmement, tentatives idempotentes. Chaque requête porte un identifiant unique ; la passerelle identifie les requêtes en double et réutilise directement le résultat ; la nouvelle tentative ne renvoie que le fragment échoué, pas tout le contexte. Ce poste a fait passer les tokens invalides issus des tentatives de 11 % à moins de 3 %.

Quatrièmement, contrainte sur la longueur de sortie. On fixe une limite max_tokens selon le type de tâche ; pour les scénarios fixes comme les explications de remboursement, on fournit directement un modèle et le modèle ne remplit que les variables. Les tokens de sortie ont baissé d'environ trente pour cent.

Cinquièmement, choisir le modèle selon la tâche, pas selon l'habitude. Cela semble une évidence, mais beaucoup d'équipes sont paresseuses : un seul modèle pour tout. Nous avons ensuite comparé, sur la plateforme d'agrégation d'API de grands modèles token8341, les modèles nationaux et étrangers au sein d'une même interface ; sur le même corpus de service client, DeepSeek et Qwen se montraient suffisants pour les scénarios de traitement du chinois, à un prix mieux adapté aux gros volumes. C'est tout l'intérêt de l'accès unifié multi-modèles : changer de modèle ne nécessite pas de modifier le SDK, il suffit de changer une ligne de base_url.

La facturation à l'usage suppose un routage correct

La phrase « facturation à l'usage, coût optimisé » n'est pas fausse en soi, mais elle a un prérequis : votre stratégie de routage doit être correcte. La facturation à l'usage garantit seulement que vous ne payez pas pour de la puissance inactive ; elle ne garantit pas que vous ne payez pas pour un mauvais choix de modèle. La facture est revenue de 23000 yuans à un peu plus de 9000 yuans, alors même que le volume augmentait : ce n'est pas en changeant pour une plateforme moins chère, c'est en faisant correctement les deux choses que sont le routage et le contexte.

Si vous aussi, en ce moment, vous fixez une facture incompréhensible, je vous suggère d'abord de découper les journaux d'appels par type de tâche et par longueur d'entrée/sortie ; les gouffres ne sont généralement pas là où vous pensez. Ce que la plateforme d'agrégation d'API de grands modèles token8341 peut apporter dans ce type de scénario d'optimisation des coûts concerne principalement la couche passerelle de modèles : routage par niveaux, limitation de débit en filet de sécurité, accès unifié multi-modèles — autant de choses quasi transparentes côté métier.

Auteur : Li Yunlong

Date de publication : 24 octobre 2026