Show HN: We compressed a 31B video+audio diffusion model to 14B, 6 steps, INT8 | Hacker News Reader

Show HN: We compressed a 31B video+audio diffusion model to 14B, 6 steps, INT8

github.com

66 pointsjiant13 comments

This is very cool, I wish they would make quality+time comparisons between the various quantisations though

Seconded, I'd like to see a head to head comparison to see how the quant loks vs the original

Yeah this is only meaningful if you can compare quality at least.

Otherwise, it's just like saying: we compressed a JPEG file to 50% of its size using some compression level and we didn't check what it looks like.

Their product page has sample videos: https://www.videorebirth.com/lp/hyperflow-flash

I see references to comfyui in the readme. Is that the easiest way to run it? I've always found it a bit cumbersome to use and wish I had something like a simple CLI tool to use it like llama.cpp. Perhaps that's not possible with a video diffusion model?

They also have references to stable-diffusion.cpp, which is probably the closest analogue to llama.cpp in this space

I use stable diffusion cpp with a LLM driving it using CLI. It’s been the quickest way for me to run new diffusion models and require near zero skills but the results come out great.

care to go more into your loop that you've setup

Not much too it! Use Hermes, *Claw, Claude cowork, etc and go like "setup this model <huggingface link> using stablediffusion cpp on this computer." Then when its done, in the same session "Use this as the main image (or video) generator moving forward" and it'll change the config

ComfyUI has an API. I've directed Hermes to pilot that API by authoring workflow JSON from scratch. I eventually migrated to launching those workflows from Concourse containers to queue a bunch of genops work against my limited hardware.

I've only recently experimented with directly executing GPU workloads on the pipeline workers themselves—this requires mounting models whereas routing through ComfyUI I kept the models on the host.

Torn.

Am curious how this compares perf/quality wise with FastVideo's FastH3 trim/omni which I have been using pretty well with a basic laptop NVidia card (e.g. 5s 480p video w/ audio in 90s).

Hi HN, I’m Jian, one of the engineers on this.

MiniMax-H3 is an open model that generates video and audio together, but its transformer is ~31B parameters and sampling takes a long trajectory, so it’s slow and heavy to run locally. HyperFlow H3 Flash is our compressed version.

What we changed:

Pruning + low-rank factorization: dropped 3 of 50 blocks and factored 102 linear layers, down to 13.7B params. Two-time (t, r) conditioning: each step knows both the current noise level and where it should land, so it samples in 4–8 steps without CFG. W8A8 INT8 with a Hadamard rotation on 180 linear layers.

End-to-end numbers for a 5.2 s clip at 1344×768, 6 steps: 8.7 s on 4× B200, 36 s on 1× H200, 92 s on an RTX 5090, 266 s on an RTX 3090. The Q4_K_M GGUF is 9.1 GB and runs in ComfyUI on 24 GB cards. 16 GB GPUs aren’t measured yet.

To be clear about “real time”: our package does 8.7 s for a 5.2 s clip on 4× B200. Real-time playback speed uses NVIDIA’s SOL-H3 runtime, which supports the model from day 0.

License: code is Apache-2.0 (ComfyUI nodes GPL-3.0). The weights are a derivative of MiniMax-H3 under its Community License, which does not cover the US, EU, UK or South Korea without MiniMax’s authorization. Please check before using.

Demos and an overview: https://www.videorebirth.com/lp/hyperflow-flash

Happy to answer questions about the compression or the numbers.

Do you have a sense of what degrades first in the smaller quants?

Reply on news.ycombinator.com