KB5067994: QNN Execution Provider Update for Copilot+ on Qualcomm Windows 11

Microsoft quietly pushed an incremental AI component update — KB5067994 — that advances the QNN Execution Provider used by ONNX Runtime to version 1.8.13.0 for qualifying Qualcomm-powered Copilot+ PCs, and it follows the same per‑silicon, componentized delivery pattern Microsoft has used for on‑device AI tuning and stability fixes.

---

Background / Overview​

Microsoft’s KB entry for KB5067994 targets a narrowly scoped runtime component: the QNN Execution Provider (QNN EP) used by ONNX Runtime to offload neural network inference onto Qualcomm accelerators. The update applies only to Copilot+ PCs running Windows 11, version 24H2, and is delivered automatically through Windows Update after the device has the latest cumulative update for 24H2 installed. The KB description is purposely brief — it states the new component version and that the package “includes improvements” without a detailed engineering changelog.
Two technical facts are verifiable from public vendor documentation:

• The QNN Execution Provider is the ONNX Runtime plugin that uses Qualcomm’s AI Engine Direct SDK (QNN SDK) to construct QNN graphs from ONNX models so they can run on supported accelerator backends (HTP/NPU, GPU, CPU fallbacks).
• ONNX Runtime’s QNN EP is supported on Android and Windows devices with Qualcomm Snapdragon SoCs and has configurable backends (htp/CPU/GPU), context caching, and session options tailored to NPU execution.

What is not public in the KB is the line‑by‑line list of fixes, model weights, or operator-level changes embedded in the QNN EP update. Microsoft’s component KBs typically omit deep diffs and CVE-style identifiers, which limits external verification of exact behavior changes beyond empirical testing.

---

What the QNN Execution Provider actually is​

QNN EP in plain terms​

• QNN Execution Provider (QNN EP) is an ONNX Runtime execution provider that converts supported ONNX model operators into QNN graph constructs that the Qualcomm AI runtime (QNN SDK / QAIRT) can compile and dispatch to hardware accelerators (Hexagon NPU / HTP), or to GPU/CPU fallbacks when needed.
• The provider exposes provider options (backend_type, backend_path, ep.context_enable, etc.) so developers and system components can tune whether inference runs on the NPU (HTP), GPU, or CPU and whether the QNN context binary cache is used to speed startup.

Why this matters for on‑device Copilot experiences​

On Copilot+ hardware, Microsoft places a premium on low‑latency, private on‑device inference for features like local summarization, image-aware prompts, super‑resolution, and other perceptual tasks. Delivering updates to the ONNX Runtime QNN Execution Provider and its bundled QNN runtime can meaningfully change:

• Latency and time‑to‑first‑token for local SLMs and LLM offload paths.
• Image pre‑/post‑processing performance for Photos and camera pipelines.
• Power consumption and thermal behavior when inference is offloaded to the NPU vs CPU/GPU.

These are the same design tradeoffs that Microsoft and Qualcomm have discussed in their platform docs and that the ONNX Runtime QNN pages describe in deployment guidance.

---

What KB5067994 announces (concise summary)​

• Applies to: Copilot+ PCs running Windows 11, version 24H2 only.
• Component: QNN Execution Provider AI component for ONNX Runtime, new version 1.8.13.0 (package label in the KB).
• Delivery: Automatic via Windows Update once the device has the latest cumulative update for Windows 11, version 24H2.
• Replacement: KB states this update does not replace any previously released update (i.e., it is an additive/iterative package, not a supersedence of an earlier QNN EP component in the KB narrative).
• Visibility: After installing, the entry will appear in Settings > Windows Update > Update history with the component version label the KB provides.

---

Technical verification and cross‑references​

Two independent vendor surfaces make the QNN EP role and its behavior clear:

• ONNX Runtime’s official documentation describes the QNN Execution Provider, its prerequisites (Qualcomm AI Engine Direct SDK / QNN SDK), and configuration options for Windows and Android deployments. That page confirms the EP’s architecture, the availability of prebuilt Windows packages that bundle QNN dependencies starting from a certain ONNX Runtime version, and session-level options like ep.context_enable used for QNN context caching.
• Qualcomm’s AI Hub and QNN/QAIRT release notes show that the Qualcomm AI runtime (QNN / QAIRT) is actively versioned independently, and that tools like Qualcomm AI Hub use ONNX Runtime/QNN EP under the hood for hosted device optimization and runtime metrics. These notes corroborate that ONNX Runtime + QNN is the canonical stack for Qualcomm‑accelerated ONNX inference.

Because the Microsoft KB itself is intentionally succinct, cross‑referencing with ONNX Runtime and Qualcomm materials is vital for understanding the runtime, supported backends, and what a component bump is likely to touch — operator coverage, context caching, backend binding, and compatibility with QNN SDK/driver versions.

---

What this update likely changes — reasoned analysis​

Microsoft’s public wording — “includes improvements” — is vague by design. Based on the class of updates and what ONNX + Qualcomm stacks typically modify, the most likely categories of change are:

• Performance and scheduling optimizations: Better operator placement, graph partitioning improvements, and QNN context caching tweaks to reduce model load time and improve latency on HTP/NPU backends. These are common targets when the provider or QNN runtime increments.
• Stability and operator coverage: Fixes for operators that failed to map cleanly to QNN, or guardrails that force CPU fallback in known‑bad patterns — these reduce session creation errors and crashes for complex models.
• Compatibility alignment with Qualcomm runtime versions: Matching ONNX Runtime provider bindings to expected QNN SDK / QAIRT library versions to avoid ABI mismatches or runtime errors. Qualcomm’s own release cadence for QAIRT and AI Hub indicates that runtime upgrades and ONNX runtime compatibility are continuously coordinated.
• Security and input parsing hardening: While there’s no public CVE list attached, multimedia and model input parsing improvements are often included as non‑disclosed stability and sanitization hardening in component updates. This is plausible but cannot be independently confirmed without vendor disclosure.

Important caveat: Microsoft’s KB does not publish a granular changelog, so all of the above are plausible, typical contents of a QNN EP increment rather than confirmed line‑items. Where Microsoft or Qualcomm do not publish explicit patch notes, the only definitive verification is empirical testing on affected hardware.

---

Strengths and benefits for end users and admins​

• Targeted, per‑silicon tuning: Componentized updates allow Microsoft to ship focused improvements for Qualcomm NPUs without waiting for a larger OS feature drop. That accelerates fixes and performance tuning for Copilot on-device flows.
• Automatic delivery: The package is pushed through Windows Update and will appear in Update history, simplifying distribution for consumers. Enterprise admins can track the component version via inventory tools and the Update history UI.
• Potential lower latency and power: Hardware‑tuned QNN EP improvements often lower CPU load and push more work to the NPU, reducing latency for local AI tasks and improving battery/thermal profiles on devices with capable NPUs.
• Easier developer leverage: App developers using ONNX Runtime can benefit from upstream provider improvements without bundling special runtime binaries into each app; the system component can improve app behavior platform‑wide.

---

Risks, unknowns, and practical cautions​

• Opaque changelog: The KB’s brevity is the single largest operational risk. Security and compliance teams that require CVE IDs or explicit change descriptions cannot make a purely informed decision from the KB alone. This increases the need for pilot testing. Caution: treat unspecified “improvements” as operational changes requiring validation.
• Hardware fragmentation: Not every Qualcomm SoC, OEM driver set, or firmware revision will behave the same. Gains seen on a Snapdragon X Elite reference platform may not reproduce identically on older Snapdragon variants. Validate across representative OEM images.
• Rollback complexity: Component updates that interact with driver and firmware stacks can be harder to roll back cleanly than plain LCUs. In some environments removal via DISM or Update history may be nontrivial; system restore images and pre‑update backups are recommended.
• Interoperability with OEM drivers and camera stacks: Image pipelines often touch vendor drivers (ISP, Adreno GPU, camera firmware) and conferencing apps (Teams, Zoom). If OEM drivers are out of date, the updated QNN EP may expose regressions. Update drivers first, or pilot carefully.
• Unverifiable contents: Any specific claim that this update modifies a named internal model weight, reduces latency by X%, or fixes a named bug is unverifiable from the public KB and requires vendor confirmation or device telemetry to substantiate. Flag such claims as unverified until Microsoft/Qualcomm publishes details.

---

A recommended validation checklist for IT teams (practical, sequential)​

• Confirm prerequisites:
• Ensure target devices are Copilot+ and running Windows 11, version 24H2 and that the latest cumulative update for 24H2 is installed.
• Inventory representative hardware:
• Select devices across OEMs and thermal designs (thin clamshell, convertible, performance laptop). Include at least one device with the same Snapdragon family as production units.
• Capture pre‑update baselines:
• Measure time‑to‑first‑token, steady‑state tokens/sec (for SLM/LLM flows), NPU/CPU utilization, battery drain under representative workloads, and app‑level metrics for Photos/Camera/Teams. Use reproducible workloads and record system logs.
• Deploy update in pilot:
• Allow Windows Update to install KB5067994 on pilot devices, or use the Microsoft Update Catalog/management tooling for controlled rollout. Monitor Update history to confirm package presence.
• Run verification suite:
• Re-run workloads, compare deltas, and watch Event Viewer for camera, driver, kernel, or NPU-related errors for 72 hours of typical usage. Verify Windows Hello, camera capture, conferencing background effects, and Photos operations.
• If regressions appear:
• Reinstall OEM drivers/firmware, collect logs, and if necessary roll back using a system restore or pre‑update image. Escalate to OEM and Microsoft support with diagnostic packages.
• Document and expand rollout:
• If pilot is successful, stage a phased rollout with monitoring and automated telemetry collection to detect late regressions.

---

Developer and advanced user notes​

• ONNX Runtime’s QNN EP supports a context binary cache mechanism (ep.context_enable) which can reduce session creation times by persisting compiled QNN contexts. Use this on devices where model load latency is critical. Enable with caution, and validate file storage behavior on devices with limited disk space.
• Prebuilt ONNX Runtime QNN packages on Windows may bundle necessary QNN runtime dependencies starting with certain runtime versions (ONNX Runtime notes that from some release versions you don’t need to separately download the QNN SDK for prebuilt packages). When building from source, the QNN SDK / Qualcomm AI Engine Direct SDK remains a build-time prerequisite. Validate the build or package recipe used by your app if you rely on custom ONNX Runtime builds.
• For model authors: verify operator coverage and quantization compatibility with the QNN EP. Quantized models (QDQ) are the common path for HTP/NPU execution; run your model through the provider on a development device and check session options such as disable_cpu_ep_fallback to verify full NPU mapping.

---

How to check the update on your device​

• Open Settings > Windows Update > Update history — the QNN Execution Provider component entry should appear with a label similar to QNN Execution Provider version 1.8.13.0 (KB5067994) after installation. If you do not see it, ensure the latest Windows 11 24H2 cumulative update is present and that Windows Update servicing is enabled.
• For developers and power users, ONNX Runtime session logs and Event Viewer entries will supply runtime errors or operator mapping fallbacks if the QNN EP cannot fully handle a model. Enabling detailed ONNX Runtime logging during test runs helps surface fallback paths and compilation errors.

---

Editorial assessment — why this matters to Windows users​

Microsoft’s strategy of shipping small, platform‑targeted AI component updates — Intel, AMD, Qualcomm variants — is a pragmatic tradeoff. It enables faster iteration and silicon‑specific tuning for on‑device AI, which in turn accelerates the availability of responsive Copilot features that run locally and preserve privacy. For end users, the benefits are often invisible (smoother image effects, snappier assistant responses), but the underlying engineering effort is significant.
However, the operational cost for IT teams increases: per‑silicon fragmentation, opaque change records, and potential interactions with OEM drivers require disciplined rollout and telemetry practices. Organizations should treat these component updates like any OS‑level change that touches hardware acceleration: pilot, measure, and stage.

---

Final recommendations (concise)​

• Allow the update through Windows Update for consumer devices, but monitor image, camera, and Copilot flows for regressions.
• Enterprise admins: pilot KB5067994 on representative Copilot+ hardware, validate OEM drivers/firmware compatibility, and capture telemetry before broad deployment.
• Developers: revalidate models with the QNN Execution Provider on target hardware, use ONNX Runtime’s session options to detect fallback behavior, and consider enabling QNN context caching where beneficial.
• If precise security or bug fixes are required for compliance, open a support case with Microsoft/OEMs to request more detailed disclosure; the public KB is succinct by design and may not contain all necessary forensic detail. Treat specific claims about fixed bugs or exact performance deltas as unverified until confirmed by vendor notes or measured telemetry.

---

The KB5067994 QNN Execution Provider update is a classic example of modern platform maintenance for hardware‑accelerated AI: targeted, rapidly delivered, and useful — but intentionally opaque at the engineering level, making structured validation the practical responsibility of administrators and developers who depend on predictable inference behavior for production and user experiences.

---

Source: Microsoft Support KB5067994: QNN Execution Provider AI component update (1.8.13.0) - Microsoft Support