🚨 Validate config attributes

[zucchini-nlp]

What does this PR do?

As per title. Continues from #40793 and supersedes #36534

NOTE: config classes can't accept positional args anymore! I don't think anyone would use pos args anyway but marring the PR as breaking

---

Note

High Risk
Refactors PreTrainedConfig and many model config classes to @dataclass + huggingface_hub @strict validation, which can change initialization/serialization behavior and reject previously-accepted configs. Also enforces save-time validation and updates defaults/deprecations (e.g., use_return_dict), risking backward-compatibility across model loading and downstream integrations.

Overview
Adds strict config validation. PreTrainedConfig is converted to a @dataclass with huggingface_hub’s @strict, introduces built-in validators (architecture consistency, special token id ranges, layer type checks, output_attentions vs attn_implementation), and runs validate() automatically on save_pretrained.

Modernizes and standardizes model configs. Many model configuration classes are migrated from custom __init__ logic to dataclass fields + __post_init__, moving compatibility logic (e.g., defaulting sub-configs, key/value casting for JSON) into post-init and adding model-specific validate_architecture where needed.

API/behavior tweaks. Deprecates use_return_dict in favor of return_dict (and updates multiple model forward paths accordingly), adjusts RoPE validation ignore-key handling, narrows AutoTokenizer fallback exception handling, and bumps the minimum huggingface-hub requirement to >=1.5.0.

^{Written by Cursor Bugbot for commit 07095f3. This will update automatically on new commits. Configure here.}

[HuggingFaceDocBuilderDev]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[zucchini-nlp]

Blocked by #41541 (comment) for now

[zucchini-nlp]

Tieme to revive this branch

[zucchini-nlp]

Nice, much better and easy to maintain BC with remote code now!

[ArthurZucker]

Very very nice!

[ArthurZucker]

is it a good time to get rid of these general attributes and only have them for models that actually require them?

[tomaarsen]

I'm getting failures here due to this PR:

from transformers import AutoConfig

config = AutoConfig.from_pretrained("tiny-random/glm-4v")
print(type(config))

Traceback (most recent call last):
  File "[sic]\demo_glm4v_config.py", line 4, in <module>
    config = AutoConfig.from_pretrained("tiny-random/glm-4v")
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[sic]\src\transformers\models\auto\configuration_auto.py", line 1484, in from_pretrained
    return config_class.from_dict(config_dict, **unused_kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[sic]\src\transformers\configuration_utils.py", line 757, in from_dict
    config = cls(**config_dict)
             ^^^^^^^^^^^^^^^^^^
  File "[sic]\transformers\Lib\site-packages\huggingface_hub\dataclasses.py", line 280, in init_with_validate
    cls.validate(self)  # type: ignore [attr-defined]
    ^^^^^^^^^^^^^^^^^^
  File "[sic]\transformers\Lib\site-packages\huggingface_hub\dataclasses.py", line 255, in validate
    validator(self)
  File "[sic]\src\transformers\modeling_rope_utils.py", line 723, in validate_rope
    validation_fn(rope_parameters, ignore_keys=self.ignore_keys_at_rope_validation)
  File "[sic]\src\transformers\modeling_rope_utils.py", line 733, in _validate_default_rope_parameters
    self._check_received_keys(rope_type, received_keys, required_keys, ignore_keys=ignore_keys)
  File "[sic]\src\transformers\modeling_rope_utils.py", line 921, in _check_received_keys
    raise KeyError(f"Missing required keys in `rope_parameters` for 'rope_type'='{rope_type}': {missing_keys}")
KeyError: "Missing required keys in `rope_parameters` for 'rope_type'='default': {'rope_theta'}"

Note that the remote config uses the old-style top-level rope parameters, including rope_theta: https://huggingface.co/tiny-random/glm-4v/blob/main/config.json#L28-L37

• Tom Aarsen

[imstevenpmwork]

Hey @zucchini-nlp 👋 Just a quick heads-up that the changes in this PR (shipped in the 5.4.0 release) introduced a breaking change for us. Specifically, the introduction of the @dataclass ... decorators to the PreTrainedConfig class.

Over at lerobot, we were decorating the classes that inherit from PreTrainedConfig with @dataclass, but now given that PretrainedConfig.__init_subclass__ applies it, on the second pass the field(init=False) objects have already been consumed, so the fields appear as non-default arguments after the parent's default arguments. Just wanted to flag this to save some debugging time in case anyone else is suddenly staring at a red CI!

Maybe we can add it into the Release Notes: subclasses of PretrainedConfig should no longer be decorated with dataclass. -> My bad, it was already included in the release notes, thanks!

Cheers!

[zucchini-nlp]

Interesting, I haven't thought that users might be already using a dataclass. TIL that we have subclasses which are dataclasses and also some that are pydantic BaseClasses

Yea, I think it is the best to remove the decorator. We've been making all subclasses a dataclass since it makes little sense for them to be non-dataclass objects after this PR