🚨 Generation config defaults are now `None`
Author: zucchini-nlp
Pull request: yes

# What does this PR do?

As per title, must have been done long time ago but could't break BC. The current impl breaks BC only half-way, i.e. the generation loop is not affected and will keep using the old defaults. The biggest difference is for users to init, access, modify, etc. the model's generation config directly:

```python
# `0` before this PR, `None` after the PR
print(model.generation_config.no_repeat_ngram_size)
```


Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42702). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

Ready for review!

run-slow: bart, csm, dia, encoder_decoder, musicgen, rag, reformer, speech_encoder_decoder, vision_encoder_decoder, whisper

This comment contains `run-slow`, running the specified jobs: 

models: ["models/bart", "models/csm", "models/dia", "models/encoder_decoder", "models/musicgen", "models/rag", "models/reformer", "models/speech_encoder_decoder", "models/vision_encoder_decoder", "models/whisper"]
quantizations: []

## CI Results
[Workflow Run ⚙️](https://github.com/huggingface/transformers/actions/runs/20131172759)

✅ No failing test specific to this PR 🎉 !


@vasqu requesting another review :)

Will merge when CI is fixed on main

Hi,

First of all, thanks for your reactivity and addressing the underlying issue:
- #42762

On the other hand, I did a quick pass over the generation code, and I think there is a subtle semantic point worth double-checking: None is not always just "unset", it can also mean "disable this behavior".

Concretely, `top_k=None` disables top-k filtering entirely and allows all tokens. Because of that, we now have two different concepts that can both be represented as "None":
- Use the global/default value for top_k (e.g. 50)
- Explicitly disable top-k filtering (top_k=None or 0) even if the model's generation config or the global defaults say otherwise

Therefore, a situation can occur during training where:
- the user-provided `generation_config` has `top_k=None` (intending to disable top-k filtering),
- the model’s own `generation_config` has a non-None value for `top_k`,
- merging logic currently preserves the model’s value instead of respecting the explicit `None`.

In that scenario, `None` is not just "unset"; it is a meaningful instruction ("don't apply top-k filtering"). If so, the merge semantics may need refinement to avoid unintentionally re-enabling filtering (e.g. by using a sentinel value instead).

I'll continue digging into this, but flagging it early so we can discuss it before merging.

@albertvillanova I think if `top_k=None` in the generation config it is the same as if users did not pass any `top_k` in kwargs. A value is not set to any value (`None`) does not specifically mean that the users is requesting to not use it, so the users would need to explicitly unset as `top_k=0` if model has saved a different value.

Unfortunately we have no way to 100% know what users wants when they set values to `None` in current code. The only way would be for us to not update generation config with model's defaults if users pass `my_generation_config`. But that will be much more breaking and will require users to always create a custom config from `model.generation_config`

For ex, if everyone prepared custom configs as below, we can fix your issue. I'm afraid it's not the case for most users
```python
my_generation_config = model.generation_config
my_generation_config.top_k = None
model.generate(inputs, generation_config=my_generation_config)

```

**[For maintainers]** Suggested jobs to run (before merge)

run-slow: bart, csm, dia, encoder_decoder, musicgen, rag, reformer, speech_encoder_decoder, vision_encoder_decoder, whisper

I think we can merge? @zucchini-nlp