# NVIDIA GeForce RTX 5060 Ti and Wan2.2 model
**URL:**
**Author:**  [@Vihaananand](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FVihaananand)%5C
**Post date:** [November 19, 2025, 2:31pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-geforce-rtx-5060-ti-and-wan2-2-model%2F170645%2F1 "2025-11-19T14:31:43Z")
Hello,
With 4 NVIDIA GeForce RTX 5060 Ti graphics cards with 8GB VRAM and Wan2.2 model, how many seconds of video can I produce from a photo?
Thank you.
---
**Author:**  [@system](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fsystem)%5C
**Post date:** [November 19, 2025, 2:31pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-geforce-rtx-5060-ti-and-wan2-2-model%2F170645%2F2 "2025-11-19T14:31:45Z")
Unlisted on November 19, 2025, 2:31pm UTC
---
**Author:**  [@system](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fsystem)%5C
**Post date:** [November 20, 2025, 3:29am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-geforce-rtx-5060-ti-and-wan2-2-model%2F170645%2F3 "2025-11-20T03:29:20Z")
Listed on November 20, 2025, 3:29am UTC
---
**Author:**  [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C
**Post date:** [November 20, 2025, 4:43am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-geforce-rtx-5060-ti-and-wan2-2-model%2F170645%2F4 "2025-11-20T04:43:21Z")
It’s best to assume that the length of a video generated in a single run will be within 3 to 5 seconds.
* * *
### 1. Direct answer (what you can realistically expect)
On a PC with **4 × NVIDIA GeForce RTX 5060 Ti (8 GB VRAM each)** and **Wan2.2 series models, running locally (ComfyUI / Diffusers)**:
- For a **single image→video clip** at **“normal” quality** :
- Adding more GPUs (4 cards instead of 1) **does not increase the length of a single clip**.
So, per _one_ generation “from a photo”, your realistic target is:
> **One Wan2.2 clip = about 3–5 seconds of video.**
> **Four GPUs = more of these 3–5s clips at once, not one huge 20–30s clip.**
* * *
### 2. Why the limit is 3–5 seconds per clip (model-level constraints)
**Wan2.2 is designed around short clips.** The key references all line up:
- The official **Wan2.2 TI2V-5B card** states that this model generates **720p video at 24 fps** , and benchmarks it as producing a **5-second 720p clip** on a single consumer GPU. ([modelscope.cn](https://modelscope.cn/models/Wan-AI/Wan2.2-TI2V-5B "Wan2.2-TI2V-5B"))
- Wiro and other frontends describe the same 5B model as supporting **both text-to-video and image-to-video at 720p/24fps**. ([wiro.ai](https://wiro.ai/models/wan-ai/wan2-2-ti2v-5b-text-to-video "Wan2.2-TI2V-5B-text-to-video"))
- Scenario’s official Wan2.2 help page says plainly:
- InstaSD’s Wan2.2 guide reinforces this:
- Fal’s Wan 2.2 API guide benchmarks _specifically_ **5-second, 720p @ 24 fps clips** (TI2V-5B ≈ 9 minutes per 5 s on an RTX 4090; 14B models on 8-GPU clusters). ([blog.fal.ai](https://blog.fal.ai/wan-2-2-api-complete-developer-guide-to-next-generation-video-synthesis/ "WAN 2.2 API: Complete Developer Guide to Next- ..."))
In other words:
- The **architecture** and **training regime** of Wan2.2 are tuned around:
- Duration is simply:
[
\text{seconds} = \frac{\text{frame count}}{\text{fps}}
]
Examples:
- 81 frames @ 24 fps ≈ **3.4 seconds**
- 120 frames @ 24 fps = **5.0 seconds**
- 80 frames @ 16 fps = **5.0 seconds**
Going much beyond this (more frames) is possible but leaves the “recommended” zone and tends to degrade quality or stability.
* * *
### 3. What your GPUs actually change (and what they don’t)
You have **4 × 5060 Ti 8 GB**. Important facts:
1. **Each GPU has its own 8 GB VRAM**
VRAM does **not** simply add up to “32 GB” for a single Wan2.2 job. Out of the box, ComfyUI / Diffusers run each workflow on **one GPU at a time**.
2. **Wan2.2 TI2V-5B is already optimized for 8 GB**
3. **Chimolog’s Wan2.2 GPU benchmarks** focus on 5-second clips and show:
4. **Four GPUs = four lanes**
In practice, on your PC:
Advanced multi-GPU sharding (FSDP / DeepSpeed or ComfyUI-MultiGPU / DisTorch) can spread Wan2.2/14B across multiple GPUs + RAM, but this mainly lets you:
- Run **bigger models (14B) or higher resolution**,
- Not stretch a single clip much beyond the ~5-second temporal window.
* * *
### 4. How this breaks down by Wan2.2 variant on your 4× 5060 Ti
#### 4.1 Wan2.2 TI2V-5B (the main “from a photo” model)
- Specs: 5B dense model, **720p @ 24 fps** , unified text+image→video. ([filtrix.ai](https://www.filtrix.ai/model/wan202 "Wan2.2 - Advanced Mixture-of-Experts Video Generation"))
- Designed to generate **up to ~5-second clips** at that resolution on consumer GPUs. ([modelscope.cn](https://modelscope.cn/models/Wan-AI/Wan2.2-TI2V-5B "Wan2.2-TI2V-5B"))
On your 8 GB 5060 Ti:
- **Safe, everyday settings:**
- **At 720p, with careful offload (Comfy native):**
Per clip, you **do not exceed ~5 seconds** comfortably; for longer content you chain clips.
#### 4.2 Wan2.2 T2V-A14B / I2V-A14B (MoE 14B series)
- Specs from the 14B model cards:
On your hardware:
- Running 14B **naively** on a single 8 GB is not realistic; it wants much more VRAM or multi-GPU. ([Hugging Face](https://huggingface.co/Wan-AI/Wan2.2-T2V-A14B "Wan-AI/Wan2.2-T2V-A14B"))
- With **quantization (GGUF) + multi-GPU sharding** (ComfyUI-MultiGPU, FSDP/Ulysses), you can make it fit and run at **480p**.
The **per-clip duration is still ~3–5 seconds** :
- The 14B series is benchmarked on **5-second 720p/480p** clips, just like 5B. ([blog.fal.ai](https://blog.fal.ai/wan-2-2-api-complete-developer-guide-to-next-generation-video-synthesis/ "WAN 2.2 API: Complete Developer Guide to Next- ..."))
- The extra capacity (14B vs 5B, or multi-GPU) mainly buys **quality, detail, or resolution** , not longer per-clip duration.
#### 4.3 Special hosted variants (e.g. Wan2.2-Fun-Control)
- Some cloud-hosted Wan2.2 variants like **Wan2.2-Fun-Control** advertise **up to 120s at 720p** because they run on large multi-GPU servers and use specialized pipelines. ([wavespeed.ai](https://wavespeed.ai/models/wavespeed-ai/wan-2.2/fun-control "Wan 2.2 Fun Control | AI Avatar & Video-To- ..."))
- If you call those APIs from your PC, your local GPUs don’t limit clip length—the provider does.
- For **local ComfyUI / Diffusers on your 4× 5060 Ti** , you should still think in terms of **3–5 seconds per clip**.
* * *
### 5. Putting it all together for your question
**Question:**
“With 4 × RTX 5060 Ti (8 GB VRAM) and Wan2.2 series, how many seconds of video can I produce from a photo?”
**Answer, in practical terms:**
1. **Per single Wan2.2 clip (local, from one photo):**
2. **Per GPU:**
3. **With 4 GPUs together:**
So the clear, easy planning rule for your setup is:
> **Think: 3–5 seconds of video per Wan2.2 clip from a photo, per GPU.
> Your 4 GPUs multiply how many of those 3–5s clips you can produce,
> but they don’t extend a single clip beyond the model’s short-clip design.**
---
**Author:**  [@Vihaananand](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FVihaananand)%5C
**Post date:** [December 16, 2025, 5:12am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-geforce-rtx-5060-ti-and-wan2-2-model%2F170645%2F5 "2025-12-16T05:12:30Z")
Hello,
Thank you so much for your reply.
So how do services like Runway ML produce long videos?
---
**Author:**  [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C
**Post date:** [December 16, 2025, 5:36am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-geforce-rtx-5060-ti-and-wan2-2-model%2F170645%2F6 "2025-12-16T05:36:07Z")
Hm.
* * *
Runway gets “long videos” by **chaining short generations** , not by generating one giant continuous clip in a single pass.
## How Runway makes longer videos in practice
### 1) Generate a short clip first
You generate an initial Gen-3 clip. Then Runway exposes an **Extensions** panel for that clip. ([academy.runwayml.com](https://academy.runwayml.com/gen3-alpha/gen3-alpha-extensions "Gen-3 Alpha Extensions"))
### 2) Use “Extend” to add more time in chunks
Runway’s own docs say you can **extend a completed generation up to three times**. ([Runway](https://help.runwayml.com/hc/en-us/articles/30266515017875-Creating-with-Gen-3-Alpha-and-Gen-3-Alpha-Turbo "Creating with Gen-3 Alpha and Gen-3 Alpha Turbo"))
Runway’s changelog also states extensions add **an additional 5 or 10 seconds** and can reach **up to 40 seconds** total. ([Runway](https://runwayml.com/changelog "Product Updates & Changelog | Runway AI"))
Concrete caps Runway documents:
- **Gen-3 Alpha** : extend up to **40 seconds total** (via up to 3 extensions). ([Runway](https://help.runwayml.com/hc/en-us/articles/30266515017875-Creating-with-Gen-3-Alpha-and-Gen-3-Alpha-Turbo "Creating with Gen-3 Alpha and Gen-3 Alpha Turbo"))
- **Gen-3 Alpha Turbo** : extend up to **34 seconds total** , when the original clip is **10 seconds**. ([Runway](https://help.runwayml.com/hc/en-us/articles/30266515017875-Creating-with-Gen-3-Alpha-and-Gen-3-Alpha-Turbo "Creating with Gen-3 Alpha and Gen-3 Alpha Turbo"))
So the product behavior is:
> short clip → extend → extend → extend → one longer clip (up to the cap)
### 3) For longer than ~34–40 seconds, they stitch multiple clips
Runway’s own guidance on “longer videos and films” is essentially: generate multiple clips and assemble them. ([ACM Digital Library](https://dl.acm.org/doi/full/10.1145/3771724 "Exploring the Latest Trends in Long Video Generation"))
That is how you get “minutes”: you make **many shots** , then edit them together.
### 4) “Expand Video” is not “Extend”
Runway’s **Expand Video** feature is about expanding the **frame boundaries / aspect ratio** , not making the timeline longer. ([Runway](https://help.runwayml.com/hc/en-us/articles/34926355398675-Creating-with-Expand-Video-on-Gen-3-Alpha-Turbo "Creating with Expand Video on Gen-3 Alpha Turbo"))
## What’s going on under the hood (simple explanation)
Runway does not fully publish the internal algorithm, but the **behavior** matches a widely used pattern in video generation:
### A) Continuation conditioning
An “extension” typically works like:
- Take the existing clip (often the last frames or a compressed representation).
- Generate the next chunk so motion continues smoothly.
- Optionally add a prompt for steering the continuation (Runway explicitly supports adding text for more control during extension). ([academy.runwayml.com](https://academy.runwayml.com/gen3-alpha/gen3-alpha-extensions "Gen-3 Alpha Extensions"))
### B) Sliding-window generation (common research approach)
In long-video diffusion research, a common approach is to **split a long target video into overlapping short clips** (a “sliding window”), generate them, then blend overlaps to reduce seams. ([CVF Open Access](https://openaccess.thecvf.com/content/CVPR2025/papers/Li_LongDiff_Training-Free_Long_Video_Generation_in_One_Go_CVPR_2025_paper.pdf "LongDiff: Training-Free Long Video Generation in One Go"))
Important nuance: this research description does not prove Runway uses the exact same technique. It explains why “extend in chunks” is the standard way to get longer outputs from models that are naturally short-clip generators.
## Why cloud services feel more capable than local models
Even if the strategy is “short clips + extension,” a service like Runway can make it feel smooth because it can afford:
- Big GPUs and lots of VRAM.
- Multiple attempts behind the scenes.
- Extra refinement passes and better post-processing.
But there are still **explicit product caps** on how long a single extended clip can be (34–40 seconds for Gen-3, per their docs). ([Runway](https://help.runwayml.com/hc/en-us/articles/30266515017875-Creating-with-Gen-3-Alpha-and-Gen-3-Alpha-Turbo "Creating with Gen-3 Alpha and Gen-3 Alpha Turbo"))
## Summary
- Runway makes longer videos by **generating short clips and extending them** up to a documented cap. ([Runway](https://help.runwayml.com/hc/en-us/articles/30266515017875-Creating-with-Gen-3-Alpha-and-Gen-3-Alpha-Turbo "Creating with Gen-3 Alpha and Gen-3 Alpha Turbo"))
- For videos longer than that, it’s **multiple clips (shots) + editing**. ([ACM Digital Library](https://dl.acm.org/doi/full/10.1145/3771724 "Exploring the Latest Trends in Long Video Generation"))
- Technically, this matches common long-video methods like **sliding-window / overlapping segment generation** used in the research literature. ([CVF Open Access](https://openaccess.thecvf.com/content/CVPR2025/papers/Li_LongDiff_Training-Free_Long_Video_Generation_in_One_Go_CVPR_2025_paper.pdf "LongDiff: Training-Free Long Video Generation in One Go"))
Links:
- Creating with Gen-3 Alpha and Turbo (Runway Help): [https://help.runwayml.com/hc/en-us/articles/30266515017875-Creating-with-Gen-3-Alpha-and-Gen-3-Alpha-Turbo](https://help.runwayml.com/hc/en-us/articles/30266515017875-Creating-with-Gen-3-Alpha-and-Gen-3-Alpha-Turbo)
- Gen-3 Alpha Extensions (Runway Academy): [https://academy.runwayml.com/gen3-alpha/gen3-alpha-extensions](https://academy.runwayml.com/gen3-alpha/gen3-alpha-extensions)
- Runway Changelog entry on Extensions: [https://runwayml.com/changelog](https://runwayml.com/changelog)
- Long-video sliding window background (LongDiff, CVPR 2025): [https://openaccess.thecvf.com/content/CVPR2025/papers/Li\_LongDiff\_Training-Free\_Long\_Video\_Generation\_in\_One\_Go\_CVPR\_2025\_paper.pdf](https://openaccess.thecvf.com/content/CVPR2025/papers/Li_LongDiff_Training-Free_Long_Video_Generation_in_One_Go_CVPR_2025_paper.pdf)
---
**Author:**  [@Vihaananand](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FVihaananand)%5C
**Post date:** [December 16, 2025, 10:40am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-geforce-rtx-5060-ti-and-wan2-2-model%2F170645%2F7 "2025-12-16T10:40:46Z")
Hello,
Thanks again.
I would be grateful if you could clarify something for me. How many seconds of video can I produce with an 8, 12, 16, 24, and 32 gigabyte graphics card, respectively? For example, if I want to produce a 10-second video, how much VRAM should my graphics card have?
---
**Author:**  [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C
**Post date:** [December 16, 2025, 12:56pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-geforce-rtx-5060-ti-and-wan2-2-model%2F170645%2F8 "2025-12-16T12:56:30Z")
VRAM is important, but it primarily affects the resolution and sophistication of the videos that can be generated. The length of the generated video is largely influenced by the architecture. Currently, the practical option is to stitch together multiple short output videos.
* * *
Wan2.2 does **not** scale “seconds per clip” linearly with VRAM. Wan2.2 is tuned for **short clips** , and VRAM mainly decides **what resolution and workflow** you can run reliably.
Wan2.2 guidance from multiple sources is consistent: **best results under ~5 seconds** , and **≤120 frames** (with **24 fps** default, **16 fps** for faster testing). ([Instasd](https://www.instasd.com/post/wan2-2-whats-new-and-how-to-write-killer-prompts "Wan2.2 – What's New & How to Write Killer Prompts"))
Wan2.2 TI2V-5B specifically targets **720p @ 24 fps** and is described as producing **up to 5 seconds**. ([fal.ai](https://fal.ai/models/fal-ai/wan/v2.2-5b/image-to-video "Wan v2.2 5B | Image to Video"))
* * *
## What “seconds of video” means (two different meanings)
1. **One continuous generation (one run)**
This is what the model outputs in a single shot. Wan2.2 is usually **3–5 seconds** per run for best stability. ([Instasd](https://www.instasd.com/post/wan2-2-whats-new-and-how-to-write-killer-prompts "Wan2.2 – What's New & How to Write Killer Prompts"))
2. **Final video length (after editing)**
A “10-second video” is usually made by **stitching two 5-second clips** (or three ~3–4 second clips). This is how most people work with short-clip generators.
* * *
## Table: What each VRAM tier buys you with Wan2.2 (local generation)
Assume Wan2.2 TI2V-5B unless noted, using common ComfyUI-style workflows.
| GPU VRAM | What’s realistic and comfortable | Typical “good” seconds per single run | Can it do a clean 10 seconds in ONE run? | Practical way to make a 10-second video |
| --- | --- | --- | --- | --- |
| **8 GB** | **480p** is the practical baseline. 720p may work only with very aggressive offload and specific workflows. Official ComfyUI docs say 5B can fit on 8 GB with native offloading. ([ComfyUIDocument](https://docs.comfy.org/tutorials/video/wan/wan2_2 "Wan2.2 Video Generation ComfyUI Official Native ...")) | **3–5 s** | **Not recommended** | Make **2 × 5 s** at 480p, stitch them. |
| **12 GB** | **480p** is comfortable in most setups. **720p can still be fragile** depending on workflow. Chimolog’s heavy 720p benchmark says **12 GB and below fails** there. ([It’s a little tight.](https://chimolog.co/bto-gpu-wan22-specs/ "〖Wan2.2〗動画生成AIにおすすめなグラボをガチで検証〖GPU別の生成速度〗 | ちもろぐ")) | **3–5 s** | **Not recommended** | Make **2 × 5 s** at 480p (or light 720p if it fits), stitch. |
| **16 GB** | First tier that is **reliably “720p-friendly”** across heavier workflows. Chimolog’s 720p benchmark implies you need **more than 12 GB** to survive 720p in that setup. ([It’s a little tight.](https://chimolog.co/bto-gpu-wan22-specs/ "〖Wan2.2〗動画生成AIにおすすめなグラボをガチで検証〖GPU別の生成速度〗 | ちもろぐ")) | **3–5 s** | **Still not ideal** (quality often degrades past 5 s) | Make **2 × 5 s at 720p** , stitch. |
| **24 GB** | **720p is easy** , more headroom for heavier graphs, fewer compromises, more stable runs. Still the model’s “sweet spot” is short clips. ([Scenario](https://help.scenario.com/en/articles/wan-2-2-models-the-essentials/ "Wan2.2 Video Models | AI Text-to-Video with Cinematic ...")) | **3–5 s** | **Sometimes possible but often worse quality** | Still best: **2 × 5 s** , stitch. |
| **32 GB** | Same as 24 GB but even more breathing room. Helps with larger model variants and complex pipelines. Does not “turn Wan2.2 into a long-clip model.” ([Scenario](https://help.scenario.com/en/articles/wan-2-2-models-the-essentials/ "Wan2.2 Video Models | AI Text-to-Video with Cinematic ...")) | **3–5 s** | **Possible to attempt** but not guaranteed clean | Best: **2 × 5 s** , stitch. |
### Why the “seconds per run” column barely changes
Because Wan2.2 itself is optimized for **short clips**. Sources explicitly say it performs best under **~5 seconds** and around **≤120 frames**. ([Instasd](https://www.instasd.com/post/wan2-2-whats-new-and-how-to-write-killer-prompts "Wan2.2 – What's New & How to Write Killer Prompts"))
VRAM mostly decides whether you can do that at **480p vs 720p** , and whether you must rely on offload. ([It’s a little tight.](https://chimolog.co/bto-gpu-wan22-specs/ "〖Wan2.2〗動画生成AIにおすすめなグラボをガチで検証〖GPU別の生成速度〗 | ちもろぐ"))
* * *
## If you want a 10-second video, how much VRAM should you target?
### Best-practice answer (recommended)
If “10 seconds” means a **final edited video** :
- **10 seconds at 480p:** **12 GB** is a comfortable target. **8 GB can work** with the right workflow and offload. ([It’s a little tight.](https://chimolog.co/bto-gpu-wan22-specs/ "〖Wan2.2〗動画生成AIにおすすめなグラボをガチで検証〖GPU別の生成速度〗 | ちもろぐ"))
- **10 seconds at 720p:** target **16 GB** for reliable local work. This matches independent 720p benchmark behavior where **≤12 GB fails** in a heavy 720p workflow. ([It’s a little tight.](https://chimolog.co/bto-gpu-wan22-specs/ "〖Wan2.2〗動画生成AIにおすすめなグラボをガチで検証〖GPU別の生成速度〗 | ちもろぐ"))
In both cases, you usually generate **two 5-second clips** and stitch.
### “One continuous 10-second clip” answer (hard mode)
Wan2.2 guidance says it works best **under 5 seconds** , and community experiments suggest quality often falls off when pushing longer (even if it runs). ([Instasd](https://www.instasd.com/post/wan2-2-whats-new-and-how-to-write-killer-prompts "Wan2.2 – What's New & How to Write Killer Prompts"))
If you insist on trying a single-run 10 seconds, **24–32 GB** gives you the best chance to fit the extra frames at decent resolution, but it still may not look good because the limitation becomes **temporal coherence** , not VRAM. ([Reddit](https://www.reddit.com/r/StableDiffusion/comments/1mdrvfc/pushing_wan_22_to_10_seconds_its_doable/ "Pushing WAN 2.2 to 10 seconds - It's Doable!"))
* * *
## Short summary
- **Per Wan2.2 run:** plan **3–5 seconds** almost regardless of VRAM. ([Instasd](https://www.instasd.com/post/wan2-2-whats-new-and-how-to-write-killer-prompts "Wan2.2 – What's New & How to Write Killer Prompts"))
- **VRAM decides resolution and stability:**
- **For a 10-second final video:** best approach is **2 × 5 seconds stitched**.
* * *
To generate longer videos than Wan2.2’s usual **~3–5 seconds** , you have to change the **generation approach or model** , not just add VRAM.
- **Stop doing “one-shot” generation.** Wan2.2 is typically used with **≤120 frames** and “works best” **under ~5 seconds**. Pushing past that often causes repetition or drift. ([Scenario](https://help.scenario.com/en/articles/wan-2-2-models-the-essentials/ "Wan2.2 Video Models | AI Text-to-Video with Cinematic ..."))
- **Generate in chunks and continue.** Make multiple short clips (for example 5s + 5s) and “continue” each next clip from the previous clip’s last frames, then stitch in editing. This is the standard practical way to get 10–60+ seconds from short-clip models. ([Scenario](https://help.scenario.com/en/articles/wan-2-2-models-the-essentials/ "Wan2.2 Video Models | AI Text-to-Video with Cinematic ..."))
- **Use overlap instead of hard cuts.** Generate overlapping segments (a sliding window) and blend the overlap to reduce visible seams. FreeNoise describes this explicitly as dividing clips into **overlapped windows**. ([OpenReview](https://openreview.net/forum?id=ijoqFqSC7p "Tuning-Free Longer Video Diffusion via Noise Rescheduling"))
- **Use long-video inference methods.** Techniques like **FreeNoise** (noise rescheduling + windowed temporal attention) and **LongDiff** (training-free components to address long-video failure modes) are specifically designed to extend short-video diffusion models to longer videos. ([arXiv](https://arxiv.org/abs/2310.15169 "FreeNoise: Tuning-Free Longer Video Diffusion via Noise Rescheduling"))
- **Or change the model or training.** Many video diffusion models are trained on a limited number of frames, which is why they struggle to stay consistent for long durations. Fixing that at the root means training (or re-training) for longer temporal windows. ([arXiv](https://arxiv.org/abs/2310.15169 "FreeNoise: Tuning-Free Longer Video Diffusion via Noise Rescheduling"))
---
**Author:**  [@Vihaananand](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FVihaananand)%5C
**Post date:** [December 16, 2025, 2:33pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-geforce-rtx-5060-ti-and-wan2-2-model%2F170645%2F9 "2025-12-16T14:33:22Z")
Hello,
Thanks again.
1- If I want to produce an 8-10 second video in 720p or 1080p quality, then what model is suitable and how much VRAM should my graphics card have?
2- If I want to produce an 8-10 second video in 720p or 1080p with a graphics card with 12 or 16 GB of VRAM, then what model is suitable?
3- How many seconds of video can a model produce?
---
**Author:**  [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C
**Post date:** [December 16, 2025, 2:56pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-geforce-rtx-5060-ti-and-wan2-2-model%2F170645%2F10 "2025-12-16T14:56:28Z")
Hmm, generating long videos locally using consumer GPUs we can normally buy isn’t really that easy _yet_…
I think it’s cheaper to just switch between commercial services as needed…
Unless you have specific requirements, of course.
* * *
### 1) 8–10 seconds at 720p or 1080p: what OSS model, what VRAM?
If you mean “one clip, 8–10 seconds, looks like 720p/1080p”:
**Best practical OSS pick today:** **CogVideoX1.5-5B-I2V**
- It explicitly supports **5 or 10 seconds** output. ([Hugging Face](https://huggingface.co/zai-org/CogVideoX1.5-5B-I2V "zai-org/CogVideoX1.5-5B-I2V · Hugging Face"))
- It runs up to **1360×768** (often called “768p-class”; it is close to 720p). ([Hugging Face](https://huggingface.co/zai-org/CogVideoX1.5-5B-I2V "zai-org/CogVideoX1.5-5B-I2V · Hugging Face"))
- **VRAM guidance:** the model card lists **~9GB minimum** for single-GPU BF16 inference with optimizations. So **12GB works** , **16GB is more comfortable** (less swapping, fewer OOM surprises). ([Hugging Face](https://huggingface.co/zai-org/CogVideoX1.5-5B-I2V "zai-org/CogVideoX1.5-5B-I2V · Hugging Face"))
- If you turn off optimizations, VRAM needs can jump a lot (the model card warns VRAM can increase heavily and mentions optimizations like CPU offload, VAE slicing, VAE tiling). ([Hugging Face](https://huggingface.co/zai-org/CogVideoX1.5-5B-I2V "zai-org/CogVideoX1.5-5B-I2V · Hugging Face"))
**What about “true 1080p generation”?**
Most OSS video models still do not natively generate **1920×1080** 8–10 second clips on consumer VRAM in a clean, repeatable way. The common OSS approach is:
1. generate at the model’s native resolution (often ~768p-class), then
2. **upscale** to 1080p (spatial upscaling) and optionally smooth motion (temporal upscaling / interpolation).
If you want an OSS ecosystem that explicitly supports this “generate then upscale” workflow, **LTX-Video** is relevant because it has **official upscalers** (spatial and temporal) and also supports video extension workflows. ([GitHub](https://github.com/Lightricks/LTX-Video "GitHub - Lightricks/LTX-Video: Official repository for LTX-Video"))
- LTX-Video also has multiple variants (13B, 2B, distilled, FP8) listed on its model card. ([Hugging Face](https://huggingface.co/Lightricks/LTX-Video "Lightricks/LTX-Video · Hugging Face"))
- It has community and official notes that it can run on very low VRAM only at **small settings** (example: 512×512, 50 frames with tricks). ([Hugging Face](https://huggingface.co/Lightricks/LTX-Video/discussions/6 "Lightricks/LTX-Video · Hardware recommendations?"))
- For **720p/1080p-looking** results, you generally step up to larger variants and rely on upscalers. That usually means **more VRAM is better** , but LTX does not give a single universal “X GB required” number in the primary docs.
**A “researchy but heavy” OSS option for 10 seconds:** **Pyramid Flow**
- It explicitly targets **up to 10 seconds at 768p and 24 FPS** , and supports image-to-video. ([GitHub](https://github.com/jy0205/Pyramid-Flow "GitHub - jy0205/Pyramid-Flow: [ICLR 2025] Pyramidal Flow Matching for Efficient Video Generative Modeling"))
- But the authors state large VRAM needs for the 768p version (around **40GB** ). ([Hugging Face](https://huggingface.co/rain1011/pyramid-flow-sd3/discussions/5 "rain1011/pyramid-flow-sd3 · Hardware requirements"))
- They do provide CPU offloading modes to run under **\<12GB** or even **\<8GB** , but it will be much slower. ([GitHub](https://github.com/jy0205/Pyramid-Flow "GitHub - jy0205/Pyramid-Flow: [ICLR 2025] Pyramidal Flow Matching for Efficient Video Generative Modeling"))
So, for “8–10 seconds at 720p/1080p-quality” on a normal desktop GPU, **CogVideoX1.5-5B-I2V + upscaling** is currently the cleanest OSS answer. ([Hugging Face](https://huggingface.co/zai-org/CogVideoX1.5-5B-I2V "zai-org/CogVideoX1.5-5B-I2V · Hugging Face"))
* * *
### 2) 8–10 seconds at 720p/1080p on 12GB or 16GB VRAM: what OSS model?
**Best fit:** **CogVideoX1.5-5B-I2V**
- Designed for **5 or 10 seconds**. ([Hugging Face](https://huggingface.co/zai-org/CogVideoX1.5-5B-I2V "zai-org/CogVideoX1.5-5B-I2V · Hugging Face"))
- **Single GPU BF16 minimum ~9GB** with optimizations. That places it squarely in **12GB and 16GB** territory. ([Hugging Face](https://huggingface.co/zai-org/CogVideoX1.5-5B-I2V "zai-org/CogVideoX1.5-5B-I2V · Hugging Face"))
- If you are tight on VRAM, use the memory-saving options the model card calls out (sequential CPU offload, VAE slicing, VAE tiling) and consider INT8 quantization. Expect slower speed if you lean hard on offload or INT8. ([Hugging Face](https://huggingface.co/zai-org/CogVideoX1.5-5B-I2V "zai-org/CogVideoX1.5-5B-I2V · Hugging Face"))
**Also plausible (but more “workflow-dependent”): LTX-Video (2B / distilled / FP8)**
- LTX-Video publishes multiple lighter variants (2B, distilled, FP8) and also points to quantized and caching acceleration projects (example: TeaCache, 8-bit model integrations) which can reduce memory or speed up inference. ([GitHub](https://github.com/Lightricks/LTX-Video "GitHub - Lightricks/LTX-Video: Official repository for LTX-Video"))
- For 12–16GB, you typically use the smaller or quantized variants and rely on its upscalers for “1080p-looking” output. ([Hugging Face](https://huggingface.co/Lightricks/LTX-Video "Lightricks/LTX-Video · Hugging Face"))
**Not a good fit for 12–16GB if you want native 10s at 768p:** Pyramid Flow 768p (unless you accept heavy offload and slow runs). ([Hugging Face](https://huggingface.co/rain1011/pyramid-flow-sd3/discussions/5 "rain1011/pyramid-flow-sd3 · Hardware requirements"))
* * *
### 3) “How many seconds of video can a model produce?”
There is no single number. It depends on:
- the model’s **trained context** (how many frames it was built to handle),
- the **FPS** it outputs at,
- and the **pipeline limits** (what the implementation supports without falling apart).
Concrete examples from OSS model docs:
- **CogVideoX-5B** : **6 seconds** , **8 FPS** , **720×480**. ([Hugging Face](https://huggingface.co/zai-org/CogVideoX-5b "zai-org/CogVideoX-5b"))
- **CogVideoX1.5-5B-I2V** : **5 or 10 seconds** , **16 FPS** , up to **1360×768**. ([Hugging Face](https://huggingface.co/zai-org/CogVideoX1.5-5B-I2V "zai-org/CogVideoX1.5-5B-I2V · Hugging Face"))
- **Pyramid Flow (768p checkpoint)**: up to **10 seconds** at **24 FPS** and **768p**. ([GitHub](https://github.com/jy0205/Pyramid-Flow "GitHub - jy0205/Pyramid-Flow: [ICLR 2025] Pyramidal Flow Matching for Efficient Video Generative Modeling"))
- **LTX-Video** : the project announces support for **long shot generation up to 60 seconds** (model/pipeline dependent). ([GitHub](https://github.com/Lightricks/LTX-Video "GitHub - Lightricks/LTX-Video: Official repository for LTX-Video"))
Important practical point: even if a repo claims “supports longer,” **quality and consistency often degrade** as you push duration. The standard “pro” approach is still: **generate shorter chunks, then extend or stitch**.
* * *
### Two quick “gotchas” people hit
**Multi-GPU is not the same as “one big VRAM pool.”**
- Example: CogVideoX1.5’s model card lists multi-GPU inference memory as ~ **24GB per GPU** (diffusers). That means 4×8GB does not magically become “one 32GB card” for that model. ([Hugging Face](https://huggingface.co/zai-org/CogVideoX1.5-5B-I2V "zai-org/CogVideoX1.5-5B-I2V · Hugging Face"))
**1080p usually means upscaling in OSS today.**
- “Native 1080p, 10 seconds, one shot” is still mostly a closed-model feature. In OSS, you typically generate at 768p-class then upscale.
* * *
### Links worth using
- CogVideoX1.5-5B-I2V (model card, VRAM, 10s support): [https://huggingface.co/zai-org/CogVideoX1.5-5B-I2V](https://huggingface.co/zai-org/CogVideoX1.5-5B-I2V) ([Hugging Face](https://huggingface.co/zai-org/CogVideoX1.5-5B-I2V "zai-org/CogVideoX1.5-5B-I2V · Hugging Face"))
- Pyramid Flow (10s @ 768p, offloading and multi-GPU notes): [https://github.com/jy0205/Pyramid-Flow](https://github.com/jy0205/Pyramid-Flow) ([GitHub](https://github.com/jy0205/Pyramid-Flow "GitHub - jy0205/Pyramid-Flow: [ICLR 2025] Pyramidal Flow Matching for Efficient Video Generative Modeling"))
- Pyramid Flow VRAM discussion (26GB 384p, ~40GB 768p): [https://huggingface.co/rain1011/pyramid-flow-sd3/discussions/5](https://huggingface.co/rain1011/pyramid-flow-sd3/discussions/5) ([Hugging Face](https://huggingface.co/rain1011/pyramid-flow-sd3/discussions/5 "rain1011/pyramid-flow-sd3 · Hardware requirements"))
- LTX-Video repo (long shot up to 60s, upscalers, acceleration ideas): [https://github.com/Lightricks/LTX-Video](https://github.com/Lightricks/LTX-Video) ([GitHub](https://github.com/Lightricks/LTX-Video "GitHub - Lightricks/LTX-Video: Official repository for LTX-Video"))
* * *
**Summary**
- **12–16GB VRAM + 8–10 seconds:** pick **CogVideoX1.5-5B-I2V** , then upscale to 1080p if needed. ([Hugging Face](https://huggingface.co/zai-org/CogVideoX1.5-5B-I2V "zai-org/CogVideoX1.5-5B-I2V · Hugging Face"))
- **“True” 1080p in OSS:** usually means **generate lower-res then upscale** , not native 1920×1080. ([GitHub](https://github.com/Lightricks/LTX-Video "GitHub - Lightricks/LTX-Video: Official repository for LTX-Video"))
- **Max seconds is model-specific:** examples range from **6s** (CogVideoX-5B) to **10s** (CogVideoX1.5, Pyramid Flow) and even longer in some pipelines (LTX-Video long shot). ([Hugging Face](https://huggingface.co/zai-org/CogVideoX-5b "zai-org/CogVideoX-5b"))