Optimisation des coûts des agents IA : utilisation des jetons et mise en cache

Les coûts opérationnels des agents IA peuvent passer de gérables à alarmants étonnamment rapidement. Un agent traitant 10 transactions par jour est peu coûteux. Le même agent traitant 5 000 transactions par jour, chaque transaction nécessitant 3 à 4 appels LLM avec de grandes fenêtres contextuelles, peut générer des milliers de dollars en coûts mensuels d'API, des coûts qui ne figuraient pas dans le modèle de retour sur investissement d'origine.

L'optimisation des coûts n'est pas facultative pour les déploiements d'IA à l'échelle de la production. C'est la différence entre un agent qui offre un retour sur investissement positif et un autre qui l'érode. Ce guide couvre les stratégies pratiques qui réduisent les coûts de 40 à 70 % dans les déploiements OpenClaw typiques sans compromettre la qualité des résultats.

Points clés à retenir

• L'optimisation des jetons (compression rapide, élagage du contexte) réduit les coûts d'API de 25 à 40 % sans perte de qualité
• La mise en cache sémantique élimine les appels LLM pour des requêtes répétées ou similaires, réduisant ainsi les coûts de 30 à 60 % dans de nombreuses charges de travail
• Le routage de modèles utilise des modèles bon marché pour des tâches simples et des modèles coûteux uniquement en cas de besoin
• La mise en cache des invites (si disponible auprès des fournisseurs) réduit les coûts des jetons d'entrée pour les invites système répétitives
• Le traitement par lots réduit les frais généraux par appel pour les charges de travail volumineuses et non urgentes
• La surveillance des coûts avec attribution par workflow identifie les comportements d'agent les plus coûteux
• Le streaming réduit le temps de latence avant l'obtention du premier jeton pour les agents orientés utilisateur sans augmenter le coût total
• Une stratégie complète d'optimisation des coûts réduit généralement les dépenses LLM totales de 45 à 65 % par rapport aux déploiements non optimisés.

---

Comprendre les facteurs de coûts des agents IA

Avant d’optimiser les coûts, comprenez ce qui les motive. Les coûts de l'API LLM sont principalement basés sur la consommation de jetons :

Jetons d'entrée : Chaque jeton envoyé au modèle coûte de l'argent : l'invite système, le message utilisateur, le contexte récupéré (morceaux RAG), l'historique des conversations et tous les exemples (quelques plans). Les coûts des jetons d’entrée sont généralement 2 à 5 fois inférieurs aux coûts des jetons de sortie pour les modèles frontières actuels.

Jetons de sortie : jetons générés par le modèle dans sa réponse. Les sorties verbeuses coûtent plus cher. Les étapes de raisonnement (chaîne de pensée) coûtent plus cher que les réponses directes. Les sorties JSON structurées coûtent plus cher que la prose si le JSON comporte de nombreux champs.

Volume d'appels : Chaque appel LLM a un coût minimum. Les agents en plusieurs étapes qui effectuent 5 appels LLM par tâche coûtent 5 fois plus cher que les agents à appel unique, mais peuvent produire de bien meilleurs résultats. La clé est d’éliminer les appels inutiles.

Sélection du modèle : La différence de coût entre les modèles est énorme. Claude 3 Haiku coûte environ 50 fois moins cher que Claude 3 Opus par jeton. GPT-4o coûte environ 15 fois plus que GPT-4o mini. L’utilisation d’un modèle frontière pour chaque tâche constitue la source la plus courante de coûts inutiles.

Un scénario de coûts réaliste :

L'agent traite 1 000 tickets de service client par jour. Chaque billet nécessite :

• Invite système : 800 jetons
• Contexte récupéré : 1 200 tokens
• Contenu du ticket : 400 jetons
• Entrée totale : 2 400 jetons
• Réponse : 600 jetons

Utilisation de Claude 3.5 Sonnet (entrée 3 $/M, sortie 15 $/M) :

• Coût quotidien : 1 000 × [(2 400 × 3 $/M) + (600 × 15 $/M)] = 16,20 $/jour = 486 $/mois

Avec l'optimisation (montrée dans ce guide), cela tombe à 150 - 200 $/mois, soit une réduction de 60 %.

---

Compression rapide et réduction des jetons

Optimisation des invites système

Des invites système sont envoyées à chaque demande. Une invite système gonflée de 2 000 jetons qui pourrait être compressée à 800 jetons sans perte d'informations coûte 2,5 fois plus que nécessaire en jetons d'entrée.

Techniques :

Supprimez la redondance : Consultez les invites de votre système pour rechercher des informations reformulées à plusieurs endroits. Consolider.

Utilisez un langage compressé : Évitez les préambules conversationnels. Comparez :

Verbeux (47 jetons) : "Vous êtes un assistant utile et compétent dans la révision des contrats. Votre travail consiste à lire attentivement le contrat et à identifier toutes les clauses qui pourraient représenter un risque pour notre entreprise."

Compressé (23 jetons) : "Vous êtes un analyste des risques contractuels. Identifiez les clauses représentant des risques pour l'entreprise cliente."

La version compressée transmet des instructions identiques. Les LLM répondent au contenu sémantique, pas au nombre de mots.

Utilisez un formatage structuré : Les listes numérotées et les puces transmettent des informations de manière plus dense que les paragraphes.

Supprimez les exemples de l'invite système lors de l'utilisation de quelques-uns : Si vous avez des exemples à la fois dans l'invite système et dans le message utilisateur, vous les payez deux fois. Consolider en un seul emplacement.

Auditez régulièrement la longueur des invites du système : Les invites du système ont tendance à augmenter à mesure que les équipes ajoutent des instructions au fil du temps sans supprimer celles qui sont obsolètes. Un examen trimestriel révèle généralement que 20 à 30 % du contenu des invites du système peut être supprimé ou compressé.

Gestion des fenêtres contextuelles

Les récupérations RAG (Retrieval Augmented Generation) sont l'un des principaux facteurs de coûts pour les agents à forte intensité de connaissances. Chaque morceau récupéré est un jeton d'entrée. Un RAG non optimisé récupère fréquemment plus de contexte que nécessaire.

Optimisation de la taille des fragments : Les fragments plus petits (256 à 512 jetons) récupérés en quantités plus élevées surpassent souvent les gros fragments (plus de 1 000 jetons) pour répondre aux questions factuelles. Les morceaux plus petits sont également moins chers car les passages non pertinents au sein d'un gros morceau ne sont pas récupérés.

Ajustement du nombre de récupérations : Si votre agent récupère 10 fragments par requête mais utilise systématiquement les informations des 2 ou 3 premiers fragments, réduisez le nombre de récupérations. Surveillez quels fragments récupérés sont réellement référencés dans les sorties de l'agent.

** Filtrage par pertinence :** appliquez un seuil de score de pertinence : n'incluez que les éléments récupérés au-dessus du seuil dans le contexte. Les morceaux peu pertinents augmentent le coût sans améliorer la qualité.

Élagage de l'historique des conversations : Pour les agents multi-tours, l'historique des conversations s'agrandit à chaque tour. Les virages plus anciens sont souvent moins pertinents. Mettez en œuvre une stratégie de résumé : après 8 à 10 tours, résumez les premières conversations dans un résumé compressé (200 à 300 jetons) plutôt que de conserver l'historique complet, tour par tour.

def manage_conversation_history(messages: list, max_tokens: int = 2000) -> list:
    """Prune conversation history to stay within token budget"""
    # Always keep system message and last N user/assistant turns
    if count_tokens(messages) <= max_tokens:
        return messages

    # Summarize early conversation if too long
    early_messages = messages[1:-6]  # Exclude system + recent 3 turns
    summary = summarize_conversation(early_messages)

    return [
        messages[0],  # System message
        {"role": "user", "content": f"[Earlier conversation summary: {summary}]"},
        *messages[-6:]  # Recent 3 turns
    ]

---

Mise en cache sémantique

La mise en cache sémantique constitue l’optimisation des coûts ayant le plus grand impact pour les agents traitant des requêtes répétitives. Il stocke le résultat des appels LLM et renvoie les résultats mis en cache pour les requêtes ultérieures qui sont sémantiquement similaires, même s'ils ne sont pas identiques.

Comment fonctionne la mise en cache sémantique

1. Lorsqu'un appel LLM est effectué, calculez un vecteur d'intégration pour l'entrée (invite + contexte)
2. Recherchez dans le cache les résultats stockés avec une similarité vectorielle élevée avec l'entrée actuelle
3. Si la similarité dépasse le seuil, renvoie le résultat mis en cache (pas d'appel LLM)
4. Sinon, effectuez l'appel LLM et stockez le résultat avec son intégration

L’idée critique : de nombreuses requêtes du monde réel sont sémantiquement similaires même si elles ne sont pas textuellement identiques. « Quelle est la politique de retour pour les commandes passées au cours des 30 derniers jours ? et "Puis-je retourner quelque chose que j'ai commandé il y a 3 semaines ?" sont des mots différents mais la même question : la mise en cache sémantique peut servir le second à partir du cache du premier.

Taux de réussite du cache par type d'agent

Pour les agents du support client avec un taux de réussite du cache de 65 %, la mise en cache sémantique réduit le volume d'appels LLM (et donc le coût LLM) de 65 %.

Configuration du cache

Seuil de similarité : Seuil de déclaration de deux requêtes « suffisamment similaires » pour la réutilisation du cache. Seuil plus élevé = moins d'accès au cache mais une précision plus élevée. Seuil inférieur = plus d'accès au cache mais risque de renvoyer des réponses subtilement fausses pour des requêtes différentes.

Pour les requêtes factuelles, un seuil de similarité de 0,92 à 0,95 est généralement sûr. Pour les tâches d'analyse ou de raisonnement, utilisez un seuil plus élevé (0,97+) pour éviter de renvoyer une analyse incorrecte pour des questions subtilement différentes.

** TTL du cache : ** Les différents types d'entrées de cache doivent avoir des périodes d'expiration différentes :

• Tarification du produit : 1 à 4 heures (les prix changent)
• Informations sur les politiques : 24 à 48 heures (les politiques changent rarement)
• Connaissances générales : 7 jours (informations très stables)
• Rapports générés : mise en cache jusqu'à ce que les données sous-jacentes changent (invalidation déclenchée par un événement)

Étendue du cache : Configurez si le cache est par utilisateur, par organisation ou global. Les agents du support client doivent disposer de caches à l’échelle de l’organisation (une réponse appropriée pour votre organisation peut ne pas convenir à une autre). Les agents de connaissances générales peuvent partager un cache global.

---

Routage de modèles et sélection LLM à plusieurs niveaux

Toutes les tâches ne nécessitent pas un modèle frontière. Utiliser GPT-4o ou Claude 3.5 Sonnet pour une tâche de classification simple que GPT-4o mini gère correctement coûte 15 à 50 fois plus que nécessaire.

Stratégie de routage

Classification de la complexité des tâches : Implémentez un classificateur léger qui classe chaque requête entrante par complexité :

• Simple : Recherche, classification avec peu de catégories, génération courte avec modèle clair
• Modéré : Raisonnement en plusieurs étapes, extraction de documents complexes, logique conditionnelle
• Complexe : Analyse ouverte, synthèse créative, jugement nuancé

Affectation du modèle :

• Simple → GPT-4o mini, Claude 3 Haiku (coût : ~0,15-0,30$/M de jetons)
• Modéré → Claude 3.5 Sonnet, GPT-4o (coût : ~3-5$/M de jetons)
• Complexe → Claude 3.5 Sonnet, GPT-4o (ou o1 pour les tâches de raisonnement profond) (coût : 5-15$/M de jetons)

Routage de secours : Si le modèle le moins cher produit une sortie inférieure au seuil de qualité (détecté par évaluation automatisée), réessayez avec le modèle le plus cher. Cette approche « en cascade » utilise des modèles bon marché avec optimisme et ne s'intensifie qu'en cas de besoin.

def route_to_model(task: AgentTask) -> str:
    complexity = classify_task_complexity(task)

    model_map = {
        "simple": "claude-haiku-3",
        "moderate": "claude-3-5-sonnet",
        "complex": "claude-3-5-sonnet"
    }
    return model_map[complexity]

def execute_with_fallback(task: AgentTask):
    primary_model = route_to_model(task)
    result = execute_with_model(task, primary_model)

    if not meets_quality_threshold(result):
        # Escalate to more capable model
        result = execute_with_model(task, "claude-3-5-sonnet")

    return result

Économies réalistes grâce au routage des modèles : Dans une flotte d'agents à charge de travail mixte, 60 à 70 % des tâches sont généralement qualifiées de « simples ». Les acheminer vers des modèles bon marché permet d'obtenir une réduction des coûts de 50 à 70 % sur ce segment, ce qui se traduit par une réduction globale des coûts de 30 à 50 %.

---

Mise en cache des invites (au niveau du fournisseur)

Anthropic et OpenAI offrent des fonctionnalités de mise en cache des invites qui réduisent le coût des invites système répétées. Lorsque l'invite système (ou tout préfixe de l'invite) est identique sur plusieurs requêtes, les jetons mis en cache coûtent nettement moins cher que les nouveaux jetons.

Tarif du cache anthropique : Les jetons d'entrée mis en cache coûtent environ 10 % du prix du jeton d'entrée standard (0,30 $/M contre 3 $/M pour Sonnet). Le coût d'écriture du cache est de 3,75 $/M (écrit une fois, puis lu à 0,30 $/M).

Stratégie efficace : La structure invite de sorte que la partie stable (invite système, exemples, instructions) vienne en premier et la partie variable (saisie utilisateur, contexte récupéré) vienne en dernier. Le fournisseur met automatiquement en cache le préfixe stable.

Calcul du seuil de rentabilité : L'écriture du cache coûte 1,25 fois le prix du jeton d'entrée standard ; la lecture du cache coûte 0,1x. Le seuil de rentabilité est à 2 requêtes partageant le préfixe. Chaque requête au-delà de la seconde est 90 % moins chère pour la partie mise en cache.

Pour un agent doté d'une invite système de 1 000 jetons exécutant 1 000 requêtes par jour :

• Sans mise en cache : 1 000 × 1 000 jetons × 3 $/M = coût d'entrée de 3 $/jour pour l'invite système seule
• Avec mise en cache : 3,75 $ (une écriture) + 999 × 1 000 × 0,30 $/M = 0,30 $/jour
• Économies quotidiennes : 2,70$ (90% de réduction sur ce volet)

---

Traitement par lots

Pour les charges de travail non urgentes (génération de rapports de nuit, traitement de documents par lots, analyse de données planifiée), les appels d'API par lots offrent des réductions de coûts significatives.

API OpenAI Batch : 50 % de réduction des coûts pour les demandes soumises par lots avec des fenêtres d'exécution de 24 heures. Pour la génération de rapports du jour au lendemain, cela réduit de moitié le coût de l'API LLM.

Lots de messages anthropiques : Tarification par lots similaire pour les charges de travail non urgentes.

Modèles de planification par lots :

• Collecter les demandes de génération de rapports tout au long de la journée, les soumettre par lots en fin d'activité
• Traiter l'ingestion de documents pour RAG pendant les heures creuses sous forme de tâches par lots
• Exécutez des analyses de surveillance de la conformité tous les soirs par lots

---

Surveillance et attribution des coûts

L'optimisation nécessite de savoir d'où viennent les coûts. Mettre en place un suivi des coûts dès le premier jour de production :

Suivi des coûts par workflow : Marquez chaque appel LLM avec le workflow auquel il appartient. Calculez le coût total par flux de travail et par jour. Cela révèle quels comportements d’agent sont les plus coûteux et priorise les efforts d’optimisation.

Attribution par jeton : Répartissez les coûts par jetons d'entrée et de sortie, par composant d'invite (invite système, contexte et entrée utilisateur) et par modèle. L'attribution des coûts à cette granularité permet une optimisation ciblée.

Détection des anomalies de coûts : Alerte lorsque les coûts quotidiens dépassent de plus de 20 % la moyenne mobile sur 7 jours. Les pics indiquent soit des augmentations de volume légitimes (attendues), soit des bugs (boucles infinies, fenêtres contextuelles incontrôlées, injection rapide provoquant des achèvements inhabituellement longs).

Coût par tâche réussie : divisez les coûts totaux par les tâches réussies pour obtenir le coût par unité de valeur. C'est la mesure qui compte pour le retour sur investissement : si le coût par tâche diminue alors que le volume et la qualité des tâches se maintiennent, l'optimisation fonctionne.

---

Questions fréquemment posées

Dans quelle mesure l'optimisation des coûts peut-elle réduire de manière réaliste les coûts de l'API LLM ?

Dans les déploiements OpenClaw typiques, un effort d'optimisation systématique portant sur la compression rapide, la mise en cache sémantique et le routage des modèles permet une réduction des coûts de 45 à 65 % par rapport aux déploiements non optimisés. Les économies spécifiques dépendent fortement des caractéristiques de la charge de travail : les agents effectuant des requêtes très répétitives bénéficient le plus de la mise en cache ; les agents avec des requêtes diverses et uniques bénéficient davantage du routage par modèle.

La mise en cache sémantique compromet-elle la précision des réponses ?

Avec une configuration de seuil appropriée, l'impact sur la précision est négligeable : généralement moins de 0,5 % de dégradation sur les tâches factuelles. La clé consiste à définir le seuil de similarité de manière appropriée pour le type de tâche. Pour les tâches où des différences subtiles dans la question conduisent à des réponses correctes différentes, utilisez des seuils de similarité plus élevés (0,96+) pour garantir que seules les requêtes véritablement équivalentes sont servies à partir du cache.

Quel est l'impact de la latence sur la mise en cache sémantique ?

Les recherches de cache (recherche de similarité vectorielle) ajoutent une latence de 5 à 15 ms. Les accès au cache éliminent la latence des appels LLM (généralement 500 ms-3 s). Résultat net : les réponses mises en cache sont 20 à 200 fois plus rapides que les réponses non mises en cache. Il s'agit d'une amélioration de la latence, pas d'une dégradation.

Comment mettre en œuvre la surveillance des coûts sans effort d'ingénierie important ?

La couche d'observabilité d'OpenClaw capture automatiquement le nombre de jetons et les sélections de modèles pour chaque exécution. ECOSIRE configure un tableau de bord des coûts lors de la mise en œuvre qui affiche les coûts par flux de travail, modèle et période de temps. Aucune ingénierie personnalisée n'est requise : l'infrastructure de surveillance fait partie de la mise en œuvre standard.

À quelle échelle les mesures d'optimisation des coûts deviennent-elles rentables ?

La plupart des mesures d'optimisation valent plus de 500 $/mois en coûts d'API LLM. En dessous de ce seuil, les efforts d’ingénierie dépassent généralement les économies réalisées. Au-dessus de 2 000 $/mois, une optimisation systématique est fortement recommandée : le retour sur investissement du temps d'ingénierie investi dans l'optimisation est très élevé à cette échelle.

Le passage à des modèles moins chers compromet-il la qualité des résultats des agents ?

Pour les tâches pour lesquelles des modèles moins chers offrent véritablement une qualité équivalente, le passage à ces modèles constitue une pure économie. Pour les tâches nécessitant un raisonnement approfondi, un jugement nuancé ou une synthèse complexe, les modèles moins chers produisent des résultats nettement moins bons. Le modèle de routage des modèles résout ce problème en utilisant des modèles moins chers uniquement là où ils sont appropriés et en les acheminant vers des modèles premium pour les tâches qui les nécessitent. La clé est la validation empirique : testez le modèle le moins cher sur votre tâche spécifique avant d'y acheminer le trafic de production.

---

Prochaines étapes

L'optimisation des coûts pour les agents IA est une discipline continue et non un projet ponctuel. Les implémentations OpenClaw d'ECOSIRE incluent une couche d'optimisation des coûts dès le premier jour : la mise en cache sémantique, le routage de modèle et l'optimisation rapide sont intégrées à l'architecture de déploiement plutôt que ajoutées après coup.

Explorez les services ECOSIRE OpenClaw pour discuter de vos besoins en matière d'optimisation des coûts, ou consultez nos options de maintenance et d'optimisation pour comprendre comment ECOSIRE gère la rentabilité continue des déploiements de production OpenClaw.