A Perplexity új GPU-s eljárása gyorsabbá teszi a keresést

A Perplexity részletesen bemutatta, hogyan szolgálják ki az embedding-modelleket a GPU-kon. Az Ivy, Tulip és ROSE nevű belső rendszereik nem különálló motorként működnek, hanem az LLM-ek előre- és utófeldolgozó kerneljeit használják. Ezáltal csökkentik a késleltetést és növelik a sebességet a keresési és rangsorolási feladatoknál.

A cég mérnökei szerint az embedding-inferencia a fejlett GPU-kon, mint a Hopper és Blackwell, már érett hardveren szinte egységes. A valódi előrelépés a futtatókörnyezetben és a modell körüli „szekérszabásban” rejlik: CUDA gráfok kezelése, aszinkron eredménykövetés és egy gyors Rust alapú kérésfeldolgozási útvonal. A Perplexity két fő forgalmi mintázatot különböztet meg: a vektoradatbázisok építésekor vagy újraindexelésekor fontos a nagy átviteli sebesség (batch embedding), míg lekérdezéskor az online embedding sebessége a kritikus.

A kulcsdöntés az volt, hogy a Perplexity nem épített külön embedding-motort. Mivel az embedding-modellek kicsi Transformer-modellek, a batch embedding a számításigényes előre- és utófeldolgozásra hasonlít, az online embedding pedig a memóriaigényes dekódolásra. Ezért a kutatócsapat az LLM-stack előre- és utófeldolgozó kerneljeit hasznosítja újra.

Az Ivy, Tulip és ROSE három szolgáltatás kezeli a kéréseket. Az Ivy egy Rust HTTP átjáró, amely az ügyféloldali feladatokat – JSON-elemzés, tokenizálás, bemeneti sablonozás, kötegelés felosztása – végzi, és a kéréseket egyedi gRPC protokollra fordítja. Emellett a nagy kötegeket kisebb darabokra osztja, és replikák között terheli, kiegyenlítve a méretbeli különbségekből adódó terhelés-egyensúlyhiányt.

A Tulip az inferenciaszerver interfésze, egy Rust, tokio és tonic nyelven írt gRPC szerver, amely az ütemezést és a kötegelést kezeli, mielőtt továbbítaná az adatokat az engine-nek. Az ROSE (Runtime-Optimized Serving Engine) végzi magát a modellinferenciát. Főként Pythonból áll, biztosítja a kerneleket, rétegeket és modelldefiníciókat, kezeli a CUDA gráfokat, és egy `step()` függvényt kínál a Tulip számára.

A scheduler szándékosan egyszerű: a Tulip a beérkezési sorrendben dolgozza fel a szekvenciákat, miközben a kérések gyűlnek. Ez az egyszerűség egy méréssel indokolható: kis embedding-modelleknél a Perplexity által kiszolgált szekvenciahosszakon a sűrű rétegek lineáris költsége dominálja a figyelmi mechanizmus kvadratikus költségét. A késleltetés ezért nagyjából a tokenek számával arányos, nem a szekvenciák számával. Amint egy köteg megtölti a GPU-t (körülbelül 512 token egy egymilliárd alatti paraméterű modellen), több szekvencia hozzáadása már nem növeli a hatékonyságot.

Kis kötegeken a CPU-oldali kernelindítás nagyobb súlyt kaphat, mint a GPU-s végrehajtás. A Perplexity minden embedding-modellhez egész-modell CUDA gráfokat épít, amelyek minden indítást egyetlen, optimalizált futtatásba rögzítenek. A „LazyTensor” pedig lehetővé teszi a CPU-oldali kötegelés átfedését a már futó GPU-s munkával, ahelyett, hogy szinkronizációra várna. Ezek a technikák drámaian csökkentik az indítási többletköltséget, kiküszöbölve a percekig tartó indítási időket.