FervorCreative AI
Live Latest 28.08.26 · morning 13 tools tracked 8 workflows indexed 25 topics Hot: MLX, Bonsai Image 4B, ACE-Step 1.5

Analysis August 28, 2026 workflow 10 min read

FastMetal-QAD makes five-second video generation practical on a 16GB Mac, and the workflow that works inverts two instincts: take the 5B over the 14B, and treat prompt caching as the main speed lever rather than model size.

FastMetal-QADFastVideoHao AI LabMLXWanvideo-genlocal-creative-aiopen-weightscreative-workflowsapple-silicon

FastMetal-QAD: Local Video Generation on a Mac, and Why the Biggest Model Is the Wrong Pick

Three Apache 2.0 video models that run natively on Apple Silicon, the measured numbers behind them, and a working setup you can have running in an hour.

In Hao AI Lab's own benchmark table, the 14-billion-parameter model in the FastMetal release takes 601 seconds to make a five-second clip at 480p. The 5-billion-parameter model takes 151 seconds and produces 720p.

Read that again, because it inverts the instinct everyone brings to a model family with three sizes. The mid-tier checkpoint runs four times faster, at more than double the pixel count, on less than half the memory. It fits on a 16 GB Mac. The 14B needs 36.

Hao AI Lab at UCSD published all three on August 10, 2026, along with the timing tables that make that comparison possible. The numbers are theirs, measured on an M4 Max with 36 GB, and they are unusually complete. What follows is what those tables actually tell you about how to work with this.

What FastMetal is, mechanically

Three checkpoints tagged text-to-video, all Apache 2.0, all running natively on Metal through a new MLX runtime in the FastVideo framework. Two compressions stack on top of the base Wan models.

The first is distillation. Each checkpoint is a DMD2-trained student that reaches a finished frame in three denoising steps. That is where most of the speed comes from.

The second is the part worth understanding, and it is what the QAD in the name refers to. The models were quantized during distillation rather than after it. Every matrix weight in the denoising transformer uses affine INT8 with a group size of 64, and the student learned to produce good frames while already living at that precision. Norms and modulation tables stay at fp16.

That distinction is usually asserted rather than measured, so here is the measurement. On the 1.3B, where the lab has a paired FP16 control, the quantization-aware checkpoint holds MS-SSIM 0.933 against its own FP16 output on the motion7 prompt set. Post-training quantization of the same model scores 0.907. Both numbers are self-reported, and both come from the same lab, so treat the comparison as internally consistent rather than independently verified. But it is a real, specific claim about why this approach beats a conversion bolted on afterward, and it is the kind of claim most releases do not bother to make at all.

The lab also explains why INT8 and not something smaller. They trained on candidate formats and measured weight reconstruction error. MXFP4 and NVFP4 reconstructed more than an order of magnitude less accurately at comparable memory cost. They built a fused int8 times int8 Metal kernel to quantize activations too, got it correct to within three parts in a million of the reference, and then shipped without it because it did not beat fp16 at the shapes a diffusion transformer actually uses. Publishing the thing that did not work is rare enough to notice.

The numbers that decide your setup

Everything below was measured on an Apple M4 Max with 36 GB of unified memory, using three-step generation with the default decoder. End-to-end time includes prompt encoding, model load, denoising, and export.

Model Output End-to-end Denoise Peak memory Mac tier
1.3B 480x832x81 110.14s 89.77s 3.87 GiB 16 GB+
5B 704x1280x81 151.42s 98.50s 9.34 GiB 16 GB+
14B 480x832x81 601.82s 554.22s 21.68 GiB 36 GB+

The 5B is the release. It generates at 720p, stays under 11 GiB in every mode the lab tested, and costs 41 seconds more than the 1.3B for 2.26 times the pixels.

The 14B is not resolution-limited. The lab lists it as capable of 480p and 720p and simply benchmarked it at 480p, where it takes four times the 5B's wall clock and needs more memory than most Macs have. What it buys is a larger model's judgment about motion and detail. That is a real option for a Mac Studio owner rendering a hero shot overnight. It is not a default.

There is a second thing hiding in that table. Look at the gap between end-to-end and denoise time on the 5B: 151.42 seconds total against 98.50 seconds of actual generation. That 53-second gap is mostly the umT5 text encoder loading and encoding your prompt, which the lab puts at about 47 seconds, with model load and export accounting for the rest. On the 1.3B and 14B the encode step costs about 18 seconds.

The runtime keeps a content-addressed prompt cache, so the second generation on the same prompt skips that step entirely. Which means the single most useful habit with this stack is to stop rewording your prompt between runs. Lock the text, iterate on seeds and modes, and you get 47 seconds back on every generation. Change one word and you pay it again.

Put this into practice

Plan on an hour, most of it downloading. You need an Apple Silicon Mac. The MPS install guide specifies macOS 14 or newer and Python 3.12.4, which is stricter than the "Python 3.11+" the model cards claim, so follow the docs page rather than the cards.

1. Install FastVideo with the MLX extra. The canonical repository is hao-ai-lab/FastVideo. This matters, because the Hugging Face model cards currently tell you to clone github.com/FastVideo/FastVideo.git, which is not the repo the blog post and the docs point at. The docs' primary path is a plain package install, uv pip install "fastvideo[mlx]", but the generation scripts you need live under examples/, so cloning is the practical route:

git clone https://github.com/hao-ai-lab/FastVideo.git
cd FastVideo
uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install -e '.[mlx]'

The project recommends uv over conda. The MPS installation guide at hao-ai-lab.github.io/FastVideo/getting_started/installation/mps/ is the authoritative page for Apple Silicon.

2. Download the 5B. Each checkpoint is self-contained: transformer, text encoder, VAE, tokenizer, scheduler. One download, nothing else to fetch.

hf download FastVideo/FastMetal-5B-QAD --local-dir ./FastMetal-5B-QAD

Budget disk for this. The blog's 4.9 GB figure is the MLX transformer alone; the full repository is about 19.5 GB, because the umT5 text encoder ships as three shards totalling roughly 11 GB and the VAE adds another 2.8. That is the number nobody puts in the announcement, and it is the difference between "self-contained" being a convenience and being a surprise. On an older Hugging Face CLI, use huggingface-cli download with the same arguments.

3. Generate your first clip. The 5B is built on Wan 2.2 and uses its own entry point, because its latent geometry and timestep conditioning differ from the Wan 2.1 checkpoints:

python examples/inference/basic/mlx_wan22_generate.py \
  --mlx-checkpoint ./FastMetal-5B-QAD \
  --text-encoder-root ./FastMetal-5B-QAD \
  --vae-root ./FastMetal-5B-QAD/vae \
  --height 704 --width 1280 --num-frames 81 \
  --prompt "A cinematic portrait with soft neon lighting and smooth camera motion."

The 1.3B and 14B use mlx_wan_prompt_to_video.py instead, with --model-root and --mlx-checkpoint both pointed at the download folder. Mixing up the two entry points is the most likely way to waste your first twenty minutes.

4. Turn on fast mode for exploration. Adding --fast --fast-factor 2 generates every second frame and interpolates the rest with a Metal-native RIFE port. On the 5B that takes the same clip from 151 seconds to 47. Quality drops, and --fast-sharpen restores some of the edge crispness. This is the mode for finding a shot you like.

5. Switch to refine mode for the take you keep. --refine generates at base resolution and then runs a second denoising pass at higher resolution with the same model. No extra weights, no LoRA, no super-resolution download. It costs about 5 to 7 percent more denoising time than baseline and is nearly free in memory, because the two-pass path keeps one resident copy of the transformer rather than two.

The two compose. Fast plus refine on the 5B lands at 51.58 seconds, still a third of baseline, and recovers much of what fast mode gives up. That is the pairing I would build a session around: fast mode to explore, fast plus refine to lock, plain baseline or --decode-backend wan-vae for the final render.

6. If you are on a laptop, you are fine. The lab repeated the 1.3B and 5B runs on a fanless 13-inch MacBook Air with an M5, 24 GB, and a 10-core GPU. Both models run at the same resolutions and modes, output quality is on par at matched settings, and the Air pays roughly 1.3x to 2x the wall clock: 200.1 seconds for a baseline 5B clip, 90.7 seconds in fast mode. The lab says peak memory tracks the desktop within a few hundred MiB, and that holds for baseline and fast mode but not for refine, where their own table shows the 1.3B at 5.14 GiB on the Air against 3.90 GiB on the M4 Max. Leave yourself headroom if you refine on a laptop.

Where it breaks

Apple Silicon and macOS only, macOS 14 or newer, Python 3.12 per the install docs. No Windows, no Intel Macs, no Linux for this path. The rest of FastVideo runs on CUDA; the MLX runtime does not.

The memory tiering is worse than nameplate RAM suggests, and the lab says so directly. Apple counts in decimal, so a 24 GB Mac actually holds 22.35 GiB, and macOS plus your open apps take several GiB of that. The 14B peaks at 21.68 GiB. That is why it is targeted at 36 GB and up despite one of the model cards listing it as "16 GB+", which is a straightforward error in that card's family table. The 5B and 14B cards say "24 GB+/ Ideally 36". The measurement settles it: do not try the 14B on 16 GB.

The documentation carries a second inconsistency. The 1.3B and 14B cards list a trained resolution of 448x832 at 77 frames; the blog benchmarks were run at 480x832 with 81 frames. The 5B card lists 704x1280 at 121 frames while its benchmark row is 81 frames. Neither gap is dangerous, but if your output looks off, check what geometry you actually asked for against what the checkpoint was trained on.

Every clip is about five seconds. Image-to-video is named as future work, not shipped, which sits oddly beside the 5B's base model being a text-and-image-to-video checkpoint. Nothing in the blog or the cards mentions an audio track, and none of the release material shows one; I read that as no audio, but it is my inference rather than a stated limitation. Two of the more interesting modes, spatial fast mode and draft attention, are labeled experimental by the lab, which in practice means they are worth trying and not worth depending on.

And the audience has not arrived. FastVideo itself sits at about 4.1k GitHub stars, which is healthy for an inference framework, but the FastMetal checkpoints show one, two, and three likes respectively, and their Hugging Face download counters read zero. Eighteen days after release, you are an early tester. Expect to find rough edges nobody has reported yet, and expect to file the issue yourself.

What this changes

Mac users have had native paths to diffusion for a while, through PyTorch MPS and ComfyUI's Metal backend, but video specifically has stayed in the territory where the result is a proof rather than an asset. Three minutes for a 720p clip on a laptop is a different category. It is slow enough that you plan a shot and fast enough that you can be wrong about it twice before lunch.

The licensing matters as much as the speed. FastVideo is Apache 2.0, the vendored TAEHV decoder and the RIFE frame interpolation backend are both MIT, and the upstream Wan 2.1 and Wan 2.2 licenses are unmodified Apache 2.0 with nothing extra flowing through. No revenue threshold, no commercial-use gate, no research-only clause. You still have to keep the copyright notices and reproduce any NOTICE file, which Apache 2.0 requires and people forget, but that is a two-line addition to a credits page rather than a legal review. Wan 2.2's card does add an acceptable-use paragraph making you accountable for what you generate, which is worth reading once. Compared to what video model licenses usually look like, this is close to unencumbered, and it is the reason I would reach for this over a hosted model for anything going into paid work.

What I do not know yet is how the three-step ceiling holds up over a longer session. Three steps is a hard architectural choice, not a slider, and every distilled model I have worked with has a characteristic sameness that shows up around the twentieth generation and not before. The published grids all show single clips.

If you run a real sequence through this, twenty or thirty shots meant to cut together, I want to hear whether the motion vocabulary holds or whether everything starts drifting toward the same slow push-in. That is the question the benchmarks cannot answer.

Sources

Medium metadata

  • Title: FastMetal-QAD: Local Video Generation on a Mac, and Why the Biggest Model Is the Wrong Pick
  • Subtitle: Three Apache 2.0 video models that run natively on Apple Silicon, the measured numbers behind them, and a working setup you can have running in an hour.
  • Tags: AI Video Generation, Local AI, Apple Silicon, Machine Learning, Open Source
  • Suggested publication: Tkay Nation's Writes
  • Estimated read time: 8 minutes