← Retour au blog

FinOps pour LLM coûts et latence

Lucian BLETAN

Une application basée sur un LLM peut vite devenir un centre de coût imprévisible. Chaque appel a un prix, et la facture dépend directement du nombre de tokens, de la complexité du modèle et de la latence. Le FinOps pour les LLM n’est pas une option : c’est une discipline essentielle pour piloter ces coûts. En optimisant les prompts, en utilisant intelligemment le cache et en choisissant le bon modèle pour la bonne tâche, on peut construire une expérience utilisateur rapide et économiquement viable.

les leviers principaux de l’optimisation

La maîtrise des coûts et de la latence repose sur un ensemble de techniques complémentaires.

optimisation llm

prompts & tokens

templates

limiter la longueur des réponses

cache

réponses déterministes

embeddings

batching

regrouper les requêtes

choix du modèle

petit modèle + rag

chaînage de modèles

mesurer pour pouvoir piloter

On ne peut pas optimiser ce que l’on ne mesure pas. La première étape est de mettre en place une observabilité fine des appels au LLM.

  • Coût par tâche et par utilisateur: Pour identifier les cas d’usage les plus coûteux et responsabiliser les équipes.
  • Latence p95: La latence moyenne est trompeuse. La p95 (le 95ème percentile) vous donne une bien meilleure idée de l’expérience utilisateur réelle.
  • Taux de cache hit: Un taux de cache élevé est le signe d’une optimisation réussie.
-- Suivre les coûts et l'efficacité du cache par route applicative
SELECT
    route_name,
    ROUND(SUM(total_cost_eur), 2) AS cout_total_7j,
    APPROX_QUANTILES(duration_ms, 100)[OFFSET(95)] AS latence_p95_ms,
    ROUND(100.0 * SUM(CASE WHEN is_cache_hit THEN 1 ELSE 0 END) / COUNT(*), 1) AS cache_hit_pct
FROM
    llm.api_traces
WHERE
    trace_timestamp >= CURRENT_DATE - INTERVAL '7 day'
GROUP BY 1
ORDER BY cout_total_7j DESC;

arbitrages dans le choix du modèle

Le modèle le plus gros et le plus puissant n’est pas toujours la meilleure solution. Une architecture intelligente est souvent plus performante et moins chère.

  • Petit modèle + RAG > Gros modèle seul: Pour des questions factuelles, un petit modèle rapide auquel on fournit du contexte via RAG (Retrieval-Augmented Generation) sera souvent plus précis et 10x moins cher qu’un gros modèle généraliste.
  • Chaînage de modèles (Chain-of-thought): Pour une tâche complexe, utilisez une chaîne de petits modèles spécialisés. Un premier modèle classifie l’intention, un second génère la réponse, un troisième vérifie la conformité.

intention 'question simple'

intention 'tâche complexe'

requête utilisateur

1. classifieur d'intention (petit modèle)
2. modèle de réponse + rag
2. modèle d'agent (gros modèle)

réponse

hygiène opérationnelle

  • Rotation des clés et quotas: Faites tourner vos clés d’API régulièrement et définissez des quotas stricts par utilisateur ou par projet pour éviter les abus.
  • Timeouts: Configurez des timeouts agressifs. Mieux vaut une erreur rapide qu’une requête qui tourne pendant 30 secondes.
  • Suppression des traces: Ne stockez les prompts et les réponses que le temps nécessaire à l’analyse, pour des raisons de coût et de confidentialité.

pièges frequents

  • Symptôme: La facture explose à cause du nombre de tokens.

    • Cause: Prompts trop verbeux et réponses non contraintes.
    • Correctif: Utiliser des gabarits de prompts (templates) très courts. Toujours spécifier une longueur maximale pour la réponse (max_tokens).

  • Symptôme: L’application est lente car elle répète les mêmes appels au LLM.

    • Cause: Pas de cache.
    • Correctif: Mettre en place un cache simple (ex: Redis) avec une durée de vie courte (quelques minutes) pour les requêtes identiques et déterministes (température à 0).

  • Symptôme: Un seul gros modèle est utilisé pour toutes les tâches, ce qui le rend lent et cher.

    • Cause: Manque de routage intelligent.
    • Correctif: Mettre en place un routeur qui envoie les requêtes simples vers un petit modèle rapide et ne sollicite le gros modèle que lorsque c’est absolument nécessaire.

faq

  • Comment définir un budget réaliste ? Commencez par estimer le coût d’un millier de requêtes types pour votre cas d’usage. Extrapolez ensuite en fonction de votre trafic attendu. Mettez une alerte à 50% de ce budget, puis ajustez-le après la première semaine de production.

  • Le streaming de la réponse améliore-t-il vraiment la latence ? Il n’améliore pas la latence totale (le temps pour générer la réponse complète reste le même), mais il améliore drastiquement la latence perçue par l’utilisateur. Afficher les mots au fur et à mesure qu’ils sont générés donne une impression de réactivité immédiate.

tags