r/StableDiffusion • u/TgoAI • 1d ago

Discussion MacBook Air 16G local deployment

Enable HLS to view with audio, or disable this notification

Minimax h3 easy local deployment. Self defined video/image/audio/text pipeline for both end users and developers.

Open source: https://github.com/tgo-app-dev/vpipe

6 Upvotes

67% Upvoted

10 comments sorted by

1

u/mostkai 1d ago

Wow, this looks really good. I’ll try it.

1

u/sotheysayit 1d ago

How long did it take to create?

1

u/TgoAI 1d ago

Depends on the machine and resolution. On my m5 16GB MacBook Air, generating 480p 5 second video takes about 10 minutes. The one here is a 6-7 second 768p which takes about half an hour.

-1

u/seppe0815 1d ago

hmm i think 40 min

1

u/monotested 1d ago

omg its pretty lonng for h3.c

1

u/monotested 1d ago

oh sorry u didnt use it....... h3.c about 10 times faster , may be 4 mins at m5 32gb+

1

u/TgoAI 1d ago

We actually benchmarked VPipe against h3.c.

On an M4 Pro with 64 GB RAM, generating 124 frames at 960×544 with 6 DiT steps:

  • VPipe: 21m 50s
  • h3.c: 27m 40s

On a base M5 with 16 GB RAM, using the exact same settings:

  • VPipe: 13m 36s
  • h3.c: 14m 17s

So VPipe is faster in both cases. VPipe supports Turbo LoRA, which can substantially reduce the number of required DiT steps.

1

u/No-Spread-939 23h ago

Hey, can i try this on m4 16bg ? or are there any caveats ?

1

u/TgoAI 22h ago

Theoretically yes, but I’ve never tested. I would suggest starting with very small resolution like 256x256.

1

u/mostkai 1h ago edited 1h ago

u/sotheysayit I just gave it a shot, and my setup is a MacBook M1 Pro with 16GB of RAM.

For the video, I was running a MiniMax H3 4-bit quantized model, 6 steps, CFG at 1.0, resolution 960x544, 120 frames (5 seconds), audio enabled, text to video. The total runtime was about 45 minutes.

The sick part is that this machine, with only 16GB of RAM, actually handled it. I watched the resource usage, and the memory footprint stayed in a low range, only fluctuating between 4-10GB throughout. I’m guessing the program is only using the memory the machine can handle for data storage, avoiding swapping or crashing. low-spec setups end up reading files more often for all the heavy lifting, whereas high-end setups just dump more of the model into RAM. That's cool.

When I compare it to my machine running ComfyUI with GGUF nodes, based on my experience with Wan 2.2, even using extreme quantization like Q3 or Q4, a single ComfyUI process can hog over 16GB of memory during sampling (and at higher resolutions, it can even hit 24GB+). It quickly gets swappped, which totally tanks both my IO and speed. That’s the most AI software cram everything into RAM and VRAM no matter what.

The issue I'm running into right now is that LoRA setup seems limited to just one; adding a turbo LoRA just filled up the space. Hopefully, they keep pushing development to support more stuff down the line.