Require bitsandbytes>=0.50.0 and drop the _check_is_size warning filter

[behroozazarkhalili]

Resolves #6447.

What

Raises the bitsandbytes floor to >=0.50.0 in the quantization and dev extras, and removes the pytest filter that silenced its _check_is_size FutureWarning.

Why the trigger has fired

bitsandbytes replaced every torch._check_is_size call with torch._check in bitsandbytes-foundation/bitsandbytes#1940, merged 2026-05-07 and shipped in 0.50.0 (2026-07-25). Counted directly at the release tags rather than inferred from dates:

tag	_check_is_size in bitsandbytes/_ops.py
0.49.2	8
0.50.0	0
0.50.1	0

The resolver already picks up 0.50.2 (released 2026-08-27), so the filter is dead in practice. Recording the minimum turns that into a guarantee. Note that #6447 asks not to bump the floor solely for this reason; see the discussion below the description.

Verification

Applying each version of the filterwarnings list programmatically and then calling torch._check_is_size(1):

pyproject	filter entries	warning surfaced
before	15	no
after	14	yes

Exactly one entry is removed and it is the intended one. Boundary check on the new specifier: 0.49.2 does not satisfy >=0.50.0, 0.50.0 and 0.50.1 do. Both requirement strings parse as valid PEP 508. pytest --collect-only still loads the config (235 tests collected in tests/test_utils.py).

Scanning the installed environment, only bitsandbytes and torch itself call _check_is_size. torch's remaining callers are in fx/passes/runtime_assert.py, fx/experimental/symbolic_shapes.py, _dynamo/trace_rules.py, and export/_patches.py, none of which sit on TRL's eager training path, so removing the filter does not unmask a second source.

Out of scope

The other bitsandbytes filter, inner dimension (\d+) is not aligned for fast kernel, stays. Its upstream issue bitsandbytes-foundation/bitsandbytes#2027 is still open, so its "remove once" condition has not been met.

Sibling issue #6466 needs triton >= 3.8.0, which reached PyPI on 2026-08-28; it is a separate change and stays out of scope here.

---

Note

Low Risk
Dependency floor bump and test-config cleanup only; no runtime or training logic changes.

Overview
Requires bitsandbytes 0.50.0+ for installs using the quantization or dev extras, replacing an unpinned bitsandbytes dependency.

Removes the pytest filterwarnings entry (and its comments) that ignored bitsandbytes’ torch._check_is_size FutureWarning. That warning is gone upstream as of bitsandbytes 0.50.0, so the filter is no longer needed. The separate bitsandbytes “inner dimension not aligned” warning filter is unchanged.

^{Reviewed by Cursor Bugbot for commit 25005bf. Bugbot is set up for automated code reviews on this repo. Configure here.}

[bot-ci-comment]

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.

[behroozazarkhalili]

@albertvillanova, a re-read of #6447 shows I misapplied its closing condition. The issue says:

Remove the filterwarnings entry once TRL's minimum required bitsandbytes is >= 0.50.0. Do not bump the floor solely to drop this filter: wait for an independent reason to require 0.50.0.

This PR bumps the floor for exactly that reason and no other. I looked for an independent one and did not find it: TRL has no bitsandbytes version gate anywhere (is_bitsandbytes_available only checks Transformers' own minimum), and nothing in the tree calls an API that 0.49.2 lacks.

Two options, your call:

1. Close this PR and leave the filter in place until a real reason to require 0.50.0 comes along. I will reopen the removal at that point.
2. Keep it if you consider the current state a good enough reason: 0.50.2 has been on PyPI since 2026-08-27, 0.49.2 is the only supported release that still emits the warning, and nothing in TRL depends on that release.

I have refreshed the verification numbers in the description to match the merge-forwarded head (the filter list is now 15 entries before and 14 after, and 235 tests collect in tests/test_utils.py). The bitsandbytes and Triton release claims that said "today" now carry dates.

[albertvillanova]

Thanks for catching this yourself and laying out the options. Going with your option 1.

Two reasons, both now settled:

• Remove bitsandbytes _check_is_size warning filter once the minimum required bitsandbytes is >= 0.50.0 #6447: the floor shouldn't move solely to drop a filter, and as you found, there is no independent reason to require 0.50.0.
• Agree on an explicit criterion for raising a dependency version floor #7116: we agreed that a cheap-to-keep old version stays until it hits 2 years, and that we don't require a release this new. 0.50.0 is six weeks old.

So the filter stays and the floor doesn't move yet. That bitsandbytes has no floor at all is a separate gap noted in #7116; declaring a first floor drops support for nothing, so it doesn't need this PR.

Your verification approach is worth reusing when the trigger does fire.