Mi történik egy inferencia során
Amikor a modell választ ad, a folyamat két élesen elkülönülő fázisra bomlik. Az első a prefill, amelyben a modell egyszerre, párhuzamosan dolgozza fel a teljes bemenetet, tehát a rendszerutasítást, a visszakeresett dokumentumokat és a felhasználó kérdését. A második a dekódolás (decode), amelyben a modell egyesével, egymás után állítja elő a kimeneti tokeneket, és minden új token az összes eddigit felhasználja. A két fázis erőforrásigénye eltér. A prefill jól párhuzamosítható és a számítási kapacitást terheli, a dekódolás viszont soros természetű és jellemzően a memória sávszélessége korlátozza, mert lépésenként az egész modellt végig kell olvasni egyetlen token előállításához. Ezért egy hosszú válasz dekódolása arányosan sokkal drágább időben, mint egy hosszú bemenet feldolgozása, és ezért különül el a bemeneti és a kimeneti token ára is a legtöbb szolgáltatónál.
A késleltetés mérőszámai és a streaming
Ahhoz, hogy a sebességet optimalizáld, előbb pontosan mérned kell. Három mérőszám a fontos. Az első az idő az első tokenig (time to first token), amit főként a prefill hossza és a modell mérete határoz meg. A második a tokenek közötti idő, tehát a dekódolás üteme. A harmadik a teljes válaszidő, amely a kettőből és a válasz hosszából adódik. A legolcsóbb sebességnyereség sokszor nem a tényleges gyorsítás, hanem a streaming, vagyis hogy a kész tokeneket azonnal, folyamatosan küldöd a felhasználónak, ahogy elkészülnek. A teljes válaszidő nem lesz kisebb, de az érzékelt késleltetés drámaian javul, mert a felhasználó az első szavakat szinte azonnal látja ahelyett, hogy a teljes válaszra várna. Interaktív felületnél a streaming szinte mindig megéri, és semmilyen minőségi kompromisszummal nem jár.
Gyorsítótárak, a KV cache és a prompt gyorsítótár
Két különböző gyorsítótár segít, és fontos nem összekeverni őket. A KV gyorsítótár (key-value cache) egyetlen válasz generálásán belül működik. A dekódolás minden lépésében a modellnek szüksége van a korábbi tokenekhez tartozó belső kulcs és érték vektorokra, és ahelyett hogy ezeket minden lépésben újraszámolná, egyszer kiszámítja és eltárolja őket. Ez teszi egyáltalán gyakorlativá a dekódolást, cserébe viszont memóriát fogyaszt, ami a szöveg hosszával nő, és éppen ez a KV cache a hosszú beszélgetések egyik legfőbb memóriakorlátja. A prompt gyorsítótárazás (prompt caching) ezzel szemben kérések között működik. Ha sok kérés eleje azonos, például ugyanaz a hosszú rendszerutasítás és példakészlet, akkor a szolgáltató ezt a stabil előtagot egyszer feldolgozza és eltárolja, a következő kéréseknél pedig újrahasznosítja. Ez csökkenti az első tokenig eltelt időt és a bemeneti költséget is, feltéve hogy az előtag valóban változatlan. Ha a prompt elején bármi kérésenként változik, például időbélyeg, a gyorsítótár sosem talál, ezért a stabil részt előre, a változót hátra kell tenni.
- StreamingA kész tokeneket azonnal küldöd, így az érzékelt késleltetés csökken minőségvesztés nélkül.
- Prompt gyorsítótárA stabil promptelőtagot előre teszed, hogy kérések között újrahasznosuljon.
- BatchelésTöbb kérést egyszerre dolgozol fel a jobb átbocsátásért, a késleltetés árán.
- KvantálásKisebb súlypontosság kevesebb memóriáért és gyorsabb futásért, enyhe minőségkockázattal.
- ModellútválasztásOlcsó modell először, drágább csak ott, ahol a feladat tényleg megköveteli.
Batchelés, a késleltetés és az átbocsátás cseréje
A GPU akkor gazdaságos, ha jól ki van használva, és egyetlen kérés dekódolása jellemzően nem tölti ki a kapacitását. A batchelés (batching) több kérés együttes feldolgozása, ami sokkal jobb átbocsátást (throughput) ad ugyanazon a hardveren, tehát olcsóbb kérésenkénti költséget. A folytonos batchelés (continuous batching) ennek a fejlett változata, amely nem várja meg, míg egy teljes köteg elkészül, hanem futás közben csúsztat be új kéréseket a felszabaduló helyekre. A batchelésnek azonban ára van, mert az együtt feldolgozott kérések osztoznak az erőforráson, így egyenként lassabbak lehetnek. Itt egy alapvető cserét kell tudatosan meghozni. Ha a cél az alacsony késleltetés, kevésbé batchelsz, ha a cél az olcsó tömeges feldolgozás, erősebben. Egy interaktív asszisztens és egy éjszakai kötegelt feldolgozás ezért teljesen eltérő beállítást kíván ugyanabból a modellből.
Kvantálás, spekulatív dekódolás és a modell mérete
A modell oldalán három eszköz csökkenti a költséget. A kvantálás (quantization) a modell súlyait kisebb számábrázolással tárolja, például egész számos, alacsonyabb bites formában a lebegőpontos helyett. Ettől a modell kevesebb memóriát foglal és gyorsabban fut, cserébe kismértékű minőségromlás léphet fel, amit evallal kell ellenőrizni, mert feladatonként eltér. A spekulatív dekódolás (speculative decoding) egy kis, gyors modellel több tokent előre megtippeltet, majd a nagy modellel egyszerre ellenőrizteti őket. Ahol a tipp helyes, ott lépéseket spórolsz, és mivel a nagy modell a végső bíró, a kimenet minősége elvben nem romlik. Végül a modell mérete önmagában is döntés. Egy nagyobb modellről egy kisebbre való desztilláció (distillation), tehát a tudás átadása egy kisebb, gyorsabb modellnek, sok szűk feladatnál összemérhető minőséget ad töredék költségen. A visszatérő elv mindegyiknél ugyanaz. Előbb mérj, azonosítsd a valódi szűk keresztmetszetet, és csak azt optimalizáld, mert a rossz helyen végzett gyorsítás időt és minőséget veszít eredmény nélkül.
Mérj, mielőtt gyorsítasz. A prefill és a dekódolás más okból lassú, ezért más eszközzel gyorsítható. Ha az első tokenig tartó idő a baj, a prompt hosszán és a gyorsítótárazáson dolgozz. Ha a dekódolás lassú, a modell méretén, a kvantáláson vagy a spekulatív dekódoláson. Ha a kérésenkénti költség a baj, a batchelésen és a modellválasztáson. A vaktában végzett optimalizálás a leggyakoribb hiba.
Workshop
AI Transformation Day
Egésznapos, vezetőknek szóló program. Feltérképezzük, hol tart a szervezet, mi az első reális lépés, és milyen belső feltételek szükségesek a sikerhez. A nap végén konkrét, prioritizált cselekvési lista.
Érdekel a program →