💸 Calculateur de coûts en tokens
La facture d'une application LLM (Large Language Model, grand modèle de langage) se calcule ainsi :
tokens d'entrée × prix d'entrée + tokens de sortie × prix de sortie.
Jouez avec le modèle, le volume, le prompt caching (mise en cache du prompt) et le
routage de modèles pour voir la facture fondre.
⚠ Grille tarifaire fictive, inspirée des ordres de grandeur mi-2026. En production, vérifiez toujours la grille du jour de votre fournisseur.
⚠ Grille tarifaire fictive, inspirée des ordres de grandeur mi-2026. En production, vérifiez toujours la grille du jour de votre fournisseur.
⚙️ Paramètres
📊 Résultat
| Poste | $ / jour |
|---|---|
| Entrée — tokens stables | — |
| Entrée — tokens variables | — |
| Sortie | — |
| Total journalier | — |
Coût mensuel estimé (×30) :
—
💡 Astuce : activez le caching puis le routage, et observez la facture. C'est l'Exercice 1 de la session.
🧠 Ce que ce calculateur enseigne
- La sortie coûte 3 à 5× l'entrée ⚠ — raccourcir les réponses est un levier de coût ET de latence.
- Le caching ne marche que si le prompt est bien structuré : contenu stable au début, variable à la fin. Un horodatage dynamique en tête de prompt = cache invalidé.
- Le routage est souvent le plus gros levier : la majorité des requêtes d'un assistant support sont simples.
🏗️ Constructeur d'architecture de déploiement
Glissez-déposez (ou cliquez) les composants pour assembler le chemin d'une requête, du client jusqu'à la réponse.
L'estimation de latence s'ajuste, et le vérificateur signale les oublis dangereux (clé API exposée, absence de journalisation…).
⚠ Latences indicatives, à titre pédagogique.
⚠ Latences indicatives, à titre pédagogique.
🧰 Composants disponibles (cliquez ou glissez vers le pipeline)
🔗 Votre pipeline (ordre = chemin de la requête)
Déposez ici votre premier composant… (commencez par le Client 😉)
🧠 Rappels pour bien assembler
- La clé API vit dans le backend, jamais dans le client → un backend est obligatoire entre client et fournisseur LLM.
- La journalisation ne coûte presque rien en latence et sauve chaque diagnostic.
- Le cache de réponses sert les questions fréquentes sans appeler le modèle : latence ~10 ms au lieu de plusieurs secondes.
- La file d'attente (queue) est le patron des charges massives asynchrones — elle « casse » le chemin synchrone : l'utilisateur ne reçoit pas la réponse immédiatement.
🔭 Dashboard de monitoring — SupportBot en production
Maquette d'un tableau de bord de production avec métriques animées : latence en percentiles
(p50 / p95 / p99), TTFT (Time To First Token, délai avant le premier token), taux d'erreur, budget de tokens,
taux de cache. Utilisez le bouton « Simuler un incident » pour voir les alertes se déclencher.
Disponibilité (24 h)
99,95 %
objectif SLA : ≥ 99,9 %
Taux d'erreur (5 min)
0,4 %
alerte si > 2 % pendant 5 min
Latence
2,1 s
p50 1,1 s · p95 ci-dessus · p99 4,2 s — SLA : p95 < 3 s
TTFT p95 (streaming)
640 ms
premier token — objectif < 1 000 ms
Budget de tokens (mois)
42 %
alertes à 50 / 80 / 100 %
Taux de cache (prompt caching)
91 %
part des tokens stables servis depuis le cache
Routage de modèles
81 %
part du trafic servie par le petit modèle
Erreurs 429 (rate limit)
2 / h
toutes résolues par backoff exponentiel
[08:00:12] ✅ Service démarré — toutes métriques nominales
🧠 Comment lire ce dashboard
- La moyenne ment : regardez le p95 et le p99, pas la moyenne. Les SLA (Service Level Agreement, engagement de niveau de service) s'écrivent en percentiles.
- Chaque alerte a une action documentée : « SI taux d'erreur > 2 % PENDANT 5 min ALORS astreinte notifiée FAIT vérifier statut fournisseur, activer le mode dégradé ».
- Ce dashboard ne voit pas la qualité des réponses — pour cela il faut des évaluations continues et du feedback utilisateur 👍/👎 (Session 9 !).