Skip to content
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

Consider refactor to PyTorch Lightning #498

Open
addisonklinke opened this issue Aug 12, 2022 · 2 comments
Open

Consider refactor to PyTorch Lightning #498

addisonklinke opened this issue Aug 12, 2022 · 2 comments

Comments

@addisonklinke
Copy link

addisonklinke commented Aug 12, 2022

Disclaimer: I have no affiliation with PyTorch Lightning, just an industry professional who wishes more research projects would make use of it 🙂

For v7 (or future YOLO versions), would you consider refactoring the code base to PyTorch Lightning? It is a much more organized way of presenting logic than vanilla PyTorch. This would make it significantly easier for other researchers/practitioners to re-use portions of your work without having to copy all dependencies of the original repository. From the maintainer's perspective, some additional benefits are that Lightning

  • Handles all the engineering pieces (DDP, mixed-precision, hardware accelerators, etc) which saves you a lot of (potentially error-prone) boilerplate code like this
  • Allows you to add auxiliary logic to the training process via callback hooks
    • For example, monitoring performance metrics to save model checkpoints: current > refactored
  • Sets up optimizers and LR schedulers in a declarative way
  • Integrates with most common logging/experiment tracking frameworks, including WandB

Note: related work was completed for v3/4 in Lightning-Universe/lightning-bolts#552

@Chris-hughes10
Copy link

I think organising the codebase would be an excellent idea! As an alternative, I am the author of a lightweight library called PyTorch-accelerated, which I believe would require a lower refactoring effort than moving to Lightning as no changes would be required to the model or the datasets; the main refactoring effort required would be replacing the training logic with an implementation of a Trainer class.

If there interest in doing this @WongKinYiu @AlexeyAB, I could dedicate some time to assist with this effort; I have previously migrated the YoloX codebase which is very similar in many regards.

@Chris-hughes10
Copy link

An update on this, myself and a colleague decided to undertake this effort. The results are detailed in this blog post, and the refactored code is in this repo.

Our implementation is compatible with the pretrained weights and is more aimed at people who want to understand Yolov7 under the hood or extend it for non-COCO use-cases, as opposed to replicating every detail of this repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants