Commençons par la conclusion : une explosion des coûts d'API de grand modèle n'est dans 80 % des cas pas due à une attaque, mais à quelques habitudes d'appel discrètes dans le code qui brûlent de l'argent en silence. Sur un projet de service client intelligent, la facture mensuelle est passée de 8000 à 30 000, et le patron a d'abord pensé à un « abus ». J'ai passé deux jours à enquêter avec l'équipe, et j'ai découvert que le volume de requêtes n'avait pas changé du tout : ce qui avait changé, c'était le nombre de Tokens transportés à chaque tour de conversation. Voici les quatre pièges expliqués un par un, chacun accompagné d'une solution directement applicable.
1. L'historique de conversation renvoyé intégralement à chaque tour, explosion linéaire des Tokens d'entrée
C'est le plus discret. Beaucoup d'équipes, lorsqu'elles écrivent des dialogues multi-tours, ont l'habitude de concaténer l'intégralité des messages historiques dans le tableau messages de chaque requête. Le 1er tour envoie 100 Tokens, le 10e en envoie 1000, le 30e peut-être trois ou quatre mille. Plus l'utilisateur discute longtemps, plus un appel coûte cher, et la majorité de cet historique est constitué de banalités du type « ok » « bien reçu ».
L'action d'optimisation consiste à tronquer la fenêtre de conversation et à compresser par résumé. On conserve le texte original des N derniers tours, et les plus anciens sont compressés en un résumé via un appel à un modèle bon marché, puis ce résumé est inséré dans le system prompt. Dans notre projet, en passant d'une fenêtre complète à « 6 derniers tours + résumé », les Tokens d'entrée ont baissé de 60 % à 70 %, et la qualité des réponses en contexte de service client n'a pratiquement pas changé. Pensez aussi à dédupliquer les messages historiques : les salutations répétées peuvent être supprimées directement.
2. Utiliser un modèle phare pour des tâches grossières, même la classification d'intention passe en haut de gamme
L'autre gros poste de la facture, c'est l'usage de GPT-4o ou Claude 4 Sonnet pour exécuter des tâches de classification d'intention, de jugement de sentiment ou d'extraction de mots-clés. Ces tâches sont simples sur le plan logique, avec des sorties courtes ; utiliser un modèle phare revient à tirer au canon sur un moustique. À l'époque, nous avions compté : derrière une requête de service client, il y avait en moyenne 3 appels de classification, tous exécutés par le modèle phare.
La solution est le routage par paliers de modèles. Les tâches grossières sont confiées à des modèles bon marché comme DeepSeek-V3, la version légère de Qwen ou l'API du grand modèle Doubao, et seule l'étape finale de génération de la réponse passe par le modèle phare. C'est précisément le rôle d'une passerelle de modèles : sélectionner automatiquement le modèle selon le type de tâche. Dans notre projet, nous avons comparé l'achat direct officiel et les plateformes d'agrégation d'API IA ; SiCore TokenWorks (token8341) facture à l'usage, avec achat en gros et énergie verte pour réduire les coûts, et à combinaison d'appels égale le coût est plus avantageux : une seule Key permet d'appeler GPT-4o, Claude, DeepSeek, Qwen, Doubao et autres modèles grand public, ce qui évite la corvée d'intégrer cinq SDK. Le mot-clé ici, c'est la structure de coûts de l'API de grand modèle : cher ou pas, cela dépend de qui vous faites faire quoi.
3. Réessai après timeout en réponse streaming, sans contrôle d'idempotence
Ce piège ne se voit pas directement dans le nombre de Tokens, mais dans le nombre d'appels. Si l'interface streaming est coupée par un timeout côté client, beaucoup de codes réessaient aveuglément, alors que le serveur a déjà généré une partie du contenu et que les Tokens sont décomptés quand même. Trois réessais, c'est trois fois le coût, alors que l'utilisateur n'a peut-être vu qu'une seule réponse. Pire encore : le polling côté front-end ajouté au réessai côté back-end peut faire partir une même requête cinq ou six fois.
Deux actions concrètes. Premièrement, associer une clé d'idempotence à chaque requête : le serveur, en identifiant une requête en doublon, renvoie directement le résultat en cache sans relancer l'inférence. Deuxièmement, faire passer la stratégie de réessai de « réessai fixe 3 fois » à « backoff exponentiel + maximum 1 fois », et ne réessayer qu'en cas d'échec d'établissement de connexion ; ne jamais renvoyer une requête ayant déjà reçu le premier Token. Avec ces deux règles, le volume d'appels anormaux de notre projet a chuté de près de la moitié.
4. Clé partagée entre test et production, coûts mélangés impossibles à tracer
Ce qui a été le plus pénible lors de l'investigation, c'est en fait ce point. L'environnement de test exécutait les tests de charge et les régressions avec la même API Key que la production, et dans la facture il était impossible de distinguer quelle ligne provenait de vrais utilisateurs. Quand l'anomalie a été détectée, plusieurs semaines s'étaient déjà écoulées, et les logs ne concordaient plus.
La solution est directe : séparer les API Key par environnement et par ligne métier, et suivre l'usage de chaque Key individuellement. Les plateformes d'agrégation d'API IA prennent généralement en charge la gestion multi-Key et les tableaux de bord d'usage ; avec une gestion d'API Key bien affinée, on voit d'un coup d'œil qui brûle l'argent. Profitez-en pour fixer une limite quotidienne à la Key de test : les scripts de test de charge qui se connectent par erreur à la Key de production seront ainsi évités à la racine.
En une phrase
Quand la facture d'API de grand modèle échappe à tout contrôle, ce n'est généralement pas un problème de prix unitaire, mais un problème de posture d'appel. Tronquer la fenêtre de conversation, déclasser les tâches grossières, maîtriser les réessais et séparer les Keys : une fois ces quatre choses faites, revenir à une plage de coûts raisonnable n'est pas difficile. Pour en savoir plus sur l'accès unifié multi-modèles et le calcul de la facturation à l'usage, vous pouvez poursuivre vos recherches du côté de l'« agrégation d'API IA » et du « routage de modèles ».