Function Compute propose cinq types de fonctions, trois environnements d'exécution et plusieurs types d'instances. Cette rubrique détaille les principales différences entre chaque option afin de vous aider à choisir la combinaison la plus adaptée à votre charge de travail.
Vue d'ensemble de la sélection
Avec Function Compute, sélectionnez des types de fonctions et des environnements d'exécution adaptés à vos scénarios métier et à votre stack technique, puis combinez différents types d'instances pour optimiser les performances et les coûts.
Applications web et services API : Utilisez les Web Functions avec un Custom Runtime. Les Web Functions prennent en charge de nombreux frameworks web populaires et sont accessibles depuis un navigateur ou directement via une URL.
Traitement de fichiers et traitement de flux de données : Utilisez les Event Functions avec un Built-in Runtime. Configurez des déclencheurs d'événements pour intégrer divers services Alibaba Cloud, tels que Object Storage Service (OSS), ApsaraMQ for RocketMQ et Simple Log Service (SLS).
Chatbot, génération texte-image et autres scénarios d'inférence IA : Utilisez les GPU Functions avec un Custom Container. Déployez rapidement des services d'inférence de modèles IA basés sur des images de conteneurs issues de projets IA populaires tels que ComfyUI, RAG et TensorRT.
Tâches asynchrones : Utilisez les Task Functions avec un Built-in Runtime pour gérer les tâches planifiées, le transcodage audio et vidéo, ainsi que d'autres scénarios similaires.
Interpréteur de code, automatisation de navigateur et autres scénarios interactifs : Utilisez les Sandbox Functions avec un Custom Container. Les Sandbox Functions fournissent des instances sandbox persistantes avec maintien de session au niveau de l'instance.
Le Built-in Runtime et le Custom Runtime sont tous deux déployés sous forme de packages de code et conviennent aux applications légères.
Pour les déploiements conteneurisés, choisissez le Custom Container. Les GPU Functions ne prennent en charge que le Custom Container.
Sélection du type de fonction
|
Event Function |
Web Function |
Task Function |
GPU Function |
Sandbox Function |
|
|
Description |
Traite les fichiers et les flux de données déclenchés par des événements de services cloud, tels que les déclencheurs OSS, les déclencheurs Kafka et les déclencheurs SLS. |
Prend en charge les frameworks web populaires. Accessible depuis un navigateur ou directement via une URL. |
Traite les requêtes asynchrones. Suit et enregistre l'état de chaque étape d'une invocation asynchrone. |
Exécute des images de conteneurs issues de projets IA populaires tels que Stable Diffusion WebUI, ComfyUI, RAG et TensorRT. |
Fournit des instances sandbox persistantes avec maintien de session basé sur la session pour les environnements d'exécution interactifs. |
|
Cas d'utilisation |
Intégration de services cloud : Traitement de fichiers en temps réel avec OSS, traitement des journaux avec Simple Log Service (SLS). Traitement ETL des données : Nettoyage de base de données, traitement de files d'attente de messages. |
Frameworks web populaires : SpringBoot, Express, Flask et bien d'autres. Migration d'applications existantes : Sites web HTML5, API REST, Backend for Frontend (BFF), applications mobiles, mini-programmes, règlements de jeux, etc. |
Tâches polyvalentes : Tâches planifiées, périodiques et scriptées. Traitement multimédia : Transcodage vidéo, enregistrement en direct, traitement d'images. |
Inférence traditionnelle : Vision par ordinateur (CV) et traitement du langage naturel (NLP). Inférence de modèles AIGC : Génération texte-texte, texte-image et texte-audio. |
Interpréteur de code : Exécution de code et analyse de données. Automatisation de navigateur : Scraping web et tests d'interface utilisateur. Exécution d'outils d'agent IA : Fournit des environnements d'exécution sécurisés pour les appels d'outils de grands modèles. |
|
Environnement d'exécution recommandé |
Uniquement Custom Container |
Uniquement Custom Container |
|||
|
Désactivé par défaut |
Désactivé par défaut |
Activé par défaut |
Désactivé par défaut |
Sans objet |
|
|
Idéal pour |
L'intégration avec les services Alibaba Cloud via des déclencheurs d'événements |
La création et la migration d'applications web et d'API |
Les travaux de longue durée nécessitant un suivi d'état |
Les charges de travail d'inférence IA/ML nécessitant une accélération GPU |
Les charges de travail interactives nécessitant des instances persistantes avec maintien de session |
Sélection de l'environnement d'exécution
|
Built-in Runtime |
Custom Runtime |
Custom Container |
|
|
Flux de développement |
Écrivez un gestionnaire de requêtes en utilisant les interfaces définies par Function Compute. |
Développez avec un modèle de framework web et visualisez instantanément le résultat sur un endpoint public. |
Téléchargez une image personnalisée vers Alibaba Container Registry (ACR) pour le déploiement, ou utilisez une image existante dans ACR. |
|
Types d'instances pris en charge |
Instances CPU |
Instances CPU |
Instances CPU et instances GPU |
|
Non pris en charge |
Pris en charge |
Pris en charge |
|
|
Le plus rapide — le package de code exclut l'environnement d'exécution. |
Rapide — le package de code (un serveur HTTP) est plus volumineux, mais ne nécessite aucun tirage d'image. |
Plus lent — nécessite le tirage d'une image lors du démarrage à froid. |
|
|
Format du package de code |
ZIP, JAR (Java) ou dossier |
Image de conteneur |
|
|
500 Mo dans certaines régions (telles que Hangzhou) ; 100 Mo dans les autres régions. Utilisez les Layers pour ajouter des dépendances et réduire la taille du package. |
Image d'instance CPU : 10 Go non compressée. Image d'instance GPU : 15 Go non compressée. Pour l'inférence IA, stockez les grands modèles dans NAS ou OSS afin de réduire la taille de l'image. |
||
|
Langages pris en charge |
Node.js, Python, PHP, Java, C#, Go |
Aucune restriction |
Aucune restriction |
|
Idéal pour |
Les fonctions légères utilisant les langages pris en charge avec les démarrages à froid les plus rapides |
Les applications web et les API utilisant n'importe quel framework |
Les charges de travail GPU et les déploiements conteneurisés |
Sélection du type d'instance
Les fonctions CPU ne prennent en charge que les Elastic Instances. Les GPU Functions prennent en charge trois types d'instances, entre lesquels vous pouvez basculer à tout moment sans interruption de service.
Guide de décision
Répondez aux questions suivantes pour identifier le type d'instance approprié :
Votre charge de travail est-elle sensible à la latence et interactive ? Par exemple, un chatbot en temps réel ou une API de génération d'images. Si oui, utilisez des Provisioned Instances pour éliminer les démarrages à froid et garantir les temps de réponse.
Votre trafic suit-il une ligne de base prévisible avec des pics occasionnels ? Si oui, utilisez le mode mixte (Provisioned + Elastic Instances) pour maintenir une capacité de base stable tout en absorbant les pics de trafic.
Votre trafic est-il variable, sujet à des pics ou de faible fréquence ? Si oui, utilisez des Elastic Instances et payez uniquement pour l'utilisation active.
Comparaison des types d'instances
|
Elastic Instance |
Provisioned Instance |
Provisioned + Elastic (Mode mixte) |
|
|
S'applique à |
Fonctions CPU (seule option) ; GPU Functions |
Uniquement les GPU Functions |
Uniquement les GPU Functions |
|
Démarrage à froid |
Oui, si le nombre minimum d'instances est égal à 0. Définissez le nombre minimum d'instances à 1 ou plus pour pré-allouer les ressources et réduire les démarrages à froid. |
Aucun. Toutes les requêtes dans la capacité allouée obtiennent une réponse en temps réel. |
Partiel. Les requêtes traitées dans le pool de ressources dédié ne subissent pas de démarrage à froid ; les instances mises à l'échelle de manière élastique, si. |
|
Modèle de facturation |
Paiement à l'utilisation |
Abonnement |
Abonnement (partie provisionnée) + paiement à l'utilisation (partie élastique) |
|
Idéal pour |
Trafic variable ou de faible fréquence ; charges de travail sensibles aux coûts |
Charges de travail sensibles à la latence ou au trafic stable |
Charges de travail avec une ligne de base prévisible et des pics de trafic imprévisibles |
Elastic Instance
Les Elastic Instances s'adaptent automatiquement au volume de requêtes et sont libérées lorsqu'elles sont inactives. La définition du nombre minimum d'instances à 0 vous offre un modèle de pur paiement à l'utilisation : vous ne payez que pour l'utilisation active.
Comportement de démarrage à froid : Les démarrages à froid se produisent lorsque les instances passent de zéro à une valeur supérieure. Pour réduire la latence de démarrage à froid, définissez le nombre minimum d'instances à 1 ou plus. Cela permet de pré-allouer des ressources élastiques afin que les instances soient prêtes à traiter rapidement les requêtes entrantes.
Facturation : Les coûts incluent les frais pour les instances dans les états actif et Shallow Hibernation. En Shallow Hibernation, les ressources vCPU ne sont pas facturées et les ressources GPU sont facturées au cinquième du tarif actif. Si vous définissez le nombre minimum d'instances à 1 ou plus, activez la Shallow Hibernation pour réduire les coûts liés à l'inactivité.
Utilisez les Elastic Instances lorsque :
Votre trafic est variable, sujet à des pics ou de faible fréquence
Vous souhaitez payer uniquement pour l'utilisation réelle
Votre charge de travail peut tolérer une latence occasionnelle de démarrage à froid (ou vous l'atténuez avec un nombre minimum d'instances)
Provisioned Instance
Les Provisioned Instances s'appliquent uniquement aux GPU Functions. Achetez à l'avance un pool de ressources dédié (anciennement pool de ressources résident), puis allouez un nombre et un type spécifiques d'instances à votre fonction. Cela élimine les démarrages à froid dans votre capacité allouée et vous offre des coûts fixes et prévisibles.
Comportement de démarrage à froid : Aucun. Toutes les requêtes dans votre capacité allouée reçoivent une réponse en temps réel. Le nombre maximal de requêtes concurrentes = (Nombre d'instances provisionnées allouées) × (Concurrence de l'instance). Les requêtes dépassant cette limite sont limitées en débit.
Facturation : Frais d'abonnement totaux pour tous les pools de ressources dédiés achetés .
Les Provisioned Instances sont disponibles uniquement pour les GPU Functions des séries Ada, Ada.2, Ada.3, Hopper ou Xpu.1.
Utilisez les Provisioned Instances lorsque :
Votre charge de travail est sensible à la latence et interactive (par exemple, un chatbot en temps réel ou une API de génération d'images)
Votre trafic est stable et prévisible
Vous avez besoin d'une capacité garantie et de temps de réponse cohérents
Instances Provisioned + Elastic (Mode mixte)
Le mode mixte s'applique uniquement aux GPU Functions. Il combine les instances Provisioned et Elastic : le pool de ressources dédié gère d'abord le trafic en état stable, et les instances élastiques s'ajustent automatiquement lorsque les requêtes dépassent la capacité du pool de ressources dédié. Cela vous offre une ligne de base garantie avec la flexibilité nécessaire pour absorber les pics de trafic soudains.
Comportement de démarrage à froid : Partiel. Les requêtes traitées dans le pool de ressources dédié ne subissent pas de démarrage à froid. Les requêtes qui déclenchent une mise à l'échelle automatique vers de nouvelles instances élastiques connaissent un démarrage à froid.
Facturation : La partie provisionnée est facturée selon le quota de votre pool de ressources dédié acheté. Les instances élastiques lancées au-delà du quota du pool de ressources dédié sont facturées selon le modèle de paiement à l'utilisation, aux mêmes tarifs que les instances élastiques actives et en Shallow Hibernation.
Utilisez le mode mixte lorsque :
Votre trafic présente une ligne de base prévisible mais des pics occasionnels
Vous souhaitez des performances stables pour la charge normale avec la capacité de gérer le trafic en pic
Vous avez besoin d'un équilibre entre la prévisibilité des coûts et la flexibilité de mise à l'échelle