Function Compute:Présentation de la facturation

Quota d'essai

Function Compute propose un quota d'essai (un plan de ressources d'essai en CU) aux nouveaux utilisateurs. Si vous n'avez pas acheté d'autres types de plans de ressources, toute utilisation dépassant le quota d'essai au cours de chaque cycle de facturation est facturée selon le modèle de paiement à l'utilisation.

Paiement à l'utilisation

La facturation est basée sur les ressources de calcul que vous consommez réellement. Par défaut, lorsque le nombre minimal d'instances est défini sur 0, aucun frais ne s'applique en l'absence d'appels de fonction. Toutefois, si vous définissez le nombre minimal d'instances sur 1 ou plus, les instances restent actives 24 h/24 et 7 j/7, ce qui entraîne une facturation continue : les périodes de traitement des requêtes sont facturées au tarif des instances élastiques (actives), tandis que les périodes d'inactivité (sans requête en attente) sont facturées au tarif des instances élastiques (inactives). Pour plus d'informations, consultez [Configurer une politique élastique pour le nombre minimal d'instances]().

Plans de ressources

Function Compute propose des plans de ressources en CU avec des engagements mensuels ou annuels. Après l'achat d'un plan de ressources, celui-ci compense en priorité votre consommation de ressources. Lorsque le plan est épuisé, la facturation bascule automatiquement vers le modèle de paiement à l'utilisation. Les plans de ressources offrent des prix unitaires plus avantageux, ce qui réduit vos coûts globaux.

Pools de ressources résidentes (abonnement)

Un pool de ressources résidentes réserve une capacité de calcul GPU via un abonnement mensuel. Achetez un pool, assignez des instances résidentes à vos fonctions GPU et bénéficiez de coûts prévisibles sans démarrage à froid.

Éléments facturables

La facturation de Function Compute se compose de deux parties :

• Utilisation des CU : Function Compute utilise l'utilisation des CU comme élément de facturation unifié. Toute l'utilisation des ressources est convertie en utilisation des CU à l'aide de facteurs de conversion fixes. Cette rubrique se concentre sur la manière dont l'utilisation des CU est mesurée et facturée.

• Trafic Internet sortant : Le trafic Internet sortant est agrégé avec d'autres produits Alibaba Cloud exposés à Internet et facturé via CDT. Pour plus d'informations, consultez Facturation CDT. Le trafic Internet sortant comprend les trois éléments suivants :

  1. Trafic de transfert de données au sein des fonctions : trafic généré lorsqu'une fonction initie une requête vers Internet.

  2. Trafic de requête-réponse de fonction : trafic généré lorsqu'une fonction est appelée via Internet et renvoie une réponse.

  3. Trafic de retour à l'origine depuis CDN : trafic généré lorsque Function Compute sert de serveur d'origine pour un CDN et qu'un récupération de contenu vers l'origine (back-to-origin) se produit.

Prix unitaires

L'utilisation des CU est facturée selon des paliers mensuels et calculée indépendamment par région. L'utilisation des CU dans chaque région est accumulée séparément et n'est pas fusionnée entre les régions. Pour plus d'informations, consultez Exemples de facturation.

Cycle de facturation

Function Compute facture sur une base horaire. L'utilisation des CU par fonction et par heure est arrondie à l'entier supérieur, puis additionnée pour toutes les fonctions afin d'obtenir l'utilisation totale des CU par heure. Si vous disposez d'un plan de ressources, celui-ci compense en premier lieu l'utilisation des CU. Une fois le plan épuisé, la facturation selon le modèle de paiement à l'utilisation s'applique.

Formule de calcul

Toute l'utilisation des ressources est convertie en utilisation de CU à l'aide de facteurs de conversion fixes, puis additionnée pour obtenir l'utilisation totale des CU.

Utilisation des CU = Σ (utilisation des ressources x facteur de conversion CU)

Utilisation des ressources

Les instances élastiques présentent deux états : actif et inactif. Lorsqu'une instance ne traite aucune requête et n'exécute aucune tâche en arrière-plan, elle passe automatiquement à l'état inactif. Le tableau suivant décrit les scénarios associés à chaque état :

Seuils de détermination des états actif et inactif

Le système utilise les indicateurs suivants pour déterminer si une instance est passée à l'état inactif. Toutes les conditions doivent être remplies simultanément :

• Utilisation du CPU — Lorsque l'utilisation des vCPU de l'instance reste continuellement inférieure à 0,01 cœur vCPU (équivalent à 1 % d'utilisation d'un seul cœur), la condition CPU pour l'état inactif est satisfaite.

• Utilisation du GPU — Lorsque les processeurs de flux, les décodeurs et autres composants GPU de l'instance descendent en dessous du seuil système, la condition GPU pour l'état inactif est satisfaite. Ce seuil varie selon la série de GPU.

• Trafic réseau — Lorsque le trafic réseau entrant et sortant de l'instance reste continuellement inférieur à 1 000 octets/seconde, la condition réseau pour l'état inactif est satisfaite.

• Traitement des requêtes — L'instance ne traite aucune requête HTTP ni aucune tâche en arrière-plan.

Le temps actif et le temps inactif ne sont pas affichés directement dans les journaux d'appel. La liste Invocation Requests de la page Logs de la console affiche des champs tels que la durée d'exécution et l'utilisation de la mémoire, mais n'indique pas le temps actif ou inactif d'une instance. Pour afficher la durée d'exécution d'une requête, vous pouvez activer les métriques au niveau de la requête dans la configuration de la fonction, puis vérifier la durée d'exécution dans la liste Invocation Requests de la page Logs.

Utilisation des ressources = utilisation de l'instance élastique (active) + utilisation de l'instance élastique (inactive). Lorsqu'une instance est inactive, le système gèle automatiquement certaines ressources et applique un tarif de maintien minimal :

• Ressources vCPU : aucune facturation.

• Ressources GPU : facturées entre 11,7 % et 23 % du tarif actif selon la série de GPU :

  Série Ada.1	Série Ada.2	Série Ada.3	Série Tesla	Série Hopper	Série Hopper.1	Série Hopper.2	Série Ampere	Série Blackwell.1	Série Xpu.1
  11,7 %	11,7 %	11,7 %	23 %	13 %	14 %	14 %	16 %	13 %	19 %

La définition du nombre minimal d'instances sur 1 ou plus convient aux charges de travail sensibles à la latence (affinité de session, connexions persistantes, etc.) et aux scénarios de tâches en arrière-plan. Cette configuration offre les avantages suivants :

• Démarrage à chaud : permet des démarrages à chaud de l'ordre de la milliseconde pour assurer la continuité des services.

• Livraison garantie : verrouille les ressources élastiques pour garantir leur disponibilité.

• Facturation intelligente pour les périodes d'activité et d'inactivité : bascule automatiquement vers la facturation inactive en l'absence de requêtes ou de tâches en arrière-plan, ce qui réduit davantage les coûts.

Facturation des appels dans les scénarios d'affinité de session MCP

Lorsque vous déployez un serveur MCP sur Function Compute et activez l'affinité de session pour Streamable HTTP, la requête initialize et la requête suivante tools/call du protocole MCP constituent des requêtes HTTP distinctes, chacune déclenchant un appel de fonction FC séparé. Chaque appel est facturé indépendamment en fonction de son utilisation réelle des CU. Par conséquent, un seul appel d'outil (initialize + tools/call) génère 2 appels de fonction. La requête initialize déclenche généralement un démarrage à froid, et les requêtes suivantes réutilisent la même instance, mais sont toujours facturées comme des appels indépendants.

Facteurs de conversion CU

Facturation des codes d'erreur

L'utilisation des CU dépend du fait qu'une requête atteigne une instance de fonction et que celle-ci s'exécute, et non du code d'état HTTP renvoyé par la fonction. Une fois qu'une requête atteint une instance de fonction et que la fonction s'exécute, l'appel est facturé en fonction du temps d'exécution réel et de la consommation de ressources, quel que soit le code d'état HTTP renvoyé par la fonction (200, 404, 401 ou tout autre code).

Si une requête est rejetée au niveau de la passerelle avant d'atteindre une instance de fonction — par exemple, un code 404 renvoyé car aucun déclencheur HTTP n'est configuré — aucune instance de fonction ne s'exécute et aucune utilisation des CU n'est encourue.