Skip to content

Declared floors torch>=2.4.0 + peft>=0.19.0 admit a broken pair: peft 0.19.0 crashes on torch<2.7 (float8_e8m0fnu) in every LoRA wrap and adapter load (CR-A16-001) #421

Open

Description

@cemililik

Wave 1 · theme D1-7: Dependency floors, container and supply chain · highest severity High · 3 finding(s) · effort small

Summary

An image with torch 2.4-2.6 preinstalled (common for CUDA base images) runs pip install forgelm. pip keeps the installed torch and picks peft 0.19.0. Every training run exits 2.

Primary finding

CR-A16-001 — Declared floors torch>=2.4.0 + peft>=0.19.0 admit a broken pair: peft 0.19.0 crashes on torch<2.7 (float8_e8m0fnu) in every LoRA wrap and adapter load

severity High · reachability default · intent contract-violation · confidence confirmed · independently confirmed · reproduced end to end

What happens. pyproject.toml:46 (torch>=2.4.0) and :54 (peft>=0.19.0) let a resolver pair peft 0.19.0 with torch 2.4-2.6. peft 0.19.0's cast_adapter_dtype does getattr(torch, name) without a default over UPCAST_DTYPES, which includes 'float8_e8m0fnu' (first in torch 2.7); peft 0.19.1 added getattr(..., None). peft's own metadata requires only torch>=1.13, so nothing blocks the pair. The same upstream helper is reached through get_peft_model (training) and PeftModel.from_pretrained (chat/export/merge/benchmark adapter loads), so every such entry point raises AttributeError. The nightly min-deps job pins exactly this pair but runs only the mocked suite.

Where.

Evidence.

  • runs/lower-* exit 2: AttributeError: module 'torch' has no attribute 'float8_e8m0fnu' (peft/tuners/tuners_utils.py:2170). With a stub alias of that dtype, sft/dpo/kto (snapshot) and simpo/orpo/grpo (patched copy) all exit 0 on transformers 5.3.0 / trl 1.0.0.
  • fpy --venv lower -m forgelm --config cfg-{sft,dpo,kto}.yaml: EXIT=2, AttributeError: module 'torch' has no attribute 'float8_e8m0fnu' (lower-sft.log). torch v2.6.0 c10/core/ScalarType.h has 0 Float8_e8m0fnu mentions; v2.7.0 has 6. peft 0.19.1 uses getattr(torch, name, None). With UPCAST_DTYPES filtered (patch_run_lower.py), sft, dpo and kto exit 0 at the floors.
  • lower venv (torch 2.6.0, transformers 5.3.0, peft 0.19.0): load_model(tiny-qwen, adapter=env/artifacts/sft) -> peft/tuners/tuners_utils.py:2170 torch_dtype = getattr(torch, name) -> AttributeError: module 'torch' has no attribute 'float8_e8m0fnu'. peft/utils/constants.py:378 UPCAST_DTYPES includes 'float8_e8m0fnu'. The peft 0.19.1 copy at tuners_utils.py:2170 reads if (torch_dtype := getattr(torch, name, None)) is not None. The merge probe in the lower venv fails the same way.

Recommended fix. Raise the torch or peft floor so that pins together with a lowest-direct-dependencies CI job prove the floor works. Research question: the first peft release that guards float8_e8m0fnu, and the torch release that introduced it.

Other findings with the same root cause

These close with the same fix; update them in the same pull request.

CR-A03-046 — Peft 0.19.0 with torch below 2.7 (both inside the declared ranges) crashes get_peft_model for every run

severity Medium · reachability default · intent contract-violation · confidence confirmed · independently confirmed · reproduced end to end

What happens. pyproject allows torch>=2.4.0 and peft>=0.19.0. peft 0.19.0 cast_adapter_dtype does getattr(torch, name) over UPCAST_DTYPES with no default, and torch 2.6.0 has no torch.float8_e8m0fnu. get_peft_model raises AttributeError for any model, any trainer and any LoRA setting, so the load stage fails with exit 2. peft 0.19.1 and later use getattr(torch, name, None), so this is limited to the declared-floor pair.

Failure scenario. An operator who pins to the declared floors (a constraints file, an air-gapped mirror) gets exit 2 on every run at model setup.

Where.

Evidence.

  • fpy --venv lower (torch 2.6.0, peft 0.19.0, transformers 5.3.0): a real run exits 2 with 'AttributeError: module torch has no attribute float8_e8m0fnu' from peft/tuners/tuners_utils.py:2170 via forgelm/model.py:609. hasattr(torch,'float8_e8m0fnu') is False on lower and True on extras. peft 0.19.0 METADATA declares torch>=1.13.0. peft 0.19.1 and 0.21.2 sources contain 'getattr(torch, name, None)'.

Recommended fix. Bump the peft floor to >=0.19.1 and document it; add a floor-matrix CI job.

TECH-T03-005 — PEFT, quantization and memory methods: peft floor peft>=0.19.0 combined with torch>=2.4.0 (range-unsound)

severity Next release

Item. peft floor peft>=0.19.0 combined with torch>=2.4.0 · verdict: range-unsound · urgency: Next release

State in ForgeLM. pyproject.toml:46 torch>=2.4.0,<3.0.0 and pyproject.toml:54 peft>=0.19.0,<1.0.0. The K-3 lower venv resolves torch 2.6.0, peft 0.19.0, transformers 5.3.0.

State of the ecosystem on 2026-10-01. peft 0.19.0 cast_adapter_dtype iterates UPCAST_DTYPES (includes float8_e8m0fnu) with getattr(torch, name) and no default (tuners_utils.py:2169-2171). 0.19.1 (2026-04-16) uses getattr(torch, name, None) (same lines). The fix is PR #​3161 ('guard UPCAST_DTYPES lookup ... to support older PyTorch', fixes #​3158, merged 2026-04-15). 0.19.1 also ships PR #​3165, which fixes swapped in/out features for LoRA on 3-D MoE parameters. My reproduction in the lower venv (torch 2.6.0, which has no float8_e8m0fnu): get_peft_model on the tiny-qwen fixture with LoRA q_proj/v_proj raised AttributeError: module 'torch' has no attribute 'float8_e8m0fnu'.

Impact. Installs that satisfy ForgeLM's declared ranges with peft==0.19.0 and an older torch (2.6.0 verified; the PR cites 2.5.1) fail every LoRA/QLoRA run at forgelm/model.py:609. The lower-bound CI lane cannot train.

Recommendation. Raise the floor to peft>=0.19.1 (this also brings the #​3165 MoE shape fix), or raise the torch floor to a release that defines float8_e8m0fnu.

Sources.

Acceptance criteria

  • A regression test reproduces the failure scenario and asserts the corrected behaviour.
  • Documentation listed above is corrected in English and in its Turkish mirror in the same PR.
  • Every finding in this issue is resolved or explicitly closed with a reason.

Found by the October 2026 ForgeLM code and documentation review against commit cab2947. Code links point at that commit; line numbers may have moved since. Finding IDs (CR-…, DOC-…, TECH-…) are stable references for this backlog.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: model-dataCode area: model-dataarea: packaging-ciCode area: packaging-cibugSomething isn't workingdependenciesDependency or ecosystem currencyseverity: highWrong behaviour or a false claim users rely onsource: review-2026-10Found by the October 2026 code and documentation reviewurgency: next-releaseTechnology currency: fix in the next releasewave: 1Roadmap wave 1: high severity, small effort

    Type

    No type

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions