support input shapes export

[danielliuce]

What does this PR do?

Fixes Issue # 1581

Tested with command:
optimum-cli export openvino -m microsoft/resnet-50 --batch_size 1 --num_channels 3 --height 224 --width 224 static_shapes and looked at the OpenVINO IR to see that the input shapes were the same as specified

Tested with
optimum-cli export openvino -m microsoft/resnet-50 testing and looked at the OpenINO IR to see that the input shapes were -1 indicating that they were dynamic

Inspected the OpenVINO XML IR and saw that the input shapes were static and specified

Before submitting

• This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
• Did you make sure to update the documentation with your changes?
• Did you write any new necessary tests?

[rkazants]

This is not needed. You can always use reshape method for ov.Model to set static shapes, for example.

[danielliuce]

This is not needed. You can always use reshape method for ov.Model to set static shapes, for example.

Does that mean this TODO here

is stale and specifying input_shapes through the cli will not be added in the future?

I believe it may be nice to allow users to specify static input shapes through the optimum CLI directly instead of having to use the OpenVINO APIs after doing optimum-cli export openvino...

Original ticket

[echarlaix]

Makes sense to me to leave the possibility for users to specify the input shapes to use during model conversion via the CLI, like what we have with ONNX https://github.com/huggingface/optimum-onnx/blob/v0.1.0/optimum/commands/export/onnx.py#L259
Can be useful for users who only uses the CLI + for cases where the inputs shapes can have an impact on the resulting model (for example for LongT5 conversion depending on sequence_length)

optimum-cli export openvino --model microsoft/resnet-50 --batch_size 2 --num_channels 3 --height 224 --width 224 output_dir

@rkazants @danielliuce what do you think ?

[danielliuce]

Makes sense to me to leave the possibility for users to specify the input shapes to use during model conversion via the CLI, like what we have with ONNX https://github.com/huggingface/optimum-onnx/blob/v0.1.0/optimum/commands/export/onnx.py#L259 Can be useful for users who only uses the CLI + for cases where the inputs shapes can have an impact on the resulting model (for example for LongT5 conversion depending on sequence_length)

optimum-cli export openvino --model microsoft/resnet-50 --batch_size 2 --num_channels 3 --height 224 --width 224 output_dir

@rkazants @danielliuce what do you think ?

I agree.
I originally made it a key value pair dict with input_shapes --input-shapes '{"batch_size": 1, "num_channels": 3, "height": 224, "width": 224}', but I think what you propose is cleaner.
It also aligns with what onnx does with optimum-cli, so I will implement it this way!

[HuggingFaceDocBuilderDev]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[rfrohar]

For the sake of usability and maintainability, I believe we should ensure consistency across the optimum-cli utility. OpenVINO should use argument names and conventions similar to other backends like ONNX.

Treating OpenVINO differently introduces confusion for users, complicates documentation and automation, and makes the CLI harder to maintain. Unless there’s a strong technical reason, I recommend aligning OpenVINO’s interface with the established patterns used by other tools.

[rkazants]

For the sake of usability and maintainability, I believe we should ensure consistency across the optimum-cli utility. OpenVINO should use argument names and conventions similar to other backends like ONNX.

Treating OpenVINO differently introduces confusion for users, complicates documentation and automation, and makes the CLI harder to maintain. Unless there’s a strong technical reason, I recommend aligning OpenVINO’s interface with the established patterns used by other tools.

optimum-onnx is not a reference for us. input_shapes can be set through inference APIs of OpenVINO GenAI using reshape method when you know which input is expected. I think that optimum-cli should output generic IRs for the input model. I vote for minimal set of parameters for conversion because it mitigates problems with using IRs for incorrect input shape data, for example, and we need to establish additional regular validation for this option.
Now we have a clear way to set static shape and it is validated well and is quite enough.

[danielliuce]

For the sake of usability and maintainability, I believe we should ensure consistency across the optimum-cli utility. OpenVINO should use argument names and conventions similar to other backends like ONNX.
Treating OpenVINO differently introduces confusion for users, complicates documentation and automation, and makes the CLI harder to maintain. Unless there’s a strong technical reason, I recommend aligning OpenVINO’s interface with the established patterns used by other tools.

optimum-onnx is not a reference for us. input_shapes can be set through inference APIs of OpenVINO GenAI using reshape method when you know which input is expected. I think that optimum-cli should output generic IRs for the input model. I vote for minimal set of parameters for conversion because it mitigates problems with using IRs for incorrect input shape data, for example, and we need to establish additional regular validation for this option. Now we have a clear way to set static shape and it is validated well and is quite enough.

Thanks for the response.
Just to make sure I understand,
To summarize:

• You are proposing that users use optimum-cli export openvino to download a model from huggingface into OpenVINO IR with dynamic shapes, and if they know the input shapes, to write an additional Python/C++ OpenVINO snippet that converts this IR into IR with static input shapes. and then finally able to use this IR, as opposed to letting them specify the input shapes directly.
• And the reasoning for this is because there would be too much validation / testing needed for users to optionally specify the static input shapes through the CLI?

Is my understanding correct?