L'API GLM n'est pas un forfait illimité : elle est facturée à l'usage réel. Beaucoup d'équipes s'étonnent de leur première facture : le nombre de requêtes est faible, mais le coût dépasse les prévisions. La cause n'est généralement pas le prix unitaire, mais des entrées trop longues, des sorties non maîtrisées, un cache qui ne touche pas, ou des reprises qui régénèrent le contenu.
Cet article ne donne pas de prix unitaires, car ils varient selon le modèle, le palier de contexte et les offres. Nous expliquons la structure de facturation, l'origine des coûts, comment estimer et réduire la dépense, puis une liste de contrôle applicable. Pour les prix actuels, consultez la page Tarifs des modèles et la grille officielle de Zhipu.
Remarque : Zhipu, GLM et BigModel sont des marques de leurs détenteurs respectifs. Cet article est purement technique et n'implique aucune affiliation ni représentation avec Zhipu. Les règles de facturation et les prix peuvent évoluer ; vérifiez la documentation officielle et la page de facturation avant toute commande.
1. L'unité de base de la facturation
Les modèles texte utilisent le token comme unité de base. La documentation officielle de Zhipu donne un ordre de grandeur d'environ 1 token pour 1,6 caractère chinois ; le nombre réel dépend du tokenizer et du contenu, et c'est le champ usage renvoyé par l'API qui fait foi. Une estimation sert au budget, pas de substitut à la facture.
Tous les modèles ne sont pas facturés au token. La génération d'images, la génération vidéo, la synthèse vocale, le clonage vocal, l'audio et la vidéo en temps réel ou l'analyse de base de connaissances peuvent être facturés à l'appel, à la minute, au caractère ou à la page. Pour un produit multimodal, commencez par confirmer l'unité de facturation avant de parler de prix unitaire.
2. Pourquoi les entrées et les sorties sont facturées séparément
Une requête comprend généralement des tokens d'entrée et des tokens de sortie, facturés séparément, les sorties étant en général plus chères. Les modèles à contexte long peuvent aussi appliquer des paliers selon la longueur d'entrée, par exemple une limite à 32K au-delà de laquelle le tarif augmente ; certains modèles appliquent également des paliers sur la longueur de sortie. Un même modèle peut donc avoir un coût unitaire différent selon l'usage.
Le coût dépend moins du nombre de requêtes que du contexte transporté à chaque appel. Insérer toute la base de connaissances, tout l'historique de conversation et des dizaines de définitions d'outils dans le prompt fait exploser les entrées. Le gaspillage le plus courant concerne les sorties : sans longueur maximale, le modèle s'étend et la facture monte.
| Poste de coût | Base de facturation | Cas déclencheur courant | Moyen de maîtrise |
|---|---|---|---|
| Tokens d'entrée | Entrées non couvertes par le cache | Prompt long, historique multi-tours, définitions d'outils | Réduire le contexte, résumer |
| Tokens de sortie | Contenu généré | Rédaction longue, génération de code | Fixer une longueur maximale de sortie |
| Cache touché | Partie en cache à tarif réduit | Prompt système fixe, préfixe de base de connaissances | Garder un préfixe stable |
| Palier de contexte long | Tarif modifié au-delà d'un seuil | Documents longs, analyse de dépôt de code | Découper, résumer, charger à la demande |
| Reprises et échecs | La partie déjà générée peut être facturée | Timeout, flux interrompu, soumission en double | Idempotence, backoff, déduplication |
| Multimodal et outils | À l'appel, la minute, la page, etc. | Génération d'images, voix, recherche, analyse | Comptabilité séparée, limiter les appels |
3. Cache de contexte : économiser sur les préfixes répétés
Zhipu propose un cache de contexte ; la documentation officielle présente surtout le cache implicite, qui détecte automatiquement les contenus répétés sans marquer manuellement des points de cache. Il convient aux scénarios du type « prompt système fixe + base de connaissances fixe + question variable ».
Pour améliorer le taux de réussite, trois conditions au minimum : un préfixe répété suffisamment long, l'officiel recommandant plus de 500 tokens ; un préfixe strictement identique, un espace de plus pouvant suffire à rater ; et un cache généré en asynchrone, d'où l'intérêt d'attendre un peu après la première requête. Le champ usage.prompt_tokens_details.cached_tokens permet de vérifier les hits.
Le cache n'est pas magique. Les prompts courts, les contenus qui changent à chaque fois et les bases de connaissances modifiées fréquemment touchent rarement. La facturation éventuelle du stockage et le niveau de remise dépendent de la grille officielle. Traitez le cache comme une optimisation, pas comme une hypothèse par défaut du modèle de coût.
4. Contexte long, traitement par lots et multimodal
Le contexte long est utile, mais c'est aussi le poste qui dépasse le plus facilement le budget. Pour traiter des contrats, des articles scientifiques ou des dépôts de code, posez trois questions : faut-il vraiment tout insérer d'un coup ? Peut-on d'abord rechercher puis assembler ? Peut-on traiter par segments puis agréger ? Beaucoup de tâches se règlent par « recherche + résumé », pour un coût bien inférieur à l'injection de toute la base.
Pour les tâches par lots, regardez l'interface Batch. La documentation officielle indique que les modèles compatibles bénéficient généralement d'une remise via Batch, adaptée à l'annotation hors ligne, au résumé massif ou au nettoyage de données. Le prix à payer est une latence plus élevée et une orchestration plus complexe, adaptée aux équipes disposant de files d'attente et de contrôles de résultats.
Les capacités multimodales se comptabilisent séparément. La génération d'images est facturée à l'image, la compréhension d'images généralement au token ; la synthèse vocale au caractère ou à la minute, l'analyse de base de connaissances à la page. Mélanger ces coûts au budget texte provoque un écart en fin de mois.
5. Reprises, flux interrompus et coûts cachés
Une requête échouée n'est pas nécessairement gratuite. Si le serveur a déjà généré une partie du contenu avant le timeout, cette consommation peut rester facturée ; en cas d'interruption d'un flux, la partie déjà générée peut aussi figurer sur la facture. La stratégie de reprise doit donc rester mesurée : ne réessayer que sur limite de débit, erreurs 5xx et timeout réseau, avec un backoff exponentiel et un nombre maximal de tentatives.
Autre coût caché : les soumissions en double. Double-clic de l'utilisateur, renvoi automatique après timeout côté frontend, consommation répétée d'une file produisent des requêtes supplémentaires. Utiliser un identifiant de requête pour l'idempotence, ou dédupliquer au niveau de la passerelle, est bien plus efficace qu'un rapprochement a posteriori.
Il faut aussi compter le coût d'ingénierie : journaux, supervision, évaluation, revue humaine. Les appels de modèle ne sont qu'une partie du coût total ; mieux vaut ne pas économiser quelques appels pour investir plusieurs fois plus en corrections manuelles.
6. Comment estimer un budget mensuel
L'estimation se fait en quatre étapes : compter les appels mensuels, estimer les entrées et sorties moyennes, estimer le taux de cache, appliquer les tarifs actuels. Pour gérer les soldes et l'usage de plusieurs modèles au même endroit, inscrivez-vous sur ZSQH AI Gateway et consultez-les de façon unifiée ; les prix restent ceux de la page Tarifs des modèles. Le code ci-dessous n'est qu'un cadre de calcul : lisez les tarifs sur la grille officielle et renseignez-les.
# Modèle de budget : tous les tarifs sont des valeurs d'exemple, à remplacer par les prix officiels actuels
monthly_calls = 300_000
avg_input_tokens = 1_200
avg_output_tokens = 300
cache_hit_rate = 0.35
input_rate = 0.0 # tarif d'entrée, voir la grille officielle
output_rate = 0.0 # tarif de sortie
cache_rate = 0.0 # tarif du cache
uncached_input = avg_input_tokens * (1 - cache_hit_rate)
cached_input = avg_input_tokens * cache_hit_rate
per_call = (
uncached_input * input_rate
+ cached_input * cache_rate
+ avg_output_tokens * output_rate
)
print(f"Coût mensuel estimé : {monthly_calls * per_call:.2f} CNY")
Prévoyez une marge. Les entrées réelles d'une nouvelle activité sont souvent plus longues que prévu, et les reprises augmentent l'usage. Faites tourner l'activité à faible volume pendant deux semaines, remplacez les hypothèses par les données usage réelles, puis fixez le budget.
7. Liste de contrôle budgétaire
- Fixer une limite de quota distincte par environnement et par service.
- Définir une longueur maximale de sortie et un timeout pour chaque requête.
- Figer l'ordre du prompt système pour améliorer le taux de cache.
- Pour les documents longs, rechercher et résumer avant de décider d'utiliser le contexte long.
- Ne réessayer que les erreurs réessayables, avec backoff et plafond de tentatives.
- Consulter l'usage chaque jour et la facture chaque semaine ; investiguer immédiatement toute hausse anormale.
- Privilégier Batch pour les tâches hors ligne, l'API en ligne pour le temps réel.
8. Questions fréquentes (FAQ)
1. Combien coûte exactement l'API GLM ?
Les prix varient selon le modèle, le palier de contexte et les offres ; cet article ne donne pas de chiffres fixes. Consultez Tarifs des modèles ou la grille officielle de Zhipu, et faites foi de la facture de la console.
2. Comment est facturé un hit de cache ?
La partie couverte par le cache est facturée à tarif réduit, les entrées non couvertes au tarif d'entrée standard. La remise exacte et les frais de stockage figurent sur la grille officielle ; le volume de hits est visible dans le champ usage.
3. Une requête échouée est-elle facturée ?
Cela dépend de l'étape de l'échec. Si une partie du contenu a déjà été générée, elle peut être facturée à l'usage réel ; une erreur de paramètre ou d'authentification ne produit généralement pas de frais de génération. La facture détaillée fait foi.
4. Le contexte long est-il toujours plus cher ?
Généralement oui. Beaucoup de modèles appliquent des paliers selon la longueur d'entrée, avec un tarif supérieur au-delà du seuil. Une tâche soluble par découpage ou recherche n'a pas besoin du contexte long.
5. Comment réduire rapidement les coûts existants ?
Trois actions d'abord : limiter la longueur de sortie, compresser le prompt système, augmenter le taux de cache. Elles agissent souvent plus vite et plus sûrement qu'un changement de modèle.
