Capacidad, SKU y CU: entendiendo el modelo de capacidad de Microsoft Fabric (Parte 1)

Como ingeniero de datos, debes tener un buen entendimiento del impacto de las decisiones que tomas y de lo que construyes dentro de tu plataforma de datos, y cómo eso se relaciona con el costo.

Así que el primer paso es entender cómo funciona el modelo de facturación de Fabric, así como las buenas prácticas que debes aplicar al diseñar tus soluciones ya que esto puede traducirse en tu empresa en una diferencia de miles de dólares.

Cabe mencionar que este modelo de facturación es bastante distinto a lo que quizá estés acostumbrado en otras plataformas como Synapse o Databricks, donde pagas por lo que consume cada trabajo o clúster, mientras que en Fabric compras por adelantado una “bolsa” única de cómputo, donde la capacidad, y todos los motores gastan de esa misma bolsa, mientras esté encendida, la uses mucho o poco.

Por eso en vez de preguntarte ¿cuánto me costó este trabajo?, pasas a preguntarte ¿cabe todo lo que ejecuto dentro de la capacidad que pagué?, y de esa pregunta sale casi todo lo que veremos en esta serie, donde cubriremos qué es una capacidad, un SKU y cómo se relacionan, cómo calcula Microsoft cuánto consumen las operaciones que ejecutas, los tipos de operaciones (background e interactivas), los conceptos de bursting, smoothing, throttling, y cómo mantener tu solución optimizada para que sea lo más costo-efectiva posible.

¿Qué modelos de facturación tiene Microsoft Fabric?

Comencemos hablando de los modelos de facturación que existen:

• El modelo de capacidad: este es el modelo predeterminado y en el que nos enfocaremos en esta serie: compras una cantidad fija de cómputo y todas tus cargas comparten ese presupuesto.
• Autoscale Billing for Spark (anunciado en FabCon 2025): es un modelo de pago por uso solo para cargas Spark, donde los trabajos corren en recursos serverless dedicados y se facturan aparte, de forma similar a Databricks o Synapse.

¿Qué es una capacidad y cómo se relaciona con el SKU y las CU?

La capacidad en Fabric es una cantidad de recursos de cómputo que Microsoft te da para realizar acciones en Fabric como: transformar datos, cargar datos, interactuar con un reporte de Power BI. Todas estas acciones consumen esta capacidad, y ese consumo se mide en algo llamado “unidades de capacidad (CU)”. Debo advertir que el modelo de capacidad puede resultar un poco abstracto, ya que una CU no es una máquina ni un procesador como tal, sino una unidad de medida que representa el cómputo que estás usando.

Antes de seguir, conviene entender cómo se organiza Microsoft Fabric, porque sobre esta estructura se apoyan prácticamente todas las estrategias de optimización de costos que veremos más adelante:

• Tu organización dispone de un tenant de Microsoft Entra ID (habitualmente uno solo).
• Dentro de ese tenant puedes crear tantas capacidades como necesites. Cada una es un recurso de cómputo dedicado que no se comparte con otros clientes.
• A cada workspace se le asigna una capacidad. Varios workspaces pueden compartir la misma capacidad, pero un workspace solo puede estar asociado a una capacidad a la vez.
• A partir de ese momento, todas las cargas de trabajo que se ejecutan en ese workspace (actualizaciones, notebooks, pipelines, consultas, etc.) consumen Capacity Units (CU) de la capacidad asignada.

Este último punto es clave, porque convierte al workspace en la unidad básica para asignar y analizar costos. Más adelante, cuando hablemos de separar cargas, aislar entornos o distribuir gastos entre equipos, todas esas decisiones partirán de esta misma regla.

¿Qué significa F2 o F64 en el nombre del SKU?

El nombre del SKU indica cuánta capacidad contratas. La letra F identifica las capacidades de Microsoft Fabric y el número representa las Capacity Units disponibles por segundo (CU/s). Por ejemplo, una F2 ofrece 2 CU/s y una F64, 64 CU/s.

Cada nivel duplica las CU del anterior y, como el precio escala de forma lineal, también duplica aproximadamente su costo.

Ahora bien, duplicar las CU no significa necesariamente que cada operación vaya a ejecutarse el doble de rápido, por lo tanto, una F8 por ejemplo, no va a ejecutar tu notebook cuatro veces más rápido que una F2. El efecto depende del motor, del tipo de carga y de si esa operación puede aprovechar recursos adicionales.

Una capacidad mayor te proporciona principalmente más recursos para ejecutar operaciones simultáneas, absorber picos y sostener una carga más alta antes de alcanzar los límites de la capacidad. Puedes imaginarlo como una conexión a internet: contratar más ancho de banda no garantiza que una sola página cargue proporcionalmente más rápido, pero sí permite que más personas naveguen al mismo tiempo sin que el servicio se degrade.

¿Qué es una CU y cómo se consume?

Una CU es la unidad utilizada por Microsoft Fabric para medir la capacidad de cómputo. Cada SKU proporciona una cantidad determinada de CU por segundo: una F2 ofrece 2 CU/s, una F4 ofrece 4 CU/s y así sucesivamente.

Para analizar el uso de la capacidad, Fabric divide el tiempo en intervalos de 30 segundos denominados timepoints. Por tanto:

• Un minuto contiene 2 timepoints.
• Una hora contiene 120 timepoints.
• Un día contiene 2.880 timepoints.

Hagamos los números para todos los SKUs:

Por ejemplo, una capacidad F2 proporciona:

• 2 CU por segundo.
• 60 CU durante un timepoint de 30 segundos.
• 7.200 CU durante una hora.
• 172.800 CU durante un día completo.

Estos valores representan la capacidad de cómputo disponible durante cada periodo, no una cantidad de CU que debas consumir obligatoriamente. Si una operación utiliza menos recursos, la capacidad restante queda disponible para otras operaciones o para absorber consumo suavizado.

Entender estos valores permite poner en contexto el consumo de pipelines, consultas, notebooks y demás operaciones ejecutadas dentro de Fabric.

¿Cómo se calcula el consumo de CU de un trabajo?

Cuando le das a ejecutar en un notebook, o corres un pipeline, veamos cómo calcula Microsoft que eso te va a costar.

Para ello se toman en cuenta 2 variables:

1. Tasa de consumo de la operación ejecutada
2. El tiempo de procesamiento

La tasa de consumo

Cada tipo de operación en Fabric tiene una tasa de consumo relativamente fija, medida en CU por segundo de procesamiento. Te adjunto el link donde puedes ver el detalle de donde se encuentran esas tasas:

Esto nos permite tener una idea del consumo de las diferentes operaciones, podemos ver que un dataflow Gen2 consume unas 32 veces más que un notebook Spark. Ojo, esto no significa que un dataflow siempre te cueste 32 veces más que un notebook, porque los tiempos de ejecución difieren, pero sí significa que la elección de herramienta de ETL es también una decisión de costo.

Copilot consume la misma capacidad

En lo que respecta a Copilot, su consumo se calcula distinto al resto, ya que se mide por tokens, según la documentación de consumo de Copilot:

• Los inputs consumen a razón de 100 CU-segundos por cada 1.000 tokens de entrada
• Los outputs, a 400 CU-segundos por cada 1.000 tokens de salida.

No existe una factura independiente por cada uso de Copilot: su consumo se imputa a la capacidad Fabric que ya tienes contratada.

El tiempo de procesamiento

Hasta aquí vimos la primera variable que determina el consumo de una operación: la tasa de consumo, es decir, cuántas CU utiliza por cada segundo de procesamiento.

Veamos ahora la segunda variable: el tiempo de procesamiento, o cuánto tarda la operación en completarse.

A diferencia de la tasa de consumo, la duración puede variar considerablemente. En un notebook de Python, por ejemplo, dependerá del volumen de datos, la complejidad de las transformaciones, el paralelismo disponible, la configuración de Spark y la eficiencia del código.

El consumo total surge de combinar ambas variables:

Consumo en CU(s) = tasa de consumo × tiempo de procesamiento

Por eso, una operación con una tasa de consumo baja puede terminar consumiendo más CU que otra con una tasa alta si tarda mucho más en completarse. Optimizar el tiempo de ejecución no solo mejora el rendimiento, sino que también reduce directamente el consumo de capacidad.

Conclusiones

La primera conclusión práctica de esta serie es que optimizar Microsoft Fabric no consiste únicamente en ejecutar menos operaciones, sino en reducir el tiempo de procesamiento y elegir el artefacto o motor adecuado para cada carga de trabajo.

Cada tipo de operación tiene una tasa de consumo determinada, pero su impacto final sobre la capacidad depende de cuánto tiempo se ejecute, de los recursos que utilice y de las características del motor. Por eso, dos alternativas que cubren una misma necesidad. Por ejemplo, un Dataflow Gen2 y un notebook, o un modelo Import y uno Direct Lake, pueden generar consumos muy diferentes.

Además, la duración visible de una operación no siempre permite deducir por sí sola cuántas CU consumió. Algunas cargas pueden utilizar bursting para acceder temporalmente a más recursos de los que proporciona el SKU como base, por lo que una consulta corta puede haber consumido más CU por segundo de lo que su duración sugiere. Veremos este comportamiento con mayor detalle en la Parte 2.

Mi recomendación

Utiliza las fórmulas y tasas de consumo para obtener una primera estimación, pero no tomes decisiones de arquitectura basándote únicamente en cálculos teóricos.

Cuando necesites comparar dos alternativas, ejecútalas bajo condiciones equivalentes y revisa su consumo real en la Microsoft Fabric Capacity Metrics App. Compara los CU-segundos consumidos, el tiempo de ejecución, el rendimiento obtenido y su efecto sobre el resto de la capacidad, luego en base a eso toma tus decisiones.

Continúa la serie

• Parte 2 — Bursting, smoothing y throttling: cómo tu capacidad te presta cómputo, te lo cobra en cuotas y te frena por etapas cuando te pasas.
• Parte 3 — ¿Cuánto cuesta Microsoft Fabric?: precios, pay-as-you-go vs reserva, la regla del 60% y el umbral F64 que define las licencias.