L'API Qwen est l'interface d'appel des modèles Tongyi Qianwen fournie par Alibaba Cloud Model Studio (Bailian). Les développeurs parlent souvent de DashScope, nom de la couche API et SDK de ce service. Trois noms, mais une seule logique de facturation : à l'usage réel, entrées et sorties séparées.

Cet article ne fige pas de prix unitaires, car les versions de modèles, les paliers de contexte et les offres évoluent. Nous expliquons où va l'argent, pourquoi le contexte long dépasse facilement le budget, comment utiliser cache et Batch, et comment estimer le mois à partir de journaux réels. Les prix actuels sont ceux de la page Tarifs des modèles et de la grille officielle d'Alibaba Cloud Model Studio.

Remarque : Qwen, Tongyi Qianwen, Alibaba Cloud, Bailian, Model Studio et DashScope sont des marques de leurs détenteurs respectifs. Cet article est purement technique et n'implique aucune affiliation ni représentation avec Alibaba Cloud. Les règles de facturation et les prix peuvent évoluer ; vérifiez la documentation officielle avant commande.

1. Mettre les noms d'abord : Bailian, Model Studio et DashScope

Ces trois noms sont souvent confondus, mais ne désignent pas la même couche :

  • Alibaba Cloud Bailian : console et nom de produit en Chine ; l'activation des modèles, les clés API, l'usage et la facturation s'y trouvent.
  • Alibaba Cloud Model Studio : nom de produit du site international, aux capacités équivalentes ; les régions et devises de facturation peuvent différer.
  • DashScope : nom de la couche API et SDK, visible dans l'URL de base, la variable d'environnement DASHSCOPE_API_KEY et les anciennes documentations.

Lors d'un appel, trois éléments sont à confirmer : la région (Pékin, Singapour, etc.), l'URL de base et l'ID du modèle. En cas de discordance, l'erreur la plus fréquente n'est pas un solde insuffisant, mais un échec d'authentification ou un modèle inexistant.

2. Le palier de modèle fixe le plafond de coût

Les modèles texte Qwen se répartissent généralement en trois paliers, représentés en 2026 par Qwen-Max, Qwen-Plus et Qwen-Flash :

Palier ID de modèle représentatif Positionnement Tâches adaptées Ordre de coût
Max qwen3.8-max Raisonnement complexe et tâches multi-étapes Code, agents, analyse approfondie Élevé
Plus qwen3.7-plus Équilibre entre capacité, vitesse et coût Service client, rédaction, traitement documentaire Moyen
Flash qwen3.8-flash Faible latence, faible coût Classification, extraction, réécriture, routage Faible

Les ID de modèles évoluent : ne figez pas les noms dans vos achats. Plus robuste : lier le type de tâche au palier. Flash par défaut pour les tâches simples, Plus pour les tâches courantes, Max seulement lorsqu'un raisonnement multi-étapes est réellement nécessaire. Utiliser Max partout n'améliore pas forcément le résultat, mais alourdit certainement la facture.

3. Unités de facturation : entrées, sorties et multimodal

Les modèles texte facturent séparément les tokens d'entrée et de sortie ; la grille officielle les présente généralement en « CNY par million de tokens ». Le coût d'un appel s'écrit :

coût d'un appel =
  tokens d'entrée hors cache × tarif d'entrée
+ tokens en cache × tarif du cache
+ tokens de sortie × tarif de sortie

Le multimodal se traite séparément : la génération d'images est souvent facturée au nombre d'images produites, la voix à la durée audio, et les modèles Omni et Realtime appliquent des tarifs distincts selon le texte, l'image ou l'audio. Mélanger ces coûts au budget texte provoque un écart en fin de mois.

De plus, un modèle de traduction comme Qwen-MT-Uni ne facture que les tokens d'entrée ; certains modèles, en mode réflexion, facturent les tokens de sortie selon une règle différente de la réponse normale. Pour un modèle donné, lisez d'abord la colonne « élément facturé » de la grille, sans appliquer le prix d'un autre modèle.

4. Contexte long : le palier s'applique à toute la requête

C'est le point le plus souvent négligé de la facturation Qwen. La grille officielle applique des paliers selon le total de tokens d'entrée d'une requête, généralement :

  • 0 < tokens ≤ 32K
  • 32K < tokens ≤ 128K
  • 128K < tokens ≤ 256K
  • 256K < tokens ≤ 1M

L'essentiel est que le palier s'applique à toute la requête : tous les tokens de cette requête (sortie comprise) sont facturés au tarif du palier atteint, et non les 32K premiers à bas prix puis le dépassement à prix élevé. Autrement dit, passer de 31K à 33K d'entrée ne coûte pas seulement 2K de plus : toute la requête change de palier.

Le contexte long doit donc servir à bon escient. Pour un contrat, un article ou un dépôt de code, posez trois questions : faut-il vraiment tout insérer ? Peut-on rechercher puis assembler ? Peut-on traiter par segments puis agréger ? Beaucoup de tâches se règlent par « recherche + résumé », bien moins cher que l'injection de toute la base. Si le contexte long est réellement nécessaire, choisissez un modèle couvrant le palier requis et testez la facture avec une requête réelle.

5. Cache et Batch : des économies, mais pas cumulables

Le cache de contexte ne remise que les tokens d'entrée. Il existe en explicite et implicite : le cache explicite exige de créer manuellement des points de cache, la création pouvant être facturée au-dessus du tarif d'entrée standard, puis les hits au tarif réduit ; le cache implicite détecte automatiquement les préfixes répétés et est activé par défaut sur certains modèles. Dans les exemples officiels, la création de cache représente environ 125 % du tarif d'entrée standard et le hit environ 10 %, mais les ratios varient selon les modèles : la documentation du cache fait foi.

Batch convient aux tâches hors ligne. Pour les modèles compatibles, les tarifs d'entrée et de sortie sont généralement calculés à 50 % du prix de l'inférence en temps réel, au prix d'une latence plus élevée et d'une orchestration des tâches. Attention : les remises cache et Batch ne s'appliquent généralement pas simultanément ; ne les additionnez pas dans un même modèle de budget.

Le cache ne fonctionne que si le préfixe est stable. Si le prompt système, les définitions d'outils et les extraits de base de connaissances changent d'ordre à chaque fois, le taux de hit restera faible. Placer le contenu stable en tête et le contenu variable à la fin est l'optimisation de base.

6. Reprises, échecs et coûts cachés

La page de facturation officielle indique qu'une requête échouée n'est pas facturée. Mais « échouée » désigne un échec explicitement renvoyé par le serveur, pas une nouvelle requête émise après un timeout côté client. Un renvoi après timeout, des clics répétés ou une consommation de file en double créent de nouvelles requêtes facturées.

Les reprises sur limite de débit et erreurs 5xx doivent rester mesurées : ne réessayer que les erreurs réessayables, avec backoff exponentiel, nombre maximal de tentatives et idempotence par identifiant de requête. En cas d'interruption de flux, la facturation de la partie déjà générée dépend de la facture et des explications officielles ; ne faites pas de « l'échec gratuit » une raison de réessayer indéfiniment.

Un autre coût souvent oublié : la main-d'œuvre engagée pour économiser des appels. Journaux, supervision, évaluation et revue humaine sont des coûts. Réduire le coût se juge sur le total, pas sur le seul prix unitaire.

7. Estimer le budget mensuel à partir des journaux réels

Ne devinez pas le budget. Procédez dans cet ordre :

  1. Exportez les journaux de requêtes des 7 derniers jours depuis la passerelle ou la facturation Bailian, avec au minimum l'ID de modèle, les tokens d'entrée, les tokens de sortie, le hit de cache et le mode Batch.
  2. Groupez par modèle et palier de contexte, puis calculez le nombre de requêtes et les tokens moyens de chaque groupe.
  3. Appliquez la formule avec les tarifs de la page actuelle, en tenant compte du palier appliqué à toute la requête pour le contexte long.
  4. Multipliez par 30 jours, puis ajoutez une marge de 10 à 20 % pour les reprises et les variations.
  5. Faites un bilan mensuel et réestimez après toute mise à niveau de modèle ou refonte de prompt.

Si l'équipe appelle plusieurs fournisseurs, inscrivez-vous sur ZSQH AI Gateway pour consulter soldes et usage de façon unifiée ; les tarifs unitaires restent ceux de la page Tarifs des modèles.

8. Ordre de réduction des coûts

Par ordre de rapport entre effort et résultat, la séquence est généralement la suivante :

  1. Quantifier d'abord : sans journaux au niveau requête, toute optimisation relève de la supposition.
  2. Choisir le bon palier : faire descendre les tâches simples vers Flash, ne pas utiliser Max pour classifier.
  3. Compresser les entrées : recherche, résumé et troncature de l'historique sont plus efficaces qu'un changement de modèle.
  4. Limiter les sorties : fixer max_tokens et exiger une sortie structurée.
  5. Stabiliser le préfixe : améliorer le taux de cache, mais vérifier d'abord le coût de création du cache.
  6. Passer par Batch hors ligne : annotation, résumé et nettoyage peuvent attendre.
  7. Contrôler les reprises : backoff, idempotence, déduplication ; ne pas transformer une panne en facture doublée.
  8. Configurer des alertes budgétaires : seuils par projet, par clé et par modèle.

9. Questions fréquentes

Quel est le lien entre l'API Qwen, Bailian et DashScope ?

Bailian est la plateforme de grands modèles d'Alibaba Cloud, Model Studio en est le nom international, et DashScope le nom de la couche API et SDK. Dire « appeler l'API Qwen » signifie généralement appeler un modèle via l'interface compatible DashScope ou l'interface compatible OpenAI de Bailian.

Pourquoi le contexte long renchérit-il toute la requête ?

Parce que le palier tarifaire est déterminé par le total de tokens d'entrée d'une requête : une fois le palier haut atteint, l'ensemble des entrées et sorties de cette requête est facturé à ce tarif, et non seulement le dépassement. Découper une entrée de 33K en deux requêtes de 16K peut coûter moins cher qu'une seule de 33K, à condition de vérifier que le découpage ne dégrade pas le résultat.

Peut-on combiner cache et Batch ?

En général, non. La grille officielle indique que les deux options sont exclusives. Pour les tâches hors ligne, privilégiez Batch ; pour les appels en ligne fréquents à préfixe stable, privilégiez le cache.

Les requêtes échouées sont-elles facturées ?

La documentation officielle indique qu'une requête échouée n'est pas facturée. Mais un renvoi après timeout côté client, une soumission en double ou une reprise après interruption de flux peuvent créer de nouvelles requêtes facturées. Utilisez un identifiant de requête et une clé d'idempotence pour distinguer une « reprise » d'une « nouvelle requête ».

Pourquoi ma facture ne correspond-elle pas à mon estimation ?

Quatre causes courantes : palier de contexte non compté, frais de création du cache oubliés, cumul de Batch et du cache, ou requêtes de reprise non intégrées. Rapprochez le champ usage et les identifiants de requête : l'écart se localise généralement sur des requêtes précises.

Étape suivante

Exportez d'abord l'usage réel de la dernière semaine, groupez par modèle et par palier, puis appliquez les tarifs actuels. Pour recharger en yuans et consulter l'usage de plusieurs modèles au même endroit, inscrivez-vous sur ZSQH AI Gateway ; les prix font foi sur la page Tarifs des modèles.

À lire aussi :