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.

Los dos modelos de facturación

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.

Capacidad, SKU, CUs y cómo se relacionan

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 vale la pena entender la estructura completa, porque sobre ella se apoyan casi todas las estrategias de ahorro que veremos más adelante:

• Tu organización tiene un tenant (normalmente uno solo).
• Dentro del tenant puedes tener tantas capacidades como necesites, que además son recursos dedicados que no se comparten con otros clientes.
• A cada workspace se le asigna a una capacidad, y a partir de ahí todo lo que se ejecute desde ese workspace consume recursos de esa capacidad.

Un tenant puede tener varias capacidades, cada workspace se asigna a una de ellas, y todo lo que ese workspace ejecuta consume de esa capacidad.

Este último punto es clave, ya que convierte al workspace en la unidad de asignación de costo: cuando más adelante hablemos de separar cargas, aislar entornos o atribuir gastos por equipo, siempre vamos a estar jugando con esta regla.

El SKU (Stock keeping unit)

El nombre del SKU te dice exactamente lo que compras, ya que la letra F va seguida de un número que corresponde a las unidades de capacidad (CU) por segundo que obtienes. Una F2 te da 2 CU por segundo, una F64 te da 64, y cada nivel duplica la potencia de su predecesor, junto con el precio.

SKU	CU por segundo	Pago por uso (mes)	Reservada (mes, ~41% dto.)
F2	2	$262,80	$156,33
F4	4	$525,60	$312,67
F8	8	$1.051,20	$625,33
F16	16	$2.102,40	$1.250,67
F32	32	$4.204,80	$2.501,33
F64	64	$8.409,60	$5.002,67
F128	128	$16.819,20	$10.005,33
F256	256	$33.638,40	$20.010,67
F512	512	$67.276,80	$40.021,33
F1024	1.024	$134.553,60	$80.042,67
F2048	2.048	$269.107,20	$160.085,33
Trial	64	Gratis durante 60 días	—

Precios de referencia en USD; el detalle de la reserva y las variaciones por región los vemos en la Parte 3.

Hay algo interesante en esta tabla, y es el Trial: es el equivalente a una F64, gratis, durante 60 días, lo cual lo convierte en la mejor herramienta de estimación que existe, ya que puedes medir tu carga real antes de gastar un solo dólar.

Cada SKU duplica el valor de la anterior, sin embargo, esto no significa que una F8 vaya a ejecutar tu notebook cuatro veces más rápido que una F2, ya que cada trabajo corre tan rápido como el motor pueda, en cualquier SKU. Al comprar una SKU lo que se compra es el “ancho de banda”, es decir, cuánto trabajo simultáneo puedes sostener antes de agotar tu presupuesto.

Es como cuando contratamos un plan de conexión a internet, contratar más megas no hace que una página cargue más rápido si estás solo, sino que permite que veinte personas naveguen a la vez sin degradarse.

Consumo de CUs (Unidades de Capacidad)

Como mencionamos, un CU es la unidad de medida utilizada para medir la potencia de cálculo disponible para cada SKU. Estos CUs se otorgan por segundo, pero al momento de consumirlos Fabric reporta el consumo en bloques de 30 segundos llamados timepoints, así que en 24 horas tenemos 2.880 timepoints.

Hagamos los números para todos los SKUs:

SKU	CU/s	CU por timepoint (× 30 s)	CU por hora (× 120 timepoints)	CU por día (× 2.880 timepoints)
F2	2	60	7.200	172.800
F4	4	120	14.400	345.600
F8	8	240	28.800	691.200
F16	16	480	57.600	1.382.400
F32	32	960	115.200	2.764.800
F64	64	1.920	230.400	5.529.600
F128	128	3.840	460.800	11.059.200
F256	256	7.680	921.600	22.118.400
F512	512	15.360	1.843.200	44.236.800
F1024	1.024	30.720	3.686.400	88.473.600
F2048	2.048	61.440	7.372.800	176.947.200

Cada columna sale de la anterior: los CU/s por 30 dan el timepoint, una hora son 120 timepoints y un día son 2.880.

Por lo tanto, con una capacidad F2:

• Por cada segundo consumes 2 CUs.
• Cada timepoint de 30 segundos puedes consumir 60 CUs (2 CUs/Seg x 30 seg).
• Así que por hora puedes consumir hasta 7.200 CUs/hr (60 CUs/timepoint × 120 timepoints/hora).
• Y 172.800 CU para gastar cada día.

Es muy importante entender cómo se obtienen estos números y qué representan, para así poner en contexto el consumo de las operaciones realizadas dentro de Fabric.

Cómo se costean los trabajos

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:

Workload	CU por segundo de procesamiento	Fuente del detalle
Dataflows Gen2	16	Dataflow Gen2 pricing
Power BI	8 (por v-core)	Fabric operations
Consultas en Data Warehouse	1*	Fabric operations
Notebooks Spark	0,5 (por vCore)	Spark compute

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.

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.

Así que si haces la cuenta con una F2, que tiene 172.800 CU al día, verás que Copilot puede comerse tu capacidad más rápido de lo que imaginas, y como no hay factura aparte, todo sale de lo que ya pagaste.

El tiempo de procesamiento

Veamos ahora la otra parte de la ecuación de cómo se calcula el consumo de las operaciones, esta parte es completamente variable ya que depende de qué trabajo haces y con qué eficiencia lo haces. Para un notebook de Python que transforma datos, por ejemplo, dependerá del volumen y de la calidad de tu código.

Conclusiones

Así que como primera conclusión práctica de esta serie de artículos:

Dado que las tasas de consumo son fijas, tu palanca real de optimización está en el tiempo de procesamiento y en la elección del artefacto.

Por otro lado, el costo exacto de una operación individual aún sigue siendo difícil de calcular con total exactitud, porque cuando una consulta usa bursting (lo veremos en la Parte 2) puede estar consumiendo varias veces más CU por segundo de lo que sugiere su duración, y las herramientas de consulta no te muestran ese detalle directamente.

Mi recomendación es que trates cualquier cálculo de costo por operación como una aproximación, y que cuando quieras comparar arquitecturas (¿dataflow o notebook?, ¿import o Direct Lake?) midas el consumo de cada una en la Capacity Metrics App y luego en base a eso tomes tus decisiones.