InfiniteTalk Dies at torch.load: the Error Tells You to Upgrade torch — the Measured Fix Is Pinning transformers 4.52.0

If an InfiniteTalk — or any Wan2.1-based — pipeline that used to work suddenly dies at torch.load with a ValueError citing CVE-2025-32434, the error message will tell you to upgrade torch to at least 2.6. On a pinned stack that already ran, the measured fix is the opposite direction: pin transformers to 4.52.0 and touch nothing else. Upgrading torch to 2.10.0 cost us five simultaneous breakages across torchaudio, torchvision, xformers, diffusers, and flash-attn — every string preserved below.

This is part 2 of the InfiniteTalk dispatch. Part 1 covers the hardware measurements: 218.5 s/step on an RTX 4090D + A4000 rig, the 20-block semi-resident split, and why we shelved the project. This part is the two-day saga (2026-02-19 – 02-20) of bringing that stack back after a disk cleanup — six failed attempts, one wrong-way error message, and the version matrix that finally launched. Every number and error string is preserved verbatim from session logs of the attempts.

The trap: an error message that is true, and wrong for you

The stack under repair is the one from part 1: torch 2.4.1, conda, Python 3.10, dual-GPU, the 19,499,692,400-byte fp8 checkpoint. The first full launch of the restore died in thirteen seconds — past GPU init, dead at the wav2vec2 loader:

ValueError: Due to a serious vulnerability issue in `torch.load`, even with
`weights_only=True`, we now require users to upgrade torch to at least v2.6
in order to use the function. This version restriction does not apply when
loading files with safetensors. See the vulnerability report here
https://nvd.nist.gov/vuln/detail/CVE-2025-32434

Facts about this wall, all measured:

• It fired on transformers 4.57.3, at check_torch_load_is_safe, killing the launch in 18.0–18.6 seconds — three consecutive attempts, same wall.
• The Chinese wav2vec2 checkpoint ships as a .pt pickle, so it goes through torch.load — which is exactly what the gate intercepts. The fp8 safetensors weights load fine; safetensors is exempt by the error’s own text.
• The catch: this exact environment had run the pipeline end-to-end two months earlier. Nothing on our side was wrong. A dependency refresh had silently crossed the gate version. Our note in the log at the time, translated: “the environment doesn’t need an upgrade — this already ran in Python; everything was OK.” That instinct was correct, and following the error message instead cost most of a day.

The message isn’t lying — CVE-2025-32434 is a real vulnerability class, and “upgrade torch” is sound advice for new code. But for a pinned working stack, it is a misdirection: the gate arrived with a transformers bump, so the minimal fix is a transformers pin, not a torch migration.

What upgrading torch actually costs

We tried it — the honest path, exactly as instructed: torch upgraded to 2.10.0+cu128. Five breakages, all on the same morning, all verbatim:

#	Breakage	Verbatim
1	pip conflict ×3	torchaudio 2.4.1+cu124 requires torch==2.4.1, but you have torch 2.10.0 (same line for torchvision 0.19.1+cu124 and xformers 0.0.28)
2	torchvision ops gone	RuntimeError: operator torchvision::nms does not exist
3	diffusers import dead	Failed to import diffusers.pipelines.pipeline_utils ... JITCallable._set_src() takes 1 positional argument but 2 were given
4	flash-attn ABI break	flash_attn_2_cuda...so: undefined symbol: _ZN3c104cuda29c10_cuda_check_implementationEiPKcS2_ib
5	xformers wheel mismatch	WARNING[XFORMERS]: xFormers was built for: PyTorch 2.4.1+cu121 with CUDA 1201 (you have 2.10.0+cu128)

The lesson generalizes past InfiniteTalk: in a stack where four compiled packages pin the same torch, torch is the load-bearing pin. “Just upgrade it” is a coordinated migration of all five packages, not a one-liner. We rolled back.

The bisection matrix: transformers 4.52.0

With torch restored to 2.4.1, we bisected transformers. Four versions, one outcome each, all measured 2026-02-20:

transformers	Outcome	Where it dies
4.57.3	❌ blocked	torch.load CVE gate (check_torch_load_is_safe), 18.0–18.6 s
4.49.0	❌ imports, then dies	xfuser → diffusers import chain
4.51.0	❌ imports, then dies	same xfuser → diffusers import chain
4.52.0	✅ launches	— reaches pipeline init + quantized T5 load

The final working set, as installed:

torch        2.4.1
torchvision  0.19.1
xformers     0.0.28
flash-attn   2.8.3
transformers 4.52.0

(One ambiguity preserved honestly: our logs contain both +cu121 and +cu124 builds of the 2.4.1-era wheels on different days; the exact wheel provenance was never recorded. The version numbers are the reproducible part.)

The last launch on these pins logged INFO: Creating infinitetalk pipeline. … INFO: Loading quantized T5 from t5_fp8.safetensors and then Process still running. — the session log ends there, so we publish no claim about whether that run completed. What we do claim: 4.52.0 is the only version in the sweep that got past every wall to pipeline initialization.

The other walls, for completeness

The CVE gate was wall #3 of six. The full timeline, with time-to-fail — useful if you’re triaging a similar restore:

Attempt	Wall	Time-to-fail	Verbatim tail
1	Wrong weights path	16.7 s	FileNotFoundError: .../InfiniteTalk/single/infinitetalk_single_fp8.safetensors
2	Missing config / missing import	36.8 s	FileNotFoundError: 'tmp/configs/config_*.json' · NameError: name 'os' is not defined
3	Deepest run, quantized-key mismatch	277.5 s	missing keys audio_proj.proj1.output_scale / .weight._scale / .weight._data
4	CVE gate ×3	18.0–18.6 s	the torch.load ValueError above
5	Sed-edited source	0.0 s ×6	torch.load(voice1, weights_only=) → SyntaxError: invalid syntax
6	torch 2.10 avalanche	same morning	the five-breakage table above

Wall #5 deserves its own sentence: an AI agent tried to neutralize the gate by sed-replacing weights_only=True in the source and produced a half-replacement — a bare weights_only= keyword — followed by six consecutive SyntaxErrors at 0.0 seconds each. If you let agents near a working source tree, restrict them to read-only, and let pins live in a requirements file.

Wall #3 (the 277.5-second run dying on missing audio_proj keys in the quantized checkpoint) never got root-caused — it did not recur in the later launches, and the logs that would explain it did not survive the cleanup. We publish it as an open failure mode with its exact key names.

Lock down what works

The meta-lesson cost us two days: the November environment that ran everything was never snapshotted. When the disk cleanup removed it, “restore” became an archaeology project. Concretely, for any stack like this:

1. pip freeze > requirements-frozen.txt (and conda env export) the day it works — before any cleanup.
2. Treat torch as the load-bearing pin; upgrade it only as a coordinated migration with its four compiled dependents.
3. When a gate error tells you to upgrade, check which package shipped the gate first — here, downgrading transformers 4.57.3 → 4.52.0 was a one-package fix for a one-package regression.

The error strings above are indexed for search: if you landed here by pasting one of them, the short version is — transformers 4.52.0, torch 2.4.1, and don’t let anything sed your source.

Part 1 with the hardware measurements: InfiniteTalk on two consumer GPUs — 218.5 s/step, measured.