Compression de jetons pour les LLMs : Réduire le coût du contexte avant le routage

Compression de jetons pour les LLMs est la pratique de réduire les invites, le contexte récupéré, les sorties d'outils, l'historique des discussions et les journaux avant qu'ils n'atteignent un modèle. Cela ne remplace pas le routage, l'évaluation ou le basculement. Cela permet à ces systèmes de fonctionner avec des entrées plus propres.
Cela est important car la plupart des problèmes de coût et de latence de l'IA commencent avant que la requête ne quitte votre application. Un bot de support peut envoyer tout un fil de discussion alors que seuls trois faits sont importants. Un agent peut coller une réponse complète d'outil alors qu'il ne lui faut qu'un statut, un montant et une action suivante. Un flux de travail RAG peut récupérer cinq morceaux alors qu'une réponse compacte suffirait.
OpenAI explique que l'utilisation de l'API est mesurée en jetons, et ces jetons proviennent à la fois du texte d'entrée et de sortie. Un contexte long n'est pas un contexte gratuit. L'objectif n'est pas d'affamer le modèle. L'objectif est d'envoyer le plus petit contexte qui préserve néanmoins la décision, les preuves et les contraintes dont le modèle a besoin.
Pourquoi la compression des jetons est importante avant le routage
De nombreuses équipes considèrent l'optimisation des coûts comme un problème de sélection de modèle : envoyer les tâches simples à un modèle moins cher, réserver les modèles premium pour les tâches plus complexes, et utiliser le basculement lorsqu'une route de fournisseur se dégrade. Cela est utile, mais cela manque un point fondamental : le routeur ne voit que la requête que vous lui donnez.
Si la requête est gonflée, chaque décision en aval devient plus difficile. Un modèle bon marché peut échouer parce qu'il reçoit trop de bruit. Un modèle de pointe peut sembler nécessaire parce que l'invite est encombrée. L'observabilité peut montrer des dépenses élevées, mais pas le contexte évitable qui les a causées.
La compression ajoute une étape avant l'accès au modèle : réduire la charge utile, préserver l'intention, puis router. Avec le marché des modèles de ShareAI, cette requête plus propre peut ensuite être évaluée en fonction du choix du modèle, du prix, de la latence, de la disponibilité et des besoins de routage sur une API.
Que faut-il compresser ?
Tous les jetons ne méritent pas le même traitement. Certains textes sont essentiels pour les instructions. Certains textes sont des preuves. Certains textes ne sont que des résidus des étapes précédentes.
| Zone d'entrée | Approche de compression | Ce qu'il faut préserver |
|---|---|---|
| Historique de chat | Résumer les tours précédents en état, décisions, contraintes et questions ouvertes. | Intention de l'utilisateur, engagements, noms, préférences et tâches non résolues. |
| Fragments RAG | Récupérer de manière ciblée, dédupliquer et extraire les passages qui répondent à la question actuelle. | Citations, faits exacts, preuves contradictoires et signaux de fraîcheur. |
| Résultats des outils | Convertir les réponses détaillées en champs structurés compacts. | Statut, identifiants, montants, erreurs, horodatages et prochaines actions. |
| Journaux et traces | Regrouper les événements répétés et conserver uniquement l'anomalie, le compte et l'échantillon pertinent. | Modèle d'erreur, fréquence, service affecté et chronologie. |
| Instructions du système | Supprimer le texte de politique en double et séparer les instructions stables du contexte spécifique à la tâche. | Règles de sécurité, contrat de sortie, contraintes de rôle et permissions des outils. |
Cinq méthodes pratiques de compression
1. Résumer l'état, pas le texte
Un résumé faible réécrit une longue conversation en un paragraphe plus court. Un résumé utile conserve l'état opérationnel : ce que l'utilisateur veut, ce qui a déjà été essayé, ce qui a échoué, quelles contraintes restent, et quelle est la prochaine décision.
Pour les agents, les résumés d'état doivent être actualisés à des limites connues : après un appel d'outil, après une décision utilisateur, après une étape de workflow, ou avant de changer de modèle. Ne compressez pas les identifiants, les exigences ou les contraintes négatives.
2. Extraire les champs des résultats d'outils
De nombreux appels d'outils renvoient beaucoup plus de texte que ce dont l'étape suivante du modèle a besoin. Au lieu de transmettre toute la réponse, extrayez les champs importants. Une recherche de paiement pourrait devenir ID client, statut de facture, solde, date d'échéance, et indicateurs de risque. Un résultat de recherche pourrait devenir titre, URL canonique, date, et la phrase qui soutient l'affirmation.
3. Filtrer la récupération avant la génération
Les systèmes RAG gaspillent souvent des jetons en envoyant des morceaux similaires, des morceaux anciens, ou des morceaux qui correspondent à des mots-clés mais pas à l'intention. Une couche de compression peut dédupliquer les passages qui se chevauchent, supprimer le contexte obsolète, et conserver uniquement les preuves qui répondent à la requête actuelle.
Cela est particulièrement important lorsque la réponse finale nécessite des citations. Compressez le contexte, mais préservez suffisamment de détails de source pour vérifier la réponse ultérieurement.
4. Utiliser des sorties intermédiaires structurées
Le texte intermédiaire libre croît rapidement. Les sorties structurées restent plus petites et plus faciles à auditer. Au lieu de demander à un modèle d'expliquer chaque action candidate, demandez-lui de retourner une liste compacte d'options avec des champs tels que action, confiance, raison, problème bloquant, et entrée requise.
5. Considérer la mise en cache des invites comme un levier distinct
La mise en cache des invites peut réduire le coût ou la latence des préfixes répétés dans les systèmes pris en charge, mais ce n'est pas la même chose que la compression de jetons. Le texte mis en cache peut toujours consommer de l'espace dans la fenêtre de contexte, et il peut toujours rendre les requêtes plus difficiles à inspecter. Anthropic’s fenêtre de contexte et mise en cache des invites La documentation est un rappel utile que la mise en cache et la conception du contexte résolvent des problèmes liés mais différents.
Où la compression s'intègre dans un flux de travail ShareAI
ShareAI est un marché et une API d'IA, pas un endroit où vous construisez l'application elle-même. Votre application gère l'expérience utilisateur, la logique du flux de travail, la sélection du contexte et l'étape de compression. ShareAI aide sur le côté accès au modèle : une API pour plus de 150 modèles, visibilité sur le marché, routage, basculement et suivi de l'utilisation.
- Collectez la demande brute de l'utilisateur et le contexte de l'application.
- Supprimez les doublons, les contextes obsolètes et les résultats de recherche non pertinents.
- Compressez l'état des conversations anciennes et les sorties détaillées des outils.
- Envoyez la demande nettoyée via le API ShareAI.
- Routez en fonction de l'adéquation du modèle, du prix, de la latence, de la disponibilité et des besoins de secours.
- Mesurez la qualité, le coût et les schémas d'échec après la réponse.
Pour les créateurs, la compression peut également rendre la monétisation plus claire. Si une application existante route le trafic d'inférence IA via ShareAI, le créateur peut configurer une surcharge ou une marge et recevoir des paiements mensuels basés sur l'utilisation générée. Un contexte plus clair aide à expliquer plus facilement cette utilisation routée aux clients, car les utilisateurs intensifs paient pour le trafic IA qu'ils génèrent réellement.
Comment mesurer si la compression fonctionne
La compression n'est utile que si la qualité est maintenue. Suivez-la comme un changement de production, pas comme une astuce de prompt ingénieuse.
- Jetons d'entrée par demande : devraient diminuer pour les flux de travail ciblés.
- Qualité de sortie : devrait rester stable sur des tâches représentatives.
- Taux de repli : ne devrait pas augmenter parce que des routes moins chères reçoivent un contexte plus faible.
- Latence : devrait s'améliorer, ou au moins justifier toute étape de prétraitement.
- Taux d'escalade : devrait révéler quand un contexte compressé force les utilisateurs ou les agents à demander à nouveau.
- Coût par tâche réussie : devrait diminuer, pas seulement le coût par requête.
Un bon ensemble de tests inclut des invites courtes, des invites longues, des tâches d'agent nécessitant beaucoup d'outils, des questions RAG et des cas limites où un contexte manquant entraînerait une mauvaise réponse. Comparez les exécutions compressées et non compressées avant de faire de la compression le paramètre par défaut.
Quand ne pas compresser de manière agressive
La compression a des compromis. Elle peut supprimer des nuances, cacher des incertitudes ou aplatir des preuves dont le modèle a besoin. Utilisez une compression légère lorsque le libellé exact est important, lorsque le modèle doit raisonner sur des contrats ou des politiques, lorsque les citations doivent être préservées ou lorsque l'utilisateur demande explicitement un matériel source exhaustif.
Le modèle le plus sûr est la compression progressive. Gardez le matériel source haute fidélité disponible dans votre application, passez un contexte compact au modèle et récupérez à nouveau les preuves originales lorsque la tâche nécessite une vérification.
FAQ : Compression de tokens pour les LLMs
Qu'est-ce que la compression de tokens pour les LLMs ?
La compression de tokens pour les LLMs signifie réduire le texte d'entrée inutile avant un appel au modèle tout en préservant les faits, les instructions et les contraintes nécessaires pour une bonne réponse.
La compression des tokens est-elle la même chose que l'utilisation d'un modèle plus petit ?
Non. La compression réduit la requête. La sélection du modèle détermine où cette requête est envoyée. La configuration la plus efficace fait souvent les deux : compresser le contexte d'abord, puis diriger vers le bon modèle.
ShareAI compresse-t-il automatiquement les invites ?
La compression est généralement un choix de conception côté application. ShareAI fournit le marché de l'IA et la couche API pour l'accès aux modèles, le routage, la reprise après échec et la visibilité de l'utilisation après que votre application a préparé la requête.
Comment la compression aide-t-elle à réduire les coûts des LLM ?
La plupart des API d'IA facturent l'utilisation en fonction des tokens d'entrée et de sortie. Si vous réduisez en toute sécurité les tokens d'entrée tout en maintenant une qualité stable, le coût par tâche réussie peut diminuer.
La compression des tokens peut-elle nuire à la qualité des réponses ?
Oui. Une compression excessive peut supprimer des preuves, des nuances ou des contraintes. Testez les invites compressées sur des tâches réelles et surveillez la qualité des réponses, le taux de reprise et les corrections des utilisateurs.
Que doivent savoir les développeurs sur la compression ?
Les développeurs qui routent l'utilisation de l'IA depuis une application existante via ShareAI peuvent utiliser la compression pour maintenir un trafic routé plus propre. Ils peuvent toujours appliquer une surcharge ou une marge et recevoir des paiements mensuels provenant de l'utilisation générée.
La compression des tokens est-elle utile pour les systèmes RAG ?
Oui. Les systèmes RAG envoient souvent des morceaux redondants ou faiblement pertinents. La compression peut dédupliquer, filtrer et extraire les passages qui répondent à la question actuelle.
La mise en cache des invites est-elle un remplacement de la compression ?
Non. La mise en cache des invites peut aider avec les préfixes répétés dans les systèmes pris en charge, mais la compression reste importante lorsque le contexte est bruyant, obsolète, dupliqué ou trop volumineux pour la tâche.
Quelles équipes bénéficient le plus de la compression des tokens ?
Les équipes avec un historique de chat long, des agents utilisant de nombreux outils, des flux de travail documentaires, l'automatisation du support, des assistants de recherche et des systèmes RAG voient généralement le besoin le plus clair de compression.
Comment devrais-je commencer à tester la compression ?
Choisissez un flux de travail coûteux, capturez des requêtes représentatives, créez des versions compressées, et comparez l'utilisation des tokens, la qualité des réponses, la latence et le coût par tâche réussie.
Comment la compression fonctionne-t-elle avec le routage IA ?
La compression prépare une requête plus propre. Le routage décide du meilleur modèle ou itinéraire fournisseur pour cette requête en fonction du prix, de la latence, de la disponibilité, de la fiabilité et des besoins en qualité.
Prochaine étape
Commencez par un flux de travail où l'encombrement du contexte est visible. Compressez les parties bruyantes, conservez les preuves importantes, puis utilisez ShareAI pour comparer les itinéraires des modèles via une API. L'objectif pratique est simple : moins de tokens gaspillés, moins d'escalades évitables et des données d'utilisation plus claires.