Commençons par la conclusion : si un chatbot de service client coûte cher, dans 80 % des cas ce n'est pas parce que le prix unitaire du modèle est élevé, mais parce que la façon de l'appeler pose problème. En interne, un robot de questions-réponses après-vente avec quelques milliers d'utilisateurs actifs par jour a vu sa facture grimper directement à trois fois le budget dès le premier mois. Après investigation, le prix unitaire du modèle n'avait pas bougé d'un centime ; tout venait de coûts cachés dans la structure des appels. Cet article retrace le processus de rétrospective ; si vous travaillez sur l'optimisation des coûts d'API de grands modèles, vous pouvez vérifier votre propre facture en parallèle.
À quoi ressemble une facture anormale
La caractéristique de l'anomalie n'est pas « un montant total élevé », mais « une structure étrange ». Nous avons extrait le détail des appels jour par jour et découvert trois points suspects : les jours de plus forte activité, le nombre moyen de tokens par requête augmentait ; la proportion de tentatives de réessai approchait les 20 % ; pour une même question utilisateur, cela allait de quelques centaines de tokens à plus de dix mille, avec une variance énorme. Ces trois éléments réunis suffisent en général à localiser le problème : il n'est pas du côté du modèle, mais dans notre propre chaîne d'appels.
Quatre coûts cachés, chacun plus insidieux que le précédent
Premièrement, le modèle phare employé pour des tâches grossières. Au début, par souci de simplicité, toutes les requêtes passaient par le modèle phare. Or dans le scénario du service client, plus de 70 % des cas sont de la reconnaissance d'intention et des réponses à scripts fixes du type « où en est ma commande », « comment retourner un article » ; pour ces tâches, un petit modèle suffit amplement, avec un coût d'un ordre de grandeur inférieur. Faire répondre au modèle phare « à quelle heure ouvrez-vous », c'est comme utiliser un camion pour livrer un repas.
Deuxièmement, l'expansion incontrôlée du contexte. Dans les conversations multi-tours, nous réinjections l'intégralité de l'historique des messages ; lorsque l'utilisateur arrivait au dixième tour, l'historique à lui seul occupait la majorité des tokens. Plus embêtant encore, une grande partie de cet historique n'avait aucun rapport avec la question en cours et ne servait qu'à accompagner. Le contexte n'est pas plus intelligent parce qu'il est plus long : au-delà d'une certaine longueur, le gain de précision est limité, alors que le coût, lui, augmente linéairement.
Troisièmement, la tempête de réessais. Nous avions mis en place un simple réessai en cas d'échec, mais sans backoff ni disjoncteur. Lorsqu'un timeout sporadique survenait en amont, le même lot de requêtes était renvoyé en boucle : un échec, un réessai, le réessai échoue, nouveau réessai. Ces appels sur la facture étaient entièrement dépensés pour rien, et côté utilisateur, c'était toujours une erreur qui s'affichait.
Quatrièmement, la double facturation entre streaming et non-streaming. C'est le plus facile à négliger. Certaines de nos chaînes appelaient en non-streaming pour obtenir le résultat complet et le post-traiter ; le front-end, lui, voulait un effet machine à écrire et rappelait en streaming. Pour une même question, deux facturations. Par la suite, nous avons unifié le tout en réception streaming avec assemblage local, et ce coût redondant a disparu.
Comment mettre en place le routage par niveaux
L'idée n'est pas compliquée : répartir selon la difficulté de la tâche. La reconnaissance d'intention, l'extraction de slots, les scripts fixes passent par un modèle léger ; seules les conversations complexes nécessitant réellement du raisonnement, des jugements multi-étapes et de l'apaisement émotionnel sont confiées au modèle phare. On ajoute au milieu une couche de passerelle de modèles qui effectue le jugement : la requête entre, passe d'abord par un classifieur, reçoit une étiquette de tâche, puis on décide vers quel modèle la router.
Nous utilisons cette logique de sélection automatique du modèle optimal selon la tâche ; après une série de comparaisons sur le routage multi-modèles de SiCore TokenWorks, une fois les tâches simples basculées vers un modèle léger, le coût global a nettement baissé et la réponse est devenue plus rapide. La clé ici n'est pas « quel modèle utiliser », mais que la table de correspondance « quelle tâche avec quel modèle » soit ajustée en continu. Au début, nous la configurions à l'expérience ; après deux semaines d'exploitation, nous l'avons recalibrée selon le taux de correspondance réel, et le résultat a été bien meilleur qu'une configuration à l'instinct. L'avantage de l'accès unifié multi-modèles se manifeste aussi à ce moment-là : changer de stratégie de routage ne nécessite pas de modifier le code métier, il suffit d'ajuster la couche passerelle.
Comparaison de la facture avant et après optimisation
Pas de chiffres précis, mais des proportions. Le volume total d'appels n'a pas changé, car le nombre d'utilisateurs n'a pas changé. Le coût total a baissé d'environ 60 %, dont la part d'appels au modèle phare est passée de près de 100 % à environ 30 %, le reste étant redirigé vers des modèles légers. Les appels liés aux réessais sont passés de près de 20 % à un pourcentage à un chiffre. Le nombre moyen de tokens par requête a diminué d'environ 40 %, principalement grâce au rognage du contexte. La double facturation en streaming est tombée à zéro. Au total, nous sommes revenus d'un dépassement de trois fois le budget à une situation dans le budget, avec même une marge.
Comment configurer la surveillance et les alertes
L'argent économisé doit être préservé par la surveillance, pas par la discipline personnelle. Nous avons configuré quatre alertes : déclenchement lorsque le nombre de tokens par requête dépasse un seuil, pour éviter l'emballement du contexte ; déclenchement lorsque le taux de réessai dépasse une proportion définie, pour éviter la tempête de réessais ; déclenchement lorsque la part d'appels au modèle phare augmente anormalement, signe possible d'une défaillance du routage ; déclenchement lorsque la hausse du coût journalier en glissement dépasse un seuil. Ces quatre alertes n'ont pas besoin d'être très complexes : une agrégation journalière et une alerte au dépassement de seuil suffisent. En mode de facturation au Token, le coût s'accumule en temps réel ; attendre la fin du mois pour regarder la facture et optimiser, c'est de l'argent déjà dépensé.
En une phrase : le gros du coût d'un chatbot de service client réside dans la structure des appels, pas dans le prix unitaire du modèle. Si vous faites solidement ces quatre choses — routage par niveaux, rognage du contexte, maîtrise des réessais, unification du streaming —, la facture baisse naturellement. Pour aller plus loin, si votre scénario comporte aussi de la recherche RAG, le nombre de documents rappelés par la base vectorielle mérite également d'être vérifié selon cette même logique.