Kandinsky 6.0 Video landt in vLLM-Omni: wat een servinglaag toevoegt aan een open model

Pull request #8537 is vanochtend om 07:55 UTC samengevoegd in vLLM-Omni, en doet precies één ding: hij maakt Kandinsky 6.0 Video serveerbaar. Het model zelf kwam dezelfde dag van Sber's Kandinsky Lab, als een paar — Kandinsky 6.0 Video Pro met 29B parameters en Kandinsky 6.0 Video Lite met 3B — dat clips van vijf seconden genereert met gesynchroniseerde audio van 44 kHz, inclusief lip-sync, op basis van een tekstprompt of een referentieafbeelding, waarbij code, gewichten en diffusers-integratie allemaal onder MIT vallen. Wat het tot vanochtend niet had, was een manier om het in een inference-server te draaien in plaats van via een eenmalige opdrachtregel.

Dat onderscheid is meer waard dan het klinkt, en het is de reden dat dit een apart verhaal is los van de release. Een open checkpoint dat je op je eigen kaart kunt draaien is een onderzoeksartefact; een open checkpoint met een server-side pipeline, gedeelde entry points en een serveerrecept is iets dat je achter een wachtrij kunt zetten. De release van deze week gaf je het eerste. De merge van vandaag is het begin van het tweede.

Wat is er eigenlijk samengevoegd?

De PR voegt tekst-naar-video-en-audio en afbeelding-naar-video-en-audio toe aan vLLM-Omni vanaf de checkpoint kandinskylab/Kandinsky-6.0-Pro-5s-Diffusers. De technische keuzes zijn het interessante deel, omdat ze je laten zien hoe de architectuur er echt uitziet wanneer iemand anders dan de auteurs hem moet serveren.

• Eén DiT denoist beide modaliteiten. De pipeline is geregistreerd als Kandinsky6TI2VAPipeline, en video-latenten en audio-latenten worden gezamenlijk gedenoiseerd door één transformer in plaats van door twee modellen die achter elkaar worden uitgevoerd. Dat weerspiegelt de dual-stream CrossDiT uit het artikel, waarbij een voorgetrainde videostream en een vanaf nul getrainde audiostream via bidirectionele cross-attentie met elkaar zijn verbonden.

• Gewichten worden map voor map geladen. Het Hub-checkpoint wordt gelezen als transformer/, vae/, text_encoder/, text_encoder_2/ en audio_vae/. De interne namen van het gepubliceerde checkpoint — videoT en audioT — worden bij het laden toegewezen aan video_dec_block en audio_dec_block, en dat is precies zo'n detail dat een dag opslokt als je het zelf ontdekt.

• Audio staat standaard aan. De pipeline levert 44,1 kHz AAC in plaats van geluid als een opt-in-vlag te behandelen, dus een verzoek zonder audioparameters komt nog steeds terug met gesynchroniseerde spraak, muziek of omgevingsgeluid.

• Een beeldinvoer is een gemaskeerd staartframe, geen aparte modus. Conditionering op referentieafbeeldingen wordt toegepast via maskering, waardoor dezelfde pijplijn zowel T2AV als I2AV zonder vertakkingen bedient.

De rooktest van de indiener is een nuttige ondergrens: één enkele NVIDIA H100 80GB met FlashAttention-3, CPU-offload aan, 864×480, 125 frames, 50 stappen, CFG 5.0, seed 42. Dat is een clip van 5 seconden op net geen HD, geen Full HD-render, en de PR beweert niet anders.

Een checkpoint is geen service

De reden om je druk te maken over een merge als deze is wat hij van je lijstje haalt. De referentie-implementatie draaien betekent de repository clonen, even `just setup` uitvoeren, SageAttention laten compileren op alles onder Hopper, de checkpoint naar een cachemap downloaden en een generate-commando aanroepen waarvan de output in een map met een tijdstempel terechtkomt. Dat is prima voor een eerste kennismaking en onhandig voor een product.

vLLM-Omni geeft je het model binnen een servingproces, met dezelfde offline-inference-entrypoints die het project gebruikt voor zijn andere diffusiemodellen (examples/offline_inference/text_to_video/text_to_video.py en zijn image-to-video-tegenhanger) en een servingrecept in recipes/Kandinsky/Kandinsky6-TI2VA.md. Daaruit volgen twee praktische consequenties. Je deploymentverhaal wordt een container die een HTTP-interface spreekt in plaats van een script dat je moet beheren, en het model is geen speciaal geval meer in je stack — het staat naast wat je verder ook in die server draait.

Let op wat dit niet is. Het is geen gehost endpoint, het is geen prijs, en het is geen onafhankelijke kwaliteitsmeting. Het is nog een plek waar het model kan draaien, bijgedragen door iemand buiten het lab, drie dagen nadat de gewichten verschenen.

Wat een clip van vijf seconden kost aan kloktijd, op echte kaarten

De eigen tabel van de repository is het eerlijke uitgangspunt. Dit zijn de verwerkingstijden van het niet-gedistilleerde basismodel voor één clip van 5 seconden na warmup, exclusief het laden van gewichten en MP4-encodering. Full HD betekent hier dat de superresolutie-pass ook draait.

• Full HD (Pro) — 402 s op een H100, 765 s op een RTX PRO 6000, 854 s op een RTX 5090, 1.106 s op een A100 80GB, 1.247 s op een RTX 4090 en 3.530 s op een RTX 5060 Ti.

• Full HD (Lite) — 284 s op een H100, 387 s op een RTX PRO 6000, 406 s op een RTX 5090, 664 s op een A100 80GB, 578 s op een RTX 4090, en 1.774 s op een RTX 5060 Ti.

• SD (Pro) — 356 s op een H100 tegenover 936 s op een RTX 4090, wat de situatie is waarin de straf voor consumentenkaarten het kleinst is en de economie het minst slecht.

De vorm van die tabel is belangrijker dan welke afzonderlijke cel dan ook. Een H100 is bij Pro Full HD ongeveer drie keer sneller dan een 4090, en ongeveer zes keer sneller dan een 5060 Ti bij dezelfde taak — maar de SR-fase kost hetzelfde bij beide modelgroottes: ongeveer 64 seconden bij HD en ongeveer 96 seconden bij Full HD op een 5090. Lite levert je geen kortere superresolutie-pass op, omdat het SR-model afzonderlijk wordt getraind en het niet uitmaakt welk basismodel de invoer leverde.

Het 16 GB-pad, en de ene instelling die je beeld verandert

Piek toegewezen geheugen tijdens een Pro SD-run bereikt 72,8 GiB, wat elke consumentenkaart te boven gaat. De repository antwoordt met blok-offloading — slechts twee transformerblokken tegelijk op de GPU, de rest wordt vanuit het hostgeheugen gestreamd — plus drie presets voor kaarten van 32 GB, 24 GB en 16 GB. De presets voor 32 en 24 GB zijn identiek, omdat boven 24 GB de extra ruimte zich niet vertaalt in snelheid.

Het voorbehoud is weggestopt en de moeite waard om te herhalen: in de 16GB-preset is de tekstencoder gekwantiseerd naar NF4, en het artikel zegt expliciet dat dit de enige presetwijziging is die de clip zelf verandert. Een andere tekstuele representatie produceert een andere video. Al het andere — segmentlengte, ruimtelijke stroken, offloading — verandert de uitvoer op het niveau van afrondingsruis, waarbij ongeveer 12% van de pixels met één helderheidsniveau verschilt bij ruwweg 57 dB PSNR. Als je het resultaat van iemand anders op een 16GB-kaart reproduceert en het komt niet overeen, is dat het eerste dat je moet controleren.

Drie dingen die de releaseopmerkingen niet oplossen

• Vijf seconden is het plafond, niet een standaardwaarde. Het model is getraind op 121 frames en 24 fps, en zowel de paper als het servingrecept zijn daarop gebouwd. Er is geen extensiemodus in de release. Alles wat langer is, is een stitchingprobleem dat je zelf moet oplossen.

• Het gedistilleerde checkpoint is wat je uiteindelijk daadwerkelijk zult serveren, en het werd op pariteit gemeten. De ablatie in het paper laat het gedistilleerde model als verkozen of gelijk eindigen op de meerderheid van de criteria, zonder dat een individueel verschil significantie bereikt, bij een gemiddelde voorkeur van 51% tegen 49%. Dat is de afweging die je maakt voor de snelheid.

• Er zijn twee word-error-rate-getallen in het paper en die zijn niet vergelijkbaar. De 47% reductie in de WER van gegenereerde spraak die gepaard gaat met de reinforcement learning-fase, wordt gemeten met Whisper-large-v3, een van de RL-beloningsmodellen; de WER die naast VABench wordt gerapporteerd, gebruikt Qwen3-ASR-1.7B op de spraaksubset. De auteurs zeggen dat zelf. Het ene als het andere citeren is de gemakkelijkste fout om met deze release te maken.

Waar een router zich bevindt in een stack als deze

OrcaRouter biedt Kandinsky 6.0 Video niet aan, en niets hier mag worden gelezen als een claim dat dit wel zo is — het model kun je zelf vanuit de Hub draaien, of het is bereikbaar via de eigen interfaces van het lab. Wat een pipeline als deze van een router nodig heeft, is de tekst eromheen. De prompt-expansiepass die een shotbeschrijving omzet in de lange, medium of korte caption waarop het model is getraind, het caption- en transcriptiewerk dat een image-to-video-pass voedt, de review-samenvattingen die bepalen welke van vier generaties je moet houden: dat zijn gewone tekstcalls, en ze draaien op één OpenAI-compatibel endpoint over meer dan 200 modellen, met providerlijstprijzen die tegen 0% markup worden doorgegeven, zodat een prijswijziging van een leverancier dezelfde dag live is. Automatische failover is hier belangrijker dan gewoonlijk, want een render van vijf minuten die in de captionfase faalt, moet worden omgeleid in plaats van de taak opnieuw te starten.

Het volgende om in de gaten te houden is niet nog een merge, maar een getal. Kandinsky 6.0 Video Pro heeft door de leverancier gerapporteerde resultaten op VABench en een in het lab uitgevoerde menselijke evaluatie tegen Kling 2.6, Veo 3.1 Fast, MiniMax H3 en Seedance 2.0 — en nog geen onafhankelijke arena-score. Wanneer die verschijnt, is de open-weights-bewering niet langer een argument over toegang, maar wordt het een argument over kwaliteit, en dat is de vergelijking die bepaalt of dit een model is dat teams downloaden of een model dat ze bewonderen.

De repository levert ook twee ComfyUI-nodes — kandinsky6 en kandinsky6-sr — die via ComfyUI Manager kunnen worden geïnstalleerd, plus twee Hugging Face Spaces: één voor het Pro-distill-checkpoint en één voor de demo voor videosuperresolutie. Tussen de CLI, de ComfyUI-nodes, de diffusers-bundel en nu een vLLM-Omni-pipeline is het deployment-oppervlak op dag drie breder dan de meeste open videomodellen in een kwartaal voor elkaar krijgen. Die breedte is het eigenlijke verhaal van de week: Sber bracht een familie uit, geen paper met een demo eraan vast.