Recommended paper: Wan: Open and Advanced Large-Scale Video Generative Models
Research interest: (pin-arxiv)
TL;DR
Wan's video suite is already fully merged here (T2V/I2V/V2V/animate/vace pipelines, Wan VAE+DiT, conversion script). Its training/data/eval contributions aren't reproducible in diffusers. Is a coverage gap worth a PR?
License & code availability
🔴 No LICENSE file detected — no legal permission to redistribute or modify the code. Treat as blocking until upstream adds a license.
Suggested experiment
Scope any implementation to a single verified gap in the existing Wan support (e.g. a missing scheduler/quantization/14B code path, LoRA/Fast path, or a Wan2.2 variant) rather than re-adding the model suite; if no gap exists, the paper is already covered and no implementation is warranted.
Why the orchestrator opened an Issue instead of a PR
Pre-flight routed to Issue before implementation
Why this didn't ship as a PR
Wan's actionable deliverable for diffusers — the full model-support stack (T2V/I2V/V2V/animate/vace pipelines, Wan DiT transformers, causal VAE, and conversion script) — is already merged in this repo, so Mode 1 has nothing left to port and Mode 2 collapses (there is no separate core to adapt around; the architecture is already native). Mode 3 does not apply because Wan's remaining contributions (scalable pre-training, billions-of-clips data curation, automated eval metric) require infrastructure diffusers does not host. With no new implementable slice, route to ISSUE for the team to decide whether a verified coverage gap is worth a PR.
Engineering analysis
Wan (arXiv 2503.20314) is an open video-generation suite with 1.3B and 14B diffusion-transformer models, a novel causal 3D VAE, and supporting pre-training / data-curation / automated-evaluation contributions. Its actionable artifact for a downstream library is the released weights and architecture, which map onto diffusers' standard model-support pattern (DiT transformer + VAE + pipelines + conversion script), exactly like the existing Mochi / CogVideoX / LTX / HunyuanVideo support.
What blocks a clean implementation
The natural Mode-1 port — adding Wan to diffusers — is already done. This repo already ships:
- Pipelines (
src/diffusers/pipelines/wan/): pipeline_wan.py (T2V), pipeline_wan_i2v.py (I2V), pipeline_wan_video2video.py (V2V), pipeline_wan_animate.py, pipeline_wan_vace.py (editing/creation)
- DiT (
src/diffusers/models/transformers/): transformer_wan.py, transformer_wan_animate.py, transformer_wan_vace.py
- VAE (
src/diffusers/models/autoencoders/): autoencoder_kl_wan.py
- Conversion:
scripts/convert_wan_to_diffusers.py
Consequently Mode 1 has nothing left to port, and Mode 2 (adapted port) collapses — there is no extractable core mechanism to wrap with substituted auxiliaries, because the full architecture is already native at higher fidelity than any adaptation. Mode 3 (inspired experiment) does not apply: Wan's remaining contributions are engineering-at-scale (scalable pre-training, large-scale data curation, scaling laws) plus an automated eval metric, none of which diffusers can host (no trainer, no dataset pipeline, not an eval suite) and none of which reframe into a worthwhile target-native experiment.
How to unblock this
- Is there a specific, verified gap in the existing Wan coverage a PR could fill — e.g. a missing scheduler pairing, a 14B-specific code path, quantization/
fbgemm path, LoRA or Fast path, or a Wan2.2 / feature variant not yet wired? If yes, scope the PR to that single gap and cite it against the files above.
- If no gap exists, this paper is already covered and should be skipped — confirm and close rather than re-adding the suite.
- Separately decide whether the team wants Wan's automated evaluation metric surfaced through some eval path; note this is outside diffusers' usual library scope.
Opened by the Remyx Recommendation orchestrator. Pre-flight routed this paper to Issue before the coding agent ran — see the reasoning above for what would need to change to scaffold it as a PR.
Reopen this Issue if you want Outrider to revisit this paper later. While it stays closed, the orchestrator will not re-recommend the same paper.
Recommended paper: Wan: Open and Advanced Large-Scale Video Generative Models
Research interest: (pin-arxiv)
TL;DR
Wan's video suite is already fully merged here (T2V/I2V/V2V/animate/vace pipelines, Wan VAE+DiT, conversion script). Its training/data/eval contributions aren't reproducible in diffusers. Is a coverage gap worth a PR?
License & code availability
🔴 No LICENSE file detected — no legal permission to redistribute or modify the code. Treat as blocking until upstream adds a license.
(none detected)(class:missing, compat: 0.00)Suggested experiment
Scope any implementation to a single verified gap in the existing Wan support (e.g. a missing scheduler/quantization/14B code path, LoRA/Fast path, or a Wan2.2 variant) rather than re-adding the model suite; if no gap exists, the paper is already covered and no implementation is warranted.
Why the orchestrator opened an Issue instead of a PR
Pre-flight routed to Issue before implementation
Why this didn't ship as a PR
Wan's actionable deliverable for diffusers — the full model-support stack (T2V/I2V/V2V/animate/vace pipelines, Wan DiT transformers, causal VAE, and conversion script) — is already merged in this repo, so Mode 1 has nothing left to port and Mode 2 collapses (there is no separate core to adapt around; the architecture is already native). Mode 3 does not apply because Wan's remaining contributions (scalable pre-training, billions-of-clips data curation, automated eval metric) require infrastructure diffusers does not host. With no new implementable slice, route to ISSUE for the team to decide whether a verified coverage gap is worth a PR.
Engineering analysis
Wan (arXiv 2503.20314) is an open video-generation suite with 1.3B and 14B diffusion-transformer models, a novel causal 3D VAE, and supporting pre-training / data-curation / automated-evaluation contributions. Its actionable artifact for a downstream library is the released weights and architecture, which map onto diffusers' standard model-support pattern (DiT transformer + VAE + pipelines + conversion script), exactly like the existing Mochi / CogVideoX / LTX / HunyuanVideo support.
What blocks a clean implementation
The natural Mode-1 port — adding Wan to diffusers — is already done. This repo already ships:
src/diffusers/pipelines/wan/):pipeline_wan.py(T2V),pipeline_wan_i2v.py(I2V),pipeline_wan_video2video.py(V2V),pipeline_wan_animate.py,pipeline_wan_vace.py(editing/creation)src/diffusers/models/transformers/):transformer_wan.py,transformer_wan_animate.py,transformer_wan_vace.pysrc/diffusers/models/autoencoders/):autoencoder_kl_wan.pyscripts/convert_wan_to_diffusers.pyConsequently Mode 1 has nothing left to port, and Mode 2 (adapted port) collapses — there is no extractable core mechanism to wrap with substituted auxiliaries, because the full architecture is already native at higher fidelity than any adaptation. Mode 3 (inspired experiment) does not apply: Wan's remaining contributions are engineering-at-scale (scalable pre-training, large-scale data curation, scaling laws) plus an automated eval metric, none of which diffusers can host (no trainer, no dataset pipeline, not an eval suite) and none of which reframe into a worthwhile target-native experiment.
How to unblock this
fbgemmpath, LoRA or Fast path, or a Wan2.2 / feature variant not yet wired? If yes, scope the PR to that single gap and cite it against the files above.Opened by the Remyx Recommendation orchestrator. Pre-flight routed this paper to Issue before the coding agent ran — see the reasoning above for what would need to change to scaffold it as a PR.
Reopen this Issue if you want Outrider to revisit this paper later. While it stays closed, the orchestrator will not re-recommend the same paper.