---
title: "InfiniteTalk Dies at torch.load: the Error Tells You to Upgrade torch — the Measured Fix Is Pinning transformers 4.52.0"
date: 2026-08-26
description: "Measured: the CVE-2025-32434 torch.load gate says upgrade torch — torch 2.10 then breaks four packages at once; the fix is pinning transformers 4.52.0."
category: "AI & Compute"
tags:
  - "InfiniteTalk"
  - "Wan2.1"
  - "PyTorch"
  - "transformers"
  - "CVE-2025-32434"
  - "Dependencies"
verifiedHardware: "RTX 4090D 24GB + RTX A4000 16GB dual-GPU workstation (Ubuntu 24.04, conda, Python 3.10)"
keyTakeaways:
  - "On a stack that had already run InfiniteTalk 14B fp8 end-to-end (torch 2.4.1), transformers 4.57.3 kills every launch at torch.load with a ValueError citing CVE-2025-32434 — failing in 18.0–18.6 s, three attempts in a row, before a single frame renders."
  - "Following the error message and upgrading to torch 2.10.0+cu128 breaks the rest of the stack simultaneously: a three-package pip conflict (torchaudio, torchvision, xformers all require torch==2.4.1), `operator torchvision::nms does not exist`, a diffusers import failure (`JITCallable._set_src()`), and flash-attn's `undefined symbol` — five verbatim breakages, measured the same morning."
  - "The measured fix goes the opposite direction of the error message: transformers pinned to 4.52.0 (4.49.0 and 4.51.0 import cleanly but die inside xfuser's diffusers imports), on torch 2.4.1 + torchvision 0.19.1 + xformers 0.0.28 + flash-attn 2.8.3 — the only combination in the sweep that reached pipeline initialization."
measuredOn: 2026-02-19
faq:
  - q: "InfiniteTalk crashes with ValueError: Due to a serious vulnerability issue in torch.load (CVE-2025-32434) — how do I fix it?"
    a: "If this stack worked before, don't upgrade torch — pin transformers 4.52.0. The gate lives in transformers' check_torch_load_is_safe (measured firing on 4.57.3) and triggers whenever the pipeline loads a .pt file through torch.load; safetensors loads are exempt (the error text itself says so). Downgrading transformers below the gate restores the old behavior without touching the rest of the stack."
  - q: "Should I upgrade torch to 2.6+ when transformers demands it?"
    a: "Measure what it costs you first. On our InfiniteTalk/Wan2.1 stack, torch 2.10.0+cu128 produced a three-package pip conflict (torchaudio 2.4.1, torchvision 0.19.1, xformers 0.0.28 — all declare torch==2.4.1) plus runtime failures: `operator torchvision::nms does not exist`, a diffusers JITCallable import error, and a flash-attn `undefined symbol`. All verbatim strings are in the article; all hit the same morning."
  - q: "Which transformers version works with InfiniteTalk on torch 2.4.1?"
    a: "4.52.0 (measured 2026-02-20). 4.57.3 is blocked at torch.load by the CVE gate; 4.49.0 and 4.51.0 import cleanly but die at runtime inside xfuser's diffusers import chain. Only 4.52.0 got the pipeline to initialize."
  - q: "What are the exact working dependency pins for the InfiniteTalk (Wan2.1 14B) pipeline?"
    a: "torch 2.4.1, torchvision 0.19.1, xformers 0.0.28, flash-attn 2.8.3, transformers 4.52.0 — conda, Python 3.10, Ubuntu 24.04, dual RTX 4090D + A4000. Both +cu121 and +cu124 wheel variants appear in our logs; exact wheel provenance is unrecorded — the version numbers are what mattered."
  - q: "Is the torch.load CVE-2025-32434 warning actually a security problem for local inference?"
    a: "The vulnerability class is real — unsafe pickle deserialization — and the gate is reasonable advice for new code. But on an offline, single-user rig loading your own locally verified checkpoints, upgrading a pinned working stack to satisfy it is a trade, measured here as a five-way breakage. If your loader supports safetensors checkpoints, that path is exempt from the gate entirely."
  - q: "Can an AI agent fix this kind of dependency hell for me?"
    a: "Partially — and it can make it worse. One failed attempt in our log is an agent sed-editing `weights_only=True` out of the source, which left a bare `weights_only=` keyword and six consecutive SyntaxErrors. Agents are genuinely fast at running a bisection matrix; the pins should still land in a requirements file reviewed by someone who knows the stack ran before."
---
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](/posts/2026-08-26-infinitetalk-14b-dual-gpu-measured/) 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](/posts/2026-08-26-infinitetalk-14b-dual-gpu-measured/).*