[Transform] Support separating v and u transforms of quip

[kylesayrs]

Purpose

• Support rotation argument with QuIPModifier which allows users to select V and U rotations separately.
  • According to research, the default can be changed to V after a basic recovery evaluation is done

Changes

• Add rotations argument
• Updated docstrings and comments to remove references to spinquant

Testing

• Tested model coherence with V and U separately

[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.

[gemini-code-assist]

Summary of Changes

Hello @kylesayrs, 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 introduces the ability to independently control V and U transformations within the QuIPModifier, allowing for more granular control over the quantization process. It refactors the internal logic to support this new flexibility and updates relevant documentation and examples.

Highlights

• Enhanced QuIPModifier Flexibility: The QuIPModifier now accepts a rotations argument, allowing users to specify whether to apply 'v' (input side) and/or 'u' (output side) rotations independently during the QuIP transformation.
• Code Refactoring for Modularity: The internal logic for creating transform schemes within QuIPModifier has been refactored into dedicated _create_v_scheme and _create_u_scheme methods, improving code organization and maintainability.
• Documentation and Example Updates: Docstrings and comments have been updated to reflect the new rotations parameter and clarify the QuIPModifier lifecycle. An example script (quip_example.py) was also updated to demonstrate the new functionality and align with current best practices (e.g., dtype instead of torch_dtype).

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 introduces a valuable enhancement to the QuIPModifier by allowing separate control over the 'v' and 'u' transforms via a new rotations argument. The changes are well-implemented, including updates to docstrings, a new field validator for robustness, and a clean refactoring of the configuration creation logic. The accompanying example has also been updated to reflect the new functionality. Overall, this is a solid contribution that improves the flexibility of the QuIP transform.

[brian-dellabetta]

awesome!

[rahul-tuli]

Few nits and a dumb question, but looks good otherwise!