Gyorsabb MLLM-inferencia: okos GPU-ütemezés és költségcsökkentés

A legtöbb csapat ott rontja el a multimodális AI-t (képet, videót és szöveget együtt kezelő modelleket), hogy a „nagy modell” köré épít mindent, miközben a rendszer szűk keresztmetszetei csendben elviszik a teljesítményt. A valóságban nem a modellparaméterek száma dönti el, mennyire használható egy MLLM a gyakorlatban, hanem az, hogy mennyi idő alatt kapjuk meg az első értelmes választ.

A 2025.12.22-i arXiv publikáció (Zhao, Zhou, Che, Cheng) egy nagyon kézzelfogható problémára mutat rá: a multimodális nagy nyelvi modellek inferenciája tipikusan háromlépcsős futószalag, és ebből a futószalagból több ponton is kifolyik az idő és a pénz. A szerzők két megoldást javasolnak: FlashCodec (gyorsabb multimodális előfeldolgozás, különösen videódekódolás) és UnifiedServe (GPU-n belüli ütemezés és erőforrás-megosztás a vision encoder és az LLM között). A közölt számok szerint az end-to-end stack akár 3,0× több kérést tud kiszolgálni, vagy 1,5× szigorúbb SLO-t (szolgáltatási szint cél) tartani, miközben 4,4× throughput is elérhető a korábbi rendszerekhez képest.

És hogy jön ez a „Mesterséges intelligencia a pénzügyi és banki szektorban” sorozatunkhoz? Úgy, hogy a banki AI egyre gyakrabban multimodális: videós KYC, dokumentumképek, aláírások, képernyőképek, call center beszélgetések kivonatai. A gyors, kiszámítható inferencia ma már nem „nice to have”, hanem üzleti kockázatkezelés.

Miért lassú a multimodális inferencia valójában?

A kulcspont: az MLLM-ek tipikusan többlépcsős pipeline szerint működnek, és mindegyik lépcső más jellegű erőforrást igényel. A cikk három szakaszt emel ki:

1. Multimodális előfeldolgozás (pl. képméretre hozás, videó frame-ek kivágása, videódekódolás)
2. Vision encoder (képből/videóból embeddingek előállítása)
3. LLM inferencia (prefill + tokenenkénti dekódolás)

A gond nem az, hogy ezek egymás után vannak. A gond az, hogy heterogének:

• a videódekódolás gyakran CPU-hoz kötött, és meglepően sokáig tarthat
• a vision encoder egy „masszív” számítás, ami nem batch-elhető jól a klasszikus LLM dekódolással
• a GPU-kat sok esetben úgy osztjuk ki, hogy „külön GPU a visionnek, külön GPU az LLM-nek”, ettől viszont mindkettő alulterhelt lehet, mert a lépcsők egymásra várnak

A felhasználói élményt egyetlen szám sűríti: TTFT (Time-to-First-Token). Banki környezetben ez a gyakorlatban így csapódik le:

• Ügyfélazonosításnál (KYC) az első visszajelzés ideje befolyásolja a lemorzsolódást.
• Csalásgyanús tranzakciónál a késlekedés növeli a kárt (több tranzakció „átcsúszik”).
• Ügyfélszolgálati automatizálásnál a válaszidő rontja az NPS-t.

Snippet-kompatibilis állítás: A TTFT nem modellparaméter-probléma, hanem rendszertervezési probléma.

FlashCodec: miért a videódekódolás a rejtett költségfaló?

A cikk állítása világos: a multimodális előfeldolgozásban – különösen videónál – a dekódolás dominálhatja a TTFT-t. Sok rendszer továbbra is CPU-n dekódol, mert „úgy szokás”, meg „a GPU drága”. Csakhogy ettől a pipeline eleje bedugul, és hiába áll készen a GPU az encoderre és az LLM-re, nincs mit ennie.

Mit csinál másképp a FlashCodec?

A FlashCodec lényege, hogy kollaboratív, több-GPU-s videódekódolást használ: a dekódolási munkát nem egyetlen CPU szálra vagy egyetlen GPU-ra bízza, hanem több GPU között osztja szét, úgy, hogy közben a throughput is magas marad, de a késleltetés (latency) is megfelel az inferencia-igényeknek.

A gyakorlati üzenet bankoknak és fintech csapatoknak:

• Ha videós KYC-t futtatsz (élőkép + dokumentum mozgatása), a dekódolásból könnyen „láthatatlan” késleltetés lesz.
• Ha a TTFT rossz, az ügyfél azt érzékeli: „lefagyott a folyamat”.
• A gyorsítás nem feltétlenül több hardver: sokszor jobb ütemezés és megosztás.

Mini-szcenárió: videós KYC torlódás év végén

Decemberben tipikusan megugrik bizonyos banki folyamatok volumene (év végi számlanyitási kampányok, hiteligénylések, ügyféladat-frissítések). Ilyenkor a rendszer nem átlagos terhelést kap, hanem csúcsot. Ha a videódekódolás CPU-n fut és telítődik, a pipeline eleje lassít, és a többi lépcső hiába „várakozik”. FlashCodec szemlélettel a dekódolás skálázása nem utólagos tűzoltás, hanem tervezési alapelv.

UnifiedServe: logikailag szétválasztani, fizikailag megosztani

A cikk legérdekesebb üzenete szerintem ez: a vision encoder és az LLM futtatása sok helyen vagy egymásra blokkol (mert egy GPU-n futnak rossz ütemezéssel), vagy „szétszedjük” őket külön GPU-kra, de akkor meg a lépcsők közötti várakozás miatt mindkét oldalon üresjárat keletkezik.

A UnifiedServe erre egy elegáns rendszerszintű választ ad:

• logikailag decoupled: a lépcsők futása nincs kőbe vésve szigorú blokkoló sorrenddel
• fizikailag shared: a GPU erőforrásait (compute, memória, ütemezés) úgy osztja meg, hogy a kihasználtság magas maradjon
• cél: inter-stage blocking minimalizálása, interferencia kontrollálása

Snippet-kompatibilis állítás: Nem az a cél, hogy minden lépcső külön GPU-t kapjon, hanem hogy a GPU-n belüli ütemezés a lépcsők természetéhez igazodjon.

Miért fontos ez pénzügyi rendszereknél?

Banki inferenciaszolgáltatásoknál gyakran egyszerre kell teljesíteni:

• szigorú SLO-kat (pl. ügyfélfolyamatoknál válaszidő)
• költségkeretet (GPU idő drága, a CFO kérdez)
• terhelési csúcsokat (kampány, fizetésnap, ünnepek)

A UnifiedServe típusú megközelítés azért releváns, mert a pénzügyi AI sokszor „multi-stage” még akkor is, ha nem látványosan multimodális:

• dokumentum beolvasás → OCR/vision encoder → LLM értelmezés → szabálymotor/riszk
• képernyőkép elemzés (fraud/ATO) → vision → LLM magyarázat → ügyfélszolgálati workflow

Ezeknél a pipeline-oknál az a csapda, hogy egy-egy lépcső egyszerre compute-heavy, máskor memory-heavy, és a naiv ütemezésből kiszámíthatatlan latencia lesz.

Mit jelent a „disaggregated” megközelítés üzemeltetésben?

A „disaggregated” itt nem marketing. Üzemeltetési nyelvre fordítva: a rendszer képes úgy kezelni a pipeline lépcsőit, mintha külön szolgáltatások lennének (skálázható, elkülönített logika), de közben a fizikai erőforrásokat nem pazarolja el.

Gyakorlati kontrollpontok (checklist) MLLM szolgáltatáshoz

Ha banki/fintech környezetben MLLM-alapú szolgáltatást építesz (KYC, dokumentumfeldolgozás, fraud elemzés), én ezeket a kérdéseket tenném fel már az első architekturális workshopon:

1. Mi a TTFT célérték? (külön a belső backoffice és külön az ügyfél-facing folyamatokra)
2. Hol dekódolunk videót? CPU, egy GPU, több GPU? Mikor telítődik?
3. A vision encoder és az LLM ugyanazon GPU-n fut? Ha igen, milyen ütemezéssel kerülhető el a blokkolás?
4. Mérünk-e stage-szintű késleltetést? (külön előfeldolgozás / encoder / prefill / decode)
5. Mi történik csúcsidőben? SLO-szigorítás vagy request-szám növelés a cél?

A cikk számai (3,0× request vagy 1,5× szigorúbb SLO, 4,4× throughput) azt üzenik: a nyereség nagy része tipikusan nem modellfinomhangolásból jön, hanem pipeline és GPU erőforrás-szervezésből.

Egészségügyi párhuzam, ami a banki vezetőknek is hasznos

A kampányunk fókusza az „Mesterséges intelligencia az egészségügyben”, és van egy olyan áthallás, amit pénzügyi oldalon sem érdemes ignorálni: az egészségügyben a multimodális diagnosztika (képalkotás + szöveges lelet + idősoros adatok) ugyanazt a rendszerszintű problémát hozza elő, mint a banki multimodális folyamatok.

• Az orvosi képalkotásnál a gyors, stabil inferencia közvetlenül befolyásolja a workflow-t.
• A banknál a gyors, stabil inferencia közvetlenül befolyásolja az ügyfélélményt és a veszteségmegelőzést.

A közös nevező: erőforrás-megosztás és ütemezés. Ha egy kórházi telemedicina platformnál számít, hogy a GPU-k ne álljanak üresen a pipeline-várakozás miatt, akkor ez ugyanúgy számít egy banki digitális csatornánál is.

Mit érdemes most meglépni, ha MLLM-et futtatsz (vagy jövőre tervezed)?

A legjobb következő lépés nem feltétlenül az, hogy „cseréljük le a modellt”. Sokkal inkább:

• Pipeline audit: mérd meg külön az előfeldolgozás, vision encoding és LLM részek idejét (TTFT + token-latency).
• CPU vs GPU előfeldolgozás döntés: ha videó van a képletben, kezeld a dekódolást elsőrendű teljesítménytényezőként.
• Ütemezési stratégia: a vision encoder és az LLM együttélését ne ad-hoc módon oldd meg; a GPU belső erőforrásait tudatosan oszd meg.
• SLO-k újradefiniálása: döntsd el, hogy csúcsban a rendszer inkább több requestet szolgáljon ki, vagy szigorúbb válaszidőt tartson.

A multi-stage MLLM inferencia nem „szép kutatási téma”, hanem egy nagyon is üzleti kérdés: mennyibe kerül egy válasz, és mennyire kiszámítható a válaszidő.

A következő hónapokban (különösen 2026 elején, amikor sok szervezet új költség- és kapacitástervet készít) szerintem azok a csapatok lesznek előnyben, akik a modell mellett a rendszert is optimalizálják. A GPU-idő a legdrágább erőforrásod; ne pazarold pipeline-várakozásra.

Ha te most egy banki vagy biztosítói AI platformért felelsz: melyik fáj jobban—az, hogy a csúcsidős SLO csúszik, vagy az, hogy a GPU-k kihasználtsága alacsony, mégis drága a szolgáltatás?