Nejlepší cloudové GPU pro nasazení a provoz velkých jazykových modelů

Co vlastně vyžaduje provozování LLM od pronajaté GPU

Provozování velkého jazykového modelu je zásadně odlišná úloha než jeho trénování. Trénování je omezeno propustností a je tolerantní k latenci; provozování je citlivé na latenci, omezené pamětí a nepravidelné. Když si pronajmete GPU pro nasazení LLM za API, úzkým hrdlem zřídka bývají samotné FLOPS. Je to, kolik modelu a jeho KV cache můžete držet ve VRAM, jak rychle tato paměť přenáší data a kolik současných požadavků můžete zpracovat v dávce, než se počet tokenů za sekundu na uživatele zhroutí.

KV cache je část, kterou většina lidí podceňuje. Každý aktivní požadavek ukládá klíče a hodnoty pozornosti pro svůj kontext a tato stopa roste s délkou sekvence a počtem současných uživatelů. Model, který se v klidu pohodlně vejde do paměti, může při reálném provozu s dlouhými výzvami rychle vyčerpat paměť. Proto nasazení pro provoz často potřebují více VRAM, než by naznačovala samotná váha modelu.

Jak dimenzovat GPU podle modelu

Praktickou první otázkou je, zda se model vejde na jednu GPU, nebo je třeba jej rozdělit na několik. Při porovnávání výše uvedeného s vaším modelem zvažte tyto faktory:

• Kapacita VRAM určuje, které modely se vejdou. Kvantovaný model 7B–13B v FP8 nebo INT8 lze provozovat na jednom středně výkonném akcelerátoru, zatímco model 70B v BF16 obvykle vyžaduje kartu s vysokou pamětí nebo více GPU v uzlu. Velmi velké modely z frontové třídy prakticky vyžadují několik špičkových GPU propojených dohromady.
• Šířka pásma paměti určuje rychlost generování tokenů. Autoregresivní dekódování čte celý soubor vah pro každý generovaný token, takže paměť třídy HBM (jaká je na datových centrech) generuje tokeny výrazně rychleji než spotřebitelské karty s GDDR při stejné velikosti modelu. Pro interaktivní chat často šířka pásma paměti hraje větší roli než výpočetní výkon.
• Podporované přesnosti určují, jak agresivně můžete model zmenšit. Karty s podporou tensorů FP8 a INT8 umožňují provozovat větší modely na méně VRAM a s vyšší propustností, pokud je váš provozní stack a kvantizační schéma modelu kompatibilní.
• Propojení je důležité, pokud model přesahuje více GPU. Provoz tensorově paralelního modelu vyměňuje aktivace mezi GPU na každé vrstvě, takže propojení třídy NVLink uvnitř uzlu poskytuje výrazně lepší latenci než konfigurace pouze s PCIe. Pro nasazení na jedné GPU je propojení irelevantní.

Provoz na jedné GPU versus více GPU

Pokud se váš model a jeho maximální KV cache vejdou na jednu GPU, ponechte jej tam. Provoz na jedné GPU zcela eliminuje režii komunikace mezi zařízeními a je jednodušší na provoz. Přecházejte na tensorovou paralelnost nebo provoz na více uzlech pouze tehdy, když se model skutečně nevejde, protože každá přidaná GPU zvyšuje náklady na synchronizaci a komplikuje automatické škálování. Když potřebujete více GPU, preferujte instance z výše uvedeného seznamu, které kombinují karty s vysokou pamětí a rychlé propojení uvnitř uzlu, místo skládání volně spojených karet.

Funkce poskytovatele, které jsou důležité pro provoz, nikoli pro trénink

Kromě hardwaru rozhoduje o životaschopnosti nasazení provozní model poskytovatele. Při hodnocení výše uvedeného porovnání pro provozní zátěž místo tréninku upřednostňujte jinak:

• Doba studeného startu a nastavení se stává prvořadou záležitostí. Provozní endpoint, který škáluje na nulu mezi špičkami provozu, platí cenu studeného startu při každém škálování nahoru, takže rychlá příprava a ukládání obrazu přímo ovlivňují latenci na konci.
• Granularita účtování mění ekonomiku nepravidelného provozu. Účtování po sekundách nebo minutách vyhovuje autoskalovacím endpointům, které spouštějí a vypínají instance; hrubé hodinové účtování tento režim penalizuje.
• Spolehlivost na vyžádání oproti spot je obvykle správná volba. Přerušitelné nebo spot instance jsou výborné pro trénink a dávkové úlohy, ale rizikové pro uživatelsky orientované endpointy, kde přerušení během požadavku znamená ztrátu živého provozu. Spot instance však stále dobře slouží pro neinteraktivní dávkové inferování.
• Trvalé úložiště a rychlé načítání modelu snižují bolest při restartu. Vícegigabajtové váhy, které se při každém restartu načítají z chladného objektového úložiště, přidávají minuty výpadku; cacheované nebo připojené svazky to zkracují.
• Síťování a odchozí provoz ovlivňují náklady ve velkém měřítku. Výkonný inferenční provoz může přenášet velké objemy dat ven; před závazkem k nasazení s vysokým provozem zkontrolujte podmínky odchozího provozu.

Dávkové versus reálné časové zpracování a kde jsou náklady

Rozhodněte se brzy, pro který režim optimalizujete. Reálný čas interaktivního provozu klade důraz na nízký čas do prvního tokenu a stabilní rychlost tokenů na uživatele, což preferuje paměť s vysokou šířkou pásma a skromné velikosti dávek. Dávkové nebo offline inferování klade důraz na celkovou propustnost a může zabalit velké dávky na levnější nebo přerušitelné hardwarové prostředky, obětujíc latenci na požadavek za výrazně lepší cenu za token. Mnoho týmů provozuje oba režimy: responzivní on-demand vrstvu pro živé uživatele a dávkovou vrstvu na spot instancích pro hromadnou generaci.

Co se týče nákladů na pronájem, provoz se pohybuje napříč celým spektrem. Malý kvantovaný model na středně výkonné kartě je levný a široce dostupný; frontové modely na více GPU s vysokou pamětí jsou vzácné, dražší a někdy kapacitně omezené během špiček poptávky. Protože sazby se neustále mění a liší podle regionu a závazků, považujte výše uvedené živé porovnání za zdroj pravdy spíše než jakékoli pevné číslo a porovnávejte instance podle VRAM, třídy šířky pásma, propojení a modelu účtování společně, nikoli jen podle ceny v titulku.

Často kladené otázky

Kolik VRAM potřebuji pro provoz LLM?

Počítejte s váhami modelu ve zvolené přesnosti plus značnou rezervou pro KV cache, která roste s délkou kontextu a počtem současných uživatelů. Orientačně kvantované malé a střední modely lze provozovat na jedné středně výkonné kartě, zatímco velké modely ve vyšší přesnosti potřebují kartu s vysokou pamětí nebo několik GPU. Vždy dimenzujte podle špičkové současnosti, nikoli klidového stavu.

Jsou spot nebo přerušitelné GPU vhodné pro provoz LLM?

Pro uživatelsky orientované reálné časové endpointy obecně ne, protože přerušení může způsobit ztrátu živých požadavků a nutnost studených restartů. Spot instance jsou vhodné pro offline nebo dávkové inferování, kde přerušení pouze zpomalí propustnost, aniž by přerušilo interaktivní relaci. Mnoho týmů drží kapacitu na vyžádání pro živý provoz a používá spot pro hromadné úlohy.

Proč je šířka pásma paměti důležitější než výpočetní výkon pro provoz?

Dekódování token po tokenu čte váhy modelu z paměti pro každý generovaný token, takže rychlost generování je omezena rychlostí přenosu paměti GPU, nikoli jeho maximálním FLOPS. Proto karty s pamětí HBM v datových centrech generují tokeny rychleji než spotřebitelské karty se stejným modelem a proto je šířka pásma klíčovým parametrem pro porovnání výše.

Mám provozovat na jedné GPU, nebo rozdělit na několik?

Použijte jednu GPU vždy, když se model a jeho maximální KV cache vejdou, protože tím eliminujete komunikaci mezi zařízeními a zjednodušíte škálování. Přecházejte na více GPU s tensorovou paralelností pouze tehdy, když se model skutečně nevejde, a v takovém případě vybírejte instance, které kombinují karty s vysokou pamětí a rychlé propojení uvnitř uzlu.