A vLLM szerint valós időben készülhet el a MiniMax H3 videója

A videógenerálás teljes feldolgozási láncát optimalizálták

A vLLM 2026. szeptember 1-jén közzétett beszámolója szerint a MiniMax H3 kiszolgálása nem egyetlen modellkomponens gyorsításáról szól. A rendszer egy nagy Qwen3-VL kódolót, hosszú sorozatokkal dolgozó audio- és videó DiT-modellt, külön video- és hang-VAE-ket, több eszköz- és folyamatközi adatátvitelt, végül pedig H.264- és AAC-kódolást használ.

A MiniMax H3 szövegből, képekből, videókból és hangreferenciákból közösen készít videót és szinkronizált hangot. A vLLM-Omni három feladattípust kezel: a T2VA szövegből generál, az FL2VA szöveg és kezdő, illetve zárókép alapján hoz létre átmenetet, a Ref2VA pedig kép-, videó- és hangreferenciákat használ szerkesztéshez.

A fejlesztők ezért a teljes feldolgozási útvonalat vizsgálták. A figyelem- és kommunikációs műveletek, a DiT-operátorok összevonása, a párhuzamos VAE-dekódolás, a tömörített kimeneti adatátvitel és a párhuzamos MP4-készítés együtt csökkentette a késleltetést.

A vLLM-Omni 30,8 százalékkal csökkentette az alapváltozat késleltetését

Az alap H3-tesztsorozatban a vLLM a Diffusers és a vLLM-Omni futtatását hasonlította össze nyolc NVIDIA B300 GPU-n. Mindkét mérés 1344×768-as felbontást, 24 képkocka/másodperces sebességet, 50 sigma-pontot és 49 DiT-előrefuttatást használt.

A Diffusers esetében a teljes kliensoldali végponttól végpontig tartó idő 82,239 másodperc, a csúcson mért GPU-memória pedig rangonként 151,699 GiB volt. A vLLM-Omni ugyanezekben a mérési feltételekben 56,917 másodperces teljes időt és 128,232 GiB csúcsmemória-használatot ért el.

A vLLM számítása szerint ez 30,8 százalékos késleltetéscsökkenésnek, illetve 1,445-szörös gyorsulásnak felel meg. A vállalat ezt veszteségmentes optimalizálásként írja le, mivel a gyorsítás nem kvantálásból, ritka figyelemből, gyorsítótár-újrahasznosításból vagy kevesebb denoising-lépésből származik. A vLLM ugyanakkor jelzi, hogy az eltérő kernelmegvalósítások és lebegőpontos összegzési sorrendek miatt a kimenet nem feltétlenül bitről bitre azonos.

A FastH3 négy DiT-lépésre rövidíti a denoising ciklust

A rendszeroptimalizálás után a megmaradó legnagyobb időigényt a denoising jelentette. A FastVideo FastH3 módszere a DiT-előrefuttatások számát 49-ről négyre csökkenti.

A FastH3 külön mérési sorozatában a vLLM nyolc NVIDIA B300 GPU-t, 1344×768-as felbontást és 24 képkocka/másodperces sebességet használt. A teszt T2VA feladatot futtatott, egyetlen replikával, encoder TP8, DiT USP8 és Ring1, valamint VAE PP8 tile beállítással.

A mérés szerint a rendszer egy teljes, 10,125 másodperces MP4-fájlt 8,678 és 8,710 másodperc között készített el. A vLLM ebben a cikkben a valós időt úgy határozza meg, hogy a teljes válasz elkészülési ideje rövidebb a lejátszás időtartamánál. Ez nem folyamatos képkockaküldést, és nem is az első képkockáig eltelt időt jelenti.

A mérés a teljes MP4-választ vizsgálta

A vLLM a mérési időt a szinkronizált kérésbeküldéstől a teljes MP4-fájl átvételéig számolta. A letöltés, az indulás, a fordítás és a kizárt bemelegítő futtatás nem része az időintervallumnak.

Az elfogadott kimenetnek H.264-videót és sztereó, 32 kHz-es AAC-hangot kellett tartalmaznia, a várt képkockaszámmal és képkockasebességgel. A teszt ellenőrizte azt is, hogy legyen változatosság a videóban, mérhető hangszint az audióban, és a kimenet megfeleljen a kérésnek.

A vLLM két bizonyítéki sávot külön kezel: az alap H3 és a vLLM-Omni összevetését, valamint a FastH3 abszolút késleltetési mérését. Mivel a két kísérlet forráskódja, promptja, magja és artefaktuma nem volt azonos, a cikk nem számol közvetlen alap H3 és FastH3 közötti gyorsulást.