Provide the ability to instantiate the model using the config file generated with LightningCLI

[mouroutzoglou]

🚀 Feature

Provide to the user some new interface, or modify the existing LightningCLI so that a model can be instantiated for testing/deployment/demos/notebooks/etc using a config.yaml (e.g., the same one generated during training).

Perhaps LightningCLI can have an extra command (besides fit, etc) that only returns the instantiated model, and perhaps the dataloaders.

Motivation

Currently, pytorch lightning lacks this feature (or it's well hidden!). What's the purpose of having modular training setups if you can't instantiate the trained model (for applications mentioned above) using the configs files you trained with. LightningCLI is rather limiting in that sense.

cc @Borda @carmocca @mauvilsa

[mauvilsa]

Instead of using config.yaml (which is only intended for reproducibility) it might be better to extend save_hyperparameters and load_from_checkpoint so that they are compatible with LightningCLI. I think it wouldn't be complex. To avoid the save_hyperparameters logic to import from pytorch_lightning.cli, it could have a custom hyper-parameter provider (maybe context var?) so that the CLI can provide the hyper-parameters dict. Something similar could be done for load_from_checkpoint which would use a custom hyper-parameter loader.

[carmocca]

@mauvilsa Wouldn't that hyper-parameter provider load the hyper-parameters from a YAML file anyways?

[mauvilsa]

It wouldn't be loaded from a yaml file. This would happen on instantiation of the LightningModule class. The CLI would take it from self.config.model and that is what save_hyperparameters would get as a dict. At this point no config has been saved to disk. This will also mean that hparams.yaml would have the model's config.

[maxfreu]

You can parse your config using e.g. cfg=Omegaconf.load(..) and then do ModelClass(**cfg.model)

[mauvilsa]

I created pull request #18105 with an initial implementation for what I proposed in #15427 (comment). Note that this loads from a checkpoint, not from a config. @mouroutzoglou you had in mind instantiating from a config. Does loading from a checkpoint resolve your needs? or is it really necessary to only instantiate without loading any weights?

[leonmkim]

Just ran into this issue today. Expected the pl_module to take in hyper_parameters from the checkpoint to initialize, but it instead used my default config values which were different and resulted in a different architecture and failure of loading of state dict. Would love to see this feature added!