-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transfer learning phases #2006
Comments
I personally like the approach of calling It allows me to have more control on how to train my model. Usually transfer learning happens on small datasets, so it's possible for the user to train some epochs, see what happens, and only then decide if it's time to unfreeze some layers or run some more epochs on the current configuration. |
Added a new proposal to OP, the scheduler interface suggested by @williamFalcon I think the main benefit of this approach is that it's easily reproducible, because we are using a list of dicts (configs), I think we can even store the scheduler into as a config file in the future. |
Another option with the scheduler, would be to pass a function to it instead of predefined actions, it would look like something like this: def phase1(trainer, model):
model.freeze()
sched = OneCycleLR(...)
trainer.new_schedule(sched)
def phase2(trainer, model):
model.unfreeze()
sched = OneCycleLR(...) # Differential LRs can be introduced here
trainer.new_schedule(sched)
sched = FineTuneScheduler([
{'func': phase1, 'epoch': 0},
{'func': phase2, 'epoch': 5},
]) This gives the user full control on what happens in these phases If you think about it, this is not even a specific We can then implement helper functions to make the definition of differential learning rates, reseting schedulers easier. But it would be up to the user to construct what we wants =) |
One thing I don't currently like about it though, is that when creating a new scheduler I also need to know the duration of the phase. Maybe we can change is signature to: def phase(trainer, model, n_epochs) |
And then, as @williamFalcon suggested again, we can implement a scheduler that is really specific to the standard transfer learning case: class FineTuneScheduler(Scheduler):
def __init__(self, pretrained, head, head_unfreeze_epoch):
...
# unfreeze head after 1 epoch
sched = FineTuneScheduler(nn.Sequential(self.c_d1, self.c_d1_bn), self.c_d2, 1)
# unfreeze head after 10 epoch
sched = FineTuneScheduler(nn.Sequential(self.c_d1, self.c_d1_bn), self.c_d2, 10) This can be easily built on top of |
I would go the scheduler way with duct config as it can be simply stored and even without load/run you can see what you did in past, kind or history notes |
@PyTorchLightning/core-contributors any other thoughts? |
When restoring a checkpoint for finetuning a model, users still need a way to reset the current_epoch and global_step to 0. Do we still need a GH issue to handle this aside from params_group and differentiable learning rate features? A hack to this was described by @lgvaz
Is there a better way? If we pass both |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Dear @lgvaz, This logic can easily be built on top of BaseFinetuning callback.
If you do implement a nice Finetuning Callback, please make a PR so the community can try it out :) Best, |
Hi @tchaton thanks for the update! Unfortunately I don't have the time to try this out right now =/ Should we leave this issue open or should we close it? |
We are not looking to add any more callbacks to core that are too opinionated, research-y, or just not applicable to most users. We suggest developing this callback in your own repository. |
🚀 Feature
When doing transfer learning we need to switch between phases.
Normally, the first phase is to freeze all but the head of the model and train only that.
After a predefined amount of epochs, we unfreeze the rest of our model (or a part of it) and start training again (possibly with the help of differential learning rates, described in #2005). We can repeat this phase as many times as we like.
We should implement a class that handles all of that for us, this includes:
lr_scheduler
parameters between phasesLearningRateLogger
is being used, register the newlr_scheduler
#2005 Will take care of the parameter groups
This will take care of what I call "phase switches"
Proposals
There are some ways of achieving this:
Logic inside
on_epoch_start
We can keep adding as many milestones as we want this way, but it's important to note that they all have to be define beforehand.
Multiple calls to
Trainer.fit
This is exactly the flow on fastai, this way of training model is excellent for iterative training, like on a notebook or a REPL.
fit_one_cycle assumes that we are using the OneCycleLR scheduler, assumes that each call is a continuation of the last, and assumes we want to reset our schedule
When we pass a slice to lr we are asking for a interpolation of values between the trainable layer groups
Implement a new scheduler (suggested by @williamFalcon)
The scheduler receives a list of dicts, each dict will specify the duration of the phase and it's configuration (what layers to freeze, what lrs to use, ...)
Then we can just pass the scheduler to the
Trainer
.Notes
In both cases, the flow should be the same for all standard areas (vision, nlp, time-series,...).
The only things we assume is:
The text was updated successfully, but these errors were encountered: