Windows 11 Update: AMD Vitis AI Execution Provider 1.8.26 (KB5070605)

  • Thread Author
Microsoft has issued a targeted component update for AMD’s on‑device AI stack — KB5070605, which bumps the Vitis AI Execution Provider to version 1.8.26.0 for Windows 11 (version 24H2 and 25H2) devices. The public-facing note accompanying the package is short: the update “includes improvements” to the AMD Vitis AI Execution Provider, is delivered automatically through Windows Update, and requires that the device already has the latest cumulative update (LCU) for the applicable Windows 11 release installed. After installation the package should appear in Settings → Windows Update → Update history. These are the facts surfaced in the KB text the vendor provided to Microsoft and mirrored by Microsoft’s update delivery model for per‑silicon AI components.

Isometric graphic of on-device inference with AMD Vitis AI, CPU/GPU/NPU blocks, and a Windows 11 laptop.Background / Overview​

Windows 11’s new on‑device AI architecture uses a system‑managed ONNX Runtime and a catalog of vendor Execution Providers (EPs) so the OS and apps can offload model inference to the best available silicon (CPU, GPU, or NPU). AMD’s contribution to that ecosystem is the Vitis AI Execution Provider — the runtime bridge that compiles and dispatches ONNX subgraphs to AMD NPUs, GPUs, and Alveo accelerators. The Vitis AI EP is the piece Microsoft installs and updates as a separate, per‑vendor component so Microsoft can iterate runtime and model changes independently of full OS feature updates. That componentized model speeds delivery but transfers testing and validation responsibility to IT teams and developers.
Technically, the Vitis AI EP compiles ONNX models on first use into an accelerator‑specific executable and caches the compiled binary for subsequent runs; graph partitioning determines which operators run on the NPU versus those that fall back to CPU/GPU. The compilation behavior, cache configuration, and provider options (for example cache_dir and cache_key) are documented in the Vitis AI provider docs and Ryzen AI runtime guides. Those behaviors explain why a component update—even one described as “includes improvements”—can affect first‑run latency, disk cache size, numerical results for quantized models, and operator mapping.

What KB5070605 actually says (and what it does not)​

  • The package updates Vitis AI Execution Provider to 1.8.26.0 for Windows 11, version 24H2 and version 25H2. The KB text provided with the update states the change as “includes improvements to the AMD Vitis AI Execution Provider AI component.”
  • Delivery is automatic via Windows Update; the device must have the latest cumulative update for the target Windows 11 version before the component will install. After update, the component should appear in Update history.
  • The KB note does not publish a line‑by‑line engineering changelog, performance benchmarks, or CVE/security mappings. Microsoft’s public KBs for these modular AI packages intentionally keep public text brief; this reduces immediate visibility into exactly what micro‑optimizations, model weight changes or bug fixes were applied. Treat any detail beyond the KB’s plain language as inferred or unverified until AMD or Microsoft publishes supplemental release notes.
Important verification note: at the time of research, Microsoft’s standard support index and public KB search returned component entries for prior Vitis AI EP updates (for example, 1.8.25.0 under a different KB number), and ONNX Runtime / AMD documentation confirms the provider’s behavior and requirements. However, a stand‑alone, directly linkable Microsoft Support page for KB5070605 could not be located in public search results during verification; the summary text you provided matches Microsoft’s established wording pattern for Vitis AI component updates but the exact KB page was not discoverable by the crawler used for this article. Treat the KB text you supplied as authoritative for this article’s reporting while noting that a live Microsoft KB page is the usual canonical reference. Where Microsoft’s public statement is terse, the practical implications must be inferred from vendor docs and prior KB patterns.

Why this update matters (practical effects)​

Even small, incremental updates to an execution provider can ripple into multiple user and developer surfaces because the provider sits between OS APIs, vendor runtimes, and device drivers.
Key end‑user surfaces likely to be affected:
  • Imaging and visual effects: Windows Photos’ Super Resolution, background segmentation used by Teams/Studio Effects, and live camera filters are common consumer surfaces that use on‑device image models. Component refreshes historically target improvements in upscaling quality, segmentation edges (hair/semantics), and noise handling.
  • Latency and power: Micro‑optimizations in operator scheduling and memory reuse can lower inference latency and energy per operation on NPUs, improving responsiveness for interactive features. Gains are workload‑dependent and device‑specific.
  • Robustness: Provider updates often include input validation and parsing hardening that reduce crashes on malformed or adversarial inputs — valuable for image pipelines that historically attract a disproportionate share of crash reports. These changes are common in component updates but are not always mapped to public CVEs.
For developers and ISVs, the update can change operator placement, numeric rounding behavior for quantized models, and session compilation timing. That means automated CI checks and model validation on target hardware should be re‑run after the component is applied. ONNX Runtime logs and provider session metadata are essential to detect operator fallbacks or partitioning changes.

Technical verification — cross‑checking vendor documentation​

Two independent, authoritative sources corroborate the relevant technical claims about how Vitis AI EP behaves and why a component update matters:
  • ONNX Runtime Vitis AI Execution Provider documentation — explains the compilation‑on‑first‑use model, cache directories, provider options (cache_dir, cache_key, log_level) and the graph partitioning model that decides which operators run on the accelerator. That doc verifies the fundamental runtime semantics referenced in the KB.
  • AMD Ryzen AI / Vitis AI developer guides — document the provider configuration (vaip_config.json), required driver/NPU compatibility checks and the need to use vendor‑matched configuration files for optimal behavior. AMD’s docs also emphasize that model compilation time can be non‑trivial and that compiled artifacts are cached for future sessions. These technical points explain the user‑visible implications (first‑run delays, cache growth, and operator mapping) likely to be affected by a provider update.
Because Microsoft’s KB entry is intentionally concise, those two vendor‑facing documents provide crucial technical context that explains why administrators and developers must validate behavior after the update. When possible, rely on direct vendor release notes for a component to confirm exact code changes; in their absence, documented provider mechanics let us form reasoned expectations.

Strengths — what this package delivers (likely and verifiable)​

  • Faster iteration cadence for on‑device AI: Componentized delivery lets Microsoft and AMD ship targeted runtime and model improvements without waiting for a full OS feature update. That means more frequent quality fixes for imaging and inference stacks.
  • Vendor‑specific tuning: Shipping an AMD‑tailored Vitis AI EP build allows per‑silicon optimizations tuned to Ryzen AI NPUs, Adaptable SoCs and Alveo cards — typically leading to better utilization of local accelerators and improved throughput for supported models. AMD and ONNX docs confirm the provider’s per‑hardware tuning model.
  • Local privacy and responsiveness: When inference runs locally on an NPU, round‑trip latency and cloud exposure are reduced — a measurable privacy and UX advantage for camera‑ and document‑centric features. This is a strategic advantage of on‑device EPs.

Risks and known unknowns​

  • Opaque public changelogs: Microsoft’s “includes improvements” phrasing leaves out granular diffs, benchmark numbers, or CVE mappings. Organizations that require explicit security history or patch detail should request release notes from Microsoft or AMD via support channels. Treat any claim of security fixes as provisional until CVE identifiers or advisory text are published.
  • Driver/firmware coupling: The most frequent cause of regressions after provider updates is a mismatch between the EP, GPU/NPU drivers, chipset firmware or OEM camera ISP drivers. Always align drivers and firmware to OEM‑recommended versions before broad deployment. AMD’s docs emphasize the need for driver compatibility checks before using the Vitis AI EP.
  • Rollback complexity: Component updates delivered through Windows Update may be harder to rollback than standalone packages. For managed fleets, prepare rollback images or a recovery plan. Pilot and staged rollouts reduce the chance of mass impact.
  • Potential for subtle numeric deltas: Quantization tweaks and operator remapping can change outputs slightly — enough to break deterministic post‑processing thresholds or automated acceptance tests. Re‑test models and downstream logic.

Deployment checklist — recommended steps for IT admins and power users​

  • Verify prerequisites:
  • Confirm target devices are Copilot+ AMD systems running Windows 11, version 24H2 or 25H2 and have the latest cumulative update (LCU) applied. The component will not install without the LCU.
  • Inventory eligible devices:
  • Identify which endpoints are Ryzen AI / NPU‑capable (laptops, desktops, or Alveo‑equipped servers). Maintain a CMDB flag for devices expected to receive the Vitis AI EP.
  • Align drivers and firmware:
  • Update AMD chipset, GPU/Adrenalin and any NPU runtimes/firmware to OEM‑recommended versions before applying the component. Driver mismatches are the leading operational risk.
  • Create a pilot ring:
  • Stage the component to a small representative group (7–14 days) with varied OEM images and thermals. Monitor imaging workflows, conferencing, and crash telemetry.
  • Acceptance tests (examples):
  • Photos: Super‑Resolution, Erase/Restore, Restyle.
  • Conferencing: Background removal/Studio Effects in Teams or other clients.
  • Camera/Windows Hello: enroll and login flows if shared camera stacks are used.
  • Record pre/post latency, CPU/NPU utilization, and visual output samples.
  • Monitor and collect artifacts:
  • If regressions occur, collect Update history entry, Windows Event logs, WER dumps, driver versions and reproducible sample inputs (images/video). These artifacts speed triage with OEM or Microsoft support.
  • Rollout and rollback:
  • Expand deployment in staged rings after 7–14 days of stable telemetry. Maintain tested rollback images and documented recovery steps for managed fleets.

Developer guidance — validating models and apps​

  • Re‑run model validation suites on representative hardware using ONNX Runtime with the VitisAIExecutionProvider selected. Inspect:
  • Provider registration logs and operator partitioning to confirm performance‑sensitive subgraphs continue to run on the NPU.
  • Session creation time and first‑run compilation duration.
  • Numeric thresholds for quantized models — even small shifts can change mask‑binarization or tokenization behavior.
  • Use provider options to control caching and logging:
  • Configure cache_dir and cache_key to manage where compiled binaries land and when they are reused across builds. Use log_level to capture provider behavior in detail for debugging.
  • Automate tests in CI:
  • Add device‑level acceptance tests that run models on a device image with the current Vitis AI EP installed, rather than relying solely on developer machines. This guards against subtle behavior changes introduced by component updates.

Troubleshooting and escalation​

If you encounter regressions after applying KB5070605:
  • Reproduce and capture:
  • Screenshots/video, exact repro steps and timestamps, the Update history entry text, and sample model or image files that reproduce the issue.
  • Collect system diagnostics:
  • Windows Event logs (Application/System), Reliability Monitor, WER crash dumps and the exact AMD GPU/Adrenalin and NPU driver versions. Include the vaip_config.json and any provider option overrides used by your application.
  • Where to escalate:
  • If data points to camera/ISP or GPU driver interactions, escalate to the OEM or AMD driver support.
  • If the issue appears tied to the Vitis AI EP (behavior reproducible only when the provider is active and persists after driver alignment), escalate to Microsoft with the full Update history entry and diagnostic package. Microsoft’s component KBs are intentionally short, and support will often require the exact package identifier to match internal release notes.

Final assessment — practical takeaways​

KB5070605’s update to Vitis AI Execution Provider 1.8.26.0 fits squarely into Microsoft and AMD’s ongoing strategy: push more frequent, per‑vendor runtime and model improvements to keep on‑device AI features current and performant. That approach delivers real benefits — modest but meaningful quality and latency improvements for imaging and interactive AI flows — while placing greater emphasis on validation and dependency management for IT, OEM and developer teams.
Conservative, evidence‑based guidance:
  • Let consumer Copilot+ AMD devices receive the update automatically via Windows Update if they are used individually. For managed or critical fleets, follow a measured pilot → staged rollout process, align drivers and firmware first, and re‑run acceptance tests that reflect actual production workloads.
Caveats to remember:
  • Microsoft’s public KBs for these components are intentionally minimal. Treat any claim about specific bug fixes, security remediations, or numerical performance gains as unverified until published in a vendor release note or CVE advisory. If your environment requires forensic patch records, open a support case with Microsoft or AMD to obtain package‑level release notes.

This update is one more step in the iterative path toward richer, local‑first AI on Windows — a path that improves responsiveness and privacy for users but also raises the bar for operational hygiene in enterprises. The Vitis AI provider’s documented behavior (compile‑on‑first‑use, cache management and provider options) explains why administrators and developers need deliberate testing practices when any component in the on‑device AI stack is updated.

Source: Microsoft Support KB5070605: AMD Vitis AI Execution Provider Update (1.8.26.0) - Microsoft Support
 

Back
Top