A legjobb felhőalapú GPU-k következtetéshez és modellkiszolgáláshoz

Mit követel valójában az inferencia egy bérelt GPU-tól

Az inferencia a modell életciklusának kiszolgálási fázisa: a súlyok már ki vannak képezve, és minden alkalommal fizetni kell a számítási kapacitásért, amikor egy felhasználó promptot, képet vagy kérést küld. Ez teljesen megváltoztatja a hardveres számításokat a tanításhoz képest. A tanítás áteresztőképesség-korlátozott, és órákig vagy napokig fut sűrű klasztereken; az inferencia késleltetés-érzékeny, szakaszos, és végtelen ideig fut. Amikor GPU-t bérel egy modell kiszolgálására, akkor az elfogadható válaszidő mellett a tokenenkénti vagy kérésenkénti költséget optimalizálja, nem pedig a nyers FLOP-okat egy hosszú feladaton.

A legfontosabb korlát általában a memóriakapacitás, nem a számítási teljesítmény. A modellnek el kell férnie a VRAM-ban a kulcs-érték (KV) gyorsítótárral együtt, amely a batch méretével és a kontextus hosszával nő. Nagy nyelvi modellek esetén ez a domináns tényező: egy 16-bites modell súlyaihoz körülbelül két bájt kell paraméterenként, így egy közepes méretű modell kényelmesen elfér egy középkategóriás kártyán, míg egy élvonalbeli méretű modell több GPU-t igényelhet összekapcsolva. A fenti összehasonlítás lehetővé teszi, hogy pontosan VRAM szerint szűrjön, így kiválaszthatja a kártyát a legnagyobb kiszolgálandó modellhez plusz a párhuzamos kérésekhez szükséges tartalékhoz.

Azok a specifikációk, amelyek befolyásolják az inferencia költségét és késleltetését

• A VRAM kapacitás határozza meg, hogy a modell és a KV gyorsítótár elfér-e egy GPU-n vagy szét kell osztani. Ha a második GPU-ra vagy a gazdagép memóriájába kell áthelyezni, az növeli a késleltetést és a komplexitást.
• A memória sávszélessége az igazi szűk keresztmetszet a token generálásnál. Az autoregresszív dekódolás minden előállított tokenhez az összes súlyt beolvassa, így a magas sávszélességű memória (HBM-osztály) gyorsabban generál tokeneket, mint a GDDR-osztályú memória azonos számítási szinten.
• Az alacsony precizitás támogatása rendkívül fontos. Az FP8 vagy INT8 tensor utakkal rendelkező kártyák lehetővé teszik a modellek kvantálását, így több kérést tudnak kiszolgálni dolláronként minimális minőségromlással. Az 8-bites vagy 4-bites kvantálás csökkenti a memóriahasználatot is, gyakran lehetővé téve, hogy a modell olcsóbb kártyán is elférjen.
• Az összeköttetés (NVLink vs PCIe) csak akkor számít, ha a modell több GPU-t foglal magába. Egyetlen GPU-s kiszolgálásnál nem releváns; nagyon nagy modellek tensor-paralel kiszolgálásánál közvetlenül befolyásolja a token késleltetést.

Batch (offline) és valós idejű inferencia

Két nagyon eltérő kiszolgálási mintázat rejtőzik az “inferencia” szó alatt, és ezek különböző bérléseket igényelnek.

A valós idejű inferencia élő felhasználókat szolgál ki: chatbotot, API végpontot, webalkalmazás mögötti képgenerátort. Itt a végső késleltetés számít, a GPU-k gyakran részben tétlenek a forgalomra várva, és nem tolerálható, hogy egy példányt félúton elvegyenek a kérés feldolgozása közben. Ez a minta az igény szerinti, mindig elérhető kapacitást és egy erős memória sávszélességű kártyát részesíti előnyben, hogy a kérésenkénti késleltetés alacsony maradjon még kis batch méretek mellett is.

A batch vagy offline inferencia egy nagy feladatot dolgoz fel: adatbázis pontozása, korpusz beágyazások generálása, egymillió kép feliratozása. Nincsenek élő felhasználók, így az egyes elemek késleltetése alig számít, és nagy batch-eket lehet csomagolni a GPU telítettségéhez. Ez a minta ideális jelölt megszakítható vagy spot kapacitásra, mert ha egy példányt visszavesznek, egyszerűen folytathatja a sort. Amikor a fenti listát olvassa, először döntse el, melyik mintázatban van, mert ez megváltoztatja, melyik számlázási modell és elérhetőségi szint ésszerű.

Miért fontosabb az áteresztőképesség és kihasználtság a csúcsteljesítménynél

Egy kártya, amely papíron kétszer olyan erősnek tűnik, ritkán csökkenti az inferencia számlát a felére. A dekódolás memória-korlátozott, így a GPU hirdetett csúcsteljesítménye gyakran alulhasznált a generálás során. Amit valójában fizet, az a hatékony tokenek másodpercenként dolláronként a valós batch méretek és kontextus hosszok mellett. A modern kiszolgáló rendszerek sok kihasználatlan kapacitást visszanyernek folyamatos batch-eléssel, lapozott KV gyorsítótárral és kvantálással. A gyakorlati tanulság bérléskor: egy középkategóriás GPU optimalizált szerverrel legyőzheti egy csúcskategóriás kártyát optimalizálatlan szerverrel, és egy kisebb, olcsóbb kártya, amely még elfér a modelljén, gyakran költséghatékonyabb a folyamatos forgalomhoz.

Szolgáltató jellemzői, amelyek kifejezetten a kiszolgálás szempontjából fontosak

Az inferencia folyamatosan fut, ezért a környező platformfunkciók nagyobb súllyal esnek latba, mint egy egyszeri tanítási feladatnál. Az opciók összehasonlításakor ellenőrizze ezeket a szempontokat:

• Számlázás részletessége: másodperc- vagy percpontos számlázás jutalmazza a szakaszos, nullára skálázódó kiszolgálást; a durva óránkénti számlázás bünteti azokat a végpontokat, amelyek forgalmi csúcsok között tétlenek maradnak.
• Hidegindítás és előkészítés sebessége: ha a példányokat a kereslethez igazítva skálázza fel és le, az új GPU példány készenléti ideje közvetlenül befolyásolja a felhasználói késleltetést és az automatikus skálázás képességét.
• Állandó tárolás és képtárolás: a nagy modell súlyok minden indításkor történő lehúzása lassú és néha mérve van. A gyorsított képek vagy csatolt kötetek, amelyek tárolják a súlyokat, drasztikusan csökkentik a hidegindításokat.
• Kimenő adatdíjak: a kiszolgálás folyamatosan küldi vissza az eredményeket a felhasználóknak. A gigabájtonkénti kimenő díj, amely a tanításnál láthatatlan, magas forgalmú API-knál valós költségtétel lehet.
• Igény szerinti megbízhatóság vs spot árképzés: a valós idejű végpontok általában garantált igény szerinti kapacitást igényelnek; a batch feladatok olcsóbb megszakítható példányokat kereshetnek.
• Automatikus skálázás és szerver nélküli opciók: a nullára skálázódás fontos, ha a forgalom hullámzó, így nem fizet egy tétlen GPU-ért éjszaka.

Hogyan olvassa a fenti összehasonlítást inferencia esetén

Ebben a sorrendben dolgozzon. Először azonosítsa a legnagyobb modellt, amelyet ki kell szolgálnia, és győződjön meg róla, hogy a kártyának van elég VRAM-ja a súlyokhoz és a KV gyorsítótárhoz a várt párhuzamosság mellett. Másodszor, részesítse előnyben a magas memória sávszélességet és az alacsony precizitású (FP8/INT8) támogatást a tokenek másodpercenkénti dolláronkénti maximalizálásához. Harmadszor, igazítsa a számlázási és elérhetőségi modellt a mintázathoz: igény szerinti, finom számlázás élő végpontokhoz, megszakítható kapacitás offline batch munkához. Használja az élő táblázatot a jelenlegi árakhoz, mivel az óradíjak a kereslet és a hiány miatt változnak, szolgáltatónként eltérnek; az állandó szabály, hogy a legolcsóbb kártya, amely kényelmesen elfér a modelljén és forgalmán, szinte mindig nyer, nem a legerősebb elérhető.

Gyakran ismételt kérdések

Mennyi GPU memória szükséges egy modell inferenciához való kiszolgálásához?

Számoljon a modell súlyokkal és a kulcs-érték gyorsítótárral. 16-bites módban a súlyokhoz körülbelül két bájt kell paraméterenként, és az 8-bites vagy 4-bites kvantálás ezt jelentősen csökkenti. Ezután adjon hozzá tartalékot a KV gyorsítótárhoz, amely a batch méretével és a kontextus hosszával nő. Szűrje a fenti listát VRAM szerint, és válasszon olyan kártyát, amely elfér a modell és még marad is hely, hogy a párhuzamos kérések ne lépjék túl a memóriát.

Elég egy olcsóbb GPU inferenciához, vagy szükség van csúcskategóriás kártyára?

Sok kiszolgálási munkaterheléshez egy középkategóriás kártya jobb ár-érték arányú. A token generálás memória sávszélességhez kötött, nem a csúcsteljesítményhez, így a csúcskategóriás FLOP-ok gyakran alulhasználtak. Ha a modell elfér egy kisebb kártya VRAM-jában, és egy optimalizált kiszolgáló rendszer leköti a GPU-t, általában jobb tokenenkénti költséget ér el, mint a legdrágább opció bérlése.

Használjak spot vagy megszakítható példányokat inferenciához?

Ez a mintázattól függ. Az offline batch inferencia jól tolerálja a megszakításokat, mert folytathatja a sort, így az olcsóbb spot kapacitás vonzó. A valós idejű, felhasználó felé néző végpontok általában garantált igény szerinti kapacitást igényelnek, mert ha egy példányt visszavesznek a kérés feldolgozása közben, az hibákat okoz és megszakítja a késleltetési garanciákat.

Miben különbözik az inferencia számlázása a tanítás számlázásától?

A tanítás egy véges, áteresztőképesség-korlátozott feladat, míg az inferencia folyamatosan fut, és gyakran tétlen a forgalmi csúcsok között. Ezért a másodperces számlázás, a gyors előkészítés, a nullára skálázódás és a kiszámítható kimenő költségek sokkal fontosabbak a kiszolgálásnál, mint egy egyszeri tanítási futtatásnál. Ezeket a platformfunkciókat is mérlegelje a fenti összehasonlításban a nyers óradíj mellett.