Másodperces LLM-helyreállítást ígér az NVIDIA Dynamo új előnézeti funkciója

Miért lassú egy LLM-motor újraindítása?

Az NVIDIA leírása szerint ha egy LLM engine folyamat meghibásodik, a szokásos helyreállítási út egy hideg újraindítás. Ilyenkor a rendszernek újra be kell töltenie a súlyokat a HBM memóriába a tárolóból, le kell fordítania a kerneleket, és újra rögzítenie kell az NVIDIA CUDA gráfokat. Nagy modelleknél ez több percig tarthat, miközben a megmaradt workeröknek kell átvenniük a kieső forgalmat.

A bejegyzés két fő okot emel ki. Az egyik, hogy a súlyok az adott engine folyamathoz kötődnek, mert a GPU memória az engine CUDA kontextusához kapcsolódik, ez pedig magához a folyamathoz. Ha a folyamat kilép, a meghajtó felszabadítja az erőforrásokat, köztük a GPU memóriában lévő súlyokat is. A másik ok, hogy bizonyos inicializált állapotok nem adhatók át egy új folyamatnak. Az NCCL és a torch.distributed kommunikátorok a konkrét futó folyamathoz kötődnek, a CUDA gráfok pedig a rögzítéskor használt virtuális címekhez.

A shadow engine recovery erre ad választ azzal, hogy a helyreállítási munka nagy részét leveszi a kiszolgálási útvonalról. A megoldás egy teljesen inicializált, tétlen shadow engine-t tart ugyanazokon a GPU-kon, amelyeken az aktív engine fut. Ha az aktív folyamat meghibásodik, a shadow engine át tudja venni a kiszolgálást, miközben az újrainicializálás a háttérben történik.

A GPU Memory Service tartja életben a súlyokat

A megoldás egyik kulcseleme a GPU Memory Service, röviden GMS. Ez a szolgáltatás meghatározott memóriaterületeket, például a súlyokat, az engine folyamattól függetlenül kezeli. Az NVIDIA szerint a GMS egy GPU-nként futó sidecar, amely fizikai GPU memóriát birtokol a következtetési engine-ek nevében. Többnyire inaktív, nincs saját CUDA kontextusa, fizikai lapokat foglal, fogantyúkat ad át hozzájuk, és szabályozza, hogy mely engine-ek olvashatnak vagy írhatnak egy adott időpontban.

Az engine-ek kapcsolódnak a GMS-hez, importálják a fogantyúkat, majd a mögöttes lapokat a saját CUDA kontextusuk virtuális címeire képezik le. A leképezés egyszer történik meg induláskor, utána a GMS már nem vesz részt a memóriaelérésben. A funkció a CUDA Virtual Memory Management API-ra épül, amely lehetővé teszi, hogy a fizikai GPU memória és a hozzá tartozó virtuális címek élettartama különváljon.

Ennek két gyakorlati következménye van. A súlyok túlélik az engine hibáját, mert a GMS referenciája miatt a fizikai lapok memóriában maradnak. Emellett a súlyok megoszthatók párhuzamos engine-ek között, így egy másodlagos engine ugyanazon a GPU-n az NVIDIA leírása szerint nulla marginális súlyköltséggel működhet. A bejegyzés szerint a vLLM, az SGLang és az NVIDIA TensorRT-LLM egyedi torch.cuda.CUDAPluggableAllocator segítségével integrálja a GMS-t a súlymemória-készlethez. A jelenlegi előnézet a KV cache GMS-en keresztüli használatát még nem támogatja, de ez a képesség aktív fejlesztés alatt áll.

Mit csinál a shadow engine?

A shadow engine egy teljesen inicializált engine folyamat, amely ugyanazokon a GPU-kon fut, mint az aktív engine, de tétlen marad. A súlymegosztás teszi ezt megvalósíthatóvá, mert különben a második engine-nek egy újabb teljes súlymásolatra lenne szüksége, ami jelentősen csökkentené a kérések feldolgozására elérhető memóriát.

A shadow engine ugyanazon az indítási útvonalon megy végig, mint az aktív engine. Minden GPU-n kapcsolódik a helyi GMS-hez, importálja a súlyleképezéseket, létrehozza a kommunikátorokat, köztük az NCCL-t és a workerök közötti KV-átvitelhez használt NIXL-t, rögzíti a CUDA gráfokat, és elvégzi a szükséges bemelegítést. Az indítás végére készen áll a kiszolgálásra, de nem kezd el kéréseket kezelni, hanem parkolt állapotba kerül.

A parkolt shadow engine megtartja a CUDA kontextust, a rögzített gráfokat, a kommunikátorokat és a súlyleképezéseket. A KV cache materializálását viszont későbbre halasztja. A bejegyzés szerint a KV cache az engine legnagyobb visszanyerhető allokációja, ezért a shadow csak a címtartományát tartja fenn fizikai háttér nélkül, és akkor materializálja, amikor előléptetik. Emiatt ugyanazon az eszközön maradhat az aktív engine mellett, miközben hiba esetén másodperceken belüli helyreállítást tesz lehetővé.

Mért eredmény: 7,3 másodperc a 283 másodperccel szemben

Az NVIDIA egy két workerből álló GLM-5.2 telepítésen mérte a hatást NVIDIA B200 node-okon. A tesztben szándékosan leállítottak egy workert. Shadow engine recovery nélkül a megmaradt worker szolgálta ki az összes bejövő forgalmat a 283 másodperces hideg újraindítás alatt. A bejegyzés szerint ez növelte a TTFT értéket, és csökkentette az egy felhasználóra jutó dekódolási sebességet a kiesés teljes ideje alatt.

Shadow engine recovery használatával a második worker 7,3 másodperc után újra kiszolgált. Az NVIDIA ezt közel 39-szer gyorsabbnak írja le a hideg újraindításhoz képest. A vállalat szerint a különbség azért jelentős, mert a hideg újraindítás újratölti a súlyokat, méretezi a KV cache-t, autotuningot végez, és újra rögzíti a CUDA gráfokat, míg az előre inicializált shadow engine jóval hamarabb képes kiszolgálásba állni.

A funkció jelenleg előnézeti képességként érhető el a NVIDIA Dynamo részeként. A forrás szerint a használatához Dynamic Resource Allocation szükséges Kubernetes 1.34 vagy újabb verzión, telepített NVIDIA GPU DRA driverrel. Az elsődlegesen támogatott backend a vLLM.

Mit jelenthet ez a szolgáltatásoknak?

A bejegyzés alapján a shadow engine recovery olyan helyzetekre készült, amikor a gyártási LLM engine-ek helyreállítható szoftverhibákat tapasztalnak. Ilyenek lehetnek a folyamatösszeomlások, a helyreállítható CUDA hibák és az átmeneti kollektív hibák. Ezekben az esetekben a hardver, a meghajtók és a node egészséges marad, csak a sérült állapotot tartó folyamat vész el, ezért egy helyettesítő engine jellemzően elindítható ugyanazokon a GPU-kon.

Felhasználói és szolgáltatói szempontból a bejelentés lényege, hogy egy worker kiesésekor rövidebb ideig kell a megmaradt kapacitásnak elnyelnie a teljes forgalmat. Az NVIDIA mérése szerint ez mérsékelheti a szolgáltatásminőség romlását, mivel a kiesés idején kevésbé nő a TTFT, és kevésbé esik vissza az egy felhasználóra jutó dekódolási sebesség. A vállalat a következő lépésként a Kubernetes quickstartot, a Shadow Engine Recovery telepítési munkafolyamatot, a vLLM failover példát és az ai-dynamo/dynamo repositoryt ajánlja a kipróbáláshoz és visszajelzéshez.