The Machine That Makes Its Own Films: NVFP4 on the DGX Spark

NVFP4 support for the Spark’s GPU finally matured this spring. I spent an afternoon rebuilding my image and video pipeline around it on a GIGABYTE AI TOP ATOM, and measured the results.

Yesterday I put all of it on one machine: a @GIGABYTEUSA AI TOP ATOM, Gigabyte’s build of the @NVIDIAAI DGX Spark. GB10, 128 GB unified memory.

Three image models

The image side of the stack settled into three models, each with a distinct job. All of them run through ComfyUI, and the boot log confirms the hardware path: Native ops: … nvfp4.

FLUX.2-dev NVFP4 (an official @bfl_ai checkpoint) handles the demanding work. It is a 32-billion-parameter model that would occupy 64 GB in BF16; quantized, it stages in 21.7 GB and renders a 1024² image in 22.8 seconds with the Turbo LoRA at 8 steps.

Qwen-Image-2512 Lightning (@Alibaba_Qwen , with the lightx2v 4-step distillation) is the strongest text renderer I have used locally. I asked it for an art-deco travel poster with a title line and a tagline, and both lines came out correctly on the first attempt. It generates at a native 1328² in 11.1 seconds.

Z-Image-Turbo NVFP4 (@Ali_TongyiLab ) is the fast one: 5.7 seconds per 1024² image. That is quick enough to explore seeds and prompt variations without breaking concentration, which changes how the tool feels in practice.

Video, with audio in the same pass

LTX-2.3 22B NVFP4 is an official @Lightricks / @LTX_studio checkpoint, and it is the most interesting model on the box. It generates video and synchronized audio together in a single diffusion pass, so a clip arrives with its own fire crackle, rain, or room tone already in place.

On the Spark, four seconds of 768×512 at 24fps takes 27 seconds once the model is warm. The 22B transformer stages in 16.7 GB. At 1152×768 each clip takes about 73 seconds, which puts an eight-shot, 29-second short film at roughly ten minutes of GPU time.

I can vouch for that estimate because the machine made two short films yesterday. Seed stills from FLUX.2 and Qwen, motion and sound from LTX, editing with ffmpeg, all on the same box. One of them opens this article.

This stack is 4-bit throughout, including the text encoders: @MistralAI Mistral-3-Small for FLUX.2, @GoogleDeepMind’s Gemma-3-12B for LTX, and Qwen3-4B for Z-Image, all in FP4-mixed form, all dispatching to the tensor-core FP4 path through CUDA 13 CUTLASS.

The practical result: the same machine also serves Qwen3.6-27B-NVFP4 as an OpenAI-compatible endpoint under vLLM, and the smaller image models can generate while it serves. Yesterday a Z-Image render finished in 12 seconds while the 27B model held 68 GB and kept answering requests. For the larger models, a small @tailscale-bound web console starts and stops the stacks so whichever one needs the memory can have it.

Three pieces of software used:

• comfy-kitchen, ComfyUI’s kernel layer, which provides the native NVFP4 ops on aarch64;

• comfy-aimdo, whose DynamicVRAM stages weights on demand rather than pinning them;

• and three launcher flags that matter on this hardware: skip –gpu-only, disable pinned memory, and turn off the @PyTorch caching allocator.

Tests:

All measured on this machine, July 6, 2026. Warm means the model was already resident; cold includes the first-time weight staging.

• FLUX.2-dev NVFP4 (32B), 1024², 8 steps: 22.8s warm, 50.8s cold

• Qwen-Image-2512 Lightning (20B), 1328², 4 steps: 11.1s warm, 20.9s cold

• Z-Image-Turbo NVFP4 (6B), 1024², 8 steps: 5.7s warm, 8.0s cold

• LTX-2.3 NVFP4 (22B), 4s of video with audio: 27.1s warm, 49.9s cold

A 32B image model, a 22B audio-video model, and a 27B language model, all quantized to four bits, all running well on one small desktop machine. A full reproduction guide with every download and launch command is in the companion post.

P.S. @nvidia @GIGABYTEUSA: if either of you has a spare ATOM, this one spends its days making short films and its nights serving a 27B model, and I have a long list of things a pair could do over ConnectX-7. Just saying.