Inférence-par-dollar : maîtriser les coûts des agents IA avec la mise en cache et les disjoncteurs

La mise en cache du contexte, que j'appelle la « règle des 90 % » pour son potentiel d'économies de coûts significatives, est une technique où les fournisseurs mettent en cache une partie substantielle d'une invite longue et fréquemment répétée. Cela fait généralement référence au « contexte » ou aux « instructions système » qui restent statiques sur plusieurs tours d'interaction d'un agent. Lorsque des appels ultérieurs sont effectués avec le même contexte mis en cache et seulement une nouvelle entrée utilisateur, le fournisseur peut récupérer le contexte prétraité. Cela réduit considérablement la consommation de jetons et la latence pour l'entrée importante. J'ai trouvé cela particulièrement efficace pour les agents qui maintiennent une personnalité système cohérente ou une base de connaissances récupérée étendue sur plusieurs tours.

Pour être éligible à la mise en cache et aux remises associées (qui peuvent être substantielles, souvent environ une réduction de 90 % pour la partie d'entrée mise en cache), les fournisseurs ont généralement plusieurs exigences. J'y prête une attention particulière lors de la conception de mes invites :

• TTL minimum (durée de vie) : les politiques de rétention du cache varient considérablement selon les fournisseurs. La mise en cache explicite (comme celle de Vertex AI de Google) facture généralement à l'heure de stockage, ce qui vous permet de définir de longues TTL pour les bases de connaissances stables. Inversement, la mise en cache automatique (comme celle d'OpenAI ou d'Anthropic) repose sur des TTL éphémères de 5 à 10 minutes qui se rafraîchissent à l'utilisation. Vous devez concevoir la cadence d'interaction de votre agent pour qu'elle corresponde à ces mécanismes TTL afin de maximiser les accès au cache.
• Nombre minimum de jetons : le bloc mis en cache doit atteindre un seuil spécifique au fournisseur pour déclencher le moteur de mise en cache. Cela varie de 1 024 à 2 048 jetons pour la mise en cache automatique à 32 768 jetons pour la création de cache explicite. Ce seuil garantit que la surcharge de calcul de la mise en cache est justifiée par les économies réalisées grâce à la réutilisation d'un grand contexte.
• Correspondance exacte : c'est l'exigence la plus cruciale et souvent négligée. La partie mise en cache de l'invite doit être exactement la même, bit par bit, que la précédente. Même un seul espace supplémentaire, un caractère de nouvelle ligne ou un réarrangement mineur peut casser le cache et forcer un nouveau traitement complet de l'invite entière, ce qui vous coûtera le prix fort. J'ai déjà été confronté à cela, alors je suis méticuleux quant à la cohérence des invites.

Lors du déploiement dans les régions européennes, j'opte généralement pour europe-west1 ou europe-west4 sur GCP, eu-west-1 sur AWS, ou westeurope ou northeurope sur Azure. Ces régions offrent souvent une excellente latence réseau en Europe et sont fréquemment parmi les premières à prendre en charge les nouvelles fonctionnalités d'IA et les déploiements de modèles. Pour connaître les capacités spécifiques aux régions, consultez emplacements google cloud, régions aws pour amazon bedrock et géographies et régions azure.

Choisir le bon modèle et le bon fournisseur de cloud est un élément essentiel de l'optimisation des coûts. La tarification des grands modèles linguistiques (LLM) peut varier considérablement, ce qui a un impact direct sur votre métrique « inférence-par-dollar ». Voici mes considérations d'évaluation comparative pour les modèles de pointe, en utilisant un taux de conversion approximatif de 1 $ = 0,92 € pour ces chiffres :

• Gemini 2.5 Pro sur GCP : 1,27 €/M (1,38 $/M) jetons d'entrée.
• GPT-5.2 sur Azure : 1,78 €/M (1,93 $/M) jetons d'entrée.
• Opus 4.5 sur AWS Bedrock : 2,30 €/M (2,50 $/M) jetons d'entrée (illustratif). Toujours confirmer les prix catalogue actuels dans votre région sur tarification amazon bedrock et id de modèle dans les documents bedrock.

Ces chiffres montrent que même de petites différences de prix par million de jetons peuvent entraîner des variations de coûts substantielles à grande échelle. Mon choix dépend des compromis spécifiques entre les performances, l'ensemble des fonctionnalités et le coût pour la charge de travail de mon agent.

Un disjoncteur agentique est un mécanisme que j'implémente pour empêcher un agent IA autonome d'entrer dans des boucles de raisonnement incontrôlées qui consomment un nombre excessif de jetons et, par conséquent, de budget. C'est une défense pragmatique contre le scénario de la « carte de crédit sans limite ». L'idée principale est d'imposer des plafonds de jetons stricts et de surveiller l'utilisation cumulative des jetons au sein d'une session ou d'une tâche d'un agent. Si l'agent approche d'un seuil prédéfini, le disjoncteur s'active, soit en terminant la ligne de raisonnement actuelle, en passant à un modèle plus petit et moins cher, soit en escaladant vers un examen humain. Il ne s'agit pas d'étouffer l'intelligence, mais d'assurer un fonctionnement responsable et soucieux des coûts.

Voici comment je visualise l'architecture d'un agent IA tirant parti de la mise en cache et d'un disjoncteur :

Gouvernance et sécurité des modèles

Lors du déploiement d'agents IA, la sécurité est primordiale. Les attaques de la chaîne d'approvisionnement sur les outils et dépendances d'IA sont un risque croissant pour les pipelines CI/CD et les environnements de développement. Mettez toujours en œuvre les pratiques suivantes :

• Principe du moindre privilège : assurez-vous que les comptes de service de votre agent n'ont que les autorisations minimales nécessaires pour accéder aux API LLM et aux autres ressources.
• Rotation des identifiants : faites pivoter régulièrement les clés API et les identifiants cloud. Mettez en œuvre une rotation automatisée si possible.
• Isolation de l'environnement : déployez les agents dans des environnements isolés (par exemple, des espaces de noms Kubernetes, des VM dédiées) pour limiter la zone d'impact.
• Journalisation d'audit : activez une journalisation d'audit complète pour tous les appels d'API LLM et les actions des agents. Intégrez ces journaux à votre SIEM pour la détection des anomalies.
• Sécurité de la chaîne d'approvisionnement : vérifiez toutes les bibliothèques et dépendances tierces. Utilisez des scanners tels que Trivy ou Snyk en CI, et suivez des frameworks comme NIST SSDF ou SLSA le cas échéant.

Le comptage local des jetons fournit des estimations pour les vérifications préalables et les disjoncteurs. Cependant, pour la facturation, fiez-vous toujours aux décomptes officiels de jetons renvoyés par le fournisseur de cloud dans la réponse de l'API. Ce sont les chiffres qui apparaissent sur votre facture.

Azure et GCP offrent des fonctionnalités de plate-forme intégrées pour la limitation du débit et les quotas qui sont le moyen le plus robuste d'appliquer des limites strictes.

• Azure : utilisez la politique azure-openai-token-limit dans API Management pour appliquer des taux de jetons par minute ou des quotas fixes.
• GCP : utilisez la politique LLMTokenQuota d'Apigee pour gérer les coûts et appliquer des limites de consommation de jetons par période.

Le code Python suivant illustre un disjoncteur côté client, qui est un modèle flexible que vous pouvez implémenter directement dans la logique de votre application d'agent.

Cet exemple illustre un agent conceptuel qui interagit avec un modèle GCP Vertex AI. Il comprend un compteur de jetons côté client pour le disjoncteur et montre comment structurer les appels pour tirer parti de la fonction de mise en cache de contexte de Vertex AI.

# File: agent_sdk_runner.py
import os
from typing import Dict, Any, List

# --- SDK Imports --- #
# Use the official SDKs for production
import vertexai
from vertexai.generative_models import GenerativeModel, Part
from vertexai.preview.generative_models import caching

# A simple, local token counter for estimates.
# For production, consider a library like tiktoken, but for billing,
# ALWAYS use the usage_metadata from the API response.
def estimate_tokens(text: str) -> int:
    """Provides a rough estimate of token count. Not for billing."""
    return len(text) // 4

class AgentCircuitBreaker(Exception):
    """Custom exception for when the circuit breaker trips."""
    pass

class VertexAIAgent:
    def __init__(self, project_id: str, location: str, model_name: str, max_session_tokens: int):
        self.project_id = project_id
        self.location = location
        self.model_name = model_name
        self.max_session_tokens = max_session_tokens
        self.cumulative_tokens = 0

        vertexai.init(project=project_id, location=location)
        self.model = GenerativeModel(model_name)
        print(f"Agent initialized for model '{model_name}' with max session tokens: {max_session_tokens}")

    def _check_circuit_breaker(self, estimated_next_call_tokens: int):
        projected_total = self.cumulative_tokens + estimated_next_call_tokens
        if projected_total > self.max_session_tokens:
            raise AgentCircuitBreaker(
                f"Circuit breaker tripped! Projected tokens ({projected_total}) exceed session limit ({self.max_session_tokens})."
            )
        print(f"Circuit breaker check OK. Cumulative tokens: {self.cumulative_tokens}, Estimated next call: {estimated_next_call_tokens}")

    def run_interaction(self, system_prompt: str, user_queries: List[str]):
        responses = []
        # --- Caching logic --- #
        # Create a cache. In a real app, you would reuse this cache across sessions.
        # The content of the cache is automatically managed by the SDK.
        # IMPORTANT: Caching in the SDK requires an exact match of the cached prefix.
        # Here, 'system_prompt' is our prefix.
        cached_content = caching.CachedContent.create(
            model=self.model.model_name,
            contents=[Part.from_text(system_prompt)]
        )
        print(f"Vertex AI Context Cache created. TTL: {cached_content.expire_time}")

        # The system prompt is now cached. We only pay the full price once.
        # We can get the token count from the created cache for our circuit breaker.
        # Note: This is a conceptual example. The actual token count for cache creation isn't directly exposed this way.
        # We'll use the response metadata for accurate accounting.

        try:
            for i, query in enumerate(user_queries):
                full_prompt_for_estimation = query if i > 0 else system_prompt + query
                self._check_circuit_breaker(estimate_tokens(full_prompt_for_estimation))

                # For subsequent calls, we use the cache and only send the new user query.
                # The SDK handles combining the cached content with the new content.
                contents_for_call = [Part.from_text(query)]

                # Use the cache in the generation request
                response = self.model.generate_content(contents_for_call, cached_content=cached_content)

                # --- Use official token count from response for circuit breaker --- #
                input_tokens = response.usage_metadata.prompt_token_count
                output_tokens = response.usage_metadata.candidates_token_count
                is_cached = response.usage_metadata.total_token_count < (input_tokens + output_tokens)

                self.cumulative_tokens += input_tokens
                responses.append(response.text)

                print(f"  Query {i+1} processed. Input tokens (billed): {input_tokens}, Output tokens: {output_tokens}")
                print(f"  Cumulative billed input tokens: {self.cumulative_tokens}. Cache hit: {is_cached}")
                print(f"  Response: {response.text.splitlines()[0]}...")

        except AgentCircuitBreaker as e:
            print(f"\nSESSION TERMINATED: {e}")
            responses.append(f"Agent terminated early: {e}")
        finally:
            # Clean up the cache
            cached_content.delete()
            print("Vertex AI Context Cache deleted.")

        return responses

# --- Main Execution --- #
if __name__ == "__main__":
    # This is a conceptual example. You would need to set up authentication.
    # export GOOGLE_APPLICATION_CREDENTIALS="/path/to/your/key.json"
    GCP_PROJECT_ID = os.environ.get("GCP_PROJECT_ID", "your-gcp-project-id")
    GCP_LOCATION = "europe-west4"

    # Illustrative model name for 2026
    MODEL_NAME = "gemini-1.5-pro-preview-0409"

    # Long system prompt to demonstrate caching benefits
    system_prompt = "You are a helpful financial assistant providing concise market analysis... " * 500
    # In a real scenario, this would need to be large enough to meet the provider's min token count for caching.

    user_queries = [
        "What is the current outlook for wind energy investments in EU-West1?",
        "How have carbon credit prices reacted to recent energy crises?",
        "Provide an overview of regulatory changes affecting green bonds in 2025."
    ]

    print("\n=== Testing Agent with Circuit Breaker (GCP) ===")
    # Set a tight token budget to demonstrate the circuit breaker
    agent = VertexAIAgent(GCP_PROJECT_ID, GCP_LOCATION, MODEL_NAME, max_session_tokens=1000)
    responses = agent.run_interaction(system_prompt, user_queries)

Sortie attendue (conceptuelle) : la sortie montrera l'agent effectuant des appels. Les usage_metadata du SDK Vertex AI fournissent le prompt_token_count exact. Pour un accès au cache, ce nombre sera bien inférieur à l'appel initial, ne reflétant que les jetons de la nouvelle requête utilisateur. Si les jetons cumulés dépassent max_session_tokens, l'exception AgentCircuitBreaker sera levée, mettant fin à la session.

Pour vérifier votre implémentation, exécutez le script de l'agent avec vos identifiants cloud configurés. Surveillez la sortie du journal pour :

• Accès au cache : après le premier appel, les appels ultérieurs devraient afficher un prompt_token_count significativement inférieur dans les usage_metadata renvoyées par le SDK. Cela confirme que le cache est utilisé.
• Activation du disjoncteur : définissez une limite max_session_tokens basse. L'agent devrait cesser de traiter les requêtes et lever l'exception AgentCircuitBreaker une fois que le nombre de jetons cumulés dépasse ce seuil. Cela confirme que votre mécanisme de contrôle des coûts fonctionne.

1. Erreur : AgentCircuitBreaker: Agent circuit breaker tripped! Solution : c'est le comportement attendu du disjoncteur. Pour permettre des interactions plus longues, augmentez le max_session_tokens lors de l'initialisation de l'agent.

2. Erreur : Manque de cache lors des appels ultérieurs, même avec une invite système identique. Solution : la mise en cache exige que la partie mise en cache de l'invite soit exactement identique. Assurez-vous qu'aucun espace blanc ou caractère supplémentaire n'est ajouté. Vérifiez également que vous respectez les exigences minimales du fournisseur pour la mise en cache, telles que le nombre minimum de jetons dans le contexte mis en cache. Pour les API LLM réelles, vérifiez les paramètres de mise en cache spécifiques du fournisseur dans leur documentation API, par exemple les documents de mise en cache de google ou les documents de mise en cache d'openai.

• La mise en cache de contexte est cruciale pour les interactions d'agents multi-tours ; faites toujours très attention à l'exigence de correspondance exacte et au nombre minimum de jetons pour un maximum d'économies.
• L'évaluation comparative de modèles comme gemini, gpt et opus par million de jetons d'entrée est essentielle pour une sélection éclairée du fournisseur et du modèle en fonction de la rentabilité.
• Les disjoncteurs agentiques sont une protection non négociable qui empêche les boucles de raisonnement coûteuses et offre un contrôle granulaire sur les dépenses des agents IA.
• Les bonnes pratiques de sécurité concernant les identifiants, l'isolation de l'environnement et la chaîne d'approvisionnement sont essentielles lors du déploiement d'agents autonomes.

L'étape suivante la plus importante pour tout chef de projet ou architecte IA est d'intégrer ces contrôles des coûts dès le premier jour. Un peu de discipline architecturale en amont permet de réaliser de réelles économies de coûts opérationnels.

Ressources externes :

• Mise en cache et coûts (fournisseurs) : mise en cache d'invites openai, mise en cache d'api gemini, vue d'ensemble du cache de contexte vertex ai, tarification amazon bedrock
• SDK Python officiels :
  • client python google cloud vertex ai
  • azure openai python (azure-ai-openai)
  • boto3 bedrock-runtime

Exemples de code supplémentaires :

Pour des modèles d'agents plus avancés et des techniques d'optimisation des coûts, consultez le référentiel github langchain ou les exemples transformers hugging face, en adaptant leurs exemples pour incorporer un comptage explicite des jetons et des vérifications budgétaires.