Function Compute:Descripción general de facturación

Trial quota

Function Compute ofrece una cuota de prueba (un plan de recursos de prueba de CU) para los usuarios nuevos. Si no ha adquirido otros tipos de planes de recursos, cualquier uso que supere la cuota de prueba en cada ciclo de facturación se cobra bajo el modelo pay-as-you-go.

Pay-as-you-go

El cobro se basa en los recursos de cómputo que consume realmente. De forma predeterminada, cuando el recuento mínimo de instancias es 0, no se aplican cargos si no hay invocaciones de funciones. Sin embargo, si establece el recuento mínimo de instancias en 1 o más, las instancias permanecen en ejecución las 24 horas del día, los 7 días de la semana, y generan cargos de manera continua: los periodos de procesamiento de solicitudes se facturan a la tarifa de instancia elástica (activa) y los periodos inactivos (sin solicitudes pendientes) se facturan a la tarifa de instancia elástica (inactiva). Para obtener más información, consulte @xref node="4423430" Configure an elastic policy for the minimum instance count @/xref .

Resource plans

Function Compute ofrece planes de recursos de CU con niveles mensuales y anuales. Después de adquirir un plan de recursos, este compensa primero su consumo de recursos. Cuando el plan se agota, la facturación cambia automáticamente al modelo pay-as-you-go. Los planes de recursos ofrecen un precio unitario más bajo, lo que reduce sus costos generales.

Resident resource pools (subscription)

Un pool de recursos residente reserva capacidad de cómputo de GPU mediante una suscripción mensual. Adquiera un pool, asigne instancias residentes a sus funciones de GPU y obtenga costos predecibles sin arranques en frío.

Elementos facturables

Los cargos de Function Compute constan de dos partes:

• Uso de CU: Function Compute utiliza el uso de CU como elemento facturable unificado. Todo el uso de recursos se convierte a uso de CU mediante factores de conversión fijos. Este tema se centra en cómo se mide y factura el uso de CU.

• Tráfico saliente de Internet: El tráfico saliente de Internet se agrega con otros productos de Alibaba Cloud orientados a Internet y se factura en CDT. Para obtener más información, consulte CDT billing. El tráfico saliente de Internet consta de las tres partes siguientes:

  1. Tráfico de transferencia de datos dentro de las funciones: el tráfico generado cuando una función inicia una solicitud hacia Internet.

  2. Tráfico de solicitud-respuesta de la función: el tráfico generado cuando se invoca una función a través de Internet y esta devuelve una respuesta.

  3. Tráfico back-to-origin desde CDN: el tráfico generado cuando Function Compute actúa como servidor de origen para un CDN y ocurre una recuperación back-to-origin del CDN.

Precios unitarios

El uso de CU se factura por niveles mensuales y se calcula de forma independiente por región. El uso de CU en cada región se acumula por separado y no se combina entre regiones. Para obtener más información, consulte Billing examples.

Ciclo de facturación

Function Compute factura por hora. El uso de CU por función y por hora se redondea hacia arriba y luego se suma entre todas las funciones para obtener el uso total de CU por hora. Si cuenta con un plan de recursos, este compensa primero el uso de CU. Una vez que el plan se agota, se aplica la facturación pay-as-you-go.

Fórmula de cálculo

Todo el uso de recursos se convierte a uso de CU mediante factores de conversión fijos y luego se suma para obtener el uso total de CU.

Uso de CU = Σ(uso de recursos x factor de conversión de CU)

Uso de recursos

Las instancias elásticas tienen dos estados: activa e inactiva. Cuando una instancia no tiene solicitudes que procesar ni tareas en segundo plano en ejecución, entra automáticamente en estado inactivo. A continuación se describen los escenarios correspondientes a cada estado:

Umbrales para determinar el estado activo e inactivo

El sistema utiliza los indicadores siguientes para determinar si una instancia entró en estado inactivo. Todas las condiciones deben cumplirse de manera simultánea:

• Utilización de CPU: cuando la utilización de vCPU de la instancia cae de forma continua por debajo de 0.01 núcleos de vCPU (equivalente al 1 % de utilización de un solo núcleo), se cumple la condición de CPU para el estado inactivo.

• Utilización de GPU: cuando los procesadores de flujo, los decodificadores y otros componentes de la GPU de la instancia caen por debajo del umbral del sistema, se cumple la condición de GPU para el estado inactivo. El umbral varía según la serie de GPU.

• Tráfico de red: cuando el tráfico de red entrante y saliente de la instancia cae de forma continua por debajo de 1,000 bytes/segundo, se cumple la condición de red para el estado inactivo.

• Procesamiento de solicitudes: la instancia no procesa ninguna solicitud HTTP ni tarea en segundo plano.

El tiempo activo y el tiempo inactivo no se muestran directamente en los registros de invocación. La lista Invocation Requests de la página Logs de la consola muestra campos como la duración de ejecución y el uso de memoria, pero no indica el tiempo activo o inactivo de una instancia. Para consultar la duración de ejecución de una solicitud, habilite las métricas a nivel de solicitud en la configuración de la función y luego revise la duración de ejecución en la lista Invocation Requests de la página Logs.

Resource usage = elastic instance (active) usage + elastic instance (idle) usage. Cuando una instancia está inactiva, el sistema congela automáticamente algunos recursos y cobra a la tarifa mínima de mantenimiento:

• Recursos de vCPU: sin cargo.

• Recursos de GPU: se cobran entre el 11.7 % y el 23 % de la tarifa activa, según la serie de GPU:

  Serie Ada.1	Serie Ada.2	Serie Ada.3	Serie Tesla	Serie Hopper	Serie Hopper.1	Serie Hopper.2	Serie Ampere	Serie Blackwell.1	Serie Xpu.1
  11.7%	11.7%	11.7%	23%	13%	14%	14%	16%	13%	19%

Establecer el recuento mínimo de instancias en 1 o más resulta adecuado para cargas de trabajo sensibles a la latencia (afinidad de sesión, conexiones persistentes, etc.) y para escenarios con tareas en segundo plano. Esto proporciona los beneficios siguientes:

• Arranque en caliente: logra arranques en caliente a nivel de milisegundos para mantener los servicios en ejecución sin interrupciones.

• Entrega garantizada: bloquea recursos elásticos para garantizar la disponibilidad de recursos.

• Facturación inteligente para periodos activos e inactivos: cambia automáticamente a la facturación inactiva cuando no hay solicitudes ni tareas en segundo plano, lo que reduce aún más los costos.

Facturación de llamadas en escenarios de afinidad de sesión MCP

Cuando despliega un MCP Server en Function Compute y habilita la afinidad de sesión para Streamable HTTP, la solicitud initialize y la solicitud posterior tools/call del protocolo MCP son solicitudes HTTP independientes, y cada una desencadena una llamada de función de FC distinta. Cada llamada se factura de forma independiente según su uso real de CU. Como resultado, una sola llamada de herramienta (initialize + tools/call) genera 2 llamadas de función. La solicitud initialize suele desencadenar un arranque en frío, y las solicitudes posteriores reutilizan la misma instancia, aunque se siguen facturando como llamadas independientes.

Factores de conversión de CU

Facturación de códigos de estado de error

El uso de CU depende de si una solicitud llega a una instancia de función y la instancia se ejecuta, no del código de estado HTTP que devuelve la función. Después de que una solicitud llega a una instancia de función y la función se ejecuta, la invocación se factura según el tiempo de ejecución real y el consumo de recursos, sin importar si la función devuelve 200, 404, 401 o cualquier otro código de estado HTTP.

Si una solicitud se rechaza en la capa de puerta de enlace antes de llegar a una instancia de función (por ejemplo, un 404 devuelto porque no se configuró ningún HTTP trigger), no se ejecuta ninguna instancia de función y no se genera uso de CU.