Eszközök

Hardverbarát LLM-tervezés: dimenziózás, kvantizálás és párhuzamosítás a jobb teljesítményért

A cikk főszereplője a NVIDIA és a TensorRT-LLM ökoszisztéma, amely a nagy nyelvi modellek (LLM) hardverbarát tervezésére ad gyakorlati irányelveket.

Hardverbarát LLM-tervezés: dimenziózás, kvantizálás és párhuzamosítás a jobb teljesítményért

A mesterséges intelligencia gyakorlati teljesítményét három, egymással összefüggő dimenzió határozza meg: pontosság (hogyan érvel és milyen minőségű kimeneteket ad a modell), átbocsátás (tokens/másodperc a datacenterben) és interaktivitás (a felhasználónak érzett késleltetés). A gyakorlatban ezek között kompromisszumok vannak: a magas pontosság kevésbé használható, ha a válaszadás lassú, és nagy összteljesítmény (throughput) kevésbé ér valamit, ha minden felhasználó tapasztalata laggos.

Ez a cikk elsősorban az átbocsátásra és az interaktivitásra fókuszál, és bemutatja, hogy a modelltervezési döntések miként alakítják ezeket a célokat anélkül, hogy indokolatlanul áldoznák fel a pontosságot. Pontosabban: ha a pontosságot rögzítjük, akkor az átbocsátás és az interaktivitás között két-dimenziós Pareto-határ vonal jön létre; a cél a határvonal kitolása úgy, hogy mindkét cél területéből többet kapjunk.

A bemutatott szempontok ma elsősorban a nagy nyelvi modellekre (LLM-ekre) érvényesek, és két nézőpontot különböztetnek meg: a rendszerüzemeltetőét (flottaszintű tokens/sec maximalizálása) és a végfelhasználóét (első token és inter-token késleltetés minimalizálása). Egy válasz folyamata: prompt → első-token késleltetés → első token → inter-token késleltetés → következő token… A cél: a hardverrel összhangban tervezett modellek gyorsabban futnak, jobban skálázhatók, olcsóbbak és szélesebb körben terjeszthetők.

Milyen telepítési üzemmódok léteznek?

A telepítési tér két tengely mentén változik: a kontextus hossza (rövid → hosszú) és a szolgáltatási cél (átbocsátás-orientált → késleltetés-orientált).

  • Hosszú kontextus, átbocsátás-orientált: az idő nagy részét az attention foglalja el; itt a skálázás sokszor model- vagy expert-parallel munkamegosztást igényel.
  • Rövid kontextus, átbocsátás-orientált: attention és a feed-forward háló (FFN) időarányai közelebb állnak egymáshoz; nagy skálán az expert-parallelism (MoE) előnyös lehet.
  • Késleltetés-orientált üzem: tipikusan modell-parallel megoldásokat adnak hozzá, hogy csökkentsék az egy lekérdezésre jutó kritikus út hosszát, de ez extra kommunikációs és fix költségekkel jár.

Amdahl törvénye érvényes: csak ott érdemes optimalizálni, ahol a futási idő nagy részét töltjük. Ha például az attention a futási idő 77%-át teszi ki, a FFN hangolása csak kis javulást hoz.

Miért számítanak a lineáris réteg-dimenziók? (H, H′, L)

A transformerek fontos tervezési paraméterei a szélesség (hidden dimension H), az FFN köztes dimenziója (H′) és a rétegek száma (L). Ezek együtt határozzák meg a számítás és memória eloszlását, azt hogy milyen jól illeszthető a modell különböző párhuzamosítási stratégiákra, illetve mennyire telítik ki a GPU-kat.

Aritmetikai intenzitás és a roofline modell

A hardverben elérhető teljesítményt a roofline modell korlátozza: egy feladat akkor memória-kötött, ha alacsony az aritmetikai intenzitása (műveletek/byte), és számítás-kötött, ha magas. Maximális throughput (tokens/s) esetén a cél az aritmetikai intenzitás növelése, hogy a feladat a számítás-kötött tartományba kerüljön. Latency-érzékeny dekódolásnál viszont alacsony párhuzamosság miatt a megkötés gyakran memória-sávszélesség.

Egy GEMM (C = A B) költségeit a M×N×K méretekre lehet bontani: FLOPs ~ 2 M N K, a beolvasott és kiírt byte-ok pedig M K, N K és M N szorzatokkal arányosak a számolt precízió szerint. A token-szám (concurrency × sequence length), H és H′ ezekbe az M, N, K dimenziókba fordítódnak át az egyes lineáris rétegeknél (Q/K/V lineárisok, attention output, FFN up-/down-projekciók). Ha például H vagy H′ kicsi, akkor még nagy token-dimenzió mellett is a GPU aránytalanul sok időt tölt adatmozgatással ahelyett, hogy számítást végezne.

Konkrét példaként egy FFN-2 réteget mutatnak be H′=512 és H=8192 beállítással, NVFP4/FP8 formátumokkal GB300 hardveren: még nagy token-szám mellett is memória-kötött marad a réteg, mert a write költség és a kis redukciós dimenzió dominál.

Gyakorlati következtetések a dimenziókra

  • Ha a GEMM-ek „négyzetes” alakúak (Tokens ≈ H′ ≈ H), akkor a FLOPs ~ 2 H^3 és a memória ~ 3 H^2, tehát az aritmetikai intenzitás nő H-val. Kis H vagy H′ viszont memória-hangolt végrehajtást eredményez.

Összefoglaló iránymutatás 1:

  • Rögzített paraméterkeret mellett kerüljük a túl kis projekciós vagy redukciós dimenziókat; törekedjünk közel-négyzetes súlymátrixokra.

Tile-quantization és a GPU-szel való illeszkedés

A GPU-k a GEMM-eket csempékre (tile) bontják, és az SM-ek együttműködése (clusterMMA, CGA) nagyobb effektív csempét hozhat létre. Ha a mátrixdimenziók nem illeszkednek ezekhez a csempézési blokkokhoz, a peremcsempék részben kihasználatlanok maradnak, de ugyanúgy lefutnak, ami cikluspazarláshoz és csökkent átbocsátáshoz vezet. Egyszerű, hordozható szabály: a dimenziók legyenek legalább 128 többszörösei; 256 vagy 512 többszörösök a nagyobb együttműködő tile-okhoz illeszkednek.

Iránymutatás 2:

  • Méreteket legalább 128-szal, ideálisan 256 vagy 512-vel igazítsuk a GPU csempeméretekhez és cache-línekkel való összehangoláshoz.

Széles modellek vs. mély modellek

Azonos paraméterkeret mellett a szélesebb modellek jellemzően nagyobb aritmetikai intenzitást és rövidebb kritikus szekvenciális utat adnak, ami alacsonyabb késleltetést és jobb hw-használatot eredményez mind throughput-, mind latency-céloknál. Ugyanakkor a mélység (rétegszám) hozzájárul a reprezentációs kapacitáshoz, ezért nincs univerzális szabály: a szélességet csak addig növeljük, amíg a pontosság nem romlik.

Iránymutatás 3:

  • Preferáljuk a kevesebb, nagyobb műveletet sok kicsi helyett: a szélesebb transformerek általában hardverbarátabbak, de csak amíg a pontosság megmarad.

Kvantálás (quantization) lehetőségei

A kvantálás egyszerre növeli a számítási áteresztőképességet és csökkenti a memóriaforgalmat. A Blackwell architektúrák támogatják az NVFP4-et, FP8-at és FP16/BF16-ot. Az NVFP4 különösen úgy van tervezve, hogy egyensúlyt adjon pontosság és sebesség között: 16-elemű mikrorezegekhez finomhangolt E4M3-es skálázást alkalmaz, plusz per-tensor FP32 skálát, ami erősen csökkenti az kvantálási hibát miközben 4-bites sebességet tesz lehetővé.

Benchmarkok (DeepSeek-R1) szerint az NVFP4 pontossága legtöbbször egy ponthoz közeli eltérést mutat az FP8-hoz képest, és egyes feladatokon (SciCode, Math-500, AIME 2024) az NVFP4 megegyező vagy jobb eredményt produkált.

NVIDIA eszközök—TensorRT Model Optimizer és LLM Compressor—támogatják a post-training quantization-t (PTQ), quantization-aware traininget (QAT) és kalibrációt, hogy NVFP4-re történő átalakítás minimális pontosságveszteséggel legyen kivitelezhető. NVIDIA Research is foglalkozik az NVFP4-gyel (Pretraining Large Language Models with NVFP4, 2025).

Iránymutatás 4:

  • Számításigényes műveleteknél mérlegeljük a kvantálhatóságot már a modelltervezésnél — rétegek tervezése alacsony precíziós futtatásra sokat hoz a modern GPU-kon.

Expert-parallelism a Mixture-of-Experts (MoE) modelleknél

Átbocsátás-orientált üzemnél a cél minél több felhasználót kiszolgálni minél kevesebb GPU-n. Mivel sok korszerű LLM MoE-szerkezetű, az expert-parallelism (EP) hatékony megoldás: attention részben data-parallel, FFN-expertek pedig szétosztva a GPU-kon.

Data-parallel attention elkerüli a tensor-parallelizmusnál gyakori AllReduce költséget, így jobban skálázik. A MoE FFN-eknél a GEMM-M növelése (globális concurrency növelése) az egyik kulcs: GEMM-M = (global concurrency × top-k) / #experts. A global concurrency nő GPU-k számával, a top-k az egy tokenhez aktivált expertek száma (DeepSeek-R1 esetén 8), a #experts a teljes expertszám (DeepSeek-R1 esetén 256).

Széles EP előnyök:

  • Aggregált sávszélesség: több GPU együtt gyorsabban tölti be expert-súlyokat.
  • Csökkenő per-GPU memóriaigény: minden GPU kevesebb expertet tárol, így nő a hatékony concurrency.

Kihívások: all-to-all kommunikáció és expert load imbalance. NVIDIA TensorRT-LLM Wide-EP funkciója magas teljesítményű all-to-all kernel-eket és adaptív terhelés-újraelosztót kínál.

Iránymutatás 5:

  • Nagy számú experttel rendelkező, sparsított MoE modelleket széles expert-parallelism-el érdemes telepíteni a magas throughput eléréséhez.

Pipeline és hibrid párhuzamosítások

Pipeline parallelism releváns, ha elkülönítjük a prefill (prefill a kontext betöltése) és a decode fázist: külön partíciózással mindkét részt optimalizálhatjuk. Chunked Pipeline Parallelism (CPP) a prefillnél hasznos: egyszerre darabolja a model rétegeit és a bemeneti kontextust chunkokra, ezáltal csökkentve az első-token késleltetést hosszú kontextusoknál anélkül, hogy széles tensor-parallelizmust kellene használni.

A CPP csak akkor hatékony, ha a pipeline stage-ek kiegyensúlyozottak; ezért érdemes a modellt úgy tervezni, hogy ismétlődő, egyenletes rétegmintákkal könnyen oszthassuk szét a stage-eket.

Iránymutatás 6:

  • Tervezd a modelledet szabályos, ismételhető rétegmintákkal, amelyek könnyen oszthatók kiegyensúlyozott pipeline stage-ekre; ez lehetővé teszi a Chunked Pipeline Parallelism nyereségét.

Hibrid stratégiák késleltetés-orientált célokra Késleltetés minimalizálásához alacsonyabb per-GPU munka vagy több GPU szükséges, de ha a párhuzamosság csökken, a FFN-ek memória-kötötté válhatnak, mert a GEMM-N és GEMM-K nagyok maradnak. Ilyen alacsony konkurenciás üzemmódban érdemes külön kezelni az attention és FFN párhuzamosítását: FFN-ekhez TP, EP vagy TP×EP; attentionhez TP és KV párhuzamosítás.

Helix Parallelism (NVIDIA Research, 2025) olyan megközelítés, amely a KV cache-et a szekvencia dimenzió mentén shard-olja attention alatt, majd ugyanazokat a GPU-kat használja a FFN-ek TP×EP megvalósítására. Bár ezek a hibrid sémák több kommunikációt hoznak, a Blackwell NVL72 magas sávszélességű NVLink hálózata sokat képes elnyelni, a maradék pedig átfedhető a számítással.

Iránymutatás 7:

  • Tervezd a modellt és a telepítést úgy, hogy az attention és a FFN párhuzamosítása külön-külön skálázható legyen; így a GPU-k hozzáadásával hatékonyan csökkenthető a késleltetés.

Záró javaslatok — ellenőrzőlista a tervezéshez

A következőket érdemes figyelembe venni új modellek tervezésekor:

  • Tartsuk a súlymátrixokat közel négyzetesek és 128-/256-/512-többszörösre igazítottak.
  • Előnyben részesíteni a szélességet a mélységgel, amíg a pontosság nem romlik.
  • Tervezni alacsony precíziós (NVFP4) végrehajtásra.
  • Használni szabályos, ismételhető rétegmintákat, amelyek jól darabolhatók pipeline-okhoz.

Ezek a kis tervezési döntések jelentősen növelhetik a GPU-k kihasználtságát, gyakorlatilag gyorsabb inferenciát, nagyobb throughputot és jobb interaktivitást biztosítva ugyanazon hardveren. A megvalósításhoz ajánlott eszközök: NVIDIA TensorRT Model Optimizer (NVFP4 kvantáláshoz) és TensorRT-LLM (expert-, pipeline- és Helix-parallelism támogatás).