Function Compute:Visão geral do faturamento

Trial quota

O Function Compute oferece uma cota de teste (um plano de recursos de teste de CU) para novos usuários. Caso você não tenha adquirido outros tipos de planos de recursos, qualquer uso que exceda a cota de teste em cada ciclo de faturamento será cobrado no modelo de pagamento conforme o uso.

Pay-as-you-go

A cobrança ocorre com base nos recursos de computação efetivamente consumidos. Por padrão, quando a contagem mínima de instâncias é 0, não há cobrança se nenhuma função for invocada. No entanto, se você definir a contagem mínima de instâncias como 1 ou mais, as instâncias permanecem em execução 24 horas por dia, 7 dias por semana, gerando cobranças contínuas: os períodos de processamento de solicitações são faturados pela tarifa de instância elástica (ativa), enquanto os períodos ociosos (sem solicitações pendentes) seguem a tarifa de instância elástica (ociosa). Para mais informações, consulte @xref node="4423430" Configure an elastic policy for the minimum instance count @/xref .

Resource plans

O Function Compute disponibiliza planos de recursos de CU nas modalidades mensal e anual. Após a aquisição de um plano de recursos, ele compensa primeiro o consumo de recursos. Quando o plano se esgota, o faturamento muda automaticamente para pagamento conforme o uso. Os planos de recursos oferecem preços unitários menores, o que reduz seus custos gerais.

Resident resource pools (subscription)

Um pool de recursos residentes reserva capacidade de computação GPU por meio de uma assinatura mensal. Adquira um pool, atribua instâncias residentes às suas funções GPU e obtenha custos previsíveis com zero cold starts.

Itens faturáveis

As cobranças do Function Compute consistem em duas partes:

• Uso de CU: O Function Compute utiliza o uso de CU como item faturável unificado. Todo o uso de recursos é convertido em uso de CU mediante fatores de conversão fixos. Este tópico foca na medição e no faturamento do uso de CU.

• Tráfego de saída para a Internet: O tráfego de saída para a Internet é agregado a outros produtos da Alibaba Cloud voltados para a Internet e faturado pelo CDT. Para mais informações, consulte CDT billing. O tráfego de saída para a Internet compõe-se das três partes seguintes:

  1. Tráfego de transferência de dados dentro das funções: tráfego gerado quando uma função inicia uma solicitação para a Internet.

  2. Tráfego de solicitação-resposta da função: tráfego gerado quando uma função é invocada pela Internet e retorna uma resposta.

  3. Tráfego back-to-origin do CDN: tráfego gerado quando o Function Compute atua como servidor de origem para um CDN e ocorre a recuperação back-to-origin do CDN.

Preços unitários

O uso de CU é faturado mensalmente por níveis e calculado independentemente por região. O uso de CU em cada região é acumulado separadamente e não é mesclado entre regiões. Para mais informações, consulte Billing examples.

Ciclo de faturamento

O Function Compute emite faturas por hora. O uso de CU por função por hora é arredondado para cima e depois somado entre todas as funções para produzir o uso total de CU por hora. Se você possuir um plano de recursos, ele compensa primeiro o uso de CU. Após o esgotamento do plano, aplica-se o faturamento de pagamento conforme o uso.

Fórmula de cálculo

Todo o uso de recursos é convertido em uso de CU usando fatores de conversão fixos e depois somado para obter o uso total de CU.

Uso de CU = Σ(uso de recursos x fator de conversão de CU)

Uso de recursos

As instâncias elásticas possuem dois estados: ativa e ociosa. Quando uma instância não tem solicitações para processar ou tarefas em segundo plano em execução, ela entra automaticamente no estado ocioso. A tabela a seguir descreve os cenários para cada estado:

Limiares para determinação dos estados ativo e ocioso

O sistema usa os seguintes indicadores para determinar se uma instância entrou no estado ocioso. Todas as condições devem ser atendidas simultaneamente:

• Utilização de CPU — Quando a utilização de vCPU da instância cai continuamente abaixo de 0,01 núcleos de vCPU (equivalente a 1% de utilização de um único núcleo), a condição de CPU para o estado ocioso é satisfeita.

• Utilização de GPU — Quando os processadores de fluxo, decodificadores e outros componentes da GPU da instância ficam abaixo do limiar do sistema, a condição de GPU para o estado ocioso é satisfeita. O limiar varia conforme a série da GPU.

• Tráfego de rede — Quando o tráfego de rede de entrada e saída da instância cai continuamente abaixo de 1.000 bytes/segundo, a condição de rede para o estado ocioso é satisfeita.

• Processamento de solicitações — A instância não está processando nenhuma solicitação HTTP ou tarefa em segundo plano.

O tempo ativo e o tempo ocioso não aparecem diretamente nos logs de invocação. A lista Invocation Requests na página Logs do console mostra campos como duração da execução e uso de memória, mas não exibe o tempo ativo ou ocioso de uma instância. Para visualizar a duração da execução de uma solicitação, ative as métricas no nível da solicitação na configuração da função e verifique a duração da execução na lista Invocation Requests na página Logs.

Resource usage = elastic instance (active) usage + elastic instance (idle) usage. Quando uma instância está ociosa, o sistema congela automaticamente alguns recursos e cobra pela tarifa mínima de keep-alive:

• Recursos de vCPU: Sem cobrança.

• Recursos de GPU: Cobrança de 11,7% a 23% da tarifa ativa, dependendo da série da 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%

Definir a contagem mínima de instâncias como 1 ou superior é adequado para cargas de trabalho sensíveis à latência (afinidade de sessão, conexões persistentes, etc.) e cenários de tarefas em segundo plano. Isso proporciona os seguintes benefícios:

• Warm start: Alcança warm starts no nível de milissegundos para manter os services em execução sem interrupções.

• Entrega garantida: Bloqueia recursos elásticos para garantir a disponibilidade de recursos.

• Faturamento inteligente para períodos ocupados e ociosos: Muda automaticamente para o faturamento ocioso quando não há solicitações ou tarefas em segundo plano, reduzindo ainda mais os custos.

Faturamento de chamadas em cenários de afinidade de sessão MCP

Ao implantar um MCP Server no Function Compute e ativar a afinidade de sessão para Streamable HTTP, a solicitação initialize e a subsequente solicitação tools/call no protocolo MCP são solicitações HTTP separadas, e cada uma delas aciona uma chamada de função FC distinta. Cada chamada é faturada independentemente com base no seu uso real de CU. Como resultado, uma única chamada de ferramenta (initialize + tools/call) gera 2 chamadas de função. A solicitação initialize geralmente aciona um cold start, e as solicitações subsequentes reutilizam a mesma instância, mas ainda são faturadas como chamadas independentes.

Fatores de conversão de CU

Faturamento para códigos de status de erro

O uso de CU baseia-se no fato de uma solicitação chegar a uma instância de função e a instância executar, e não no código de status HTTP retornado pela função. Depois que uma solicitação chega a uma instância de função e a função é executada, a invocação é faturada com base no tempo real de execução e no consumo de recursos, independentemente de a função retornar 200, 404, 401 ou qualquer outro código de status HTTP.

Se uma solicitação for rejeitada na camada de gateway antes de chegar a uma instância de função — por exemplo, um 404 retornado porque nenhum HTTP trigger está configurado — nenhuma instância de função será executada e nenhum uso de CU será incorrido.