Wan2.2 FP8 e4m3fn vs e5m2: Which Quant to Download (and Why torch.compile Breaks on RTX 30-Series)

If you download a Wan2.2 model from Kijai’s repack, from the Comfy-Org repackaged collection, or from most community mirrors, you will hit the same small naming fork almost immediately: fp8_e4m3fn_scaled versus fp8_e5m2_scaled. Both are "fp8." Both are roughly the same size on disk (a 14B model lands around 14–16GB either way). But they are not interchangeable, and picking the wrong one produces a specific, confusing failure — an error that only appears after you enable torch.compile, on specific GPUs.

This guide explains what the naming actually means, when each variant matters, and how to decide which file to pull for your card. It is based on the model author’s own published explanations and linked downstream bug reports, not on a benchmark run on hardware I happen to own, so each claim is traced to its source rather than asserted as personal testing.

The symptom: it works until you flip one switch

The typical sequence goes like this:

• You load a Wan2.2 14B workflow (T2V, I2V, or Animate) with the e4m3fn_scaled fp8 file the official tutorial links to.
• It runs fine at default settings.
• You enable torch.compile in the loader node to speed things up, as several speed guides recommend.
• You get a hard error — something in the torch.compile / inductor path — and the prompt dies before the first sample.

The error reads like an unsupported-operation or dtype failure, and it is easy to misread as "torch.compile is broken" when the real cause is which fp8 encoding your file uses. The confusion is compounded by the fact that the two variants have near-identical names and live in the same directory.

What e4m3fn and e5m2 actually mean

fp8 is not one format. It is a family of layouts that divide eight bits between the sign, the exponent, and the mantissa (fraction). The two you will see for Wan2.2 are:

• e4m3fn — 4 exponent bits, 3 mantissa bits, "fn" for "finite only" (no inf/NaN encoding). This gives a smaller exponent range but more mantissa precision, so it represents values near 1.0 more accurately. It is the default fp8 layout in basically every contemporary model quantizer, including PyTorch’s own fp8 tooling.
• e5m2 — 5 exponent bits, 2 mantissa bits. This trades mantissa precision for a much wider exponent range, closer to bf16’s dynamic range.

Both are standard IEEE-aligned layouts (e4m3fn and e5m2 match the FP8 formats introduced for transformer inference). The key practical difference for Wan2.2 is not raw quality — it is toolchain compatibility, which is what this article is about.

Why e4m3fn breaks torch.compile on pre-4000 GPUs

The most important guidance on this comes directly from Kijai, who maintains the WanVideo_comfy fp8 repack that most people download. In the discussion thread on the model repository, Kijai states the reason for publishing both variants plainly:

"I’ve shared e5m2 mostly because it works with torch.compile on pre-4000 series GPUs, while e4m3fn does not."

That is the entire rationale, and it is the single most useful sentence to internalize here. The reason is architectural: fp8 tensor-core support in PyTorch’s torch.compile/inductor path is not uniform across GPU generations. The e4m3fn layout is the one whose fast-path kernels are only reliably emitted on the newer hardware (the RTX 40-series “Ada” generation and newer, including Blackwell 50-series). On older cards — RTX 20/30-series (Turing/Ampere) — enabling torch.compile with an e4m3fn model trips the inability to lower that fp8 op, and the run hard-fails.

The e5m2 layout, with its wider exponent range, happens to lower cleanly on the older hardware’s compile path, which is why Kijai ships a separate e5m2 file specifically for those cards.

So the decision rule is not about quality. It is:

• RTX 40-series or newer (Ada / Blackwell) → use e4m3fn_scaled, and torch.compile will work.
• RTX 30-series or older (Turing / Ampere) → use e5m2_scaled if you intend to use torch.compile. Kijai’s e4m3fn vs e5m2 thread is the primary source.

"scaled" is not a third format — it is how you normalize weights

One recurring question in that same thread is whether e5m2 corresponds to what the official Wan repo calls "scaled." The answer, again from Kijai, is no:

"No, the comfy scaled models for Wan are e4m3fn only. Difference to mine is how the scaling is calculated only."

This clears up a frequent point of confusion. "Scaled" in these filenames does not signal the fp8 encoding. It refers to how the per-tensor scales are computed when the weights are converted to fp8 — effectively which scale factor gets baked into the file. The official Comfy-Org repackaged Wan fp8 models use one scaling recipe (e4m3fn encoding), while Kijai’s repack uses a different scaling recipe for the same e4m3fn encoding, and additionally provides an e5m2-encoded variant for the older-GPU compile case.

In practice this means: do not treat "scaled" as an indicator of which file to pick. Match on the actual e4m3fn / e5m2 token instead, and treat the wrapper’s provenance as a separate concern.

A second confusion source: fp8 "ghosting" that is actually a sampler problem

The same community discussion surfaces a second trap worth flagging, because people frequently blame the fp8 quant for artifacts that are not the quant’s fault. A user reported that switching between fp8 and a Q8 GGUF caused "ghosting / blending" hallucinations with the lightx2v LoRA, concluding fp8 was lower quality. The follow-up pinpointed the real cause: they had changed the sampler (DPM++ to Euler) while keeping the step count low, and needed roughly double the steps at low Euler counts to match Q8’s output.

Kijai’s own comparison showed no meaningful quality gap between the scaled fp8 and fp16 at matched settings. The lesson: if you see artifacts after switching to fp8, first lock the sampler and step count to be identical to your known-good run, then compare. The quantization is rarely the thing that changed when the sampler was changed in the same breath.

Which file do I actually download?

Putting it together, here is the concrete selection guidance for the common cases:

• You have an RTX 4090 / 4080 / 50-series card. Download the e4m3fn_scaled file. It is the default recommendation in the official Wan2.2 ComfyUI workflow documentation, it enables torch.compile acceleration, and it is what most speed guides assume.
• You have an RTX 3090 / 3080 or older, and you want torch.compile. Download the e5m2_scaled file from Kijai’s repack instead. This is the entire reason that variant exists.
• You are not using torch.compile at all. Either variant will load and run; the e4m3fn is the safer general default because it is the more widely tested path and has slightly more mantissa precision.

If the model you download is close to or larger than your total VRAM (a 14B fp8 file is ~14–16GB, which is right at the ceiling of a 16GB card), the quant choice is only half the battle — you also have to get the offload behavior right or you will OOM regardless. See our companion piece on how block_swap and offload_device actually work for the VRAM side of the same 14B-fp8 problem.

A note on what this article does and doesn’t verify

Everything above is documentation and community-sourced analysis, linked to the specific sources, not a benchmark I ran on local hardware. I do not currently own an RTX 30-series card to reproduce the torch.compile failure end-to-end, so I am deliberately not reporting fabricated iteration counts, VRAM curves, or "I tested it and…" claims here. The two authoritative anchor points are Kijai’s published explanation of why the e5m2 variant exists, and the official ComfyUI Wan2.2 documentation’s default e4m3fn_scaled recommendation. If you are on 40-series or newer, the default advice is simple and safe: use e4m3fn. If you are on older hardware and want compile acceleration, the e5m2 file is the documented reason it exists — verify against your own version and read the linked thread for any updates.

Conclusion

The fp8_e4m3fn versus fp8_e5m2 fork is the kind of detail that costs an hour when you get it wrong and clears up in five minutes when you know what it means. Match the token to your GPU generation: e4m3fn for 40-series and newer, e5m2 for older cards when torch.compile is on. Treat "scaled" as a scaling-recipe label, not a format label. And when fp8 output looks worse at a glance, freeze your sampler and step count before blaming the quantization — in the documented case, the sampler was the actual culprit all along.