Function Compute propose cinq types de fonctions, trois environnements d'exécution et plusieurs types d'instances. Cette rubrique présente les principales différences entre chaque option afin de vous aider à choisir la combinaison adaptée à votre charge de travail.
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 conteneur issues de projets d'IA populaires tels que Stable Diffusion WebUI, ComfyUI, RAG et TensorRT. |
Fournit des instances sandbox persistantes avec maintien de session pour les environnements d'exécution interactifs. |
|
Cas d'utilisation |
Intégration aux 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 bases de données, traitement de files d'attente de messages. |
Frameworks web populaires : SpringBoot, Express, Flask et 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 de texte à partir de texte, d'images à partir de texte et d'audio à partir de texte. |
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 pour agents IA : Fournit des environnements d'exécution sécurisés pour les appels d'outils par grands modèles. |
|
Environnement d'exécution recommandé |
Conteneur personnalisé uniquement |
Conteneur personnalisé uniquement |
|||
|
Désactivé par défaut |
Désactivé par défaut |
Activé par défaut |
Désactivé par défaut |
Non applicable |
|
|
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 tâches 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
|
Environnement d'exécution intégré |
Environnement d'exécution personnalisé |
Conteneur personnalisé |
|
|
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 le résultat sur un endpoint public instantanément. |
Téléchargez une image personnalisée vers Alibaba Container Registry (ACR) et déployez-la, 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 n'inclut pas 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 un dossier |
— |
Image de conteneur |
|
500 Mo dans certaines régions (telles que Hangzhou) ; 100 Mo dans les autres régions. Utilisez les couches 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 prennent uniquement en charge les instances élastiques. 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
Utilisez les 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 instances provisionnées pour éliminer les démarrages à froid et garantir les temps de réponse.
Votre trafic suit-il une base prévisible avec des pics occasionnels ? Si oui, utilisez le mode mixte (instances provisionnées + instances élastiques) 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 instances élastiques et payez uniquement pour l'utilisation active.
Comparaison des types d'instances
|
Instance élastique |
Instance provisionnée |
Provisionnée + Élastique (Mode mixte) |
|
|
S'applique à |
Fonctions CPU (seule option) ; GPU Functions |
GPU Functions uniquement |
GPU Functions uniquement |
|
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 dans le pool provisionné n'ont pas de démarrage à froid ; les instances mises à l'échelle de manière élastique en ont un. |
|
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 au coût |
Charges de travail sensibles à la latence ou au trafic stable |
Charges de travail avec une base prévisible et des pics de trafic imprévisibles |
Instance élastique
Les instances élastiques 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 à actif. Pour réduire la latence de démarrage à froid, définissez le nombre minimum d'instances à 1 ou plus. Cela pré-alloue les 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 Hibernation peu profonde. En hibernation peu profonde, 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 l'hibernation peu profonde pour réduire les coûts d'inactivité.
Utilisez des instances élastiques 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)
Instance provisionnée
Les instances provisionnées s'appliquent uniquement aux GPU Functions. Achetez à l'avance un pool de ressources provisionnées, 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.
Après l'achat d'un pool de ressources provisionnées mensuel, la plateforme fournit un quota supplémentaire d'instances boost sans frais supplémentaires.
Comportement de démarrage à froid : Aucun. Toutes les requêtes dans votre capacité allouée reçoivent une réponse en temps réel. Nombre maximal de requêtes simultanées = (Nombre d'instances provisionnées allouées) × (Simultanéité de l'instance) + quota d'instances boost. Les requêtes dépassant cette limite sont limitées.
Facturation : Le frais d'abonnement total pour tous les pools de ressources provisionnées achetés. Les instances boost ne sont pas facturées.
Les instances provisionnées sont disponibles uniquement pour les GPU Functions des séries Ada, Ada.2, Ada.3, Hopper ou Xpu.1.
Utilisez des instances provisionnées 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 provisionnées + élastiques (Mode mixte)
Le mode mixte s'applique uniquement aux GPU Functions. Il combine des instances provisionnées et élastiques : le pool provisionné gère d'abord le trafic en état stable, et les instances élastiques s'ajustent automatiquement lorsque les requêtes dépassent la capacité provisionnée. Cela vous offre une base garantie avec la flexibilité nécessaire pour absorber les pics soudains de trafic.
Comportement de démarrage à froid : Partiel. Les requêtes traitées dans le pool provisionné n'ont pas de démarrage à froid. Les requêtes qui déclenchent la mise à l'échelle automatique vers de nouvelles instances élastiques subissent un démarrage à froid.
Facturation : La partie provisionnée est facturée selon le quota de votre pool de ressources provisionnées acheté. Les instances élastiques lancées au-delà du quota provisionné sont facturées selon le modèle de paiement à l'utilisation, aux mêmes tarifs que les instances élastiques actives et en hibernation peu profonde.
Utilisez le mode mixte lorsque :
Votre trafic présente une 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