openvinotoolkit
Use storage scopes when determining train-only modules
Changes
When replacing only non-train-only modules, check the scopes of the modules we iterate on against the scopes corresponding to the storage of the module, not the execution module call stack of the op.
Reason for changes
Some PT models may be written in such a fashion that a given submodule calls a certain other submodule in the model, but at the same time does not contain it in the storage hierarchy (see the test case in the PR for an explicit example of such a model). In this case the storage scope does not coincide with the execution scope of the operations; this also causes problems during module traversal in replace_modules.
Related tickets
75373
Tests
tests.torch.test_nncf_network.test_wrapping_of_indirect_module_operations
I wonder how ignored_scope and target_scope will work in case of such model. Am I right, that everything will be in storage-mode now: scopes in original and compressed graphs, scopes in log? User will never know that there's execution-mode scope, will he?
No, in fact, the storage scope comparisons are limited to determining the train-only modules and referencing their scopes against the storage scope that is being tracked during the one-time replacement process with NNCF-wrapped ones. The user would probably have to specify storage scope if they really want to not wrap a part of the model, but otherwise all the other ignored scopes and target scopes are still specified in terms of what is visible in the compressed_graph.dot, i.e. in terms of the execution scope.
No, in fact, the storage scope comparisons are limited to determining the train-only modules and referencing their scopes against the storage scope that is being tracked during the one-time replacement process with NNCF-wrapped ones. The user would probably have to specify storage scope if they really want to not wrap a part of the model, but otherwise all the other ignored scopes and target scopes are still specified in terms of what is visible in the compressed_graph.dot, i.e. in terms of the execution scope.
It makes sense to document this, it can be not obvious even for developers after a while