Hardveres optimalizálás: az input és output csapdája
Egy LLM felhasználási módjától nagyban függ, hogy a bemeneti (input) vagy a kimeneti (output) tokenek száma dominál. Szélsőséges arányokat látunk: egyesek rövid utasításokat adnak, de többoldalas szöveget kérnek vissza (például rajongói történetgenerálás), míg mások hatalmas adathalmazokat akarnak röviden összefoglalni. Ezek a különbségek fontos hardveres döntéseket követelnek: gyorsabb input- vagy output-feldolgozásra van-e szükség. Az MI-ügynökök esetében jellemzőbb a hatalmas bemeneti tokenmennyiség, így kritikus lett a gyors inputfeldolgozás és az eszközhívások gyors kezelése.
Prefill–decode szétválasztás: minden GPU a maga dolgán dolgozik
Az LLM-ek futtatása kétrészes: a prefill (bemeneti tokenek feldolgozása és gyorsítótárba pakolása) és a decode (kimenet generálása). Ezek különböző GPU-erőforrásokra támaszkodnak, de ha egyetlen gép csinál mindkét lépést, az pazarlás. A prefill–decode diszaggregációval külön kiszolgálók vállalják a két fázist. Így minden szerver arra van hangolva, amit éppen csinál: a bemeneti vagy a kimeneti tokenek özönének gyors feldolgozására. Ez bonyolult, tokenérzékeny terheléselosztót igényel, amely folyamatosan figyeli, mely végpontokon mennyi input vagy output token van épp folyamatban. Az új rendszer élesítése óta a leglassabb válaszidők harmadára csökkentek, 90 százalék felett pedig 100 ms-ról 20–30 ms-ra mérséklődött az átlagos tokenidő – mindez a GPU-k számának növelése nélkül.
Prompt cache: ha valamit már kiszámoltál, ne számold újra
Az MI-ügynökök szeretik a hosszú, összefüggő kontextust, ez viszont kezelhetetlenül lassú lenne az ismétlődő inputtenzorok számolgatásával. Ezért került bevezetésre a gyorsítótárazás: ha egy felhasználó ugyanabban a régióban folytatja a munkát (X-Session-Affinity fejléccel), nem számoljuk újra ugyanazt a bemenetet. Az OpenCode (MI-kódgenerátor) használatakor például 60 százalékról 80 százalékra ugrott a cache-hit arány csúcsidőben, így a rendszer egyszerre több felhasználói kérést kezel, jobb teljesítmény és olcsóbb működés mellett.
KV-cache megosztása: több GPU, egy közös memória
A Kimi modellmérete miatt egy példány akár több GPU-t is igényel. A bemeneti tokenek eredménye (KV-cache) eredetileg egyetlen GPU memóriájában, a VRAM-ban él. Több GPU-s futtatásnál a cache-nek átjárhatónak kell lennie: ezt a Moonshot AI „Mooncake Transfer Engine” rendszere oldja meg, amely gyors, közvetlen memóriatranszfert valósít meg NVLinken vagy NVMe over Fabric protokollon. A Mooncake Store-ral együtt használva a cache nemcsak a GPU RAM-ban marad, hanem NVMe SSD-n is. Ez megnöveli a gyorsítótárazás élettartamát és lehetővé teszi a terhelés kiegyensúlyozását, így egyszerre több kérést lehet feldolgozni.
Spekulatív dekódolás: gyorsabb szövegírás okosan
A modellek tokenenként generálnak szöveget, de spekulatív dekódolással egy kisebb LLM (úgynevezett draftmodell) előre legenerál több tokent, azokból pedig a nagy főmodell választ. Ez annyival gyorsabb, hogy a főmodellnek nem kell minden egyes következő tokent külön kiszámolnia. Az NVIDIA EAGLE-3 draftmodelljével például a tokengenerálás átviteli sebessége jelentősen nőtt, miközben a végeredmény minőségét a fő LLM garantálja.
Infire: a Cloudflare saját inferenciamotorja
Az Infire motor Rust nyelven íródott, kifejezetten elosztott MI-rendszerekre. Fő feladata a nagy LLM-ek gyors indítása, valamint az, hogy egyidejűleg több GPU-t is rugalmasan kezelhessen: lehetőség szerint pipeline- és tensorpárhuzamos módban, illetve szakértői párhuzamosítási támogatással. A rendszer egyrészt optimalizálja az adatok áramlását a GPU-k között, másrészt jelentősen csökkenti az indulási (cold start) időt – akár 20 másodpercen belül működésre képes a legnagyobb modellekkel is.
Az optimalizálásoknak köszönhetően a Kimi K2.5 például 8 H100-as GPU-n is kényelmesen fut, miközben több tíz GB VRAM szabadon hagyható a cache-nek, ami 1,2 millió tokenes kontextusablakot tesz lehetővé.
Gyorsabb és olcsóbb – folyamatosan fejlődve
A hardver és szoftver együttes optimalizálásával a legmodernebb LLM-ek futtatása nemcsak egyszerűbb és gyorsabb lett, hanem jelentősen csökkentek a működtetési költségek. Előfordul, hogy akár 20 százalékos gyorsulás is elérhető tokenenként, ráadásul már nemcsak a legdrágább GPU-kkal futhatnak a nagy modellek, hanem gyengébb gépekkel is, ami korábban elképzelhetetlen volt.
A fejlődés nem áll meg; minden héten új kutatási eredmények, modellek és módszerek jelennek meg. Az MI-technológiák optimalizálása így folyamatos kihívás – de aki ebben lát fantáziát, az most igazán izgalmas időszakban van!
