Skip to content

fix: bump accelerate floor to 1.13.0 for transformers 5.3.0 compat#2388

Open
lonexreb wants to merge 2 commits intoNVIDIA-NeMo:mainfrom
lonexreb:fix/2221-accelerate-version-v2
Open

fix: bump accelerate floor to 1.13.0 for transformers 5.3.0 compat#2388
lonexreb wants to merge 2 commits intoNVIDIA-NeMo:mainfrom
lonexreb:fix/2221-accelerate-version-v2

Conversation

@lonexreb
Copy link
Copy Markdown

@lonexreb lonexreb commented May 4, 2026

Summary

Closes the dep mismatch flagged in #2221.

NeMo-RL pins transformers==5.3.0 (pyproject.toml:46) but currently
declares accelerate>=0.26 (pyproject.toml:31). Versions of
accelerate older than 1.13.0 are incompatible with transformers
5.3.0's call sites that pass the _is_hf_initialized keyword to
Parameter.__new__, producing the runtime crash described in the
issue:

TypeError: Parameter.__new__() got an unexpected keyword argument '_is_hf_initialized'

Why specifically 1.13.0

Investigation of accelerate upstream:

  • v1.10.0's register_empty_parameter (line 129) has no handling for
    the _is_hf_initialized kwarg, so it is forwarded to
    Parameter.__new__, which rejects it.
  • v1.13.0 (lines 131–141) explicitly pops the kwarg before
    constructing the Parameter and reapplies it as an attribute
    afterwards — which is exactly the contract transformers 5.3.0
    relies on.

So >=1.13.0 is the precise floor required for transformers 5.3.0
compatibility. (The earlier draft of this PR claimed >=1.1.0 would
suffice; that was wrong — 1.1.0 predates the kwarg-handling fix
entirely. Corrected here.)

Change

  • pyproject.toml: accelerate>=0.26accelerate>=1.13.0
  • uv.lock: regenerated with uv lock to pick up the new specifier.

What this PR does not touch

  • 3rdparty/Megatron-Bridge-workspace declares an unconstrained
    accelerate dep at pyproject.toml:476 — that lives in upstream
    Megatron-Bridge's setup.py::CACHED_DEPENDENCIES and per the
    comment must stay in sync with the Bridge source. Updating it is
    outside the scope of this fix and should be coordinated with
    Megatron-Bridge directly.

Test plan

  • uv lock ran cleanly with the >=1.13.0 floor.
  • Verified upstream accelerate source on GitHub: v1.13.0 is
    the first release with the _is_hf_initialized pop/reapply
    handling in register_empty_parameter.
  • CI L0 (build verifies the lockfile is internally consistent).
  • Reviewer confirms 1.13.0 is the correct floor.

Refs: #2221

…IDIA-NeMo#2221)

NeMo-RL pins ``transformers==5.3.0`` but currently declares
``accelerate>=0.26``. Versions of accelerate older than 1.1.0 are
incompatible with transformers 5.3.0's call sites that pass the
``_is_hf_initialized`` keyword to ``Parameter.__new__``, producing a
runtime crash:

    TypeError: Parameter.__new__() got an unexpected keyword
    argument '_is_hf_initialized'

The currently locked version (1.10.0) is unaffected because the
resolver was constrained from elsewhere, but a fresh resolve in a
different environment can pick a too-old accelerate and fail at
runtime. Tighten the floor so the constraint accurately reflects
transformers 5.3.0's real requirement.

uv.lock was regenerated with ``uv lock``. The only semantic change is
the matching ``accelerate`` specifier in nemo-rl's
``[package.metadata.requires-dist]`` block; the resolved version
(``accelerate==1.10.0``) and every other package version are
unchanged. The remaining lockfile churn is resolution-marker
normalization from a newer uv release and is benign.

Refs: NVIDIA-NeMo#2221
Signed-off-by: lonexreb <[email protected]>
@lonexreb lonexreb requested a review from a team as a code owner May 4, 2026 07:01
@copy-pr-bot
Copy link
Copy Markdown

copy-pr-bot Bot commented May 4, 2026

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

The previous commit on this branch claimed `accelerate>=1.1.0` would
fix the ``_is_hf_initialized`` ``TypeError`` from NVIDIA-NeMo#2221. That was
wrong — verified by reading accelerate's source on the
huggingface/accelerate repo:

* v1.10.0 ``register_empty_parameter`` (src/accelerate/big_modeling.py:129)
  has no handling for the ``_is_hf_initialized`` kwarg, so transformers
  5.3.0's ``Parameter.__new__`` call still crashes.
* v1.13.0 ``register_empty_parameter`` (line 131) pops ``_is_hf_initialized``
  from kwargs and re-applies it after parameter creation.

So the actual floor required to unblock transformers 5.3.0 is
``>=1.13.0``. Bump pyproject.toml accordingly and regenerate uv.lock —
``accelerate`` moves from 1.10.0 to 1.13.0; no other versions change.

Refs: NVIDIA-NeMo#2221
Signed-off-by: lonexreb <[email protected]>
@lonexreb
Copy link
Copy Markdown
Author

lonexreb commented May 4, 2026

Updated to correct floor >=1.13.0 (commit ae7bd147).

A code review caught that >=1.1.0 does not actually fix the bug —
verified by reading accelerate's source on GitHub:

  • v1.10.0 register_empty_parameter (src/accelerate/big_modeling.py:129) has no handling for the _is_hf_initialized kwarg, so transformers 5.3.0's Parameter.__new__ call still crashes.
  • v1.13.0 register_empty_parameter (line 131) pops _is_hf_initialized from kwargs and re-applies it after parameter creation.

So the actual minimum required to unblock transformers 5.3.0 is >=1.13.0. The constraint and uv.lock have been updated; accelerate moves from 1.10.0 to 1.13.0, no other versions change.

The original >=1.1.0 claim in the first commit message and PR description was based on the issue reporter's text; subsequent verification against the upstream source corrected it.

@lonexreb lonexreb changed the title fix: bump accelerate floor to 1.1.0 for transformers 5.3.0 compat fix: bump accelerate floor to 1.13.0 for transformers 5.3.0 compat May 5, 2026
@svcnvidia-nemo-ci svcnvidia-nemo-ci added the waiting-on-maintainers Waiting on maintainers to respond label May 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

community-request waiting-on-maintainers Waiting on maintainers to respond

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants