Optimisation de tokens LLM style Headroom : réduire le coût du contexte sans casser les réponses

Réponse rapide

L'optimisation des coûts LLM doit commencer par la qualité du contexte, pas par une compression aveugle. Un optimiseur style Headroom se place entre l'application et le modèle, retire le contexte de faible valeur, compresse les sorties d'outils bruyantes, réutilise les parties stables du prompt et route les tâches simples vers des modèles moins coûteux lorsque la qualité le permet.

L'objectif n'est pas "utiliser moins de tokens à tout prix". L'objectif est :

Garder une qualité de réponse stable.
Préserver les instructions critiques de sécurité.
Réduire le contexte répété, non pertinent ou généré automatiquement.
Mesurer économies et régressions avec le même jeu de tests.
Déployer progressivement avec observabilité et rollback.

Si vos prompts incluent de longs logs, payloads JSON, résultats de recherche, chunks RAG ou historiques répétés, l'optimisation de contexte mérite un test.

D'où vient le gaspillage de tokens

La plupart des requêtes LLM coûteuses ne le sont pas à cause d'une phrase utilisateur. Elles le sont parce que l'application attache trop de contexte.

Source de gaspillage	Exemple	Meilleure approche
Texte système répété	Même bloc de politique à chaque tour	Cacher ou raccourcir les instructions stables
Sortie d'outil bruyante	Logs, stack traces, HTML, dumps JSON complets	Extraire les champs pertinents avant envoi
Chunks RAG trop grands	20 passages quand 4 suffisent	Reranker et couper agressivement
Historique long	Tous les messages depuis la première session	Résumer ou fenêtrer par récence et pertinence
Mauvais routage modèle	Classification simple envoyée à un grand modèle	Router les tâches simples vers des modèles plus petits
Retries non bornés	Calls échoués renvoient tout le contexte	Budgets de retry et état intermédiaire caché

Une architecture d'optimisation plus sûre

Utilisez des couches. N'appliquez pas toutes les optimisations en même temps.

User request
  -> input normalization
  -> context selection
  -> tool/RAG output cleanup
  -> prompt assembly
  -> cache lookup
  -> model routing
  -> model call
  -> quality and cost logging

Chaque couche doit être mesurable et désactivable indépendamment.

Couche 1 : sélection du contexte

La sélection du contexte décide ce dont le modèle a réellement besoin.

Bons candidats à retirer :

Instructions dupliquées.
Anciens tours de chat devenus non pertinents.
Documents récupérés avec faible similarité ou faible score de rerank.
Champs de sortie d'outil inutiles pour la tâche.
Stack frames ou lignes de log répétées.

À ne pas retirer :

Instructions de sécurité et de permission.
Contraintes utilisateur.
Contrats d'API.
Règles métier.
Provenance des données nécessaire pour citations ou audit.

Règle d'exemple :

type ContextBlock = {
  id: string;
  source: "system" | "user" | "tool" | "rag" | "memory";
  text: string;
  score?: number;
  required?: boolean;
};

function selectContext(blocks: ContextBlock[], maxBlocks = 8) {
  const required = blocks.filter((block) => block.required);
  const optional = blocks
    .filter((block) => !block.required)
    .sort((a, b) => (b.score ?? 0) - (a.score ?? 0))
    .slice(0, maxBlocks);

  return [...required, ...optional];
}

Couche 2 : compression des sorties d'outils

Les sorties d'outils sont souvent la plus grande source de tokens évitables. Logs, JSON, HTML, lignes de base de données et sorties CLI doivent être convertis en résumés spécifiques à la tâche avant d'atteindre le modèle.

Sortie d'outil	Envoyer plutôt
Stack trace complet répété 200 fois	Erreur unique, frames clés, première/dernière occurrence
500 lignes de base de données	Agrégats, anomalies, lignes d'exemple
HTML brut	Texte extrait, liens, titres, métadonnées
Réponse JSON complète	Champs nécessaires à la tâche actuelle
Logs de tests	Tests échoués, assertions, blocs d'erreur pertinents

Exemple :

function summarizeTestOutput(output: string) {
  const failed = output
    .split("\n")
    .filter((line) => /FAIL|Error:|AssertionError/.test(line));

  return failed.slice(0, 80).join("\n");
}

C'est plus sûr qu'une compression générique, car les preuves pertinentes sont préservées.

Couche 3 : prompt caching

Beaucoup de prompts contiennent des parties stables : instructions système, règles produit, schémas, guides de style et descriptions d'outils. Séparez les blocs stables du contexte dynamique pour permettre le caching.

Assemblage recommandé :

Stable:
  - system policy
  - output schema
  - product rules
  - tool descriptions

Dynamic:
  - current user request
  - selected history
  - selected retrieved passages
  - current tool output

Même sans prompt caching côté fournisseur, un cache applicatif peut éviter de refaire retrieval, reranking et summarization coûteux.

Couche 4 : model routing

Le model routing peut réduire les coûts lorsque les tâches ont des niveaux de complexité clairs.

Type de requête	Routage typique
Classification, extraction, réécriture simple	Modèle petit/rapide
Réponse avec retrieval et contexte court	Modèle intermédiaire
Raisonnement complexe, code, revue juridique	Modèle plus fort
Action critique sécurité ou argent	Modèle plus fort plus revue humaine

Le routage doit reposer sur une qualité mesurée, pas sur l'intuition. Gardez un fallback : si le modèle moins cher est incertain ou échoue à la validation, réessayez avec un modèle plus fort.

function chooseModel(task: { type: string; risk: "low" | "medium" | "high"; tokens: number }) {
  if (task.risk === "high") return "strong-model";
  if (task.type === "classification" && task.tokens < 2000) return "small-model";
  if (task.tokens > 24000) return "long-context-model";
  return "balanced-model";
}

Mesurer la qualité avant les économies

Les économies de tokens ne valent que si la qualité de sortie reste acceptable.

Suivez au minimum :

Métrique	Pourquoi elle compte
Input tokens	Moteur direct du coût
Output tokens	Moteur direct du coût
Task success rate	Signal qualité principal
Human correction rate	Révèle les pertes subtiles de qualité
Validation failures	Détecte régressions de schéma et factuelles
Escalation rate	Montre si le routage est trop agressif
Latency	La compression peut ajouter de l'overhead
Cost per successful task	Mieux que le coût brut par requête

Lancez un A/B test sur trafic réel ou cas historiques rejoués. Comparez sorties optimisées et baseline avant un déploiement large.

Plan de déploiement

Logger l'usage de tokens par route, outil et feature.
Choisir un workflow volumique à faible risque métier.
Ajouter uniquement la sélection de contexte.
Ajouter le nettoyage des sorties d'outils.
Ajouter le caching des composants stables du prompt.
Ajouter le model routing seulement quand la validation existe.
Déployer par pourcentage.
Garder un kill switch par feature.

Ne commencez pas par les tâches à haut risque comme remboursements, suppression de compte, conseil médical, revue juridique ou automatisation de sécurité.

Pièges courants

Compresser l'exigence réelle de l'utilisateur

La dernière instruction utilisateur doit presque toujours rester intacte. Compressez d'abord les contextes plus anciens.

Résumer les règles de sécurité

Les règles de sécurité et de permission doivent être copiées exactement ou référencées via un bloc de politique stable. Ne laissez pas un summarizer les affaiblir.

Optimiser seulement le coût moyen

Une seule tâche importante échouée peut effacer les économies de nombreuses requêtes bon marché. Suivez le coût par tâche réussie et le coût de correction humaine.

Router seulement par longueur de prompt

Des prompts courts peuvent être difficiles et des prompts longs peuvent être simples. Utilisez type de tâche, risque, confiance de validation et performance historique.

Oublier l'auditabilité

Si le contexte optimisé change la réponse, vous devez savoir ce qui a été retiré, résumé, caché ou routé différemment.

FAQ

L'optimisation de tokens peut-elle réduire les coûts de 50 % ou plus ?

Parfois, surtout quand les prompts contiennent des logs répétés, de grands payloads JSON ou trop de contexte récupéré. Mais les économies varient selon le workload. Mesurez votre propre baseline.

La compression de contexte est-elle sûre ?

Elle peut l'être lorsque les instructions requises sont protégées, les sorties validées et le déploiement progressif. La compression aveugle est risquée.

Faut-il utiliser un petit modèle pour tout ?

Non. Les petits modèles sont utiles pour les tâches simples, mais raisonnement complexe, décisions à haut risque et demandes ambiguës nécessitent des modèles plus forts ou une revue humaine.

Que faut-il optimiser en premier ?

Commencez par les sorties d'outils et le contexte RAG. Ils contiennent généralement plus de gaspillage que le message utilisateur.

Résumé

L'optimisation de tokens style Headroom se comprend surtout comme de l'ingénierie de contexte : mieux sélectionner le contexte, nettoyer les sorties d'outils bruyantes, cacher les blocs stables du prompt, router selon le risque de la tâche et mesurer la qualité avant de célébrer les économies. Bien faite, elle peut réduire coûts et latence LLM. Faite aveuglément, elle peut supprimer l'information exacte dont le modèle a besoin.