Running MiniMax H3 on an 8GB GPU (All Measured Values)

Up until last time, I wrote about running MiniMax H3 on rented GPUs (RunPod's 4090 and RTX PRO 6000). This time, the question is: "Can it run on my own machine?"

I'll start by explaining why I'm so fixated on this.

Seedance 2.0 and 2.5 are truly excellent models. However, they are difficult to use unless you have a project with a sufficient budget.

You can't just test them out. I worry about the cost for every single clip, so I can't run them until I'm satisfied. You might think, "Then just get an unlimited plan," but unlimited plans are often tied to annual contracts.

I have been burned by those three words, "unlimited," many times. Before I knew it, I had several annual contracts I barely used. At the time I signed up, they were indeed the best tools.

Yes, that's the problem—AI tools evolve too quickly. It's common for a completely different tool to be superior within a few months. I started to feel it was a bad idea to pay for a year in advance when I don't even know what I'll be using a year from now.

I just want to try it out, but I'm forced to make a year-long commitment. That was the dead end.

If I can run it locally, I can escape this entire structure.

What I have on hand is an RTX 3060 Ti with 8GB of VRAM. The H3 model alone is 19.5GB. There's no way it will fit.

The conclusion is, it worked. I managed to get 480p, 15 seconds, with audio. Furthermore, I even got 720p equivalent (0.9MP) to work. The mechanism for connecting clips also worked, and I have confirmed it up to 20 seconds by connecting two 10-second clips.

This was produced using the 8GB card I have on hand. It's 832x480, 10 seconds and 7 cuts from a single still image. I connected the following 10 seconds to make it 20 seconds. (The audio was created separately and added later. I'll explain why later.)

I will leave behind all the traps I fell into and the numbers I measured to get there.

What you will learn in this article

• Configuration to run on 8GB (4 models, 3 startup flags, and patches to apply)

• The fact that system RAM is more effective than VRAM

• Measured values (5s/10s/15s × with/without turbo × time and VRAM by sampler)

• How to pass 15 seconds (Just apply 2 VAE PR files)

• The fact that 720p equivalent works, and the real reason why 1280x720 results in an error

• How to connect continuations (measured up to 20 seconds) and the color shift at that time

• Things that didn't work (EasyCache / SageAttention / 6 audio control methods)

• How to use it alongside borrowed GPUs

⚠️ All numbers are as of August 11, 2026. It has been 8 days since H3 was released, and new things are coming out almost every day (I will touch on this at the end).

Environment

• GPU / RTX 3060 Ti 8GB (Ampere / SM86)

• Driver / 591.86

• System RAM / 64GB

• ComfyUI / 0.31.0 (portable version)

• Python / 3.13.14

• PyTorch / 2.13.0+cu130

• comfy-kitchen / 0.2.28

• triton-windows / 3.7.1.post27

I am already using the ComfyUI Desktop version for image generation and have 30 custom nodes installed. Without touching any of that, I deployed a new portable version on a different drive. I am sharing only the model folder via extra_model_paths.yaml.

🔴 What matters more than VRAM is system RAM

When I heard it "runs on 8GB," this is the first thing I suspected.

There is no way a 19.5GB model fits on an 8GB card. It runs because it doesn't fit. ComfyUI swaps only the necessary parts in and out of VRAM, and the rest is kept in system RAM.

In other words, the actual constraint is system RAM, not VRAM. I have 64GB installed.

And the launch flag --disable-pinned-memory is what makes this work. By default, ComfyUI pins (locks) most of the system RAM. Since the OS cannot move pinned areas, it reduces the room for swapping and causes issues. I am using this flag to stop that.

I have seen reports that it runs on 32GB, but it seems to hit a wall with either resolution or duration. If you have an 8GB card, I think you should check your RAM before your VRAM.

Trap #1 was already avoided from the start

The thing I was most wary of beforehand was that "with cu128, the comfy-kitchen optimization kernels are completely disabled." This is what appeared in the logs of my existing environment.

Found comfy_kitchen backend cuda: {'available': True, 'disabled': True, ...}

disabled: True means the optimization is not in effect.

However, the portable version 0.31.0 came with torch 2.13.0+cu130 from the start. When launched, all three become disabled: False.

Found triton 3.7.1. Enabling comfy-kitchen triton backend.
  eager  : disabled: False
  triton : disabled: False
  cuda   : disabled: False

The task of replacing torch was unnecessary. The most daunting step disappeared.

nvfp4 runs on Ampere

I am using the nvfp4 quantized version (14.61GB) for the text encoder. I was worried because there was talk that "nvfp4 has only been verified on Ada generation and later," but in the launch log, the cuda backend capabilities showed

dequantize_nvfp4, scaled_mm_nvfp4, quantize_nvfp4

listed, and generation actually worked. It runs without issues on Ampere (RTX 30 series).

Model configuration (actual size 39.55GB)

• Main body / File minimax_h3_fl2va_pruned_int8_convrot / Size 19.53 GB

• Text Encoder / File qwen3vl_32b_minimax_h3_nvfp4_awq / Size 14.61 GB

• Video VAE / File minimax_h3_video_vae_fp16 / Size 4.85 GB

• Audio VAE / File minimax_h3_audio_vae_fp32 / Size 0.56 GB

The download for all 4 files took 7.3 minutes (approx. 95MB/s).

Startup flags

--enable-triton-backend --disable-pinned-memory --preview-method none --port 8188

• --enable-triton-backend … Disabled by default. Triton won't be used unless enabled.

• --disable-pinned-memory … ComfyUI pins most of the system RAM by default.

• --preview-method none … Previews during generation consume VRAM. Disable on 8GB.

🔴 How I got 15 seconds working on 8GB

This is the biggest takeaway this time.

The first wall I hit

VRAM runs out when extending the duration. Here are the actual measurements.

• 124 / Duration 5.17s / VRAM 6,304 MiB

• 243 / Duration 10.12s / VRAM 7,286 MiB (906 remaining out of 8,192 limit)

It is calculated that VRAM usage increases by about 1.0GB for every 119 frames. At 15 seconds (362 frames), it would reach about 8.3GB and exceed the limit, which was my assessment at the time.

And this is how I explained it:

This was wrong.

The cause was VAE decoding

On August 9, 2026, PR #15446 was merged into ComfyUI. It was by Kijai, and the description says the following.

It means that the VAE decoding has been changed to streaming 17 frames at a time.

I applied it and measured it again.

Since ComfyUI 0.31.0 is a git checkout, you can apply only these two files.

cd <ComfyUIのディレクトリ>
git branch backup-v0.31.0
curl -sL https://github.com/Comfy-Org/ComfyUI/commit/2a68ce33b4c9ea6ee4283e618a74560cefb32694.patch -o p.patch
git apply --check p.patch && git apply p.patch

The changes are only to comfy/ldm/minimax/vae.py (+59/-45) and comfy/sd.py (+9/-0). Since it should be included from 0.32.0 onwards, it will be unnecessary at that time.

Here are the results.

• 124 / Duration 5.17 seconds / VRAM 6,304 MiB

• 243 / Duration 10.12 seconds / VRAM 7,286 MiB / Increase +982 (before patch)

• 362 / Duration 15.08 seconds / VRAM 7,677 MiB / Increase +391 (after patch)

The rate of increase has become 1/2.5. It finished with 515 MiB remaining against an 8,192 MiB limit.

15 seconds on 8GB. With audio.

⚠️ However, the time increases. From 243 to 362 frames, it went from 605.7 seconds → 2113.2 seconds (3.5x). Although the frame count is 1.49x, the time is 3.5x. Since the computational complexity of Attention scales with the square of the number of tokens, it becomes rapidly more expensive as you increase the duration.

Measured values

Everything is 832×480 (0.40MP) · 24fps · with audio · i2v · same input image, same prompt, same seed.Measured by running each one individually (running multiple in parallel mixes in wait times, making it meaningless).

Comparison at 10 seconds (243 frames)

• turbo (lightx2v) / steps 8 / sampler er_sde / time 605.7 seconds (10 minutes 06 seconds)

• turbo (Tutu) / steps 8 / sampler euler / time 725.8 seconds (12 minutes 06 seconds)

• raw / steps 20 / sampler res_multistep / time 1491.8 seconds (24 minutes 52 seconds)

• raw / steps 25 / sampler res_multistep / time 1677.0 seconds (27 minutes 57 seconds)

• turbo (lightx2v) · 15 seconds / steps 8 / sampler er_sde / time 2113.2 seconds (35 minutes 14 seconds)

Measured turbo 8 steps twice, resulting in 605.7 seconds and 610.7 seconds. The variance was 0.8%.

Comparison at 5 seconds (124 frames)

• raw / steps 25 / cold 625.8 seconds / warm 595.7 seconds

• turbo (lightx2v) / steps 6 / cold 310.5 seconds / warm 185.5 seconds

📌 Increasing the number of steps does not increase the time much

Going from 20 steps to 25 steps, despite the step count being 1.25x, the time was 1.12x.

I think it's because the fixed cost of loading and unloading the model with 8GB is high. In other words, if you're running it natively, the loss is small even if you increase it from 20 to 25.

Just by changing the sampler, the expression of movement changed.

This was completely unexpected.

I was comparing the turbo version and the native version and got the result that "the turbo version has better movement expression", but when I looked closely, I realized I had also changed the sampler at the same time.

素の版    sampler = res_multistep
turbo版   sampler = er_sde        ← ここも違う

It wasn't just the difference in step count and LoRA. So, I tried running it with the native 20 steps, but changing only the sampler to er_sde.

• res_multistep + simple / Time 1491.8 seconds / Movement expression: Baseline

• er_sde + simple / Time 1451.8 seconds / Movement expression: ✅ Improved

The time is almost the same (2.7% difference). The cost of changing the sampler is zero.

This is a guess, but er_sde is a stochastic sampler that injects noise at each step. res_multistep is nearly deterministic, so as steps accumulate, it may converge to the average of the prediction, making the movement flat. I haven't verified this.

I have now set the default to er_sde. Both when running natively and when using turbo.

Turbo LoRA "always cuts something"

I tested three independent systems of turbo LoRA for acceleration. I am comparing them with the same image, same prompt, and same seed.

• QrusherZA (Previous test / Verified on RTX 4090) / Lines/Image quality: 🔴 Rough

• lightx2v (Kijai conversion) / Lines/Image quality: Depends on the subject (described later) / Movement: 🔴 awkward (walking scene)

• Tutu AudioVideo 20→8 / Lines and Image Quality 🔴 Degraded

The third Tutu is a LoRA that explicitly states it will preserve H3's native stereo audio, dialogue, and synchronized sound effects. The image quality clearly dropped.

Note that I did not evaluate the audio this time. The prompt used for comparison only contained sound effects with no background music, so there was too little sound to serve as material for comparison. I will measure this again separately.

It is easy to overlook that "movement" in particular is stripped away

In the previous verification, I only looked at lines and sound. This time, I noticed that the footwork in scenes where characters walk becomes clearly awkward.

Step distillation strips away not only lines and sound but also the smoothness of movement. I have seen reports saying it is "not much different from 20 steps," but it is possible the subject matter had little movement. It is probably best to avoid it for shots where characters are walking or running.

🔴 However, depending on the subject, turbo was better

After writing all that, I am going to flip the script.

Two girls standing under a starry sky—when I lined up the four versions (Raw 20 / Raw 25 / turbo(lightx2v) / turbo(Tutu)) under the same conditions for this different image, the two turbo versions were judged to have better video quality. (There was almost no difference between Raw 20 and Raw 25.)

Why? Step distillation reduces gradation and makes outlines harder. Whether that trade-off becomes a detriment depends on the subject matter.

• Girl walking on water / Style: Water caustics, light diffusion, walking / turbo evaluation: 🔴 Lines are rough, walking is awkward

• Two people under a starry sky / Style: Black + glowing white + stars. Flat and high contrast / turbo evaluation: ✅ Better than raw

What looked like "roughness" in the water surface image becomes "definition" in a flat, cel-shaded image. And since raw 25 steps creates fine gradations, it might be adding unnecessary texture to flat images.

"More steps is not always better."

⚠️ This is still a hypothesis, as I only tested it once per subject. I need to verify if the same trend appears with other flat images.

The measurement for SageAttention failed.

When I installed SageAttention 2.2.0 and measured it, the warm-up took 766.4 seconds. This is 28.7% slower than the 595.7 seconds taken natively.

However, this comparison cannot be trusted.

This is because at the same time I installed SageAttention, I also swapped the prompt from a short one (1 cut) to a long one (3 cuts). Since two variables were changed, I cannot isolate the cause of the slowdown.

Long prompts increase the load on the text encoder (14.6GB, which doesn't fit on 8GB and is offloaded), and they also affect the 25 steps × 124 frames of cross-attention. Both are possibilities.

I will not use these figures until I re-measure under consistent conditions.

For the same reason, I discarded all figures obtained while running multiple generations in parallel (such as 1733.8 seconds).This is because the ComfyUI queue was mixed in, so it does not represent the generation time itself.

📌 Afterward, I found a more fundamental cause.SageAttention wasn't actually running in the first place. I will write about the details in the section below, "The Real Reason SageAttention Could Not Be Measured."

Comparison with other environments

RTX 3060 12GB (Measured by @TlanoAI)

• Resolution / 3060 12GB 640×640 = 0.41MP / 3060 Ti 8GB (this time) 832×480 = 0.40MP

• Steps / 3060 12GB 25 / 3060 Ti 8GB (this time) 25

• SageAttention / 3060 12GB Yes / 3060 Ti 8GB (this time) No

• EasyCache / 3060 12GB Available / 3060 Ti 8GB (This time) None

• Time (Warm) / 3060 12GB 5 min 19 sec / 3060 Ti 8GB (This time) 9 min 56 sec

There is a 1.87x difference, but it is a mistake to interpret this as a difference in VRAM. The other side has two optimizations included, while this one is in its raw state. The conditions are different.

Comparison with rented GPUs

• RunPod RTX 4090 / Resolution 1344×768 / Duration 10 sec / Steps 20 / Time 475.8 sec / Cost approx. 8 yen

• RunPod RTX PRO 6000 / Resolution 1344×768 / Duration 10 sec / Steps 20 / Time 256.2 sec / Cost approx. 25 yen

• My 3060 Ti / Resolution 832×480 / Duration 10 sec / Steps 20 / Time 1491.8 sec / Cost Electricity only

Since the resolutions are different, these numbers cannot be compared directly. The rented side is 1.03MP, while mine is 0.40MP. There is a 2.6x difference in pixel count.

A clear division of labor has emerged

After running it for a day, I settled on this division of tasks.

ローカル（無料・480p）  →  構成を決める
                            カット割り・演出・プロンプトを詰める
        ↓
RunPod（8円・1344×768）  →  決まったものを高解像度で本番生成

Refining prompts requires the most iterations. Being able to do that for free is a big deal. By using turbo, you can get a 10-second result in 10 minutes, so you can try dozens of them in a day.

Only rent when you need high image quality. This way, the time spent on rented GPUs is kept to a minimum.

Bonus: You can also generate images in the same environment

I also added Krea 2 (Krea.ai's 12B open-weight image model) to the same ComfyUI.

• Main Model / krea2_turbo_nvfp4 7.15 GB

• Text Encoder / qwen3vl_4b_fp8_scaled 4.88 GB

• VAE / Same as Qwen Image (can be reused)

• Generation Time / 36 seconds for 1024×1024 (with model loaded)

8 steps, cfg 1 works. The license is proprietary, but it is commercially available if annual revenue is under $1 million, you own the rights to the generated output, and credit is not required if you are only outputting images.

The video H3 and image Krea 2 models are coexisting on the same 8GB card.

What follows are things I learned after writing the article.

The following was measured after finishing the content above.Several items I had written as "not yet understood" have now been filled in.

You can extend the duration while staying within 8GB by connecting sequences.

Up to this point, I have written under the assumption that "15 seconds per clip is the limit," but that limit has been removed.I actually connected up to 20 seconds. Anything beyond that is just a matter of time, so I will describe it later.

ComfyUI-MiniMaxH3-Contex-Loop is the custom node I installed. It works by passing the last 22 frames of the previous clip as context to the next generation. Instead of passing it as a reference image, it fixes the frames in latent space before drawing the continuation, which reduces misalignment at the joints.

I actually measured it.

• Configuration / Ref2VA w4a8 (10.96GB) / 832×480 / 243 frames / 22 frames of context

• turbo / lightx2v 8 steps, er_sde

• Peak VRAM / 7,392 MiB / 8,192

• Time / 781.0 seconds (13 minutes 01 seconds)

The VRAM usage was lower than the 7,677 MiB used for a single 15-second clip.

Since 10 seconds takes 13 minutes, it would take about 78 minutes for 6 clips to make 1 minute. This is a calculation; I haven't actually made a 1-minute clip yet. ⚠️ This is just a calculation; I haven't created a 1-minute clip yet. I have only confirmed by connecting up to 20 seconds. However, it is within reach if you spend the time. It's the kind of scale where you can run it overnight and have it finished by morning.

The 20-second clip I posted at the top of this article is exactly that. It connects the first 10 seconds and the last 10 seconds, and there is a join at the 10.1-second mark.

I can't say the join is completely invisible.

When I first lined up the still images, I was impressed that both the character's position and the background matched. However, when you play it, the image jumps slightly at the join.

I measured the translation amount that best overlaps the two images using phase correlation.

• Continuation of just walking / Vertical shift -12 px / Horizontal shift 0 px

• Continuation including a turn / Vertical shift +7 px / Horizontal shift 0 px

12px relative to a height of 480px is 2.5%. The horizontal shift is 0, and only the vertical is moving. The camera height or angle of view has changed slightly, making the character appear to shift up and down.

I didn't notice this when comparing still images. You can't tell unless you play the video to check.

Connect without audio

When connecting, export with -an to drop the audio. It is standard to add background music yourself later, so there is no need to worry about it here.

If you need dialogue or singing, ref_audios allows you to provide an audio file for each clip. Since it is generated to match the provided audio, the audio you prepare yourself becomes the standard. Those making music videos with lyrics were splitting the song's mp3 into 15-second segments and providing them. (⚠️ Lip-sync accuracy has not been verified.)

There are 2 things that cannot be fixed even by connecting them

① It gets slightly darker every time you connect them.

When I measured the average RGB of the boundary, this is what I found.

• Night waterfront (dark image) / Difference at boundary (R / G / B) -8.3 / -11.0 / -9.1

• Midday seaside (bright image) / Difference at boundary (R / G / B) -13.7 / -12.6 / -10.7

• Midday seaside (with audio context) / Difference at boundary (R / G / B) -16.1 / -12.3 / -9.1

Across three clips with different brightness and subjects, they all darkened in the same way.It seems to be a property of this connection method itself, not the nature of the source material. Passing audio context doesn't fix it (that's a separate issue).

You won't notice it with one clip, but it should accumulate the more you connect. If you connect six clips to make a minute-long video, the end might be visibly darker. If you're doing long-form content, you'll need to monitor it or have a process to restore brightness each time you connect.

② Angles not present in the final frame will not connect properly.

I ran into this too. The first clip ends with a shot of someone "walking away from behind." When I wrote the continuation where they "turn around to look at me," the face became someone else the moment they turned around.

Thinking about it, it's obvious; all 22 frames I provided were from behind. The model has never seen her face. So, I'll remake it.

So, I ref_images provided one reference image of the character and re-rendered it. I used the original image used for the input (the one showing her profile).

This worked. The braid at her temple returned, and her facial features became closer to the original image. It is clearly different from the version without a reference.

⚠️ However, there is a side effect. Small items (a drink) that were in the reference image came back too. Even though it's a scene after she walked away, she's holding it again. Even if you intend to pass only the "face" as a reference image, everything in the image has an effect.

If you want to do it properly, preparing a character sheet with front, 3/4, side, and back views in the same pose and lighting is the way to go. Since there are no extra items, only the intended parts will be affected.

In any case, you can connect "continuations of movement," but "angles never seen before" require a reference. This is something you need to keep in mind.

In summary

You can make a 1-minute video locally. However, there are three conditions.

1. Connect without audio (Add BGM later. If you need dialogue, provide an audio file.)

2. If a person appears, provide a reference image as well (be careful, as small objects may be carried over)

3. It gets darker the more you connect, so monitor the colors

4. There is a vertical jump of around 10px at the connection point. You can hide it by placing the connection where the cut breaks

As for the audio, I gave up

H3 generates video and audio simultaneously. The sound of waves or the sound of drinking through a straw plays at the right timing for the image. That part is genuinely good.

The problem was that unrequested BGM would be added automatically. Sometimes it was piano, other times it sounded like a xylophone.

Prompting methods (negative forms, affirmative forms, deleting all music-related terms), ducking in post-processing, replacing with synthesized audio, source separation—I tried 6 ways, and they all failed.

📌 Methods that worked to remove it in Seedance 2.5 did not work in H3. When I tested it in Seedance the other day, music was still added even when I wrote "no BGM", so I prohibited the "content of the music" such as melody / harmony / chords, and it disappeared. Even if you apply the same logic to H3, the BGM does not stop. I think it means that how prompts work differs for each model.

The conclusion is to "delete the audio track entirely when exporting and create the audio separately."

ffmpeg -i in.mp4 -c:v copy -an out.mp4

Since it is normal to add BGM yourself later, this is not a problem in practice. If you need dialogue or singing, you can provide audio files for each clip.

⚠️ There is one untested method remaining. If you provide audio as a reference during generation, the model has no room to create music. I haven't tried that yet.

The real reason I couldn't measure SageAttention

I wrote earlier that "measurement failed," but it wasn't running in the first place.

When I install KJNodes and enable SageAttention, it crashes during generation like this.

tcc.exe ... cuda_utils.c ... returned non-zero exit status 1

triton is trying to compile a small C code at runtime and failing. When I looked inside, the reason was simple.

• sageattention 2.2.0 / Status ✅ Installed

• triton-windows 3.7.1 / Status ✅ Installed

• python_embeded/Include (Python.h, etc.) / Status ❌ Empty

• python_embeded/libs/python313.lib / Status ❌ Folder is missing

The embedded Python in the portable version of ComfyUI does not include the headers and libraries for C compilation.To fix this, you need to take Include and libs from CPython 3.13 and place them there.

If you are using the portable version on Windows and SageAttention is not working, try checking this.

Furthermore, there is a report from another user's measurements (RTX 3070 Ti 8GB, ref2va, 0.6MP, 20 steps) of Original 45m 13s → SageAttention + memory efficiency patch 29m 57s (-34%). It's a significant improvement if it works, so I'll try it eventually.

I tried another turbo LoRA.

joyfox/MiniMax-H3-Turbo was released as a 4-step turbo LoRA, so I compared it using the same image and seed.

• Time / lightx2v 8 steps 730.9s / joyfox 4 steps 460.8s (-37%)

• Prompt adherence / lightx2v 8 steps: Lanterns appeared in the cut of "only water surface reflections" that I specified / joyfox 4 steps Followed instructions

• Details / lightx2v 8 steps: Paper fibers and creases are visible / joyfox 4 steps Became a uniform gradient

• Audio / lightx2v 8 steps: BGM is included / joyfox 4 steps Became broadband noise

It was a takeaway that the audio broke in a different way. While structured audio is produced at 8 steps, the structure of the audio itself collapses at 4 steps.Audio requires more steps is what I think this means.

This LoRA has training metadata embedded, and it stated audio_loss_weight: 0.25. The claim that audio is also included in the distillation target seems to be true, but 4 steps were still not enough.

720p wasn't "too heavy to pass," but was rejected due to its dimensions.

I hadn't tested whether "1280x720 would pass" until the end, so I tried it.

The result was an error. However, it was not an OOM error.

shape '[1, 24, 1, 1, 22, 2, 40, 2]' is invalid for input of size 86400
RuntimeError

You can see it by following the numbers. 1280÷16=80, 720÷16=45. The 22 and 40 in the error message become 44 and 80 when doubled. While a width of 80 is divisible, a height of 45 is an odd number, so it is truncated to 22, causing a mismatch.

In other words, it only accepts resolutions that are multiples of 32.

• 832x480 (used regularly in this article) / divided by 32 is 26 x 15 / ✅

• 1344x768 (production run on a borrowed GPU) / divided by 32 is 42 x 24 / ✅

• 1280x720 / divided by 32 is 40 x 22.5 / ❌

I hadn't noticed this because all the resolutions I've used so far happened to be multiples of 32. It's a waste to give up by mistakenly assuming "an error occurred at 720p, so it must be a VRAM shortage."

1280x704 worked.

When I corrected it to a multiple of 32 (32x22) and ran it again, it worked.

• Resolution / 1280x704 (0.90MP)

• Duration / 5 seconds (124 frames) / turbo 8 steps

• Peak VRAM / 7,655 MiB / 8,192 (537 MiB remaining)

• Time / 861.0 seconds (14 minutes 21 seconds)

I previously wrote that I expected about 7.7 GB in 5 seconds, and the actual measurement was 7.65 GB. It was almost spot on.

With an 8GB card, you can output up to 0.9 MP, which is equivalent to 720p.That is 2.25 times the pixels of 480p (0.40 MP), and the time is also about 2.3 times longer. It scales linearly.

These were generated with the same prompt and seed, changing only the resolution.On the left (480p), the water droplets melt and lose their outlines, and the ice surface is crushed. On the right (704p), the water droplets stand out individually, and the edges and reflections of the ice remain.

In shots like close-ups of a glass, this difference is clearly conveyed. Conversely, 480p is sufficient for wide shots or just checking movement.

(You can see things with movement in the second post embedded at the top of this article.)

However, since it takes 14 minutes for 5 seconds, it is not suitable for test runs. It seems the best approach is to refine the composition at 480p and only render the final cuts at 704p. This adds one more option for situations where you don't need to rent a machine but still need high image quality.

EasyCache did not have any effect when used in combination with turbo.

I hadn't measured the "shortening rate when adding EasyCache," so I did that.

The conditions were completely identical (832×480 / 243 frames / 8 steps / er_sde / turbo lightx2v), with only the presence or absence of EasyCache as the variable.

• Without EasyCache / Time 740.8 seconds

• With EasyCache / Time 735.9 seconds

The difference is -0.7%. It's within the margin of error.

I also compared the images by lining up frames from the same time, but I couldn't tell them apart. The result is that there is neither gain nor loss.

The reason is likely simple: there are only 8 steps. Since EasyCache is a mechanism that "skips calculations similar to the previous step," there are simply no opportunities to skip anything. I suspect it never once hit the default threshold (reuse_threshold 0.2).

It might be effective when running at 20–25 steps without using turbo. However, since the reason for using turbo in the first place is speed, I doubt there is any point in a configuration that "removes turbo and adds EasyCache."

If you are running with turbo, the conclusion for today is that it makes no difference whether you use EasyCache or not.

The figures in this article are as of August 11, 2026.

The configuration I have written about so far is just the best combination I found today.

It has been only 8 days since H3 was released with open weights (August 3rd). In those 8 days, or rather, just the last 2 days, things like this have emerged.

• Projection nodes that replace the text encoder from 32B to 4B (TE stage: 15.7GB → 4.5GB)

• GGUF quantized version of the main model (19.5GB → 11.6GB)

• Nodes that pass the previous clip as context to connect them (used in the addendum of this article)

• Two types of turbo LoRAs (one explicitly states that audio was also included in the distillation target)

• TTS workflow that runs video at 32x32 and extracts only the audio

• Extensions specialized for audio processing (e.g., 4 steps for video / multi-steps for audio)

• PR to include int8 attention in the main ComfyUI (speeds things up on 20-series and 30-series cards)

• PR to train LoRA on still image datasets

The number is increasing by several every day. The configuration I thought was "the best" yesterday is already outdated today. In fact, I have rewritten this article four times between writing it and publishing it.

Therefore, please read the combinations written here not as a fixed answer, but as an observational record of today. I will continue to search for even better combinations myself. I will write about what I find.

Things I don't know yet

• The net effect of SageAttention (measuring after adding headers to the embedded Python)

• What happens if I pass audio as a reference (the final resort for the BGM issue)

• From which clip does the color shift become visible when connected

Things I plan to write about next

The process of connecting sequences to make a 1-minute video has not been fully written yet. Just from what I learned today, there are these points to consider.

• How to hide visual jumps at the transitions using cuts

• Where to restore the colors that get darker each time you connect them

• How to provide character sheets so they don't turn into a different person when they turn around

• At what stage to add the audio

I plan to summarize these points in a separate article.

*All measurements were conducted on the same machine with the same input image between 2026-08-09 and 10. To ensure cold and warm starts are not mixed, only warm-to-warm comparisons were used. Any figures affected by queueing during parallel execution were discarded.*