CUs médios no Microsoft Fabric: como calcular e dimensionar sua capacidade

← Voltar ao blog

Dimensionar uma capacidade do Microsoft Fabric apenas pelo pico de consumo pode levar a uma contratação maior — e mais cara — do que o necessário. No caminho oposto, olhar somente para uma média diária muito ampla pode esconder períodos críticos e resultar em lentidão, delays e throttling.

O melhor caminho é combinar CUs médios, distribuição do consumo ao longo do tempo, picos, smoothing, workloads interativos e de background.

Uma estratégia prática é começar com uma capacidade de teste ou Fabric Trial, colocar os relatórios e cargas representativas nesse ambiente e acompanhar o comportamento real antes de definir a SKU definitiva.

Neste artigo, vamos entender como fazer isso.

O que são CUs no Microsoft Fabric?

CU significa Capacity Unit.

É a unidade utilizada pelo Microsoft Fabric para representar a capacidade computacional disponível e o consumo realizado pelos diferentes workloads da plataforma.

Uma capacidade F8, por exemplo, disponibiliza nominalmente 8 Capacity Units. Uma F16 disponibiliza 16 CUs, uma F32 disponibiliza 32 e uma F64 disponibiliza 64.

Esses recursos são compartilhados entre diferentes operações, como:

consultas de relatórios Power BI;
execução de medidas DAX;
atualizações de modelos semânticos;
Dataflows;
pipelines;
Warehouse;
Lakehouse;
notebooks;
Data Engineering;
Real-Time Intelligence;
outras cargas do Microsoft Fabric.

Por isso, dimensionar uma capacidade apenas pela quantidade de usuários ou pelo tamanho dos relatórios não é suficiente.

O que realmente importa é quanto processamento o ambiente demanda ao longo do tempo.

Segundo a Microsoft, o Fabric utiliza CUs como uma forma comum de medir o consumo das diferentes cargas executadas dentro de uma capacidade.

Consulte a documentação oficial em Otimizar a capacidade do Microsoft Fabric.

O que significa CU médio?

Para análise de capacidade, podemos utilizar o conceito de CU médio como uma forma de transformar a utilização percentual observada em uma demanda média equivalente de CUs.

A lógica é simples:

CU médio = CUs disponíveis da capacidade × utilização média

Imagine uma capacidade F64 com utilização média de 25%.

O cálculo seria:

64 × 25% = 16 CUs médios

Isso significa que, durante o período analisado, aquela capacidade apresentou um consumo equivalente médio de aproximadamente 16 CUs.

Esse indicador é especialmente útil para:

comparar capacidades diferentes;
estimar quanto processamento um conjunto de workspaces realmente demanda;
simular consolidação de ambientes;
distribuir workloads entre novas capacidades;
analisar oportunidades de redução de SKU;
projetar crescimento.

Importante: CU médio é uma métrica analítica para planejamento. Ela não substitui as métricas oficiais do Fabric Capacity Metrics nem deve ser analisada isoladamente.

Exemplo prático de cálculo

Considere uma empresa utilizando uma F64.

Durante um período representativo, o monitoramento apresentou:

Capacidade: F64
CUs disponíveis: 64
Utilização média: 28%

Temos:

64 × 28% = 17,92 CUs médios

Isso indica que o workload analisado demandou, em média, aproximadamente 17,9 CUs.

Poderíamos pensar imediatamente:

“Então uma F32 seria suficiente.”

Talvez.

Mas ainda não podemos concluir isso.

Precisamos entender como esses 17,9 CUs estão distribuídos no tempo.

Média não é a mesma coisa que pico

Esse é um dos pontos mais importantes do dimensionamento.

Considere dois ambientes.

Ambiente A

CU médio: 16
pico: 25
utilização relativamente estável

Ambiente B

CU médio: 16
pico: 90
grandes atualizações concentradas em determinados horários

Apesar de apresentarem a mesma média, o comportamento operacional é completamente diferente.

Por isso, o dimensionamento deve observar pelo menos:

CU médio + comportamento temporal + picos + throttling + tipo de workload

A média indica a demanda estrutural.

O pico mostra a intensidade das janelas críticas.

Por que não devemos dimensionar apenas pelo pico?

O Microsoft Fabric possui mecanismos de bursting e smoothing.

Isso significa que uma operação pode temporariamente consumir recursos acima da capacidade nominal para ser concluída mais rapidamente.

Depois, o consumo é distribuído ao longo do tempo para efeito de avaliação da capacidade.

Segundo a Microsoft, o smoothing permite justamente dimensionar a capacidade mais próximo do consumo médio, em vez de exigir uma SKU capaz de suportar cada pico instantâneo.

Veja a documentação oficial em Smoothing e throttling no Microsoft Fabric.

Esse comportamento muda completamente a lógica tradicional de capacity planning.

Um pico isolado acima de 100% não significa automaticamente que a capacidade esteja subdimensionada.

O que é bursting?

O bursting permite que determinadas operações consumam temporariamente mais processamento do que a capacidade nominal.

Imagine uma operação que, durante alguns segundos, demande processamento equivalente a 20 CUs dentro de uma F8.

Isso não significa necessariamente que a operação será bloqueada.

Dependendo do workload e das condições da capacidade, o Fabric pode permitir que a carga utilize recursos adicionais temporariamente para concluir a execução.

Depois, esse consumo entra no mecanismo de smoothing.

A documentação da Microsoft explica que workloads podem utilizar recursos acima do provisionado temporariamente, evitando a necessidade de contratar uma capacidade maior apenas para suportar picos breves.

Consulte Throttling no Microsoft Fabric.

O que é smoothing?

O smoothing distribui contabilmente o consumo de uma operação ao longo de uma janela de tempo.

Para operações interativas, o consumo é suavizado por uma janela menor. Para operações de background, como determinadas atualizações e processos agendados, o consumo pode ser distribuído por uma janela muito maior.

Isso explica uma situação bastante comum:

Um refresh executado durante a madrugada pode continuar impactando a disponibilidade da capacidade durante outras horas do dia.

Não porque o refresh ainda esteja executando, mas porque seu consumo ainda está sendo amortizado pelo mecanismo de smoothing.

Um refresh pode consumir mais CU do que a capacidade possui?

Sim.

É justamente por isso que analisar apenas o pico bruto pode gerar interpretações erradas.

Uma F8 não significa que nenhuma operação possa ultrapassar temporariamente 8 CUs.

O Fabric trabalha com bursting e smoothing para permitir que operações intensivas sejam executadas sem exigir imediatamente uma capacidade maior.

O problema aparece quando o consumo deixa de ser um pico pontual e passa a ser persistentemente superior ao orçamento disponível.

Nesse momento começamos a criar uma espécie de dívida de capacidade.

O que acontece quando a capacidade não consegue recuperar o consumo?

Quando o ambiente consome continuamente mais recursos do que consegue disponibilizar, ocorre o chamado overage.

Esse consumo excedente é carregado para os períodos seguintes.

Se novas cargas continuam chegando e a capacidade não possui tempo suficiente para recuperar esse saldo, o Fabric pode começar a aplicar throttling.

Entre os sintomas possíveis estão:

Interactive Delay;
aumento no tempo de resposta;
Interactive Rejection;
rejeição de novas operações;
Background Rejection;
atualizações ou processos aguardando recursos.

Um pico acima de 100% significa problema?

Não necessariamente.

Essa é uma das interpretações incorretas mais frequentes.

Um ambiente pode atingir:

130%, 180% ou até mais em determinados períodos

e ainda assim funcionar normalmente.

A pergunta correta não é:

“Minha capacidade ultrapassou 100%?”

A pergunta deveria ser:

“Ela consegue recuperar esse consumo antes que novas cargas gerem uma sobrecarga contínua?”

É por isso que indicadores como overage, carryforward, interactive delay, throttling e rejeições são tão importantes quanto o próprio percentual de utilização.

Como calcular CUs médios por workspace

Depois de calcular a demanda média da capacidade, podemos distribuir esse consumo entre os workspaces.

Imagine novamente:

F64 × 25% de utilização = 16 CUs médios

Agora suponha que o Capacity Metrics indique a seguinte distribuição:

Workspace	Participação no consumo
Comercial	40%
Financeiro	25%
Operações	20%
RH	10%
Outros	5%

Podemos estimar:

Comercial: 16 × 40% = 6,4 CUs
Financeiro: 16 × 25% = 4 CUs
Operações: 16 × 20% = 3,2 CUs
RH: 16 × 10% = 1,6 CU
Outros: 16 × 5% = 0,8 CU

Total:

16 CUs médios

Essa memória de cálculo permite começar a tratar a capacidade como um conjunto de workloads independentes.

Agrupando workspaces por aplicação ou domínio

Em ambientes maiores, analisar centenas de workspaces individualmente pode não ser prático.

Uma alternativa é criar agrupamentos.

Por exemplo:

Bloco	CUs médios
Portal de Clientes	7,8
Financeiro	4,1
Comercial	3,7
Operações	5,2
Demais workloads	2,9

Total:

23,7 CUs médios

A partir daqui podemos começar a simular diferentes arquiteturas.

Por exemplo:

Portal de Clientes → F16
Financeiro + Comercial → F16
Operações + outros → F16

Ou:

todos os workloads → F32

O melhor desenho dependerá não apenas da soma dos CUs médios, mas também da simultaneidade e dos picos de cada workload.

Não some picos cegamente

Imagine dois workloads:

Workload A

CU médio: 8
pico: 16
maior consumo entre 8h e 12h

Workload B

CU médio: 7
pico: 16
maior consumo entre 18h e 22h

Somar os picos resultaria em:

16 + 16 = 32

Mas isso pressupõe que os dois workloads atinjam seus picos exatamente no mesmo momento.

Se isso nunca acontece, uma F32 pode estar sendo superdimensionada.

Por isso, para consolidação de capacidades, a análise ideal utiliza uma série temporal.

Devemos observar:

consumo combinado no mesmo intervalo de tempo

e não apenas:

soma do maior pico histórico de cada ambiente

Comece pelo Fabric Trial

Uma das melhores maneiras de estimar uma capacidade é testar os workloads antes da contratação definitiva.

A Microsoft disponibiliza o Fabric Trial para avaliação da plataforma e essa experiência pode ser utilizada como ponto de partida para observar o comportamento dos workloads antes da escolha definitiva da capacidade.

Consulte Fabric Trial.

Isso oferece uma oportunidade interessante para capacity planning.

Em vez de tentar responder teoricamente:

“Qual Fabric minha empresa precisa?”

podemos fazer uma prova real.

Passo 1 — Crie ou habilite uma Trial

Configure a capacidade Trial e defina quais workspaces serão utilizados no estudo.

Evite testar apenas um relatório simples.

A Trial deve representar o ambiente real o máximo possível.

Inclua:

principais modelos semânticos;
atualizações;
relatórios mais acessados;
usuários de teste;
pipelines relevantes;
Dataflows;
demais cargas importantes.

Passo 2 — Gere utilização real

Uma capacidade vazia não produz informação útil para dimensionamento.

Durante o teste:

execute os refreshes normalmente;
permita utilização dos relatórios;
simule horários de maior acesso;
execute processos de ETL;
utilize os principais workloads.

Quanto mais representativa a utilização, mais confiável será o estudo.

Passo 3 — Instale o Fabric Capacity Metrics

O Microsoft Fabric Capacity Metrics deve ser uma das principais fontes para o estudo.

O Capacity Metrics permite investigar:

consumo por capacidade;
consumo por workspace;
consumo por item;
operações;
CUs;
workloads;
overage;
throttling;
Interactive Delay;
utilização ao longo do tempo.

Veja a documentação em Fabric Capacity Metrics.

Passo 4 — Não tire conclusões no primeiro dia

Um único dia dificilmente representa uma operação corporativa.

Sempre que possível, acompanhe um período que contenha:

dias úteis;
segunda-feira;
sexta-feira;
fechamento mensal;
processos semanais;
atualizações mais pesadas;
períodos de maior acesso.

Para ambientes maduros, uma janela de duas a quatro semanas costuma produzir uma baseline muito melhor.

Passo 5 — Calcule os CUs médios

Depois de obter o percentual médio de utilização, transforme esse número em CUs equivalentes.

Exemplo:

Trial F64.

Utilização média observada:

21%

Então:

64 × 21% = 13,44 CUs médios

Já temos uma primeira referência de demanda estrutural.

Passo 6 — Olhe também para P90 e P95

A média geral pode esconder períodos importantes.

Imagine que um ambiente tenha:

média geral: 13 CUs;
P90 horário: 21 CUs;
P95 horário: 26 CUs;
pico máximo: 57 CUs.

Dimensionar apenas pelos 13 CUs pode ser agressivo.

Dimensionar pelos 57 CUs pode ser conservador demais.

Uma abordagem melhor é estudar um percentil operacional, como P90 ou P95, junto com os efeitos de smoothing e os eventos de throttling.

Passo 7 — Adicione headroom

Uma capacidade não deve trabalhar permanentemente no limite.

Novos usuários, relatórios, atualizações e pipelines serão adicionados ao ambiente.

Por isso, uma margem operacional pode ser aplicada.

Exemplo:

P95 observado:

24 CUs

Margem planejada:

25%

Temos:

24 × 1,25 = 30 CUs

Nesse cenário, uma F32 passa a ser uma candidata natural para validação.

Não porque exista uma fórmula oficial dizendo que P95 + 25% sempre resulta na SKU correta, mas porque estamos criando uma reserva razoável para variação e crescimento.

Como escolher entre F8, F16, F32 ou F64?

Uma maneira prática de pensar é:

F8

Indicada para workloads pequenos e controlados, desde que o comportamento real demonstre que 8 CUs são suficientes após smoothing.

F16

Pode atender ambientes intermediários, portais Embedded menores e workloads segmentados.

F32

Pode fazer sentido para consolidações maiores ou workloads com demanda média relevante.

F64

Além da capacidade computacional, possui implicações importantes de licenciamento para cenários de consumo direto pelo Power BI Service.

Por isso, escolher uma SKU não é apenas uma decisão de desempenho.

Também envolve:

arquitetura;
licenciamento;
Embedded;
usuários;
recursos Fabric utilizados;
modelo de distribuição dos relatórios.

Para aprofundar esse ponto, consulte também Como funcionam as licenças do Microsoft Fabric e Power BI Embedded e Power BI Embedded ou Microsoft Fabric: qual é a diferença?.

Um exemplo completo

Considere um ambiente sendo avaliado em uma Trial F64.

Após algumas semanas:

utilização média: 27%;
P95 do CU médio horário: 41%;
pico observado: 118%;
Interactive Delay: praticamente zero;
throttling: zero;
rejeições: zero.

CU médio

64 × 27% = 17,28 CUs

P95 equivalente

64 × 41% = 26,24 CUs

Aplicando uma margem de 20%:

26,24 × 1,20 = 31,49 CUs

Uma F32 seria, portanto, uma forte candidata para um teste seguinte.

Observe a diferença.

O ambiente teve pico de 118% de uma F64.

Se dimensionássemos apenas pelo pico, poderíamos chegar à conclusão de que seria necessária uma capacidade superior a F64.

Mas o comportamento suavizado demonstrou que a demanda estrutural estava muito abaixo disso.

É exatamente aqui que uma análise correta de CUs pode gerar economia.

Antes de aumentar a capacidade, otimize

Quando uma capacidade começa a trabalhar próxima ao limite, a primeira resposta não deveria ser automaticamente:

“Vamos subir a SKU.”

Primeiro descubra quem está consumindo os recursos.

Alguns problemas comuns incluem:

refresh completo desnecessário;
consultas Power Query sem folding;
modelos com cardinalidade excessiva;
DAX mal otimizado;
tabelas que poderiam utilizar atualização incremental;
relatórios abandonados ainda sendo atualizados;
modelos duplicados;
refreshes executados com frequência maior que o necessário;
notebooks pesados;
pipelines redundantes;
consultas DirectQuery ineficientes.

Eliminar um único workload problemático pode liberar capacidade suficiente para evitar um upgrade.

Separe consumo interativo e background

Outra análise extremamente importante é entender de onde vem o consumo.

Interactive

Normalmente relacionado ao uso direto pelo usuário:

abertura de relatórios;
filtros;
consultas;
interação com visuais;
navegação.

Background

Normalmente relacionado a processos como:

refreshes;
pipelines;
processamento;
operações agendadas;
determinadas cargas de engenharia.

Um ambiente pode ter excelente experiência para os usuários e ainda apresentar grande consumo de background.

Da mesma forma, um ambiente com poucos refreshes pode apresentar lentidão devido a centenas de consultas interativas simultâneas.

São problemas diferentes e exigem respostas diferentes.

KPIs para acompanhar continuamente

Depois de dimensionar a capacidade, o trabalho não termina.

Uma capacidade que hoje precisa de 15 CUs pode precisar de 25 daqui a seis meses.

Alguns indicadores importantes são:

CU médio;
P90 e P95;
pico de utilização;
percentual de tempo acima de 100%;
Interactive Delay;
Interactive Rejection;
Background Rejection;
throttling;
overage;
consumo por workspace;
consumo por modelo semântico;
consumo por operação;
duração e CU dos refreshes;
tendência de consumo mensal.

Também é útil acompanhar:

CU por usuário ativo

CU por relatório utilizado

Esses indicadores ajudam a avaliar a eficiência do ambiente.

O consumo pode crescer sem ninguém perceber

Esse é um problema comum.

Você não precisa trocar de licença para aumentar o consumo da capacidade.

Basta:

criar mais relatórios;
aumentar o número de usuários;
adicionar um refresh;
publicar um novo modelo;
aumentar o volume de dados;
adicionar uma carga Fabric.

O consumo cresce silenciosamente.

Alguns meses depois, os usuários começam a reclamar:

“O Power BI ficou lento.”

Sem histórico, a equipe começa a investigar rede, gateway, banco, navegador e relatório.

Mas o problema pode simplesmente ser uma capacidade que cresceu de 55% para 95% de utilização ao longo dos últimos meses.

Dimensionamento é um processo contínuo

O dimensionamento inicial é apenas uma fotografia.

Uma boa estratégia trabalha em ciclos:

Medir → analisar → otimizar → dimensionar → monitorar → revisar

Por isso, capacity planning e FinOps precisam andar juntos.

Uma capacidade bem administrada não é necessariamente aquela que nunca chega perto de 100%.

É aquela em que sabemos:

por que o consumo acontece;
quais workloads são responsáveis;
quando os picos acontecem;
quanto recurso está disponível;
quanto existe de headroom;
quanto custa a operação;
quando será necessário crescer.

Checklist para dimensionar uma capacidade Fabric

Antes de contratar ou alterar uma SKU, valide:

Qual é o CU médio do ambiente?
Qual é o P90/P95 por hora?
Quais são os maiores picos?
Os picos são simultâneos?
Existe Interactive Delay?
Existe throttling?
Houve rejeição de operações?
Existe overage sendo carregado?
Qual percentual vem de cargas interativas?
Qual percentual vem de background?
Quais workspaces mais consomem?
Quais modelos mais consomem?
Quais refreshes possuem maior custo?
Existem workloads que podem ser otimizados?
Existe margem para crescimento?
O modelo de licenciamento exige F64?
A arquitetura utilizará Power BI Service ou portal Embedded?

Comece pequeno, monitore e escale conforme necessário

Uma abordagem pragmática para capacity planning é utilizar Trial ou capacidades F em Pay-As-You-Go para observar o consumo real, começar com uma capacidade menor quando possível e aumentar gradualmente conforme a necessidade.

Essa estratégia tende a ser mais eficiente do que contratar uma grande capacidade antecipadamente baseada apenas em estimativas.

O ambiente real fornece a resposta.

Comece com uma capacidade controlada, coloque os workloads representativos nela, monitore os CUs, entenda o smoothing e somente depois escolha a SKU definitiva.

Monitoramento contínuo da capacidade

Depois do dimensionamento, acompanhar apenas o Capacity Metrics de forma eventual pode não ser suficiente para ambientes maiores.

A Power Insight possui recursos para monitorar continuamente capacidades Power BI e Microsoft Fabric, acompanhando consumo de CUs, picos, workloads, workspaces, throttling, delays, rejeições e oportunidades de otimização.

Conheça o monitoramento de capacidades da Power Insight.

O objetivo não é simplesmente descobrir se uma F32 ou F64 está “cheia”, mas entender quanto cada workload consome, quando o consumo acontece e se a capacidade contratada continua sendo a melhor opção para o ambiente.

Conclusão

Escolher uma capacidade Fabric não deveria começar pela pergunta:

“Quantos usuários temos?”

Uma pergunta mais útil é:

“Quantas CUs nossos workloads realmente demandam e como esse consumo se distribui ao longo do tempo?”

O CU médio ajuda a transformar utilização em uma métrica comparável e facilita estudos de consolidação, migração e redução de custos.

Mas ele deve ser analisado junto com:

P90 e P95;
picos;
smoothing;
bursting;
overage;
throttling;
consumo interativo;
background;
simultaneidade;
margem para crescimento.

Com esses dados, o dimensionamento deixa de ser uma estimativa e passa a ser uma decisão baseada no comportamento real da plataforma.

E, em muitos casos, a melhor estratégia é simples:

Trial → monitoramento → baseline → otimização → dimensionamento → monitoramento contínuo.