fairseq
fairseq copied to clipboard
fairseq v2
fairseq v2
Hi everyone,
We wanted to let you know that FAIR will soon kick off the fairseq v2 project in order to modernize our code base and to address fairseq’s long standing structural and technical issues. Our high-level goals are for fairseq to:
- have a clean, maintainable, well-tested code base that leverages the latest features of PyTorch and its ecosystem.
- preserve the performance optimizations of the original fairseq that have accumulated throughout the years.
- enforce user code to be separate from library code via well-defined APIs so that it can be used both as a framework and as a library.
- offer a familiar interface for researchers used to the original fairseq.
- come with new fault-tolerant features and tools for large-scale training and inference.
Note that, although our aim is to keep them at a minimum, in order to realize some of our goals we will be making backwards-incompatible changes, mostly in our trainer and data loading APIs. Along with these changes we also plan to offer a large set of extensibility APIs that will mitigate the need to fork/branch fairseq in majority of use cases.
We will share our pre-release versions in the upcoming months and will be looking forward to your feedback. In the meantime you can follow our GitHub Issues page to track our progress.
Thank you!
FAQs
Should I keep using fairseq right now? What will happen to my work when fairseq v2 gets released? Yes, please continue using fairseq. fairseq, as it is today, already provides a great set of features for researchers. None of that is going away. As we mentioned, there will be backwards-incompatible changes, but the procedure to migrate an existing work to fairseq v2 will be clearly documented and our goal is to confine it to mostly syntactical updates and minor refactorings.
Will fairseq v2 have feature-parity with fairseq? The official v2 release at the end of the project will have feature-parity with fairseq. Our pre-release versions will start with a smaller set of features and then gradually increase the scope until we have full coverage of fairseq features.
What will happen to current fairseq? Till we officially release v2 we will continue to support and maintain the current fairseq. However we won’t accept any PRs besides critical bug fixes and minor feature improvements (mostly to unblock ongoing research projects). The release of v2 will be an in-place update, meaning we will be using the fairseq repository and its main branch to host our next version. After that point for researchers that need access to the original fairseq, there will be a “v1” branch in the fairseq repository. Note though that once v2 is officially released, the original version won’t be maintained anymore.
How can I test fairseq v2? In the upcoming months we will communicate on our GitHub Issues page when pre-release versions of fairseq v2 are ready to download and test.
Hi @cbalioglu , good to know fairseq v2 is coming. in the v2, fairseq should think about how to integrate with huggingface models (train from huggingface models) That could be useful.
PLZ, making easily...!
nowadays, i`m always using huggingface 😥
So glad to know fairseq v2 is coming !
Currently, I am familiar with Huggingface/transformers
and a rookie for fairseq
. I find it easy to extend transformers
but a little bit hard for fairseq
. From my personal perspective, a detailed and thorough document and code decomposability are what I want.
Great to see effort being made in this direction and not just abondening fairseq all together which felt like it with the release of metaseq. A few suggestions:
- Please make arguments accessible globally to avoid piping arguments through multiple levels of inheritance and have one consistent way of adding arguments and setting their defaults, it is one of the most annoying things currently. In its current version, we mix argument defaults in
argparse
, registering architectures and setting defaults there, configs (with the most recent changes), or just usinggetattr
with defaults throughout the codebase. With arguments being accessible everywhere, class/method signatures also remain way more concise than they currently are. - Also I'd generally argue that less inheritance and integrating functionality into existing procedures with flags is often beneficial for maintainability and to avoid jumping between multiple files.
- From a code-organization standpoint, it probably would make sense to have
shared
folders containing modules like linears, dropout, multi-head attention, and even combinations of those like the transformer but we should also consider having split-off folders for specific use-cases i.e. machine translation, language modeling, speech, etc. This would allow sub-communities to contribute (mostly) only to these respective parts and make things a little bit more maintainable from a PR perspective. - Please add a linting/formatting workflow to PR's and general contributions to have a consistent codebase.
Feel free to reach out in case you want any more feedback or contributors to the current architecture drafts of fairseq v2, I'd be happy to help out as I'm a heavy user of fairseq v1!
Please keep an eye on torch JIT export: as today, transformers in v1 are not exportable: https://github.com/facebookresearch/fairseq/issues/4459
Is there are plan to support external maintainers/contributors? I was discussing the possibility of being an external maintainer with Myle some time ago, but it sorted of petered out. Many Meta-external PRs go unmerged in the current fairseq which is discouraging and can hurt adoption. I'm happy to continue this conversation as appropriate.
I'm hopeful that going forward, regular versions can be cut for fairseq v2 as well. Backwards compatibility is very iffy with the current fairseq and since there are no regular versions being cut, often I have to tote around commit hashes as a proxy which can be a bit of a headache.
Thrilled to hear that fairseq is getting a re-release. I think it's a great idea to keep the core library and implemented papers separate as in its current state the repo can be quite overwhelming. One of the things I'd suggest is perhaps more tutorials on how the library is built and how one can alter/extend individual components of a full model (that cannot be easily adapted with command line options, so input/output, search etc.). While figuring it out on your own is a lot of fun, I think it can be frustrating to new users of fairseq.
Looking forward to fairseq-v2! Is there any ETA on the v2 release?
Hey everyone, sorry for the delay in checking your messages! Thanks a lot for all your feedback so far! Hope the new version will address most of your concerns raised here.
@awan-10 we plan to have an early release before the end of the year. Most likely in December so that we can start gathering more concrete feedback and also start accepting external contributions.
@erip I see no reason for not supporting external maintainers/contributors. Quite contrary I believe it is critical for the project to be as open as possible if we want it succeed (similar to PyTorch). In the new version we will have a proper CODEOWNERS model which will be open to anyone willing to commit to the project. I will get in touch with you once we get close to the first public release.
This is great news! I just wanted to point out that @st-vincent1 raises a very important point, which is that currently fairseq v1 is somewhat lacking with regards to both tutorials and code documentation. This is something that you get used to if you have spent multiple years working with fairseq (although there are still many things which I don't quite grasp due to the lack of code documentation), but I find it is a big problem for new students joining my lab.
Hello I wonder how is the progress now? Really expect to hear some news!
Hey folks, sorry for the late reply. We have been making good progress internally, but there had been some slowdowns as well which shifted our initial estimates by a few months. We are going to release a beta version in the first half of this year. The exact timing is not set yet, but I will post it to this thread as soon as we have a date.
Will fairseq-v2 support Pytorch2.0?
Will fairseq-v2 support Pytorch2.0?
Yes, we will specifically support torch.compile()
and other bells-and-whistles of PT2.
@cbalioglu any update on the time for v2 release.
Really looking forward to the new framework as a v1 user!
Hey @sukuya @yizhilll thanks a lot for your interest! We are still actively working on the next version. Based on our internal roadmap, the beta release will be in summer, most likely sometime between end of June and beginning of August. I will keep you posted once we finalize the dates!
At the risk of sounding a bit pointed: is there a reason the development is happening like a closed-source project instead of an open-source one? Many of us would love to help make the toolkit better but if we just get quarterly teasers about internal development, it's hard to believe that anything is going to change regarding the governance of fairseq.
When will v2 version be completed? Any new updates?
Thanks, looking forward to it!
any update on v2?
Hey everyone, sorry for the delays in my replies. We have finally open sourced an early version of fairseq2 (https://github.com/facebookresearch/fairseq2) along with the SeamlessM4T project (this is also why it was closed-source till today). Note that documentation and training recipes are not in the repo yet, but will be gradually merged in the next few weeks. In the meantime you can check out the models directory, SeamlessM4T, and SONAR repositories to get a sense of how modeling works in fairseq2. We also have a pretty advanced C++ based data pipeline API that is already landed with this initial release. Its documentation will also follow pretty soon.
Obviously your feedback would be greatly appreciated. In the following days I will share our backlog/roadmap in fairseq2 repository. Please don't hesitate to reach out to me as well if you have specific questions.
Cheers!