A legjobb felhőalapú GPU-k nagy nyelvi modellek kiszolgálásához és telepítéséhez
Nagy nyelvi modellek éles környezetben történő kiszolgálásához olyan GPU-k szükségesek, amelyek elegendő VRAM-mal rendelkeznek a modell súlyainak tárolásához, gyors memória-sávszélességgel a token generáláshoz, valamint olyan infrastruktúrával, amely támogatja az automatikus skálázást. Az olyan keretrendszerek, mint a vLLM, a TGI és a TensorRT-LLM gyakran használatosak az LLM inferencia áteresztőképességének optimalizálására. Ez az útmutató felsorolja azokat a felhőalapú GPU-szolgáltatókat, amelyek jól alkalmasak az LLM-ek nagy léptékű hosztolására és kiszolgálására.
Ehhez az útmutatóhoz még nem találhatók megfelelő GPU szolgáltatók. Kérjük, térjen vissza később.
Mit követel meg valójában az LLM szolgáltatás egy bérelt GPU-tól
Egy nagy nyelvi modell kiszolgálása alapvetően eltérő feladat, mint annak betanítása. A betanítás áteresztőképesség-korlátozott és tolerálja a késleltetést; a kiszolgálás viszont késleltetés-érzékeny, memória-korlátozott és szakaszos. Amikor egy GPU-t bérel, hogy egy LLM-et API mögé telepítsen, a szűk keresztmetszet ritkán a nyers FLOPS. Sokkal inkább az számít, hogy mennyi modellt és annak KV cache-jét tudja a VRAM-ban tartani, milyen gyorsan tud az a memória adatot továbbítani, és hány párhuzamos kérést tud egy csomagba rendezni, mielőtt az egy felhasználóra jutó másodpercenkénti tokenek száma összeomlik.
A KV cache az a rész, amit a legtöbben alulbecsülnek. Minden aktív kérés tárolja a figyelem kulcsait és értékeit a kontextusához, és ez a memóriafoglalás a szekvencia hosszával és a párhuzamos felhasználók számával nő. Egy modell, amely nyugalmi állapotban kényelmesen elfér, kifogyhat a memóriából, amint valódi forgalmat indít hosszú promptokkal. Ezért van az, hogy a kiszolgáló telepítések gyakran több VRAM-t igényelnek, mint amit csak a modell súlyai jeleznének.
Hogyan méretezzük a GPU-t a modellhez
Az első gyakorlati kérdés, hogy a modell elfér-e egyetlen GPU-n, vagy többre kell osztani. Az előző összehasonlítást figyelembe véve a modelljével kapcsolatban mérlegelje a következő tényezőket:
- A VRAM kapacitása határozza meg, mely modellek férnek el. Egy kvantált 7B–13B modell FP8 vagy INT8 formátumban egyetlen középkategóriás gyorsítóról kiszolgálható, míg egy 70B modell BF16-ben általában nagy memóriájú kártyát vagy több GPU-s csomópontot igényel. A nagyon nagy, élvonalbeli modellek gyakorlatilag több csúcskategóriás GPU összekapcsolását követelik meg.
- A memória sávszélessége határozza meg a token generálás sebességét. Az autoregresszív dekódolás minden generált tokenhez az összes súlyt olvassa, ezért a HBM-osztályú memória (amely adatközponti kártyákon található) sokkal gyorsabban generál tokeneket, mint a GDDR-alapú fogyasztói kártyák ugyanazon modellméret mellett. Interaktív csevegésnél a sávszélesség gyakran fontosabb, mint a számítási teljesítmény.
- A támogatott precizitások határozzák meg, mennyire lehet agresszíven tömöríteni a modellt. Az FP8 és INT8 tensor támogatással rendelkező kártyák lehetővé teszik nagyobb modellek kiszolgálását kevesebb VRAM-mal és nagyobb áteresztőképességgel, feltéve, hogy a kiszolgáló rendszer és a modell kvantálási sémája kompatibilisek.
- Az összeköttetés számít, ha a modell több GPU-t fed le. A tensor-párhuzamos kiszolgálás minden rétegen adatokat cserél a GPU-k között, ezért az NVLink-szintű kapcsolatok egy csomóponton belül lényegesen jobb késleltetést biztosítanak, mint a kizárólag PCIe-s konfigurációk. Egyetlen GPU-s telepítésnél az összeköttetés nem releváns.
Egy GPU-s vagy több GPU-s kiszolgálás
Ha a modell és a csúcs KV cache elfér egyetlen GPU-n, tartsa ott. Az egy GPU-s kiszolgálás teljesen elkerüli az eszközök közötti kommunikációs többletterhet, és egyszerűbb az üzemeltetése. Csak akkor térjen át tensor-párhuzamosságra vagy több csomópontos kiszolgálásra, ha a modell valóban nem fér el, mert minden hozzáadott GPU szinkronizációs költséget jelent és bonyolítja az automatikus skálázást. Ha több GPU-ra van szükség, előnyben részesítse azokat az előző listában szereplő példányokat, amelyek nagy memóriájú kártyákat párosítanak gyors csomóponton belüli összeköttetéssel, ahelyett, hogy lazán kapcsolt kártyákat fűzne össze.
Szolgáltatói jellemzők, amelyek a kiszolgálás szempontjából fontosak, nem a betanításnál
A szilíciumon túl a szolgáltató működési modellje határozza meg, hogy egy telepítés életképes-e. Amikor az előző összehasonlítást kiszolgálási munkaterhelésre nézi, nem betanításra, más szempontokat helyezzen előtérbe:
- Hidegindítási és beállítási idő elsőrendű fontosságúvá válik. Egy olyan kiszolgáló végpont, amely a forgalmi csúcsok között nullára skáláz, minden skálázáskor megfizeti a hidegindítási költséget, így a gyors előkészítés és képkészlet gyorsítótárazás közvetlenül befolyásolja a végső késleltetést.
- Számlázási részletesség megváltoztatja a szakaszos forgalom gazdaságosságát. A másodperces vagy perces számlázás alkalmas az automatikusan skálázódó végpontokhoz, amelyek példányokat indítanak és állítanak le; a durva, óránkénti számlázás bünteti ezt a mintát.
- Az igény szerinti megbízhatóság a spot helyett általában a helyes választás. Az megszakítható vagy spot példányok kiválóak betanításhoz és kötegelt feladatokhoz, de kockázatosak felhasználó felé irányuló végpontnál, ahol egy visszavonás kérés közben élő forgalmat szakíthat meg. A spot példányok továbbra is jól szolgálják a nem interaktív kötegelt inferenciát.
- Állandó tárolás és gyors modellbetöltés csökkenti az újraindítás okozta kellemetlenséget. Több gigabájtos súlyok, amelyek minden újraindításkor hideg objektumtárolóból töltődnek be, perceknyi leállást okoznak; a gyorsítótárazott vagy csatolt kötetek lerövidítik ezt.
- Hálózat és kimenő forgalom befolyásolja a költségeket nagy skálán. A nagy áteresztőképességű inferencia sok adatot mozgathat ki; ellenőrizze a kimenő forgalom feltételeit, mielőtt magas forgalmú telepítésbe kezd.
Kötegelt vagy valós idejű, és hol helyezkedik el a költség
Korán döntse el, melyik módot kívánja optimalizálni. A valós idejű interaktív kiszolgálás alacsony első tokenigénylési időt és stabil felhasználónkénti tokensebességet értékel, ami a nagy sávszélességű memóriát és mérsékelt kötegméretet támogatja. A kötegelt vagy offline inferencia a teljes áteresztőképességet értékeli, és nagy kötegeket tud olcsóbb vagy megszakítható hardverre pakolni, a kérésenkénti késleltetés feláldozásával jobb tokenenkénti költségért. Sok csapat mindkettőt futtatja: egy reagáló, igény szerinti réteget élő felhasználóknak, és egy spot-alapú kötegelt réteget tömeges generáláshoz.
A bérleti költségek tekintetében a kiszolgálás az egész spektrumon helyezkedik el. Egy kis kvantált modell egy középkategóriás kártyán olcsó és széles körben elérhető; az élvonalbeli modellek több GPU-s, nagy memóriájú csomópontokon ritkák, drágábbak és néha kapacitáskorlátosak a kereslet csúcsán. Mivel az árak folyamatosan változnak és régiónként, valamint elköteleződés szerint eltérnek, az előző élő összehasonlítást tekintse igaz forrásnak, ne pedig bármely fix számot, és az összehasonlításnál vegye figyelembe a VRAM-ot, a sávszélességi osztályt, az összeköttetést és a számlázási modellt együtt, ne csak a címárat.
Gyakran ismételt kérdések
Mennyi VRAM szükséges egy LLM kiszolgálásához?
Tervezze be a modell súlyait a választott precizitáson, valamint jelentős tartalékot a KV cache-nek, amely a kontextus hosszával és a párhuzamos felhasználók számával nő. Durva iránymutatásként a kvantált kis- és közepes méretű modellek egyetlen középkategóriás kártyáról kiszolgálhatók, míg a nagyobb, magasabb precizitású modellek nagy memóriájú kártyát vagy több GPU-t igényelnek. Mindig a csúcs párhuzamosságra méretezzen, ne a nyugalmi állapotra.
Alkalmasak-e spot vagy megszakítható GPU-k LLM kiszolgálásra?
Felhasználó felé irányuló valós idejű végpontokhoz általában nem, mert egy visszavonás élő kéréseket szakíthat meg és hideg újraindítást kényszeríthet. A spot példányok jól használhatók offline vagy kötegelt inferenciához, ahol a megszakítások csak a teljesítményt késleltetik, nem szakítják meg az interaktív munkamenetet. Sok csapat tart igény szerinti kapacitást élő forgalomra, és spotot használ tömeges feladatokra.
Miért számít jobban a memória sávszélessége, mint a számítási teljesítmény a kiszolgálásnál?
Tokenenkénti dekódolásnál a modell súlyait minden generált tokenhez a memóriából olvassa, így a generálási sebességet inkább a GPU memóriaátviteli sebessége korlátozza, mint a csúcsteljesítményű FLOPS. Ezért generálnak a HBM-mel felszerelt adatközponti kártyák gyorsabban tokeneket, mint a fogyasztói kártyák ugyanazon modellméret mellett, és ezért fontos összehasonlítási szempont a sávszélesség az előző táblázatban.
Egy GPU-n szolgáljak ki, vagy osszam többre?
Használjon egyetlen GPU-t, amikor a modell és a csúcs KV cache elfér, mert így elkerülhető az eszközök közötti kommunikáció és egyszerűbb a skálázás. Több GPU-s tensor-párhuzamosságra csak akkor térjen át, ha a modell valóban nem fér el, és akkor válasszon olyan példányokat, amelyek nagy memóriájú kártyákat gyors csomóponton belüli összeköttetéssel kombinálnak.