Skip to content

feat: add --allow-unsupported-nodes to perf/build/eval/run#821

Merged
xieofxie merged 5 commits into
mainfrom
hualxie/fix_ov_gpu_another
Jun 8, 2026
Merged

feat: add --allow-unsupported-nodes to perf/build/eval/run#821
xieofxie merged 5 commits into
mainfrom
hualxie/fix_ov_gpu_another

Conversation

@xieofxie

@xieofxie xieofxie commented Jun 8, 2026

Copy link
Copy Markdown
Contributor

Problem

winml perf -m depth-anything/Depth-Anything-V2-Small-hf --task depth-estimation --ep openvino --device gpu aborts at the optimize/analyze loop:

RuntimeError: Unsupported nodes persist after N analyze pass(es): ['OP/ai.onnx/Resize']

The static analyzer flags nodes the target EP doesn't fully support (e.g. Resize on OpenVINO GPU), so the build raises — even though the EP can still run the model (CPU fallback for those nodes).

Change

Add an opt-in --allow-unsupported-nodes flag that turns the hard failure into a warning and lets the build proceed. The gate lives at the single raise in build/common.py:

if analysis is not None and analysis.has_errors:
    message = f"Unsupported nodes persist after {analyze_iterations} analyze pass(es): ..."
    if allow_unsupported_nodes:
        logger.warning("%s. Continuing anyway ...", message)
    else:
        raise RuntimeError(message)

The flag is a shared CLI option (cli_utils.allow_unsupported_nodes_option()) applied to every command that builds a model via WinMLAutoModel.from_*:

Command Path Status
winml perf BenchmarkConfigfrom_pretrained/from_onnx; --modulebuild_hf_model ✅ verified e2e
winml build _run_optimize_stagerun_optimize_analyze_loop; module mode → build_hf_model ✅ verified e2e
winml eval WinMLEvaluationConfig.allow_unsupported_nodesfrom_pretrained
winml run InferenceEngine.load_load_from_hffrom_pretrained plumbed (command currently disabled)

ONNX / skip_build load paths don't run the analyzer, so they're untouched. Default is False everywhere — strictly opt-in. Named --allow-unsupported-nodes (not a generic --force) since it gates exactly this analyzer check.

Verification

  • winml perf ... --ep openvino --device gpu --allow-unsupported-nodes → builds, compiles on OV GPU, benchmarks (~15.9 ms avg).
  • winml build ... --ep openvino --device gpu --allow-unsupported-nodes → logs the warning (['OP/ai.onnx/Resize']) and completes.
  • New/updated unit tests cover the gate (build/test_common.py), and flag passthrough for build/eval/run; full commands + inference + build + eval suites pass (871 tests).

🤖 Generated with Claude Code

…rors

The optimize/analyze loop raises "Unsupported nodes persist after N analyze
pass(es)" when the static analyzer reports nodes the target EP doesn't
support (e.g. Resize on OpenVINO GPU), which aborts the build even though
the EP can run the model via CPU fallback.

Add an opt-in allow_unsupported_nodes flag that logs a warning instead of
raising, threaded from the new `winml perf --allow-unsupported-nodes` CLI
flag through WinMLAutoModel.from_pretrained/from_onnx and
build_hf_model/build_onnx_model down to run_optimize_analyze_loop. Default
is False, so existing behavior is unchanged.
@xieofxie xieofxie requested a review from a team as a code owner June 8, 2026 02:24
@xieofxie

xieofxie commented Jun 8, 2026

Copy link
Copy Markdown
Contributor Author

Note: although AI says (CPU fallback for those nodes) , the op profiler find that gpu supports it as interpolate type

hualxie added 2 commits June 8, 2026 11:41
Mirror the perf-command flag on the build command. The build command runs
its own pipeline orchestration (_run_optimize_stage -> run_optimize_analyze_loop)
for single-model HF/ONNX builds and delegates to build_hf_model for module
mode, so thread allow_unsupported_nodes through all three paths.

When set, the optimize/analyze loop logs a warning instead of raising on
persistent unsupported nodes (e.g. Resize on OpenVINO GPU). Default False,
so existing behavior is unchanged.
Extract the flag into a reusable cli_utils.allow_unsupported_nodes_option()
decorator and adopt it in perf and build (replacing the inline options).

Apply the same flag to the other commands that build via WinMLAutoModel.from_*:
- eval: new WinMLEvaluationConfig.allow_unsupported_nodes field, auto-mapped
  from the CLI and forwarded to from_pretrained in eval._load_model.
- run: threaded through InferenceEngine.load -> _load_from_hf -> from_pretrained
  (the run command is currently disabled, but the engine plumbing is shared).

ONNX/skip_build load paths don't run the analyzer, so they are left untouched.
Default remains False everywhere.
@xieofxie xieofxie changed the title feat(perf): add --allow-unsupported-nodes to continue past analyze errors feat: add --allow-unsupported-nodes to perf/build/eval/run Jun 8, 2026
Comment thread src/winml/modelkit/inference/engine.py
Comment thread src/winml/modelkit/commands/build.py Outdated
Comment thread tests/unit/build/test_common.py Outdated
- engine.load docstring: note the flag has no effect on pre-built ONNX /
  cached build-dir load paths (no analyze step runs there).
- build: always set extra_kwargs['allow_unsupported_nodes'] (even when False)
  so the downstream .pop default isn't load-bearing and both build paths match.
- test_common: pin caplog.at_level to the build.common logger.
Comment thread src/winml/modelkit/models/auto.py
Comment thread src/winml/modelkit/models/auto.py
- auto.from_pretrained: pass allow_unsupported_nodes to the composite-model
  dispatch (WinMLCompositeModel.from_pretrained); it was a named param, so it
  was silently dropped for composites (T5, Qwen, ...).
- auto.from_onnx: declare allow_unsupported_nodes as an explicit keyword-only
  param (parallel to skip_build) instead of relying on **kwargs, and forward
  it explicitly to build_onnx_model; documented it.
- Tests: HF/composite/onnx forwarding all reach the build call.
@xieofxie xieofxie merged commit e32507d into main Jun 8, 2026
9 checks passed
@xieofxie xieofxie deleted the hualxie/fix_ov_gpu_another branch June 8, 2026 07:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants