Průvodce velikostí Lenovo LLM
Plánování / realizace

Komplexní rámec velikosti LLM

Velké jazykové modely (LLM) způsobily revoluci v oblasti zpracování přirozeného jazyka a umožnily aplikace, jako je generování textu, analýza sentimentu a překlad jazyka. Výpočetní požadavky na provoz těchto modelů však mohou být značné, takže pro architekty řešení je náročné navrhnout a nakonfigurovat systémy, které splňují potřeby jejich zákazníků.
K vyřešení tohoto problému je tento průvodce dimenzováním LLM navržen tak, aby vám poskytl komplexní pochopení toho, jak LLM fungují, jejich výpočetní požadavky a klíčové faktory, které ovlivňují jejich výkon. Cílem této příručky je vybavit vás znalostmi a nástroji potřebnými k posouzení požadavků zákazníků, navrhování schopných systémů a rychlé a přesné realizaci úspěšných nasazení LLM.

Průvodce, inspirovaný z NVIDIA LLM Inference Sizing, bude pokrývat zásadní témata, jako je základní pravidlo pro odhadování požadavků na paměť GPU pro odvození a školení/jemné ladění, shromažďování požadavků od zákazníků, pochopení benchmarků a metrik výkonu a odhad celkových nákladů na vlastnictví. Podle tohoto průvodce se budete moci orientovat ve složitém prostředí LLM a poskytovat jejich zákazníkům optimalizovaná řešení, která splňují jejich specifické potřeby.
V této příručce poskytneme praktické příkladyampsoubory, vzorce a pokyny, které pomohou architektům řešení odhadnout výpočetní požadavky pro různé scénáře LLM. Budeme také diskutovat o důležitosti porozumění požadavkům zákazníků, jako je model, kvantizace, velikost tokenu a požadavky na latenci, a jak tyto faktory ovlivňují návrh a výkon systému.
V další části představíme „Rule of Thumb“ pro odhadování požadavků na paměť GPU, počínaje odvozením. To vám poskytne jednoduchý a efektivní způsob, jak odhadnout minimální potřebu paměti GPU pro provoz LLM v produkčním prostředí.

Pravidlo palce

Rule of Thumb poskytuje zjednodušený přístup k odhadu výpočetních požadavků pro provozování velkých jazykových modelů (LLM). Tato část popisuje klíčové faktory, které ovlivňují požadavky na paměť GPU, a poskytuje vzorce pro rychlý odhad minimální potřeby paměti pro odvození a jemné ladění/trénink.

Vyvozování závěrů
Odvozování odkazuje na proces použití vyškoleného LLM ke generování textu nebo předpovědi nových, neviditelných dat. Můžeme odhadnout minimální požadavky na paměť GPU pro odvození použijte následující vzorec:
M = P*Z* 1.2

Kde:

• M = paměť GPU vyjádřená v gigabajtech
• P = Velikost modelu (parametru) v miliardách
• Z = kvantizační faktor v bytech (1 byte = 8 bitů) – viz níže
• 1.2 = Představuje 20% režii pro načítání dalších dat do paměti GPU

Kvantizační faktor Z se liší v závislosti na použité přesnosti:

• INT4: = 0.5
• FP8/INT8: = 1
• FP16: = 2
• FP32: = 4

Napřample, abychom odhadli minimální požadavky na paměť GPU pro spuštění Llama 3.1 se 70 miliardami parametrů při 16bitové kvantizaci (FP16), můžeme zapojit hodnoty následovně:
M = 70 ∗ 2 ∗ 1.2 = 168 GB

Tento vzorec poskytuje rychlý a jednoduchý způsob, jak odhadnout minimální požadavky na paměť GPU pro odvození, což umožňuje architektům řešení navrhovat systémy, které splňují potřeby jejich zákazníků.

Jemné ladění/školení
Jemné doladění nebo školení velkého jazykového modelu (LLM) vyžaduje podstatně více výpočetních zdrojů než odvození. Minimální požadavky na paměť GPU pro jemné doladění/trénink lze odhadnout pomocí následujícího vzorce:
Celkem = (Z + 12 + Z) bajtů/parametr = P (2Z + 12) GB potřebné paměti
Kde:

• P = Velikost modelu (parametru) v miliardách
• Z = kvantizační faktor v bytech (1 bajt = 8 bitů)

Tento vzorec však poskytuje extrémní odhad, protože předpokládá, že úplné parametry modelu, stavy optimalizátoru a přechody jsou uloženy v paměti. V praxi techniky jako Low-Rank Adaptation (LoRA) a Quantized LoRA (QLORA) může výrazně snížit požadavky na paměť.
Pro lepší představu uvádíme některé odhadované požadavky na paměť GPU pro jemné doladění LLM pomocí různých metod a přesností:

Tabulka 1. Porovnání požadavků na VRAM pro různé velikosti modelů a techniky jemného ladění

Metoda	Přesnost	7B	13B	30B	70B	110B
Plný	16	67 GB	125 GB	288 GB	672 GB	1056 GB
LoRA	16	15 GB	28 GB	63 GB	146 GB	229 GB
QLoRA	8	9 GB	17 GB	38 GB	88 GB	138 GB
QLoRA	4	5 GB	9 GB	20 GB	46 GB	72 GB

Jak můžete vidět, použití LoRA nebo QLoRA může snížit požadavky na paměť o 75-90% ve srovnání s metodou úplného jemného doladění. Je to proto, že tyto techniky ukládají pouze přizpůsobené parametry a nikoli celý model, což má za následek značné úspory paměti.
Při navrhování systémů pro jemné ladění/trénink LLM je důležité zvážit konkrétní použitou metodu a přesnost a také velikost modelu, aby bylo zajištěno, že systém splňuje požadované výpočetní zdroje. Pomocí technik jako LoRA nebo QLoRA mohou architekti řešení navrhovat efektivnější a nákladově efektivnější systémy, které splňují potřeby jejich zákazníků.

Požadavky na sběr

Aby bylo možné přesně určit nezbytnou konfiguraci systému pro nasazení velkého jazykového modelu (LLM), je důležité získat od zákazníka konkrétní požadavky. Tyto požadavky pomohou odhadnout výkon odvození a zajistí, že systém splní požadované cíle.

Před odhadem výkonu odvození je třeba shromáždit následujících pět informací:
1. Výběr modelu:
Identifikujte model LLM určený pro použití v tomto projektu. Velikost modelu výrazně ovlivňuje výkon odvození, přičemž větší modely jsou pomalejší a dražší. Všimněte si, že menší modely mohou mít vynikající kvalitu pro konkrétní úlohy a zároveň snížit náklady na odvození. Proto se doporučuje prozkoumat i menší modely. Pochopení charakteristik zvoleného modelu pomůže při odhadu požadovaných výpočetních zdrojů.
Při shromažďování požadavků na případ použití LLM je důležité vzít v úvahu délku vstupního tokenu, která je jedním z faktorů při určování výkonu modelu. Kontextové okno, definované jako součet vstupních a výstupních tokenů, hraje v tomto procesu podstatnou roli. Nové modely, jako je Llama 3.1, podporují větší kontextová okna až do 128,000 XNUMX tokenů.

2. Vstupní tokeny:
Určete průměrný počet tokenů ve výzvě k LLM, včetně:

• Systémová výzva
• Kontext
• Uživatelská výzva

U modelů v angličtině je jeden token přibližně 0.75 slova. Zahrnutí systémových výzev a kontextu do počtu tokenů zajistí, že se při odhadování výkonu vezme v úvahu celá vstupní sekvence.
Chcete-li přesně vypočítat počet vstupních tokenů, zahrňte všechny prvky, které k němu přispívají, jako jsou systémové výzvy (vlastní pokyny), načtené dokumenty (v kanálech Retrieval Augmented Generation) a historie chatu (předchozí výměny konverzací). Každá z těchto komponent se započítává do maximálního rozpočtu tokenů, které lze do modelu předat.
Velká délka vstupu může ovlivnit výkon odvození, protože slova se převádějí na vložení a mezipaměť KV roste kvadraticky. Aplikace jako RAG pipeline mohou vyžadovat větší vstupní délky, což má za následek zvýšenou latenci prvního tokenu kvůli značnému množství zpracovávaných dat.
Tokenům a jejich vlivu na latence se budeme hlouběji věnovat později v tomto dokumentu a prozkoumáme, jak ovlivňují výkon LLM a jaké úvahy jsou nutné pro optimální provoz modelu.

3. Výstupní tokeny:
Stanovte průměrný počet tokenů ve výstupu LLM. To je nezbytné, protože generování více tokenů vyžaduje více výpočetních zdrojů a času. Pochopení očekávané velikosti výstupu pomůže při navrhování systému, který zvládne požadovanou propustnost bez kompromisů v latenci nebo kvalitě.

4. Průměrný počet požadavků za sekundu (RPS):
Chcete-li zajistit optimální výkon a efektivní využití zdrojů, určete maximální počet požadavků, které by měl systém zpracovat za sekundu. Při dimenzování pro místní nasazení je životně důležité založit výpočty na špičkovém využití, nikoli na průměrném využití.
Abychom zohlednili variabilitu vzorců požadavků, používáme 95. percentil Poissonovy PPF (funkce pravděpodobnosti bodu) průměrné RPS (požadavky za sekundu). Tento přístup pomáhá identifikovat maximální očekávané zatížení, což nám umožňuje navrhnout systém, který zvládne špičkové požadavky, aniž by byl nedostatečně využíván během období mimo špičku.
Proces zahrnuje získání průměrného počtu požadavků od zákazníka a výpočet maximálního počtu požadavků pomocí 95. percentilu Poissonova rozdělení. Tato metoda poskytuje přesnější reprezentaci požadavků systému, protože zohledňuje přirozenou variabilitu vzorců požadavků. Je zvláště důležité poznamenat, že pokud systém neběží na špičkovou kapacitu, mohou se efektivní náklady na token značně zvýšit.

5. Požadavky na latenci:
Pochopte cíle a limity latence zákazníka, včetně:

1. Latence prvního tokenu: Doba, kterou model potřebuje k vygenerování prvního tokenu odpovědi.
2. Latence posledního tokenu: Celková doba, kterou model potřebuje k vygenerování celé odezvy.

Latence je kritickým faktorem v mnoha aplikacích, protože vysoká latence může negativně ovlivnit uživatelskou zkušenost. Omezení na nižší latenci prvního tokenu (TTFT) by drasticky hamper propustnost, což znamená, že schopnost systému zpracovávat více požadavků současně by byla ohrožena.
Proto je nezbytné najít rovnováhu mezi latencí a propustností na základě specifických požadavků zákazníka.
Tyto požadavky jsou klíčové pro odhad výkonu odvození, dimenzování systému a zajištění, že splňuje očekávání zákazníka. Shromážděním těchto informací budete schopni lépe porozumět potřebám zákazníka a navrhnout vhodnou konfiguraci systému, která vyvažuje výkon, náklady a kvalitu. V dalších částech se budeme hlouběji zabývat některými z těchto požadavků a prozkoumáme, jak ovlivňují nasazení LLM.

Technický ponor: Porozumění LLM

V této části prozkoumáme složité fungování velkých jazykových modelů (LLM) tím, že se ponoříme do jejich technických aspektů. Budeme vyšetřovat stages provádění LLM, porozumět klíčovým metrikám měření a podívat se na techniky, které urychlují odvození.

Dva StagProvedení LLM: Předvyplnění vs dekódování
Velké jazykové modely (LLM) jsou komplexní systémy, které zahrnují více stages zpracování pro generování lidských textových odpovědí. Pochopení těchto stages je užitečný pro optimalizaci výkonu, snížení latence a zlepšení celkové uživatelské zkušenosti. V této části se ponoříme do dvě primární stages provádění LLM: Předvyplnění a dekódování.

Předvyplnit Stage
Předvyplnění stage označuje čas, který LLM potřebuje ke zpracování vstupní výzvy uživatele a vygenerování prvního výstupního tokenu, který je přibližně ekvivalentní slovu. Tato stage zahrnuje následující kroky:

1. Načtení uživatelské výzvy: Vstup uživatele je přijat a nahrán do systému.
2. Naplnění KV-cache: Během této stage, LLM naplní svou mezipaměť Key-Value (KV) informacemi ze vstupních tokenů. Tato mezipaměť se používá k ukládání a získávání relevantních kontextově specifických dat.
3. Požadavek přijetí na první token: Doba, kterou LLM potřebuje ke zpracování vstupní výzvy a vygenerování prvního výstupního tokenu.

Předvyplnění stage je primárně vázán na výpočet, což znamená, že jeho výkon je do značné míry závislý na dostupných výpočetních zdrojích. Čas potřebný k dokončení tohoto stage závisí pouze na počtu vstupních tokenů, což z něj činí předvídatelný a konzistentní proces.

Dekódování Stage
The Decoding stage, také známé jako generování nebo expanze, je místo, kde LLM generuje tokeny odezvy jeden po druhém, přičemž vychází z počátečního výstupního tokenu vytvořeného během předvyplnění.tagE. Tato stage zahrnuje:

1. Latence mezi tokeny: Doba potřebná k vygenerování každého následujícího tokenu po prvním tokenu.
2. Generování tokenu po tokenu: LLM generuje tokeny odpovědi slovo po slovu pomocí kontextu a informací shromážděných během předvyplněnítage.
3. Závislost na vstupních a výstupních tokenech: Latence mezi tokeny závisí jak na počtu vstupních tokenů, tak na počtu generovaných výstupních tokenů.

Na rozdíl od Prefill stage, Dekódování je typicky vázáno na paměť, což znamená, že jeho výkon je silně ovlivněn dostupností paměťových zdrojů. Protože LLM generuje více tokenů, vyžaduje více paměti pro ukládání a správu rostoucího kontextu, což může vést ke zvýšené latenci.

LLM Inference Measurement Metrics

Při hodnocení výkonu velkých jazykových modelů (LLM) se k měření rychlosti odvození používá několik klíčových metrik. Patří sem:

• Čas do prvního tokenu (TTFT): Doba potřebná ke zpracování vstupu a vygenerování prvního tokenu.
• Inter-token Latency (ITL): Doba potřebná k vygenerování každého následujícího tokenu po prvním, také známé jako Time Per Output Token (TPOT).
• End-to-End Latency (E2E) : Celková doba potřebná ke zpracování výzvy a vygenerování všech tokenů, od vstupu po výstup.

Tyto metriky poskytují přehled o výkonu modelu, pomáhají identifikovat úzká místa a optimalizovat rychlost odvození.

Dávkování za letu
Inflight Batching (IFB) je specializovaná technika používaná při vyvozování velkého jazykového modelu (LLM) k dosažení rovnováhy mezi pamětí GPU a využitím výpočetní techniky, což v konečném důsledku snižuje latenci. Tato metoda je zvláště účinná v auto-regresivní inferenci, kde LLM generuje tokeny postupně, přičemž se při výrobě dalších spoléhá na dříve vygenerované tokeny.
IFB umožňuje sekvence v různých stages (předvyplnění i dekódování), které mají být zpracovány v rámci stejné dávky bez čekání na dokončení všech požadavků před zavedením nových. Tento přístup nabízí několik klíčových výhod:

• Konstantní velikost dávky: IFB umožňuje téměř konstantní velikost dávky pro každou generaci tokenu, což vede k vyššímu využití GPU.
• Rychlejší spuštění spuštění: Nové požadavky mohou začít vykonávat rychleji, jakmile budou k dispozici sloty, protože plánovač čeká pouze na vygenerování dalšího tokenu, nikoli na dokončení aktuálních požadavků.

TensorRT-LLM obsahuje vlastní Inflight Batching pro optimalizaci využití GPU během poskytování LLM. Tato funkce:

• Nahradí dokončené požadavky v dávce.
• Vyřadí požadavky za značku konce sekvence (EoS) a vloží nové požadavky.
• Zlepšuje propustnost, čas do prvního tokenu a celkové využití GPU.

IFB je navíc hladce integrován do backendu TensorRT-LLM Triton a lze jej spravovat prostřednictvím správce dávek TensorRT-LLM. V kombinaci s dalšími technikami, jako je vyvažování operací vázaných na paměť a operace vázané na výpočet, blokové dekódování, spekulativní dekódování a vzácnost, zvyšuje IFB propustnost LLM, což z něj činí nepostradatelný nástroj pro efektivní vyvozování LLM.

Tenzorová paralela
Tensor Parallelism (TP) je technika používaná ve velkém jazykovém modelu (LLM) k rozložení výpočetní zátěže mezi více GPU. Tato metoda zahrnuje rozdělení jednoho modelu na několik GPU, což do značné míry závisí na efektivní výměně dat mezi těmito GPU. TP je zvláště výhodné pro větší modely, kde požadavky na paměť překračují kapacitu jednoho GPU.

Klíčové vlastnosti tenzorového paralelismu:

• Nižší latence, ale nižší propustnost: Zatímco TP může snížit latenci paralelizací výpočtů, může také vést k nižší celkové propustnosti kvůli režii spojené s komunikací mezi GPU.
• Požadavek na větší modely: U větších modelů, jako je LLaMa-70B, je vyžadován paralelismus tenzoru alespoň 2 (TP >= 2). To zajišťuje, že model lze adekvátně rozdělit mezi více GPU, aby se vešel do dostupné paměti a výpočetních zdrojů.
• Doporučení pro servery s podporou NVLink: Když TP překročí 2, společnost NVIDIA důrazně doporučuje používat servery s podporou NVLink pro odvození. NVLink poskytuje širokopásmové propojení s nízkou latencí, které výrazně zlepšuje přenos dat mezi GPU ve srovnání s tradičními připojeními PCIe.

Pochopení měřítek

Benchmarky jsou zásadní pro dimenzování a výběr ideální konfigurace pro zákazníky, protože vyhodnocují kompromisy mezi klíčovými metrikami, jako je propustnost, latence a četnost požadavků. Pochopení těchto benchmarků pomáhá určit optimální konfiguraci pro odvození velkého jazykového modelu (LLM), což umožňuje informovaná rozhodnutí o požadavcích na hardware a software.

Propustnost vs latence
V kontextu vyvozování LLM je rozhodující dosažení rovnováhy mezi propustností a latencí. Propustnost označuje počet požadavků, které lze zpracovat za jednotku času, zatímco latence je doba potřebná ke zpracování jednoho požadavku od začátku do konce.

Kompromis:
Zavedení limitů latence může snížit dostupnou propustnost. Naopak, uvolnění omezení latence může vést k mnohem vyšší propustnosti. Porozumění případům zákaznického použití poskytuje odhady vstupních tokenů, výstupních tokenů a průměrných požadavků za jednotku času, což umožňuje navrhnout konkrétní hardware, který odpovídá požadované propustnosti při zachování potřebné latence.
Kombinace více požadavků za účelem zvýšení propustnosti může způsobit zpoždění a zvýšit latenci jednotlivých požadavků. Odvozování LLM zahrnuje dvě fáze – předvyplnění (vysoká latence, výhody paralelního zpracování) a dekódování (nižší latence, nižší výpočetní využití).

Praktické důsledky:

1. Vysoká propustnost: Ideální pro rozsáhlá nasazení s vysokými objemy požadavků.
2. Nízká latence: Rozhodující pro aplikace odezvy v reálném čase, jako jsou konverzační AI nebo interaktivní systémy.

Pochopením a správou kompromisu mezi propustností a latencí mohou být LLM inferenční systémy optimalizovány tak, aby splňovaly specifické požadavky aplikací. Pro vlastní benchmarking, nástroje jako GenAI-Perf od NVIDIA může poskytnout cenné informace o výkonu konkrétního modelu v systému.

Chcete-li se dozvědět, jak interpretovat srovnávací grafy, přečtěte si téma na konci tohoto dokumentu Další informace – Čtení grafů pro stanovení velikosti.

Pochopení maximální velikosti dávky, souběžnosti, rychlosti požadavků a propustnosti
Zpracování všech žargonu může být trochu matoucí, takže pojďme rozebrat jednotlivé koncepty, abychom objasnili jejich vztahy a důležitost při hodnocení systému.

Maximální velikost dávky
Parametr max_batch_size má dvě role: jednu během sestavování motoru a druhou za běhu.

1. Engine Build: Toto nastavení zajišťuje, že se výsledný systém se svou kapacitou pro určitou velikost dávky vejde do dostupné paměti. Jde v podstatě o plánování kapacity, aby se předešlo problémům s pamětí během provádění.
2. Runtime: Toto nastavení určuje, kolik požadavků lze dávkovat dohromady před zpracováním. Max_batch_size za běhu musí být menší nebo rovna max_batch_size v době sestavení. Skutečné dávkování požadavků v reálných scénářích je ovlivněno tímto parametrem a přímo ovlivňuje efektivitu a výkon.

Velikost dávky a souběžnost

• Souběžnost (C) < Maximální velikost dávky (MBS): Když je počet souběžných požadavků menší než maximální velikost dávky, stroj obvykle zpracovává dávky o velikosti rovnající se úrovni souběžnosti. To znamená, že v každé dávce jsou k dispozici volné sloty, protože ne všechny potenciální pozice v dávce jsou obsazeny.
• Souběžnost (C) >= Max. velikost dávky (MBS): Pokud se souběžnost rovná nebo překračuje maximální velikost dávky, pak jsou dávky obvykle plné a zpracovává se maximální kapacita. Fronta na nové požadavky se začne zvětšovat s průměrnou velikostí C – MBS, protože příchozí požadavky čekají na dokončení předchozích dávek.

Souběžnost a sazba požadavků jako metrika výsledku
Chcete-li komplexně změřit výkon systému, zvažte:

• Propustnost: Počet požadavků, které může systém zpracovat za jednotku času.
• End-to-end Latency: Celková doba potřebná ke zpracování požadavku od začátku do konce.
• Souběžnost: Počet požadavků, které lze zpracovat současně.

Systém s vysokou souběžností a vysokou latencí může dosáhnout stejné propustnosti jako systém s nižší souběžností, ale nižší latencí. Ten druhý je však efektivnější, protože rychleji reaguje na jednotlivé požadavky.
Proto použití „požadavek za minutu“ (nebo podobné časové metriky) jako primárního měřítka pro dimenzování systémů a diskuse o výkonu se zúčastněnými stranami poskytuje vyvážené view kapacity systému. Pomáhá zohlednit požadavky na souběžnost i latenci a nabízí jasnější obrázek o tom, co systém dokáže efektivně zvládnout.

Souběžnost a sazba požadavků jako vstupní parametr
Pro přesné měření rychlosti (propustnosti) je nezbytné udržovat konstantní velikost dávky motoru od jednoho cyklu zpracování k druhému.

• Použití souběžnosti jako vstupu: Tento přístup zajišťuje, že velikost dávky zůstává konzistentní a poskytuje spolehlivá měření.
• Nastavení rychlosti požadavků jako vstupního parametru: To může být problematické, protože pokud rychlost požadavků překročí propustnost systému, fronta bude neustále narůstat, čímž se zvyšuje latence. Naopak nastavení četnosti požadavků pod propustnost systému znamená, že nejsou využity všechny dostupné sloty, což vede k nedostatečnému výkonu.

Doporučení

1. Použít souběžnost s velikostmi tokenů jako vstupní metriky: To umožňuje řízené experimenty, které mohou zatížit systém na jeho limity nebo měřit jeho odezvu při menší zátěži.
2. Použít míru požadavků jako metriku výsledku: Poskytuje přehled o tom, kolik požadavků může systém skutečně zpracovat v daném časovém rámci, což odráží jak jeho kapacitu, tak efektivitu.

Řízením těchto parametrů a zaměřením se na správné metriky mohou podniky navrhovat efektivnější systémy, které efektivně vyvažují propustnost, latenci a využití zdrojů.

Celkové náklady na vlastnictví: Cloud vs. On-prem

Nasazení odvození velkého jazykového modelu (LLM) se pro moderní podniky stává zásadní. Existují dvě hlavní možnosti: cloudové a on-premise. Prozkoumáme výhody a omezení každé možnosti, abychom vám pomohli učinit informované rozhodnutí.

Cloud-Based Deployment
Cloudové nasazení nabízí model „pay-as-you-go“, kdy platíte pouze za použité zdroje.
Je však třeba zvážit některé nevýhody:

• Zabezpečení dat: Pokud si nezakoupíte podnikovou licenci, mohou být vaše data použita k trénování budoucích modelů, což může vést k úniku dat.
• Nejistota ceny: Ceny se mohou změnit a vy máte menší kontrolu nad modelem, který nemusí podporovat jemné ladění nebo přizpůsobení.
• Omezená kontrola: Máte omezenou kontrolu nad latencí a propustností výzev.

Náklady na cloudové nasazení se obvykle vypočítávají na základě vstupních a výstupních tokenů s pevnou cenou za token. Napřample, jeden milion vstupních tokenů může stát 15 $, zatímco milion výstupních tokenů stojí 60 $.
Chcete-li odhadnout náklady, můžete použít kalkulačku který bere v úvahu počet vstupních a výstupních tokenů.

On-Premise Deployment
On-premise nasazení vyžaduje značné počáteční investice, ale nabízí několik výhod:

• Úplná kontrola: Máte úplnou kontrolu nad systémem a umožňuje změny podle potřeby.
• Nákladově efektivní: S pevným využitím blízko kapacity může být místní nasazení z dlouhodobého hlediska nákladově efektivní.
• Zabezpečení: Vaše data jsou v bezpečí a máte plnou kontrolu nad systémem.

Náklady spojené s on-premise nasazením zahrnují:

1. Nákup serveru GPU: Cena nákupu serveru GPU, která se liší v závislosti na hardwaru a typu systému.
2. Náklady datového centra: Náklady související s elektřinou, pronájmem prostor, personálem a dalšími výdaji.
3. Licenční poplatky: Roční licenční poplatek za jakékoli další služby, např. NVAIE

Chcete-li zjistit cenu za 1 milion výzev (volání):

kde

• Z = Cena za 1 milion výzev
• C = celkové náklady na předplatné zprůměrované za rok
• X = Výzvy za sekundu (propustnost) v systému

Porovnání cloudového a on-premise nasazení
Abychom provedli spravedlivé srovnání mezi cloudovým a on-premise nasazením, předpokládáme, že:

1. Modely nasazené na obou platformách jsou kvalitativně rovnocenné.
2. Latence a propustnost dosažená na obou platformách jsou podobné.

Můžeme porovnat místní náklady na 1 milion výzev s náklady na cloud na 1 milion výzev, abychom získali spravedlivé srovnání. Mohli bychom dokonce zjistit náklady na vstupní a výstupní token pro on-prem.

Rekapitulace nákladů
Závěrem lze říci, že jak cloudové, tak on-premise možnosti nasazení mají své výhody a omezení.
Cloudové nasazení nabízí flexibilní a škálovatelné řešení, ale může ohrozit zabezpečení a kontrolu dat. On-premise nasazení poskytuje úplnou kontrolu a zabezpečení, ale vyžaduje počáteční investici.
Z dlouhodobého hlediska je dosaženo bodu zlomu, kdy on-premise nasazení dává finanční smysl než on-cloud instance.

Doporučení
Při rozhodování mezi cloudovým a on-premise nasazením zvažte následující:

• Zabezpečení dat: Pokud je to vaše nejvyšší priorita, je lepší místní nasazení.
• Škálovatelnost: Pokud potřebujete rychle škálovat, může být vhodnější cloudové nasazení.
• Rozpočet: Pokud jde o rozpočet, nasazení na místě může být z dlouhodobého hlediska nákladově efektivní.

Nakonec rozhodnutí závisí na vašich konkrétních potřebách a prioritách.

Závěr
Závěrem lze říci, že při navrhování systémů pro nasazení LLM (Large Language Model) je zásadní přesně odhadnout výkon a výpočetní požadavky. Chcete-li toho dosáhnout, shromážděte specifické požadavky od zákazníků, včetně výběru modelu, délky vstupního tokenu, kvantizace a potřeb latence. Poskytnuté vzorce a pokyny, jako je „Rule of Thumb“ pro odhadování požadavků na paměť GPU, slouží architektům řešení jako cenné nástroje k rychlému posouzení a navrhování schopných systémů, které splňují požadavky zákazníků.
Zvážením klíčových faktorů, jako je velikost modelu, přesnost a kvantizace, můžete optimalizovat konfiguraci systému, abyste vyvážili výkon a náklady. Navíc techniky jako Low-Rank Adaptation (LoRA) a Quantized LoRA (QLoRA) mohou radikálně snížit požadavky na paměť během jemného ladění a tréninku, což umožňuje efektivnější a nákladově efektivnější řešení.
Tato příručka LLM Inference Sizing Guide poskytuje znalosti a odborné znalosti potřebné k orientaci ve složitém prostředí LLM, k úspěšnému nasazení a poskytování řešení na míru, která splňují jedinečné potřeby jejich zákazníků. Dodržováním těchto pokynů a osvědčených postupů můžete zajistit optimální výkon, snížit náklady a podpořit obchodní úspěch v rychle se vyvíjející oblasti zpracování přirozeného jazyka.

Další informace – Čtení grafů pro stanovení velikosti

Graf založený na srovnávací data z NVIDIA NIM vypadá takto:

Obrázek 5: Sample Graf propustnosti vs první token latence pro model Llama 3 8B s 2000 vstupními a 2000 výstupními tokeny
Interaktivní grafy vám umožňují vybrat modely, zařízení, kombinaci vstupních a výstupních tokenů, metriku na ose X a výsledek na ose Y. Pro osu X bychom mohli mít vstupní parametry jako TTFT, TTLT nebo ITL pro tokeny. Pro osu Y máme výstupní parametry, jako jsou výzvy za sekundu na systém nebo out_tokens za sekundu na systém nebo na instanci GPU.
Bývalýampvelikost le:
Zákazník chce token 2000 in, 2000 out s modelem lama3 8B a chce TTFT pod 1 sekundu. Pomocí omezení najdeme bod na grafu vlevo od 1 s TTFT (FTL), vypadal by takto:

To vám říká, že jeden systém 8xH100 by byl schopen zvládnout až 400 souběžných (špičkových) uživatelů při použití TRT-LLM. Vidíme však, že to má celkovou latenci přes 38 sekund. Pokud chceme nižší celkovou latenci (řekněme pod 20 sekund), budeme muset obětovat propustnost a reformovat osu X jako celkovou latenci (TTLT), máme:

Zde máme bod se 100 souběžnými uživateli s 358 ms TTFT a pod 20 s TTLT. Jak vidíme, nastavení omezení latence silně ovlivňuje propustnost a maximální souběžnost.
Chcete-li spouštět benchmarky na svém vlastním systému, viz Průvodce srovnáváním NIM pro LLM od NVIDIA používat GenAIPerf získat metriky LLM.

Autoři
Sachin Gopal Wani je AI Data Scientist ve společnosti Lenovo, pracuje na komplexních aplikacích strojového učení (ML) pro různé zákazníky a vyvíjí rámec NewTalk AI. Vystudoval Rutgers University jako zlatý medailista se specializací na strojové učení a získal stipendium JN Tata.
David Ellison je hlavní datový vědec společnosti Lenovo ISG. Prostřednictvím amerických a evropských center AI Discover Center společnosti Lenovo vede tým, který využívá nejmodernější techniky AI k poskytování řešení pro externí zákazníky a zároveň interně podporuje celkovou strategii AI pro skupinu World Wide Infrastructure Solutions Group. Před nástupem do společnosti Lenovo vedl mezinárodní společnost zabývající se vědeckými analýzami a vybavením a pracoval jako datový vědec pro americkou poštovní službu. Předtím získal doktorát v biomedicínském inženýrství na Johns Hopkins University. Má četné publikace ve špičkových časopisech, včetně dvou ve Proceedings of the National Academy of the Sciences.

Rodiny příbuzných produktů

Rodiny produktů související s tímto dokumentem jsou následující:

• Umělá inteligence

Oznámení
Lenovo nemusí nabízet produkty, služby nebo funkce popsané v tomto dokumentu ve všech zemích. Informace o produktech a službách aktuálně dostupných ve vaší oblasti vám poskytne místní zástupce Lenovo. Jakýkoli odkaz na produkt, program nebo službu Lenovo není zamýšlen tak, aby uváděl ani nenaznačoval, že lze používat pouze tento produkt, program nebo službu Lenovo. Místo toho lze použít jakýkoli funkčně ekvivalentní produkt, program nebo službu, které neporušují žádná práva k duševnímu vlastnictví Lenovo. Je však odpovědností uživatele vyhodnotit a ověřit fungování jakéhokoli jiného produktu, programu nebo služby. Lenovo může mít patenty nebo nevyřízené patentové přihlášky týkající se předmětu popsaného v tomto dokumentu. Poskytnutí tohoto dokumentu vám nedává žádnou licenci k těmto patentům. Dotazy na licence můžete zasílat písemně na adresu:

Lenovo (Spojené státy), Inc.
8001 Vývoj Drive
Morrisville, NC 27560
USA
Pozor: Lenovo Director of Licensing

LENOVO POSKYTUJE TUTO PUBLIKACI „TAK, JAK JE“, BEZ ZÁRUKY JAKÉHOKOLI DRUHU, VÝSLOVNÉ NEBO PŘEDPOKLÁDANÉ, VČETNĚ, ALE NE OMEZENÍ, PŘEDPOKLÁDANÝCH ZÁRUK NEPORUŠENÍ, OBCHODOVATELNOSTI NEBO VHODNOSTI SOUČÁSTI. Některé jurisdikce neumožňují zřeknutí se výslovných nebo předpokládaných záruk v určitých transakcích, proto se na vás toto prohlášení nemusí vztahovat.
Tyto informace mohou obsahovat technické nepřesnosti nebo typografické chyby. Zde uvedené informace se pravidelně mění; tyto změny budou začleněny do nových vydání publikace. Lenovo může kdykoli bez upozornění provádět vylepšení a/nebo změny v produktech a/nebo programech popsaných v této publikaci.

Produkty popsané v tomto dokumentu nejsou určeny pro použití při implantaci nebo jiných aplikacích pro podporu života, kde může porucha způsobit zranění nebo smrt osob. Informace obsažené v tomto dokumentu neovlivňují ani nemění specifikace nebo záruky produktů Lenovo. Nic v tomto dokumentu nebude fungovat jako výslovná nebo předpokládaná licence nebo odškodnění podle práv duševního vlastnictví společnosti Lenovo nebo třetích stran. Všechny informace obsažené v tomto dokumentu byly získány ve specifických prostředích a jsou uvedeny jako ilustrace. Výsledky získané v jiných operačních prostředích se mohou lišit. Lenovo může používat nebo distribuovat jakékoli vámi poskytnuté informace jakýmkoli způsobem, který považuje za vhodný, aniž by jí tím vznikl jakýkoli závazek vůči vám.
Jakékoli odkazy v této publikaci na jiné výrobce než Lenovo Web stránky jsou poskytovány pouze pro pohodlí a v žádném případě neslouží jako jejich podpora Web stránky. Materiály u nich Web stránky nejsou součástí materiálů pro tento produkt Lenovo a jejich použití Web stránky je na vlastní nebezpečí. Veškeré zde uvedené údaje o výkonu byly určeny v kontrolovaném prostředí. Proto se výsledky získané v jiných operačních prostředích mohou výrazně lišit. Některá měření mohla být provedena na systémech na úrovni vývoje a nelze zaručit, že tato měření budou stejná na obecně dostupných systémech. Navíc některá měření mohla být odhadnuta pomocí extrapolace. Skutečné výsledky se mohou lišit. Uživatelé tohoto dokumentu by si měli ověřit platná data pro jejich konkrétní prostředí.

© Copyright Lenovo 2025. Všechna práva vyhrazena.

Tento dokument, LP2130, byl vytvořen nebo aktualizován dne 24. ledna 2025.
Pošlete nám své komentáře jedním z následujících způsobů:
Použijte online Kontaktujte nás znovuview formulář najdete na: https://lenovopress.lenovo.com/LP2130
Své připomínky zasílejte na e-mail: comments@lenovopress.com
Tento dokument je k dispozici online na adrese https://lenovopress.lenovo.com/LP2130.

ochranné známky
Lenovo a logo Lenovo jsou ochranné známky nebo registrované ochranné známky společnosti Lenovo ve Spojených státech a případně v dalších jiných zemích. Aktuální seznam ochranných známek Lenovo je k dispozici na Web at https://www.lenovo.com/us/en/legal/copytrade/.
Následující termíny jsou ochrannými známkami Lenovo ve Spojených státech a případně v dalších jiných zemích: Lenovo®
Ostatní názvy společností, produktů nebo služeb mohou být ochrannými známkami nebo servisními známkami jiných společností.

Průvodce velikostí Lenovo LLM

Dokumenty / zdroje

Lenovo LLM Sizing Comprehensive Framework [pdfUživatelská příručka LLM Sizing Comprehensive Framework, LLM Sizing, Comprehensive Framework, Framework

Reference

• Uživatelská příručka