A vLLM új módszere 1 millió tokenes GLM 5.3 futtatást tesz lehetővé

A GPU-memória korlátját célozza a fejlesztés

A vLLM szeptember 8-án ismertetett bejegyzése szerint a GLM 5.3 mérete miatt egy 8× H200-as csomóponton szűkös a GPU-memória, különösen akkor, amikor sok, hosszú és folyamatosan növekvő kontextusú kérés fut egyszerre. A vállalat szerint a Hybrid HiSparse korábban ezen a hardveren lehetetlennek számító, teljes 1 millió tokenes kontextushosszt tesz elérhetővé.

Az ügynöki munkafolyamatokban minden kérés egyre több gyorsítótárazott kulcs-érték adatot, vagyis KV-cache-t használ. Ha a GPU-blokkok közös készlete megtelik, két hagyományos megoldás áll rendelkezésre. Az elővétel törli egy kérés KV-cache-ét, amelyet később újra fel kell tölteni, az áthelyezés pedig a hostmemóriába másolja az adatokat. Utóbbi esetben azonban a sűrű figyelemmechanizmus miatt a teljes előzménynek vissza kell férnie a GPU-ra.

Csak a fontos tokenek maradnak a gyorsítón

A GLM 5.3 sparse MLA mechanizmusa egy indexelő segítségével kiválasztja a legfontosabb tokeneket, és csak ezekre figyel. A HiSparse ezt használja ki: a kiválasztott tokenek kivételével a KV-cache CPU-memóriába kerülhet. Az indexelő KV-cache-e a GPU-n marad, de a vLLM szerint lényegesen kisebb, ráadásul a GLM 5.3 IndexShare megoldása miatt négy sparse MLA rétegenként csak egy indexelőrétegre van szükség.

A Hybrid HiSparse elsőként teljes GPU-s jelenlétet használ. Csak akkor kezd lapokat áthelyezni, amikor a KV-cache számára szűkül a hely. A kérés legújabb része a GPU-n marad, míg a régebbi lapokból az indexelő által kért sorok úgynevezett gyorspufferekbe kerülnek. Így a rendszer csak a ténylegesen felhasznált adatokat tölti vissza, és a kérés részleges GPU-jelenlét mellett is folytathatja a dekódolást.

A gyorspufferek ugyanabból a blokk-készletből és ugyanabban a KV-cache tenzorban kapnak helyet, mint a GPU-n maradó adatok. A vLLM Hybrid Memory Allocator rendszere a kapacitást megosztja a kérések között. A fejlesztők szerint ez csökkenti a CPU és GPU közötti másolások költségét, mivel az áthelyezés csak memóriahiány esetén válik szükségessé.

GLM 5.3 benchmark OpenHands terheléssel

A vLLM a módszert 8× H200 GPU-n, OpenHands többfordulós ügynöki munkaterheléssel mérte. A teszt 13 fordulós beszélgetéseket használt, az első forduló 74 160 tokenes, a későbbi fordulók 753 tokenesek, a kimenetek pedig rögzítetten 220 tokenesek voltak.

Mindkét, nyolcutas tenzorparhuzamosítású telepítés MTP3-at, FP8 KV-cache-t, 142K-s beléptetési korlátot, 32 768-as max_num_batched_tokens értéket, 256-os max_num_seqs értéket és 0,92-es gpu_memory_utilization beállítást használt. A hagyományos áthelyezési teszt 512 GiB-os hostmemória-készlettel futott. A Hybrid HiSparse ugyanekkora keretet osztott fel, 384 GiB-ot a HiSparse számára, 128 GiB-ot pedig az áthelyezéshez.

A vLLM szerint a mérések alapján a Hybrid HiSparse nagyobb párhuzamosságot tesz lehetővé a vizsgált kontextushosszokon. A pontos eredmények és az összehasonlító grafikon a forrás bejegyzésében, a reprodukciós függelékben találhatók.

A széles körű elérhetőség még várat magára

A Hybrid HiSparse a vLLM közös memóriakészletére épül, miközben a többi gyorsítótárcsoport továbbra is használhatja a megszokott prefix-gyorsítótárazást, adatátvitelt és áthelyezést. A fejlesztés támogatja a spekulatív dekódolást, a prefixek párhuzamos és szétválasztott feldolgozásból érkező importját, valamint az indexelő KV-cache-ének külön kezelését.

A vLLM azt tervezi, hogy a Hybrid HiSparse széles körben elérhetővé válik a v0.30-as kiadásban. Addig a fejlesztők a bejegyzésben közzétett indítási parancsokkal és benchmarkbeállításokkal reprodukálhatják a bemutatott eredményeket. A felhasználók számára a technika elsősorban azt jelentheti, hogy hosszú kontextusú, párhuzamos ügynöki terheléseknél több kérés futhat egyidejűleg ugyanazon GPU-kapacitás mellett.