[generate] model defaults being inherited only happens for newer models

[gante]

What does this PR do?

#36684 activated the use of model-defaults (as opposed to global defaults) for unfilled parameters in the generation_config argument.

It may lead to unexpected behavior on models that saw no changes, especially if the model has defined flags like max_length or max_new_tokens. This PR adds a flag to control this behavior, and makes it the default only for models saved from v4.50 (next release) onwards.

[github-actions]

Hi 👋, thank you for opening this pull request! The pull request is converted to draft by default. When it is ready for review, please click the Ready for review button (at the bottom of the PR page).

[ArthurZucker]

Ok that sounds good!

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

[MTDickens]

I personally think the processing logic can be further improved.

For example, consider a user wanting to ensure greedy decoding by explicitly setting my_config = GenerationConfig(do_sample=False). Since do_sample=False is also the default in the base GenerationConfig, the merging logic might interpret this as "not specified by the user." Consequently, if a model-specific configuration (like gemma3_config) defaults to do_sample=True, it could unintentionally override the user's explicit do_sample=False setting.

The core issue is that the current approach seems to primarily track deviations from the default, rather than explicit user intent.

Perhaps the GenerationConfig object or the merging process could internally track which parameters were explicitly provided by the user during instantiation, even if the provided value matches the default. This would allow the merging logic to prioritize any explicitly user-set value over model-specific defaults.

I'm not familiar enough with the codebase to propose a specific implementation, but hopefully, this description of the problem and the suggested conceptual approach is helpful.

[gante]

@MTDickens yes, this will be improved :) Our path forward will consist of having per-model GenerationConfig classes, like we have per-model config classes. That way, when instantiating a new generation config, the starting point are the model-specific defaults, as opposed to generalist defaults + convoluted logic