Weekly ML Roundup: Streaming signals, Fabric governance, and MLVC

by TechHub

This week's ML roundup focuses on the practical path from research ideas to systems you can ship. Microsoft open-sourced ML Video Codec (MLVC) with code, weights, and tooling for real-time deployment on commodity NPUs, while Fabric and SQL updates show clearer patterns for streaming fresh signals into ML enrichment and feature updates. On the platform side, OneLake and Lakehouse improvements reduce friction around query iteration, cross-platform table access, and tighter inbound controls. We close with lessons on scaling large training runs across AMD and NVIDIA via Foundry Managed Compute and a look at Microsoft IQ as a governance-first way to feed agents the right context.

This Week's Overview

Open-sourcing MLVC: learned video compression aimed at real-time on NPUs

Microsoft released ML Video Codec (MLVC) as open source, positioning it as a learned video codec derived from the DCVC family and focused on practical deployment targets like real-time performance on commodity NPUs. The team reports bitrate savings compared to traditional codecs like H.264/H.265, which is a useful data point if you are evaluating ML-based compression for bandwidth-constrained streaming or on-device capture.

For developers, the most immediate value is that this is not just a paper drop: the release includes model code, weights, training scripts, and platform conversion tooling under the MIT License. That combination makes it easier to reproduce results, fine-tune for your content domain, and test deployment paths without rebuilding the entire pipeline from scratch.

The roadmap note to watch is the planned C++ codec library, which would make integration into existing media stacks more realistic (especially for production encoders/decoders that expect native libraries). Until then, teams can start by validating rate-distortion behavior (quality vs bitrate) against their own datasets and profiling end-to-end latency on the NPU targets they care about.

Fabric and SQL streaming patterns for real-time ML signals

This week had a cluster of practical “how do you get fresh data into models and agents” updates across Microsoft Fabric and the SQL ecosystem. The common theme is lowering the friction between operational events (carts, clicks, updates) and near-real-time enrichment so ML features and downstream actions stay current, building on last week's push to make AI workloads more operational inside Fabric and SQL (embeddings, MCP wiring, and governed runtime behavior).

Eventstreams + Spark Structured Streaming + AI Functions for PySpark

A new end-to-end pattern shows how to turn operational cart activity into real-time, AI-enriched outputs using Fabric Eventstreams, CDC connectors, and Spark Structured Streaming notebooks. The flow highlights DeltaFlow (Preview) as part of the streaming architecture, and it layers in AI Functions for PySpark to do inline enrichment directly in the streaming job.

In practice, this is a useful reference for teams building intent scoring, anomaly flags, or personalized offers where timing matters more than perfect batch accuracy. It also demonstrates an emerging “stream + LLM/AI function” approach that keeps the enrichment close to the data path instead of pushing everything into separate microservices.

Change Event Streaming (CES) preview across SQL Server 2025, Azure SQL, and Fabric SQL

Microsoft highlighted Change Event Streaming (CES) in public preview, spanning Azure SQL, SQL database in Fabric, and SQL Server 2025. The coverage focuses on how CES fits next to more familiar approaches like Change Data Capture (CDC) and mirroring, which is the comparison most teams need before they redesign pipelines.

For ML workloads, CES is interesting because it can simplify how you produce feature updates or trigger enrichment when rows change, especially when you already depend on SQL as the operational source of truth. Picking up from last week's “SQL as an agent-ready retrieval surface” thread (embeddings and MCP), CES extends the same idea into the event plane so context and features can stay current without as much glue code.

Fabric Lakehouse and OneLake updates that make ML workflows easier to ship

Several Fabric updates landed around query iteration, cross-platform table access, and network controls, which are the pieces that tend to slow down ML teams after the model code works. The thread connecting these is reducing the time from “data exists” to “data is usable safely by the right compute,” and it follows last week's focus on productionizing Fabric patterns with clearer runtime controls and governance signals.

Lakehouse Query Explorer reaches GA for faster Spark SQL iteration

Lakehouse Query Explorer is now generally available, adding an in-Lakehouse Spark SQL editor to quickly explore datasets, validate assumptions, and convert useful queries into views. The guidance on when to use notebooks vs the SQL analytics endpoint vs Query Explorer matters because it helps teams choose the lowest-overhead tool for the job instead of defaulting to heavier workflows.

For ML practitioners, this is a practical improvement for feature discovery and sanity checks, especially when you want to iterate on joins and filters without turning everything into a notebook session. The ability to promote a proven query into a view can also help standardize feature inputs across training and inference consumers.

Mirror Snowflake Iceberg tables into OneLake via metadata shortcuts

Fabric mirroring now supports Snowflake Apache Iceberg tables, using OneLake shortcuts to replicate metadata rather than copying the underlying data. Fabric then virtualizes Iceberg as Delta Lake so the tables can be queried across Fabric engines, which is aimed at reducing data duplication while still making the data broadly usable.

If your ML data lives in Snowflake but your training, feature engineering, or analytics workloads are shifting into Fabric, this approach can shorten migration timelines and reduce storage costs. The key detail is the metadata-first design, which pairs naturally with last week's theme of keeping governance close to runtime behavior since access can be broadened across engines without multiplying physical copies.

OneLake resource instance rules reach GA for tighter inbound controls

OneLake resource instance rules are now generally available, letting workspace admins allow inbound access from specific trusted Azure resource instances validated by Azure Resource Manager (ARM) identity. This sits alongside existing controls like Private Link, IP firewall rules, and OneLake data permissions, but it is more precise than broad network allowlists.

For ML teams, this helps when you need to lock down which managed services (and which specific instances) can read or write training data, features, or evaluation datasets. It is also a practical continuation of last week's governance thread (labels and guardrails as prerequisites for agents) by tightening the infrastructure-level boundary around OneLake access.

Scaling and orchestration for large model workloads and AI agents

Two items this week focused on what happens after you pick a model: how you scale compute across vendors, and how you give agents access to the right knowledge sources without breaking security boundaries, echoing last week's emphasis on moving from research-scale capability to operational, testable systems.

AT&T and Microsoft: trillion-token development using Foundry Managed Compute across AMD and NVIDIA

AT&T shared details on scaling development of its telecom-focused OTel 2.0 models using Microsoft Foundry Managed Compute, running open models across both AMD and NVIDIA GPUs. The write-up claims roughly one trillion tokens processed while optimizing for cost and deployment speed, with specific mention of running on AMD Instinct MI300X as part of the stack.

For teams planning serious training or continued pretraining runs, the cross-vendor angle is the practical takeaway: you can design for portability while still taking advantage of the GPU capacity you can actually procure. The article also signals a “managed compute” direction where platform tooling, scheduling, and deployment paths matter as much as raw accelerator specs.

Microsoft IQ: agent intelligence sources across Work, Fabric, Foundry, and Web contexts

John Savill outlined Microsoft IQ as a way to give AI agents access to relevant intelligence sources across Work, Fabric, Foundry, and Web contexts. The emphasis is on relevance, multi-model flexibility, and security controls like identity and least-privilege access, which are usually the blockers when you move from demos to real agent deployments.

For developers building agentic systems, the key is the framing: IQ is not just about adding connectors, it is about governing what the agent can see and why. Following last week's focus on making data platforms “agent-ready” (with MCP, embeddings, and sensitivity-driven guardrails), IQ reads like the next layer up where those governed surfaces get composed into an end-to-end agent architecture.