Description
Users see the following warning during winml compile and winml perf when QNN EP features are active:
The requested API version [24] is not available, only API versions [1, 23] are supported in this build.
Current ORT Version is: 1.23.4
The warning is non-fatal (execution continues via fallback), but it is alarming and erodes trust in the tool output.
Root Cause
A dependency version split in pyproject.toml causes two ORT packages with incompatible API versions to be installed side-by-side:
| Dependency |
Pin |
Max ORT API |
onnxruntime-windowsml (line 38) |
>=1.23.2, <1.24.0 |
23 |
onnxruntime-qnn (line 88, [qnn] extra) |
>=1.24.1 |
24 |
When the [qnn] extra is installed, two code paths load ORT 1.24.x native libraries that request API version 24 from the onnxruntime-windowsml 1.23.x runtime — which only supports up to API 23:
session.py:272 — ort.ModelCompiler(sess_options, ...) is part of the ORT 1.24.x C API surface. The native layer emits the warning when it cannot satisfy the API 24 request.
qairt_session.py:188 — from onnxruntime.tools.qnn import gen_qnn_ctx_onnx_model imports a module shipped with onnxruntime-qnn 1.24.x, triggering the same API 24 initialization path.
The ModelCompiler call is already wrapped in a try/except at session.py:285–287 and falls back gracefully — but the native-layer warning prints to stderr before the Python fallback runs, so users always see it.
Steps to Reproduce
pip install winml-modelkit[qnn]
winml compile -m model.onnx --ep qnn -o output/
# or
winml perf -m ProsusAI/finbert --device npu
Expected Behavior
No warning. Either:
- The ORT packages are version-aligned so API 24 is available when requested, or
- The warning is suppressed at the call sites since the fallback already handles it cleanly.
Proposed Fix (two options)
Option A — Align dependency versions (preferred long-term):
Bump onnxruntime-windowsml to >=1.24.0 to match onnxruntime-qnn>=1.24.1. Requires verifying no breaking API changes affect the rest of the codebase.
Option B — Suppress at call sites (short-term):
Wrap the ort.ModelCompiler instantiation and gen_qnn_ctx_onnx_model import in stderr suppression (similar to the existing _suppress_native_output context manager already used at session.py:277) so the ORT native warning is swallowed since the Python-level fallback already handles the failure gracefully.
Environment
onnxruntime-windowsml: 1.23.4
onnxruntime-qnn: 1.24.1+
- OS: Windows 11
Related Files
Description
Users see the following warning during
winml compileandwinml perfwhen QNN EP features are active:The warning is non-fatal (execution continues via fallback), but it is alarming and erodes trust in the tool output.
Root Cause
A dependency version split in pyproject.toml causes two ORT packages with incompatible API versions to be installed side-by-side:
onnxruntime-windowsml(line 38)>=1.23.2, <1.24.0onnxruntime-qnn(line 88,[qnn]extra)>=1.24.1When the
[qnn]extra is installed, two code paths load ORT 1.24.x native libraries that request API version 24 from theonnxruntime-windowsml1.23.x runtime — which only supports up to API 23:session.py:272—ort.ModelCompiler(sess_options, ...)is part of the ORT 1.24.x C API surface. The native layer emits the warning when it cannot satisfy the API 24 request.qairt_session.py:188—from onnxruntime.tools.qnn import gen_qnn_ctx_onnx_modelimports a module shipped withonnxruntime-qnn1.24.x, triggering the same API 24 initialization path.The
ModelCompilercall is already wrapped in a try/except atsession.py:285–287and falls back gracefully — but the native-layer warning prints to stderr before the Python fallback runs, so users always see it.Steps to Reproduce
pip install winml-modelkit[qnn] winml compile -m model.onnx --ep qnn -o output/ # or winml perf -m ProsusAI/finbert --device npuExpected Behavior
No warning. Either:
Proposed Fix (two options)
Option A — Align dependency versions (preferred long-term):
Bump
onnxruntime-windowsmlto>=1.24.0to matchonnxruntime-qnn>=1.24.1. Requires verifying no breaking API changes affect the rest of the codebase.Option B — Suppress at call sites (short-term):
Wrap the
ort.ModelCompilerinstantiation andgen_qnn_ctx_onnx_modelimport in stderr suppression (similar to the existing_suppress_native_outputcontext manager already used atsession.py:277) so the ORT native warning is swallowed since the Python-level fallback already handles the failure gracefully.Environment
onnxruntime-windowsml: 1.23.4onnxruntime-qnn: 1.24.1+Related Files
ModelCompilercall + fallbackgen_qnn_ctx_onnx_modelimport