GPU-időzítés MLLM-ekhez: gyorsabb kép- és videóelemzés

A legtöbb szervezet ott veszít időt a multimodális AI-val (kép+szöveg, videó+szöveg), ahol nem is keresi: nem a “modell okosságán”, hanem a kiszolgálásán. A Time-to-First-Token (TTFT) – az az idő, amíg egy rendszer az első értelmes választ “kiköpi” – sok esetben nem a nagy nyelvi modell (LLM) miatt csúszik el, hanem már azelőtt, hogy a modell egyáltalán dolgozni kezdene.

A friss kutatások egyik tanulsága, hogy a multimodális pipeline (előfeldolgozás → látás encoder → LLM inferencia) három külön világ, és ha ezeket naivan, egymást blokkolva futtatjuk, akkor drága GPU-k mellett is meglepően rossz lesz a kihasználtság. A 2025.12.22-én aktuális tanév végi hajrában ez EdTech-ben is fáj: ha egy platform videós beadandót elemez, táblaképet értelmez vagy kézírást olvas, akkor a késés közvetlenül rontja a felhasználói élményt.

A most megjelent rendszer-szintű megközelítés (FlashCodec + UnifiedServe) nem új modellt ígér, hanem gyorsabb és kiszámíthatóbb kiszolgálást: a beszámoló szerint akár 3,0× több kérés szolgálható ki vagy 1,5× szigorúbb SLO tartható, miközben 4,4× throughput is elérhető a korábbi megoldásokhoz képest. És ami a kampányunk szempontjából lényeges: ugyanez a gondolkodásmód az egészségügyben (képalkotás, távdiagnosztika, triázs) és az oktatásban is ugyanoda mutat – a “valós idejű” nem modellkérdés, hanem rendszerkérdés.

Miért lassú a multimodális AI a gyakorlatban?

A kulcsállítás egyszerű: az MLLM inferencia nem egy lépés, hanem egy háromlépcsős gyártósor, és a gyártósor leglassabb állomása fogja a tempót diktálni.

1) Multimodális előfeldolgozás: a videódekódolás megeszi a TTFT-et

A multimodális előfeldolgozás tipikusan olyan feladatokat jelent, mint:

• videó dekódolása képkockákra,
• képek átméretezése, normalizálása,
• tokenizálás és csomagolás a modell bemenetéhez.

A kutatás szerint különösen a videódekódolás hajlamos dominálni a TTFT-et, mert a legtöbb rendszer CPU-n dekódol. Ez két okból gond:

1. A CPU gyakran szűk keresztmetszet, amikor párhuzamosan sok kérést kell kezelni.
2. A GPU közben tétlenkedik, pedig pont arra fizettünk be, hogy számoljon.

EdTech-párhuzam: ha egy tanuló feltölt egy 60–90 másodperces prezentációvideót, és a rendszernek azonnal visszajelzést kell adnia (beszédtempó, kulcspontok, vizuális elemek), akkor a késés gyakran nem a “nyelvi értékelés”, hanem a videó feldolgozhatóvá tétele.

Egészségügyi párhuzam: távleletezésnél vagy sürgősségi triázsnál a percek is számítanak, de a felhasználó az első másodpercekben ítéli meg, hogy “működik-e a rendszer”. A TTFT itt UX és bizalom kérdés.

2) Vision encoder: önálló, nehezen együtt batch-elhető szakasz

A látás encoder (pl. ViT-alapú kódoló) a képből/videóból vizuális embeddinget gyárt. Ez számításigényes, és jellemzően nem batch-elhető együtt az LLM prefill vagy decoding lépéseivel, mert más jellegű kernel-futtatásokat és memóriamintázatot kíván.

A rendszer-szintű következmény: ha külön “szigetként” futtatjuk, akkor a pipeline-ban könnyen kialakul inter-stage blocking, vagyis az egyik szakasz vár a másikra. Itt nem az a baj, hogy nincs GPU, hanem az, hogy rosszul van beosztva az idő és az erőforrás.

3) LLM inferencia: prefill és decoding, eltérő ritmussal

Az LLM inferencia belül is két világ:

• prefill (a bemenet “betöltése”, figyelem-számítások),
• decoding (tokenenkénti generálás).

A decoding sok kis lépésből áll, és ha a többi szakasz nem illeszkedik hozzá, akkor a GPU kihasználtság hullámzik. A felhasználó ezt úgy éli meg, hogy “néha gyors, néha gondolkodik”.

FlashCodec: gyorsabb videódekódolás több GPU-val, okosan

A FlashCodec lényege: a videódekódolást nem a CPU-ra bízza, hanem kollaboratív módon több GPU között osztja meg.

A fontos rész nem az, hogy “GPU-n dekódolunk” (ilyet láttunk már), hanem az, hogy a kutatás szerint a korábbi GPU-alapú megoldások sokszor átviteli teljesítményre optimalizálnak, miközben MLLM inferenciánál gyakran késleltetés-érzékeny a feladat. Magyarul: nem az a cél, hogy “sok videót daráljunk le egyszerre”, hanem az, hogy egy kérésből gyorsan legyen modellezhető bemenet.

A gondolkodásmód, amit én különösen hasznosnak tartok: a pipeline első lépését (dekódolás) ugyanúgy SLO-hoz kell kötni, mint a modellválaszt. Ha a TTFT-et akarod levinni, a CPU-dekódolás sokszor a legdrágább önámítás.

EdTech példa (konkrét helyzet):

• online vizsgafelügyelet rövid klippekből (pl. 10–20 mp-es eseményrészletek),
• a rendszernek azonnal jeleznie kell, ha gyanús viselkedés látszik,
• ha a dekódolás csúszik, a riasztás késik, a value elvész.

Egészségügyi példa:

• telemedicinás konzultáció során feltöltött rövid videó (járásminta, bőrjelenség),
• gyors első visszajelzés kell, különben a klinikus nem fogja beépíteni a munkafolyamatába.

UnifiedServe: logikailag külön, fizikailag megosztott GPU-erőforrás

A UnifiedServe üzenete: ne kényszerítsd a különböző szakaszokat arra, hogy egymást várják, de ne is pazarolj külön GPU-t mindegyikre úgy, hogy közben félgőzön mennek.

A kutatás szerint a megoldás két részből áll:

• logikai szétválasztás: a vision→text és az LLM inferencia úgy fut, hogy csökkenjen az inter-stage blocking,
• fizikai erőforrás-megosztás: a GPU erőforrásait (számítás, memória, ütemezés) megosztva, belső időzítéssel használják, hogy a kihasználtság nőjön és az interferencia csökkenjen.

Ezt érdemes egy oktatási hasonlattal elképzelni: a tanulási folyamatban is külön “modul” a videónézés, a jegyzetelés és a tesztkitöltés – de a diák idejét mégis úgy osztod be, hogy ne legyen üresjárat. A GPU pontosan ilyen: ha rossz az órarend, sokat várakozik.

Mit jelent ez SLO és skálázás szempontból?

A publikált eredmények alapján a keretrendszer:

• akár 3,0× több kérést tud kiszolgálni azonos infrastruktúrán,
• vagy 1,5× szigorúbb SLO-t tud tartani (azaz kisebb megengedett késleltetés mellett stabil),
• és akár 4,4× nagyobb throughputot ad a korábbi rendszerekhez viszonyítva.

A gyakorlati következtetés: ha egy intézmény (iskola, kórház, szolgáltató) eddig azért nem mert valós idejű multimodális AI-t bevezetni, mert “GPU-ból úgysem lesz elég”, akkor itt egy kellemetlen igazság: sok esetben nem a GPU kevés, hanem a kiszolgálás pazarló.

Mi köze mindennek az egészségügyhöz és az EdTech-hez?

A legjobb rendszermérnöki ötletek gyakran ott születnek, ahol nagy a forgalom és drága a késés. Az MLLM-ek kiszolgálása pontosan ilyen. És ez két iparágban különösen releváns.

Egészségügy: gyorsabb képi triázs, megbízhatóbb telemedicina

Az egészségügyi AI sokszor multimodális:

• képalkotás (röntgen, CT, MR) + lelet szöveg,
• fotó (bőr, szemfenék) + anamnézis,
• videó (mozgás, remegés) + klinikai kérdések.

Ha a rendszer késik, a klinikus nem fog várni, hanem visszatér a régi rutinokhoz. Itt a GPU-időzítés és erőforrás-megosztás nem “infra finomhangolás”, hanem adoptálhatósági feltétel.

EdTech: személyre szabott tanulás multimodális inputból

A „Mesterséges intelligencia az oktatásban és EdTech területen” sorozatban gyakran beszélünk adaptív tanulási utakról, automatikus értékelésről, tanulói analitikáról. A következő lépcső viszont egyre inkább multimodális:

• dolgozatfotó → automatikus javítás,
• táblakép → jegyzetgenerálás,
• prezentációvideó → kommunikációs visszajelzés,
• laborvideó → lépésről lépésre hibakeresés.

Ezeknél nem elég, hogy “pontosan értékel” a modell. Gyorsan kell reagálnia, különben a diák már továbbkattintott.

Gyakorlati ellenőrzőlista: mit csinálj másként, ha MLLM-et szolgálsz ki?

Ha a csapatod MLLM inferenciát épít (akár egészségügy, akár EdTech), ez a 7 pontos lista segít elkerülni a tipikus zsákutcákat.

1. Mérd külön a TTFT-et és a tokenenkénti késleltetést. Ne egyetlen “átlagos latency” számot nézz.
2. Profilozd a pipeline-t szakaszonként. Előfeldolgozás / vision encoder / prefill / decoding.
3. Kezeld a videódekódolást elsőrendű rendszerkomponensként. Ne “mellékfeladat” legyen.
4. Ne kényszeríts mindent közös batch-be. A heterogén szakaszoknál a túlzott co-batching visszaüthet.
5. Ütemezés > több vas. Előbb nyerd vissza az üresjáratot, utána vegyél új GPU-t.
6. SLO-alapú tervezés. Mondd ki, hogy pl. TTFT ≤ 800 ms vagy ≤ 1,2 s – és ahhoz igazíts mindent.
7. Interferencia-tudatos megosztás. Ha megosztod a GPU-t, figyeld, mikor zavarják egymást a szakaszok.

Egy mondatban: a multimodális AI-nál a “valós idejű” nem varázslat. Ütemezés, erőforrás-megosztás, és könyörtelen mérés.

Merre megy ez 2026-ban? (és miért érdemes most foglalkozni vele)

2026-ban az EdTech platformoknál a videós és képi tartalom csak nőni fog: projektmunkák, portfóliók, hibrid órák felvételei, AI-alapú korrepetálás képernyőmegosztással. Az egészségügyben pedig a telemedicina és a képi triázs skálázása marad napirenden. Mindkét területen ugyanaz lesz a döntő: kiszámítható késleltetés és stabil kiszolgálás csúcsidőben.

Ha ezen a ponton azt érzed, hogy a szervezeted “jó modellt választott, mégis lassú”, akkor valószínűleg nem modellvitát kell nyitni, hanem egy infrastruktúra-vitát: hol blokkol a pipeline, hol tétlen a GPU, és mennyi idő megy el dekódolásra.

Ha szeretnél olyan MLLM-architektúrát tervezni (oktatás vagy egészségügy), ami tényleg bírja a valós terhelést, érdemes a következő beszélgetést ezzel kezdeni: mennyi a TTFT cél, és melyik szakasz a szűk keresztmetszet ma?