Wan Workbench is an independent engineering blog dedicated to running, understanding, optimizing, and reproducing Wan2.2 video workflows on real consumer hardware.
This is not a prompt gallery. It is not a highlight reel of cherry-picked results. It is a working log of what actually happens when you try to make Wan2.2 produce consistent, usable video on the kind of GPUs most people actually own.
If a workflow cannot be repeated with the same settings, the same seeds, the same hardware, and the same failure modes, it is not finished. That is the only rule that matters here.
Who Runs This
My name is Dan Kowalski. I am an independent AI video engineer based in Pittsburgh, Pennsylvania.
I build, benchmark, and deliberately break Wan2.2 workflows. I do this on consumer hardware, not in a research lab with unlimited VRAM and a support team. My primary test card is a carefully maintained GPU. The secondary card is a used RTX 3090 I bought secondhand, repaired, and turned into a dedicated testing machine. Both cards have logged hours of thermal, power, and VRAM measurements so I know exactly what they do under load.
I am not a research scientist. I am not affiliated with any model lab. I am a practitioner who got tired of undocumented settings, missing version numbers, and workflows that only work once on someone else’s machine. So I started writing down everything: exact node graphs, dependency versions, seeds, render times, VRAM peaks, and the precise point at which things fall apart.
Why This Exists
Most Wan2.2 content online falls into one of two categories: impressive demos with zero reproducibility data, or fragmented troubleshooting threads that never get resolved. Neither is useful when you are trying to ship something.
I started this site because I needed a place that answered four questions on every major post:
What hardware and software were used?
What exactly was tested?
What failed or changed?
Can another reader reproduce it?
If a post cannot answer those four questions, it does not get published.
The Hardware Reality
I test on the same class of cards most independent creators and small studios actually use. That means 16 GB and 24 GB consumer GPUs, not multi-GPU server racks. It means dealing with real thermal limits, real power draw, real secondhand hardware quirks, and real evening time constraints.
After my daughter Nora goes to bed, I usually have a limited window to run controlled tests. That constraint forced a strict process: one configuration at a time, full logging, and no uncontrolled batches. The cat, Biscuit, objects to loud GPU fans, which has also taught me the practical value of good case airflow and quiet power profiles.
I repair and modify old hardware for fun — mechanical keyboards, GPUs, audio gear. That habit carries over. When a used 3090 arrives with issues, I diagnose and fix it before it becomes a test platform. The same mindset applies to workflows: if something is broken, I want the root cause, not a workaround that hides it.
Voice and Standards
The voice here is simple: the technically sharp friend who shows you the settings, explains what broke, and never pretends a bad result is good.
You will see exact versions, parameters, seeds, hardware specs, VRAM measurements, and render times. Jargon gets explained once in plain language. Verified results, current tests, and informed guesses are clearly separated. Failed or unstable results are never presented as production-ready.
I do not use “we” to imply a team. There is no team. There is one independent engineer, a notebook, two GPUs, and a high bar for what counts as a finished workflow.
Signature phrases you will see repeatedly:
“If you can’t reproduce it, it’s not a workflow.”
“Run the test. Save the settings. Show the failure.”
“The settings are part of the result.”
What You Will Find Here
The site is organized around four core categories:
The Wan Bench — structured experiments with fixed variables, controlled comparisons, and output evidence.
ComfyUI Under the Hood — node-by-node breakdowns, dependency setup, graph design, and practical debugging.
VRAM and Hardware Reality — consumer GPU testing, memory requirements, offloading, quantization, thermals, power use, and secondhand hardware.
Failure Reports — failed renders, temporal artifacts, broken anatomy, flicker, model-loading errors, and systematic root-cause analysis.
Every major technical article is written so another reader with similar hardware can attempt the same test and get the same (or informatively different) result.
Life Outside the Bench
On weekends I hike or ride the trails around Pittsburgh. I watch science-fiction films and pay attention to practical effects, lighting, motion, and visual continuity — the same things that fall apart in AI video when temporal consistency breaks. I live with my wife Megan (a pediatric nurse), our five-year-old daughter Nora, and Biscuit the cat.
The limited evening testing window is not a complaint. It is a feature. It forces discipline. One configuration. Full documentation. No shortcuts.
Contact and Reproducibility
If you run one of the workflows published here and get a meaningfully different result under the same conditions, I want to know. Reproducibility is the entire point. Send the versions, the seeds, the hardware, the logs, and the output. That is how the next post gets better.
Wan Workbench exists for creators and developers who want practical Wan2.2 results without wasting days on undocumented settings. The goal is simple: make the work reproducible, or admit it is not finished yet.
Run the test. Save the settings. Show the failure.