O Function Compute oferece quatro tipos de função, três ambientes de runtime e vários tipos de instância. Este tópico aborda as principais diferenças entre cada opção para ajudar você a escolher a combinação ideal para sua carga de trabalho.
Guia rápido de seleção
|
Carga de trabalho |
Tipo de função |
Runtime |
|
Aplicações web e APIs REST |
Custom Runtime |
|
|
Processamento de arquivos e streams orientado a eventos |
Built-in Runtime |
|
|
Inferência de IA (visão computacional, AIGC) |
Custom Container |
|
|
Tarefas de longa duração e agendadas |
Built-in Runtime |
O Built-in Runtime e o Custom Runtime são implantados como pacotes de código e são mais adequados para aplicações leves. As GPU Functions suportam apenas Custom Container.
Seleção do tipo de função
|
**Event Function** |
**Web Function** |
**Task Function** |
**GPU Function** |
|
|
Descrição |
Processa arquivos e streams de dados acionados por eventos de serviços em nuvem, como OSS triggers, Kafka triggers e SLS triggers. |
Compatível com frameworks web populares. Acessível via navegador ou diretamente por URL. |
Processa requisições assíncronas. Rastreia e salva o estado de cada etapa de uma invocação assíncrona. |
Executa imagens de container de projetos populares de IA, como Stable Diffusion WebUI, ComfyUI, RAG e TensorRT. |
|
Casos de uso |
Integração com serviços em nuvem: processamento de arquivos em tempo real com OSS e processamento de logs com Simple Log Service (SLS). Processamento de dados ETL: limpeza de banco de dados e processamento de filas de mensagens. |
Frameworks web populares:SpringBoot, Express, Flask, entre outros. Migração de aplicações existentes: sites HTML5, APIs REST, Backend for Frontend (BFF), aplicativos móveis, mini programs, liquidação de jogos, etc. |
Tarefas de uso geral: tarefas agendadas, periódicas e scriptadas. Processamento multimídia: transcodificação de vídeo, gravação ao vivo e processamento de imagens. |
Inferência tradicional: visão computacional (CV) e processamento de linguagem natural (NLP). Inferência de modelos AIGC: geração de texto para texto, texto para imagem e texto para áudio. |
|
Runtime recomendado |
Apenas Custom Container |
|||
|
Desativado por padrão |
Desativado por padrão |
Ativado por padrão |
Desativado por padrão |
|
|
Mais indicado para |
Integração com serviços da Alibaba Cloud via gatilhos de eventos |
Criação e migração de aplicações web e APIs |
Jobs de longa duração que exigem rastreamento de estado |
Cargas de trabalho de inferência de IA/ML que requerem aceleração por GPU |
Seleção do ambiente de runtime
|
**Built-in Runtime** |
**Custom Runtime** |
**Custom Container** |
|
|
Fluxo de desenvolvimento |
Escreva um handler de requisição usando as interfaces definidas pelo Function Compute. |
Desenvolva com um modelo de framework web e visualize o resultado em um endpoint público instantaneamente. |
Carregue uma imagem personalizada no Alibaba Container Registry (ACR) e implante-a, ou use uma imagem existente no ACR. |
|
Tipos de instância suportados |
Instâncias de CPU |
Instâncias de CPU |
Instâncias de CPU e instâncias de GPU |
|
Não suportado |
Suportado |
Suportado |
|
|
**Cold start** |
Mais rápido — o pacote de código não inclui o runtime. |
Rápido — o pacote de código (um servidor HTTP) é maior, mas não exige pull de imagem. |
Mais lento — exige pull de imagem no cold start. |
|
Formato do pacote de código |
ZIP, JAR (Java) ou pasta |
— |
Imagem de container |
|
500 MB em selecione regions (como Hangzhou); 100 MB nas demais regiões. Use Layers para adicionar dependências e reduzir o tamanho do pacote. |
— |
Imagem para instância de CPU: 10 GB descompactados. Imagem para instância de GPU: 15 GB descompactados. Para inferência de IA, store large models in NAS or OSS para reduzir o tamanho da imagem. |
|
|
Linguagens suportadas |
Node.js, Python, PHP, Java, C#, Go |
Sem restrições |
Sem restrições |
|
Recomendado para |
Funções leves usando linguagens suportadas com os cold starts mais rápidos |
Aplicações web e APIs usando qualquer framework |
Cargas de trabalho de GPU e implantações em container |
Seleção do tipo de instância
Funções de CPU suportam apenas Elastic Instances. As GPU Functions suportam três tipos de instância, permitindo alternar entre eles a qualquer momento sem interrupção do serviço.
Guia de decisão
Utilize as perguntas abaixo para identificar o tipo de instância adequado:
Sua carga de trabalho é sensível à latência e interativa? Por exemplo, um chatbot em tempo real ou uma API de geração de imagens. Em caso afirmativo, utilize Provisioned Instances para eliminar cold starts e garantir tempos de resposta.
Seu tráfego segue uma linha de base previsível com picos ocasionais? Se sim, opte pelo Mixed Mode (Provisioned + Elastic Instances) para manter uma capacidade de base estável enquanto absorve rajadas de tráfego.
O tráfego é variável, irregular ou de baixa frequência? Nesse cenário, escolha Elastic Instances e pague apenas pelo uso ativo.
Comparação dos tipos de instância
|
**Elastic Instance** |
**Provisioned Instance** |
**Provisioned + Elastic (Mixed Mode)** |
|
|
Aplica-se a |
Funções de CPU (única opção); GPU Functions |
Apenas GPU Functions |
Apenas GPU Functions |
|
Cold start |
Sim, se o mínimo de instâncias for 0. Defina o mínimo de instâncias como 1 ou mais para pré-alocar recursos e reduzir cold starts. |
Nenhum. Todas as requisições dentro da capacidade alocada recebem resposta em tempo real. |
Parcial. Requisições dentro do pool provisionado não têm cold start; instâncias elásticas de scale-out sim. |
|
Modelo de faturamento |
Pagamento conforme o uso |
Assinatura |
Assinatura (parte provisionada) + pagamento conforme o uso (parte elástica) |
|
Ideal para |
Tráfego variável ou de baixa frequência; cargas de trabalho sensíveis a custos |
Cargas de trabalho sensíveis à latência ou com tráfego estável |
Cargas de trabalho com linha de base previsível e rajadas de tráfego imprevisíveis |
Elastic Instance
As Elastic Instances dimensionam automaticamente conforme o volume de requisições e são liberadas quando ociosas. Definir o número mínimo de instâncias como 0 proporciona um modelo puro de pagamento conforme o uso — você paga apenas pelo uso ativo.
Comportamento de cold start: Cold starts ocorrem quando as instâncias escalam a partir de zero. Para reduzir a latência de cold start, defina o número mínimo de instâncias como 1 ou mais. Isso pré-aloca recursos elásticos para que as instâncias estejam prontas para lidar rapidamente com requisições recebidas.
Faturamento: Os custos incluem cobranças por instâncias nos estados ativo e de Shallow Hibernation. Na Shallow Hibernation, recursos de vCPU não são cobrados e recursos de GPU são faturados a um quinto da tarifa ativa. Se você definir o número mínimo de instâncias como 1 ou mais, ative a Shallow Hibernation para reduzir custos de ociosidade.
Use Elastic Instances quando:
Seu tráfego for variável, irregular ou de baixa frequência
Você desejar pagar apenas pelo uso real
Sua carga de trabalho tolerar latência ocasional de cold start (ou você a mitigar com uma contagem mínima de instâncias)
Provisioned Instance
Provisioned Instances aplicam-se apenas a GPU Functions. Adquira um Provisioned Resource Pool antecipadamente e aloque um número e tipo específicos de instâncias para sua função. Isso elimina cold starts dentro da capacidade alocada e oferece custos fixos e previsíveis.
Após adquirir um pool de recursos provisionados mensal, a plataforma fornece uma cota adicional de instâncias boost sem custo extra.
Comportamento de cold start: Nenhum. Todas as requisições dentro da capacidade alocada recebem resposta em tempo real. Máximo de requisições simultâneas = (Number of allocated Provisioned Instances) × (Instance concurrency) + boost instance quota. Requisições que excederem esse limite serão limitadas (throttled).
Faturamento: A taxa total de assinatura para todos os Provisioned Resource Pools adquiridos. Instâncias boost não são faturadas.
Provisioned Instances estão disponíveis apenas para GPU Functions nas séries Ada, Ada.2, Ada.3, Hopper ou Xpu.1.
Use Provisioned Instances quando:
Sua carga de trabalho for sensível à latência e interativa (por exemplo, um chatbot em tempo real ou API de geração de imagens)
Seu tráfego for constante e previsível
Você precisar de capacidade garantida e tempos de resposta consistentes
Provisioned + Elastic Instances (Mixed Mode)
O Mixed Mode aplica-se apenas a GPU Functions. Ele combina Provisioned Instances e Elastic Instances: o pool provisionado lida primeiro com o tráfego de estado estacionário, e as instâncias elásticas escalam automaticamente quando as requisições excedem a capacidade provisionada. Isso garante uma linha de base assegurada com flexibilidade para absorver rajadas repentinas de tráfego.
Comportamento de cold start: Parcial. Requisições tratadas dentro do pool provisionado não têm cold start. Requisições que acionam o auto-scaling para novas instâncias elásticas passam por um cold start.
Faturamento: A parte provisionada é faturada contra sua cota adquirida de Provisioned Resource Pool. Instâncias elásticas lançadas além da cota provisionada são faturadas na modalidade de pagamento conforme o uso, às mesmas tarifas das instâncias elásticas ativas e em Shallow Hibernation.
Adote o Mixed Mode quando:
Seu tráfego tiver uma linha de base previsível, mas com picos ocasionais
Você quiser desempenho estável para carga normal com capacidade de lidar com tráfego em rajada
Você precisar de equilíbrio entre previsibilidade de custos e flexibilidade de dimensionamento