Kandinsky 6.0 Pro: 292 s a clip on an H100, 100 clips take 8.1 hours

Kandinsky's published timing is 292 seconds per 5-second Pro HD clip on an H100. That is 8.1 hours for 100 clips, set against hosted per-clip prices on Sume.

5 min readSume
All posts

A batch of 100 five-second clips takes about 8.1 hours on one H100 if every clip costs what Kandinsky's own table shows for Kandinsky 6.0 Pro HD: 292 seconds (100 x 292 = 29,200 s). On an RTX 5090 the Pro SD row reads 754 seconds a clip, which makes 100 clips 75,400 s, or 20.9 hours.

Those figures come from the performance table in the kandinsky-6 repository, read on 2026-10-11. The repository says the times cover working time after warmup and exclude weight loading and encoding, so a cold start adds to them. The page that follows turns that table into plan numbers and sets them beside what a hosted Sume id would charge for the same batch.

The arithmetic for one GPU

Run clips one after another on a single card and the batch time is the clip count times the per-clip time. The table reuses only the two timings the vendor page gave me.

Sequential batch time from Kandinsky's published per-clip timings (read 2026-10-11)
Setup (vendor row)Seconds per 5 s clip100 clips1,000 clips
Pro HD on H10029229,200 s = 8.1 h292,000 s = 81.1 h (3.4 days)
Pro SD on RTX 509075475,400 s = 20.9 h754,000 s = 209.4 h (8.7 days)

What the number leaves out

A timing row is not a throughput plan. The repository documents presets for RTX 4090, RTX 5090, H100, A100 80GB and RTX PRO 6000 cards, with module or block offloading depending on the card, and it states no minimum VRAM. Three costs are still yours to price.

  • Hardware or rental time: the table gives seconds, not dollars, so no per-clip cost can be derived from it.
  • Warmup, weight loading and encoding, which the vendor excludes from the 292 s.
  • The super-resolution step. The base output is 864x480 and a separate plug-in raises it to 1920x1080, so a Full HD clip needs that second model on the same machine or another.

What a hosted batch looks like on Sume

On Sume the unit is a job, and the price is a catalog rate per output second. The rates below come from the catalog code on the main branch, read on 2026-10-11, and they are the billable amounts after Sume's margin. A 5-second clip at the listed rate is the rate times five.

Five-second clips at catalog per-second rates (catalog code, read 2026-10-11)
Sume id and tierRate per secondOne 5 s clip100 clips
gemini-omni-flash-1.1, 360p$0.0375$0.1875$18.75
wan-3.0, 480p$0.0625$0.3125$31.25
minimax-h3, 480p$0.0625$0.3125$31.25
kling-3, 1080p, audio off$0.14$0.70$70.00
kling-3, 1080p, audio on$0.21$1.05$105.00

How a hosted batch actually runs

Sume's generation admission page says a paid job can wait in queued until a workspace concurrency slot opens, and that concurrency is set by plan: 1 on Free, 4 on Pro, 8 on Startup, 20 on Scale. Accepted job capacity is concurrency plus queue capacity, which is 24 on Pro, so a 100-clip batch has to be submitted in waves or it returns 429 queue_full. For that submit pattern read 100 Omni clips on Sume Pro.

Sume's video docs say a job usually takes from 30 seconds to several minutes depending on the model and parameters. That is a range, not a per-model timing, so this page does not turn it into hours. Time one real job on your own account before you promise a batch deadline.

When each side wins

A GPU you already own, an MIT license and no per-clip invoice favor Kandinsky for a steady backlog. A deadline, no hardware and a per-clip price you can budget before the run favor a hosted id. The two are not equal on look either, and neither page here claims a quality ranking: render the same prompt both ways before you commit.

Sources

Related posts

More in Comparisons

All Comparisons posts

Written by Sume