Younghwan Na

For Accelerate, even though save_state is a powerful feature, it can be limiting for users with custom serialization workflows. Extending get_state_dict to support not just models but also optimizers, schedulers, and RNG states would provide more flexibility. Additionally, introducing a load_from_state_dict method to load these components from user-defined dictionaries would make the library more adaptable and user-friendly.

Thank you for all your hard work!

https://discuss.huggingface.co/t/proposal-to-enhance-get-state-dict-and-introduce-load-from-state-dict-for-greater-flexibility/126951

For Accelerate, it would be great to have clearer distinctions around Plugin and KwargsHandler. Understanding when to use plugins versus handlers (and their compatibility) can be confusing, especially for new users. Streamlining this would make the library even more accessible.
Thank you for all the amazing work!

https://discuss.huggingface.co/t/request-for-clarification-and-possible-refinement-of-plugin-and-kwargshandler-design/126864

One improvement I’d like to suggest is regarding the naming of the notebook_launcher function in the Hugging Face Accelerate library. While the name is descriptive of its compatibility with Jupyter Notebooks, it might unintentionally limit its discoverability and perceived scope.
The function is actually a versatile tool for spawning distributed training processes programmatically within Python, making it similar in purpose to the Accelerate CLI but in a function-based format. However, because “notebook” is in the name, new users (myself included) might assume it’s restricted to Jupyter Notebook environments.
To better reflect its broader utility, I propose renaming it to something more general, such as accelerate_launcher or distributed_launcher.

https://discuss.huggingface.co/t/proposal-to-rename-notebook-launcher-for-broader-accessibility-and-clarity/126816