Kandinsky 6.0 in a pipeline: offload, the untimed default and what to measure

Say your product manager wants "generate a short video with sound" in the app. Kandinsky 6.0, which Kandinsky Lab put on GitHub on 6 October under MIT for both code and weights, is a candidate: text, or text plus an image, in; a 5-second clip with a matching soundtrack out. It comes in two sizes, Lite with 3B parameters and Pro with 29B (parameters are the learned numbers inside a model, a rough measure of its size). The hard parts are scheduling, hardware and one missing measurement.

Every figure here comes from Kandinsky Lab's repos and model cards, gathered in our Kandinsky 6.0 cost-per-clip breakdown. We have not run the model or watched its output, so none of this judges quality.

Treat it as a batch job

Kandinsky Lab's timing table measures the standard models, which clean up random noise into a picture over 50 passes, after a warm-up run, leaving out model loading and file writing:

Five to forty-five minutes per clip is not a synchronous API call. The repo's guide for serving Pro with vLLM-Omni (a server that exposes models over HTTP) already follows the batch pattern: post a video job, receive an ID, poll it, download the result. Copy that shape, plan capacity as clips per hour, and expect less than the table, since the excluded time is never quantified.

More memory, slower clip

The RTX PRO 6000 has 96 GB, sixteen more than the H100, and it needs 561 seconds for the same Pro HD clip.

The download sizes explain it. Pro weighs about 90 GB on disk, roughly 70 GB of it in the component that generates the frames. So every shipped GPU preset offloads: the weights stay in the host's RAM and get copied to the GPU in chunks while a clip is being made. On the H100, A100 and RTX PRO 6000 the presets use module mode, moving one whole component at a time. On the gaming cards they use block mode, keeping two slices of the frame generator on the GPU while the following slice is copied in. --offload none exists as a CLI flag, yet no preset uses it, and the vLLM-Omni guide calls offload "required" on an 80 GB card.

Two effects on the machine you spec: host RAM becomes a requirement, with no published minimum, and the table cannot separate GPU speed from copying cost: every row offloads, no row runs with the model fully on the card, and the H100 alone uses FlashAttention 3 where the others use SageAttention (two libraries for attention, the step where the model relates each part of the clip to the rest). We think the H100 wins on raw chip speed, but nothing in the table measures it. The card pairs that hint the opposite way are covered in the analysis of offload on the H100 and RTX PRO 6000.

Your default model has no timings

The presets, and the public demo on Hugging Face, all load a distilled Pro: a version trained to reach a finished clip in 10 passes rather than 50, at about 81 GB instead of 90. The timing table never covers it. A fifth of the passes tempts you to write in a fivefold speed-up; leave that cell empty until someone measures it.

Profiling ships disabled; a copied preset with one extra block turns it on:

cp kandinsky/configs/devices/rtx-5090.yaml my-5090.yaml
printf 'profile:\n  mode: time_mem_module\n' >> my-5090.yaml
just generate "a cat on a mat" --config my-5090.yaml --warmup --out clip.mp4

With --warmup, the first generation is thrown away and only the second one is timed, roughly how the table was produced. The profile wraps the full pipeline call, so total_time also includes encoding the MP4, joining the audio track to it and the prompt rewrite the Qwen2.5-VL encoder does by default. The table leaves encoding out. Compare the per-component times instead: the DiT (the frame generator), the video VAE and audio VAE (which decode the result into frames and sound) and the vocoder (which turns that into a waveform).

Full HD drops the soundtrack

Generation happens at 864 by 480. A separate super-resolution model upscales to Full HD by redrawing detail one tile at a time. Next to generation it costs little: on an H100 its 2-step version takes 41 seconds for a 2x upscale and 118 seconds for 4x, measured on an input slightly smaller than a base clip. It handles frames only, so your job must reattach the audio from the original generation. No gaming-card timings exist for it.

Checklist before you commit

• Run one prompt set through Lite and Pro and compare. Pro needs 1.4 to 2.8 times the GPU time, and none of the sources we read says what that buys.
• Profile the distilled default on your own GPU, component by component.
• Check the Hugging Face gate on the non-distilled Pro: approval is automatic, its terms visible only after logging in, and we have not read them.

Credit

Kandinsky Lab built the models, the upscaler, the presets and the timing table, with a technical report behind them. They build on Alibaba's Qwen2.5-VL, OpenAI's CLIP, Tencent's HunyuanVideo decoder design, MMAudio, NVIDIA's BigVGAN, the π-Flow distillation method, FlashAttention 3 (Tri Dao and co-authors) and SageAttention (Tsinghua's thu-ml group). Diffusers, ComfyUI, vLLM-Omni, SGLang and FastVideo supported it on release day, and the community account realrebelai published experimental compressed Pro builds for smaller cards. Our part was reading the repos and doing the arithmetic.

Timings on seven GPUs, file sizes, setup and every known limit are in the InferenceKey article on Kandinsky 6.0 video with sound.