[Entrypoints] initialize processor error handling

[brian-dellabetta]

SUMMARY:
Resolves #1795

• [Bug]: MistralCommonTokenizer not supported #1795

Currently, we initialize a processor in entrypoint pre_process even if one isn't provided, even though it isn't needed for data-free recipes like FP8_DYNAMIC or W4A16, causing downstream user issues like #1795. This updates pre-processing to

• wrap processor initialization in a try/catch
• error out if initialization fails and a processor is required (i.e. if a dataset is needed for training/calibration)
• otherwise, log a warning if an output_dir is provided, because the processor will not be saved with the trained/compressed model.

TEST PLAN:
Example script in #1795 succeeds on this branch, confirmed error is raised if output_dir is set and error is raised if dataset is set.

[gemini-code-assist]

Summary of Changes

Hello @brian-dellabetta, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses an issue where the system would attempt to initialize a processor even when no dataset was provided, causing errors for data-free operations. The changes ensure that processor initialization only occurs when a dataset is present, streamlining the pre-processing flow and preventing unnecessary resource allocation.

Highlights

• Conditional Processor Initialization: The system will now only initialize a processor during pre-processing if a dataset is explicitly provided. This resolves an issue where processors were unnecessarily initialized for data-free recipes, leading to user issues.
• pre_process Function Signature Update: The pre_process function in train.py and utils.py has been updated to accept dataset_args, enabling the new conditional logic.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request aims to prevent the initialization of a processor when no dataset is provided, which is useful for data-free recipes. The changes involve passing dataset_args to the pre_process function and adding a condition to only initialize the processor if a dataset is specified. The overall approach is correct, but I've identified a potential issue where specifying a dataset via dataset_path might not be handled correctly by the new condition. I've left a comment with a suggestion to make the check more robust. Please also note that get_processed_dataset in src/llmcompressor/datasets/utils.py seems to have a related issue where it only checks for dataset_args.dataset and might need to be updated to fully support dataset_path.

[fynnsu]

LGTM (although fix the gemini issue)

[github-actions]

👋 Hi! Thank you for contributing to llm-compressor. Please add the ready label when the PR is ready for review.

Note: This is required to complete the testing suite, please only add the label once the PR is code complete and local testing has been performed.

[shanjiaz]

Makes a lot of sense to me! Could you add the fix Gemini proposed? Thanks!

[kylesayrs]

Can we check that not saving the processor doesn't break loading in vllm?

[shanjiaz]

Thanks for adding the warnings!