🗜 Hotfix: avoid passing quantization_config=None

[qgallouedec]

passing

model = AutoModelForCausalLM.from_pretrained("my_model", quantization_config=None)

isn't the same as

model = AutoModelForCausalLM.from_pretrained("my_model")

causing gpt oss model to fail loading when used with trl cli

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

[albertvillanova]

Thanks for the PR: definitely, GPT OSS models should be supported in TRL!!!

That said, I'm not fully convinced we need to apply the "filter out all None kwargs" policy across the board. Most parameters in from_pretrained are robust to None: have you seen any issue with any parameter other than quantization_config?

In my view, there are two complementary points here:

1. Upstream issue in Transformers: do you know why transformers treat differently missing and None quantization_config? I think this might be a bug. In my opinion, passing None should be treated the same as omitting the key altogether, not as an invalid quantization config. It would be worth raising or linking an issue upstream so we can align behavior there.
   • I can have a look at this.
2. Targeted fix in TRL: While investigating and waiting for an upstream fix, it makes sense for TRL to guard specifically against this problem.

What about stripping only the quantization_config (and associated device_map) if it is None. This would keep the fix minimal, and avoid unnecessarily rewriting the kwargs for unrelated arguments. What do you think?

[qgallouedec]

yeah good point.

have you seen any issue with any parameter other than quantization_config?

no

do you know why transformers treat differently missing and None quantization_config?

I think it comes from these lines, probably a bug, but I haven't had time to look into it further.

https://github.com/huggingface/transformers/blob/37c14430c99edca79dfcdcb76f1209f291b12fab/src/transformers/configuration_utils.py#L962-L967

Targeted fix in TRL: While investigating and waiting for an upstream fix, it makes sense for TRL to guard specifically against this problem.

yep, agree, done

---

I will merge this PR now, as I'd like to include it in the release, but we should definitely do this

It would be worth raising or linking an issue upstream so we can align behavior there.