Seleção de tecnologia - Function Compute: Central de Documentação do Alibaba Cloud

O Function Compute oferece cinco 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 escolha a combinação ideal para sua carga de trabalho.

Visão geral da seleção

Ao usar o Function Compute, escolha os tipos de função e ambientes de runtime adequados com base nos seus cenários de negócio e preferências de stack tecnológica. Combine também os tipos de instância para otimizar desempenho e custos.

Aplicações web e service de API: Use Web Functions com Custom Runtime. As Web Functions suportam diversos frameworks populares de aplicações web e permitem acesso via navegador ou invocação direta por URL.
Processamento de arquivos e fluxos de dados: Use Event Functions com Built-in Runtime. Configure gatilhos de eventos para integração com vários service da Alibaba Cloud, como Object Storage Service (oss), ApsaraMQ for RocketMQ e Simple Log Service (SLS).
Chatbot, texto para imagem e outros cenários de inferência de IA: Use GPU Functions com Custom Container. Crie rapidamente service de inferência de modelos de IA baseados em imagens de container de projetos populares, como ComfyUI, RAG e TensorRT.
Tarefas assíncronas: Use Task Functions com Built-in Runtime para gerenciar tarefas agendadas, transcodificação de áudio e vídeo, entre outros cenários.
Code Interpreter, automação de navegador e outros cenários interativos: Use Sandbox Functions com Custom Container. As Sandbox Functions fornecem instâncias de sandbox persistentes com keep-alive de instância no nível de sessão.

Nota

Tanto o Built-in Runtime quanto o Custom Runtime são implantados como pacotes de código e são ideais para aplicações leves.
Para implantações containerizadas, selecione Custom Container. As GPU Functions suportam apenas Custom Container.

Seleção do tipo de função

	Event Function	Web Function	Task Function	GPU Function	Sandbox Function
Descrição	Processa arquivos e fluxos de dados acionados por eventos de service cloud, como OSS triggers, Kafka triggers e SLS triggers.	Suporta 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 de IA populares, como Stable Diffusion WebUI, ComfyUI, RAG e TensorRT.	Fornece instâncias de sandbox persistentes com keep-alive baseado em sessão para ambientes de runtime interativos.
Casos de uso	Integração com service cloud: Processamento de arquivos em tempo real com oss, processamento de logs com Simple Log Service (SLS). Processamento de dados ETL: Limpeza de banco de dados, processamento de filas de mensagens.	Frameworks web populares: SpringBoot, Express, Flask, entre outros. Migração de aplicações existentes: Sites HTML5, API 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, 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.	Code Interpreter: Execução de código e análise de dados. Automação de navegador: Web scraping e testes de UI. Execução de ferramentas de agentes de IA: Fornece ambientes seguros para chamadas de ferramentas de grandes modelos.
Runtime recomendado	Built-in Runtime	Custom Runtime	Built-in Runtime	Apenas Custom Container	Apenas Custom Container
Asynchronous Task	Desativado por padrão	Desativado por padrão	Ativado por padrão	Desativado por padrão	Não aplicável
Mais indicado para	Integração com service da Alibaba Cloud via gatilhos de eventos	Criação e migração de aplicações web e API	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	Cargas interativas que necessitam de instâncias persistentes com keep-alive de sessão

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 instantaneamente em um endpoint público.	Faça upload de uma imagem personalizada para o Alibaba Container Registry (ACR) e implante, 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
Concorrência de instância única	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 — requer pull de imagem durante o cold start.
Formato do pacote de código	ZIP, JAR (Java) ou pasta		Imagem de container
Limite de tamanho do pacote de código	500 MB em select regions (como Hangzhou); 100 MB em outras regiões. Use Layers para adicionar dependências e reduzir o tamanho do pacote.		Imagem de instância de cpu: 10 GB descompactados. Imagem de instância de GPU: 15 GB descompactados. Para inferência de IA, use 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
Mais indicado para	Funções leves usando linguagens suportadas com cold starts mais rápidos	Aplicações web e API usando qualquer framework	Cargas de trabalho de GPU e implantações containerizadas

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 alternância entre eles a qualquer momento sem interrupção do service.

Guia de decisão

Use 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, use 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, use o Modo Misto (Provisioned + Elastic Instances) para manter uma capacidade de base estável enquanto absorve rajadas de tráfego.
Seu tráfego é variável, irregular ou de baixa frequência? Nesse caso, use Elastic Instances e pague apenas pelo uso ativo.

Comparação dos tipos de instância

	Elastic Instance	Provisioned Instance	Provisioned + Elastic (Modo Misto)
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 de recursos dedicado 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)
Mais indicado para	Tráfego variável ou de baixa frequência; cargas sensíveis a custos	Cargas sensíveis à latência ou com tráfego estável	Cargas 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 partem 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 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 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 dedicated resource pool (formerly resident 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.

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 = (Número de Provisioned Instances alocadas) × (Concorrência da instância). Requisições que excederem esse limite serão limitadas (throttled).

Faturamento: Taxa total de assinatura para todos os pools de recursos dedicados adquiridos .

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, 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 (Modo Misto)

O Modo Misto aplica-se apenas a GPU Functions. Ele combina Provisioned e Elastic Instances: o pool de recursos dedicados lida primeiro com o tráfego de estado estacionário, e as instâncias elásticas fazem scale-out automaticamente quando as requisições excedem a capacidade do pool dedicado. 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 de recursos dedicados não sofrem cold start. Requisições que acionam auto-scaling para novas instâncias elásticas passam por um cold start.

Faturamento: A parte provisionada é faturada contra a cota do pool de recursos dedicados adquirido. Instâncias elásticas iniciadas além da cota do pool dedicado são faturadas no modelo de pagamento conforme o uso, às mesmas tarifas das elastic instances ativas e em Shallow Hibernation.

Use o Modo Misto 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 de rajada
Você precisar de equilíbrio entre previsibilidade de custos e flexibilidade de dimensionamento