[executor_runner] Add --input_shapes to run dynamic-shape models below their upper bound

[msluszniak]

Summary

prepare_input_tensors() sizes every input from the bound recorded in the method metadata, so a model exported with dynamic shapes can only ever be executed at its upper bound from executor_runner. There is no flag to request a smaller shape, and --inputs files must match nbytes() of the bound, so there is no way to supply one indirectly either.

That matters more than it might sound. The upper bound is precisely the shape at which a whole class of backend bug is invisible:

• an op that never resizes its output is correct at the bound, because the built extents already are the right ones;
• a kernel whose launch geometry is derived at build time but recomputed at runtime agrees with itself at the bound and disagrees below it.

Neither can be reproduced from this runner today.

Change

Add --input_shapes, taking a comma-separated shape per input with dims joined by x:

--input_shapes="1x144x200,1x256x98,1x50x256,1x1x98,1x1x200,1,1"

Inputs are resized after prepare_input_tensors() and before execute(). Input files stay upper-bound sized and the surplus is simply not read, so existing invocations keep working unchanged and no new file plumbing is needed.

The resize is factored into one helper called from both input-preparation sites (the --server_mode loop and the normal path).

Why it is worth having

I used this flag to find and confirm four ET-VK dynamic-shape bugs, every one of which is correct at the bound and wrong below it:

bug	symptom below the bound
squeeze_copy.dims on dim 0 never resizes (#22409)	~half the output zeroed
embedding / index_select pass nullptr resize fns (#22410)	stale extents reach consumers
reduce NWORKERS spec constant vs launch (#22348)	reduces over uninitialized shared memory
buffer softmax, same pattern (#22349)	tree reduction folds in unwritten slots

The two nworkers bugs produced NaN sentence embeddings for any input under 31 tokens on real published models, and were undetectable at the bound.

Testing

Built for Android arm64 and exercised on a Galaxy S26 Ultra across four models and shapes from the minimum up to the bound. Verified that omitting the flag reproduces exactly the previous behaviour, and that with the flag the outputs match CPU references at shapes well below the bound.

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/22411

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

⚠️ 20 Awaiting Approval

As of commit 45b5b1f with merge base 519b740 ():

AWAITING APPROVAL - The following workflows need approval before CI can run:

• Build Aarch64 Linux CUDA Wheels (gh)
• Build Aarch64 Linux Wheels (gh)
• Build documentation (gh)
• Build Linux CUDA Wheels (gh)
• Build Linux Wheels (gh)
• Build macOS Wheels (gh)
• Build Presets (gh)
• Build Windows Wheels (gh)
• Lint (gh)
• periodic (gh)
• pull (gh)
• Test ARM Backend (gh)
• Test CoreML Backend (gh)
• Test Cortex-M Backend (gh)
• Test NXP Backend (gh)
• Test QNN Backend (gh)
• Test QNN Windows MSVC build (gh)
• Test Vulkan Backend (gh)
• Test WebGPU Backend (gh)
• Test XNNPACK Backend (gh)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.