Technical Tutorials

Les grands modèles de langage (LLM) sont puissants, mais ils sont aussi coûteux. Pour de nombreuses équipes d'ingénierie, le défi principal n'est plus seulement la capacité du modèle, mais l'efficacité économique de leurs pipelines d'inférence. Un piège courant est la « fuite de jetons », où des données redondantes, verbeuses ou inutiles sont envoyées au modèle, ou où les modèles génèrent des sorties excessives qui n'apportent aucune valeur. Sans une observabilité appropriée, ces coûts restent cachés dans la facture globale, rendant difficile l'identification des étapes spécifiques du pipeline qui entraînent des pertes financières.

Ce guide explore comment passer de la spéculation à la connaissance en implémentant des métriques d'observabilité spécifiques pour quantifier le gaspillage de jetons et conduire à des optimisations de coûts ciblées.

Pourquoi le gaspillage de jetons est important

Dans les applications LLM, les coûts sont directement proportionnels au nombre de jetons traités (entrée + sortie). Cependant, tous les jetons ne sont pas égaux en termes de densité de valeur. Le gaspillage de jetons peut se manifester de trois manières principales :

Gonflement de l'entrée : Envoi de fenêtres de contexte volumineuses et non filtrées ou de prompts système redondants.
Verbiage de la sortie : Les modèles génèrent des réponses longues et conversationnelles alors que des données structurées et concises sont nécessaires.
Surcharge de réessai : Plusieurs tentatives dues à une ingénierie de prompt médiocre ou à des échecs de validation, multipliant le coût par requête réussie.

Quantifier ce gaspillage vous permet de distinguer les jetons « nécessaires » des jetons « gaspillés », permettant ainsi des stratégies d'optimisation précises plutôt que des réductions générales qui pourraient nuire à la qualité.

Métriques clés pour l'observabilité

Pour quantifier le gaspillage, vous devez instrumenter votre pipeline pour suivre des métriques spécifiques au-delà du simple nombre total de jetons. Voici les trois métriques critiques :

1. Taux de pertinence du contexte (CRR)

Cette métrie estime le pourcentage de jetons d'entrée qui sont réellement pertinents pour la réponse finale. Bien qu'il soit difficile de la mesurer parfaitement sans analyse sémantique, vous pouvez l'estimer en suivant la longueur de contexte « effective » par rapport à la longueur de contexte « fournie » dans les systèmes RAG (Génération Augmentée par Récupération). Si vous récupérez 5 000 jetons mais que le modèle ne cite que les 500 premiers, le CRR est de 10 %, indiquant un gaspillage significatif de la récupération.

2. Indice de verbeux de la sortie (OVI)

L'OVI mesure le ratio entre les informations utiles et le nombre total de jetons de sortie. Vous pouvez le calculer en comparant le nombre de caractères de la sortie finale analysée (par exemple, un objet JSON) avec la réponse brute du LLM. Une grande différence indique que le modèle ajoute du remplissage conversationnel (« Bien sûr, voici le JSON... ») que vous devez supprimer a posteriori, représentant des jetons de sortie gaspillés.

3. Taux de réussite au premier essai (FPSR)

C'est le pourcentage de requêtes qui retournent un résultat valide et utilisable à la première tentative. Un FPSR faible indique une surcharge de réessai élevée. Chaque réessai double le coût des jetons d'entrée et ajoute le coût des jetons de sortie. Suivre le FPSR par modèle de prompt vous permet d'identifier quels prompts sont mal conçus et provoquent des échecs coûteux.

Mise en œuvre de l'observabilité avec du code

Voici un exemple en Python utilisant un cadre d'observabilité hypothétique (comme LangSmith, Phoenix ou un journalisation personnalisée) pour instrumenter ces métriques.


import time
import logging
from dataclasses import dataclass

@dataclass
class LLMResponseMetrics:
    input_tokens: int
    output_tokens: int
    response_time_ms: int
    success: bool
    parsed_output_size: int  # Taille de la sortie finale, nettoyée

def instrument_llm_call(prompt: str, model_response: str, parsed_output: str, usage_data: dict):
    """
    Calcule et journalise les métriques d'observabilité clés pour l'analyse du gaspillage de jetons.
    """
    # 1. Extraire les nombres bruts de jetons des données d'utilisation de l'API
    input_tokens = usage_data.get('prompt_tokens', 0)
    output_tokens = usage_data.get('completion_tokens', 0)
    
    # 2. Calculer l'Indice de verbeux de la sortie (OVI)
    # Approximation : Ratio de la longueur analysée (utile) par rapport à la longueur brute
    raw_length = len(model_response)
    parsed_length = len(parsed_output)
    
    # Si la sortie analysée est significativement plus petite, elle est probablement verbeuse
    # Note : En production, utilisez la pertinence sémantique ou une comparaison basée sur les jetons
    if raw_length > 0:
        verbosity_ratio = parsed_length / raw_length
    else:
        verbosity_ratio = 1.0

    # 3. Déterminer la réussite au premier essai (basée sur la validation)
    success = parsed_output is not None and len(parsed_output) > 0

    # 4. Journaliser les métriques pour la plateforme d'observabilité
    logging.info(
        "LLM_METRICS",
        extra={
            "input_tokens": input_tokens,
            "output_tokens": output_tokens,
            "total_tokens": input_tokens + output_tokens,
            "verbosity_ratio": round(verbosity_ratio, 3),
            "success": success,
            "timestamp": time.time()
        }
    )

    return {
        "verbosity_ratio": verbosity_ratio,
        "success": success
    }

# Exemple d'utilisation
# suppose que 'raw_response' est la chaîne LLM complète, 'parsed_json' est le JSON extrait
# metrics = instrument_llm_call(user_prompt, raw_response, parsed_json, api_usage_dict)

Stratégies d'optimisation pratiques

Une fois que vous avez ces métriques, vous pouvez agir :

Pour une verbeux élevée (OVI faible) :
- Instruire le modèle pour « répondre uniquement en JSON » ou « sans préambule ».
- Utiliser des analyseurs de sortie plus robustes, réduisant le besoin pour le modèle d'être « poli ».
- Passer à un modèle plus petit et plus directif pour les tâches d'extraction simples.
Pour des taux de réessai élevés (FPSR faible) :
- Ajouter des exemples few-shot au prompt pour clarifier le format attendu.
- Implémenter une validation d'entrée plus stricte avant l'envoi au LLM pour détecter tôt les requêtes malformées.
- Utiliser la logique de « auto-correction » uniquement pour les tâches à haute valeur, et non pour chaque requête.
Pour le gonflement de l'entrée :
- Implémenter une troncature dynamique du contexte. Si le CRR est faible, réduire le nombre de documents récupérés.
- Utiliser des prompts système compatibles avec la mise en cache pour tirer parti de la mise en cache côté fournisseur, réduisant les coûts d'entrée effectifs.

Conclusion

L'optimisation des coûts dans les pipelines LLM n'est pas une tâche ponctuelle, mais une discipline d'ingénierie continue. En traitant l'utilisation des jetons comme une métrique de système observable, vous obtenez la visibilité nécessaire pour identifier les inefficacités. Commencez par instrumenter votre pipeline pour suivre l'Indice de verbeux et le Taux de réussite au premier essai. Vous constaterez probablement que de petits ajustements de prompt et une meilleure logique de récupération peuvent entraîner une réduction de 20 à 40 % du gaspillage de jetons, améliorant significativement votre rentabilité unitaire sans sacrifier les performances du modèle. Adoptez l'observabilité non seulement pour le débogage, mais aussi pour la gestion financière.