Direct Lake Semantic Model Compute Usage Reduction

Thanks for the context. One question first: are you seeing throttling in the Capacity Metrics app, or only high interactive CU?

Interactive CU is charged per query. Every visual sends a query for every user, so one slow measure on a busy page gets multiplied by 250+ users each morning. Query logic and report design drive most of the cost.

On your ideas: cache warming improves first-open speed but does not reduce total CU. The load cost moves from the first user to the notebook. DAX optimization is the right call, since every fix repeats across every user.

Steps:

1. Open the Capacity Metrics app, filter to Interactive, and find the top items and timepoints by CU. A few pages usually drive most of the cost.
2. Profile those pages with Performance analyzer and DAX Studio Server Timings. Rewrite measures with high formula engine time, such as FILTER over a full fact table or IF inside SUMX.
3. Add Apply buttons under Options > Current file > Query reduction, and cut visuals per page.
4. Confirm V-Order and run OPTIMIZE on large fact tables.
5. Skip the model-wide aggregate swap. If reports use central measures, add aggregate logic inside two or three heavy measures only. Reports stay untouched.

If you use Direct Lake on SQL endpoint, check for DirectQuery fallback in a DAX Studio trace. Fallback costs far more than in-memory queries.

Next step: list your top five interactive items by CU from the last 14 days.

References
https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-how-it-works
https://learn.microsoft.com/en-us/fabric/data-engineering/delta-optimization-and-v-order
https://learn.microsoft.com/en-us/fabric/enterprise/metrics-app

Thank you!
Proud to be a Super User!
🏷️ Need more help?
✅ Don’t forget to Accept as Solution if this guidance worked for you.
❤️Your Like motivates me to keep helping