-
Notifications
You must be signed in to change notification settings - Fork 6.6k
[WIP] Refactor Model Tests #12822
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
base: main
Are you sure you want to change the base?
[WIP] Refactor Model Tests #12822
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent stuff! S
ome general comments:
- Normalize the model outputs to a common format before they go to
torch.allclose(). - Initialize the input dict newly before passing to a new initialization of the model with
torch.manual_seed(0). This is because some autoencoder models take ageneratorinput. - Use fixtures wherever possible to reduce boilerplate and take advantage of
pytestfeatures.- One particular session-level fixture could be
base_output. It should help reduce test time quite a bit.
- One particular session-level fixture could be
- Use
pytest.mark.parametrizewhere possible.
Okay for me to do in a future PR but:
- Should also account for the attention backends.
- Should we also do a cross between CP and attention backends?
- How about the caching mixins?
Some nits:
- Use
torch.no_grad()as an entire decorator as opposed to using it inside the functions.
| config.addinivalue_line("markers", "lora: marks tests for LoRA/PEFT functionality") | ||
| config.addinivalue_line("markers", "ip_adapter: marks tests for IP Adapter functionality") | ||
| config.addinivalue_line("markers", "training: marks tests for training functionality") | ||
| config.addinivalue_line("markers", "attention: marks tests for attention processor functionality") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to club this with attention backends?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can. But I think it's a bit out of scope for this PR because we need to create a container with the relevant backends available.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have to do it in this PR then.
But just as a note, most of the attention backends that have complex installation processes, we should actually encourage users to rely on their kernels-variants (FA2, FA3, SAGE). This way, we won't have to build any containers.
| - get_dummy_inputs(): Returns dict of inputs to pass to the model forward pass | ||
| Pytest mark: attention | ||
| Use `pytest -m "not attention"` to skip these tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do we implement it in an individual model testing class? For example, say we want to skip it for model X where its attention class doesn't inherit from AttentionModuleMixin?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally, any model using attention also uses AttentionModuleMixin. The options here
- Do not add tests from attention Mixin to a module file.
- Add a decorator that makes AttentionModuleMixin a requirement for running attention tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But there are important classes like Autoencoders that don't use the Attention mixins.
Let's do this?
Add a decorator that makes AttentionModuleMixin a requirement for running attention tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But there are important classes like Autoencoders that don't use the Attention mixins.
The check is forAttentionModuleMixinnotAttentionMixinand Autoencoders do use it
ModelMixin, AttentionMixin, AutoencoderMixin, ConfigMixin, FromOriginalModelMixin, PeftAdapterMixin
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I see your point!
So, as long as there is an Attention module this class should apply.
So, maybe for each of the tests, at the beginning, we could check if their attention classes inherit from
| if isinstance(module, AttentionModuleMixin): |
and if that's not the case, we skip.
Otherwise, I think it could be cumbersome to check which model tests should and shouldn't use this class because attention is a common component.
|
|
||
| model.to(torch_device) | ||
|
|
||
| def _test_quantization_lora_inference(self, config_kwargs): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very cool rewrite!
|
|
||
| model.to(torch_device) | ||
|
|
||
| def _test_quantization_lora_inference(self, config_kwargs): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should also be a corresponding training test similar to:
diffusers/tests/quantization/bnb/test_4bit.py
Line 418 in 6708f5c
| def test_training(self): |
| if isinstance(output, tuple): | ||
| output = output[0] | ||
| assert output is not None, "Model output is None" | ||
| assert not torch.isnan(output).any(), "Model output contains NaN" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dequantize() tests are missing from bitsandbytes but they exist:
diffusers/tests/quantization/bnb/test_4bit.py
Line 490 in 6708f5c
| def test_generate_quality_dequantize(self): |
| def test_gguf_quantized_layers(self): | ||
| self._test_quantized_layers({"compute_dtype": torch.bfloat16}) | ||
|
|
||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where do we include:
| class QuantCompileTests: |
| @@ -0,0 +1,489 @@ | |||
| #!/usr/bin/env python | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it cannot currently generate the dummy input and init dicts? I would understand if so because inferring those is quite non-trivial.
| model.load_lora_adapter(tmpdir, prefix=None, use_safetensors=True) | ||
| parsed_metadata = model.peft_config["default_0"].to_dict() | ||
| check_if_dicts_are_equal(metadata, parsed_metadata) | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we include a training test too?
|
One thing I think we should do is get a coverage report for If we are, then we should likely be able to explain why that's the case. |
What does this PR do?
Following the plan outlined for Diffusers 1.0.0, this PR introduces changes to our model testing approach in order to reduce the overhead involved in adding comprehensive tests for new models and standardize tests across all models.
Changes include
generate_model_tests.py) to automatically generate tests based on the model file. Also provide a flag that allows us to include any optional features to test e.g. (we can turn this into a bot down the line)I've only made changes to Flux to make this PR easy to review. I'll open follow ups in phases for the other models once this is approved.
Will now generate a template test file that can be populated with the necessary config information
Fixes # (issue)
Before submitting
documentation guidelines, and
here are tips on formatting docstrings.
Who can review?
Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.