A gépi nyelvi modellek két széles körben használt szervezési megközelítése a dense (sűrű) és a Mixture-of-Experts (MoE, szakértői keverék) architektúra. A kulcs: nemcsak az összes paraméter számít, hanem az is, hogy a modell hogyan használja azokat. Ez a választás nagyobb hatással lehet a teljesítményre, a memóriaigényre és a kiszolgálás bonyolultságára, mint maga a paraméterek száma.
Alapvető különbség
- Dense modell: minden token feldolgozásakor az összes paraméter (például egy 27B modell összes 27 milliárd paramétere) részt vesz a számításban — tipikusan egy közös feed-forward (FFN) blokk per dekóder réteg.
- MoE modell: egy rétegben több FFN blokk ("szakértő") van, és egy router hálózat minden tokenhez csak a legjobb k szakértőt választja ki. A kiválasztott FFN-ek futnak az adott tokenre, a többi blokknak nem kell számolnia. Sok modern MoE-modell emellett futtat egy minden tokenhez kiosztott „shared” szakértőt is.
Hogyan működik a routing?
A routing döntés rétegenként külön történik: egy token minden dekóder rétegben újraroutereződik, így nem marad végig ugyanannál a szakértőnél. Ezek a szakértők általában nem témaspecialisták; inkább a szintaxisra vagy token-típusokra (pl. írásjelek, számok) „fókuszálnak”, bár ez architektúrától és tanítástól függ.
Fontos: a router kiválasztja, mely FFN blokkokat hagyja ki, de a tokenek továbbra is végigmennek a teljes attention mechanizmuson és az embedding súlyokon. Amikor egy modell „3B aktív paramétert” említ, az az attention és embedding súlyokat is tartalmazza a kiválasztott FFN súlyok mellett.
MoE variánsok és hibrid megoldások
Egyes modellek hibrid megoldásokat alkalmaznak. Például a Nemotron 3.5 Lightning NVIDIA model cardja egy Mamba-2 + MoE + Attention hibridet ír le: a Mamba-2 rétegek a legtöbb rétegben az attention szerepét veszik át, és állandó méretű rekurzív állapotot hordoznak a növekvő KV cache helyett. Emellett Lightning a routing döntéseket kisebb, tömörített térben számolja ki, hogy olcsóbb legyen a routing végrehajtása.
Teljesítmény: melyik gyorsabb?
Általánosságban az MoE modellek jobb token-througputot kínálnak, mivel egy tokenhez csak egy részhalmaznyi FFN fut. A dense modellek egyszerre teljes hálózatot aktiválnak, de egyszerűbbek és kiszámíthatóbb késleltetést adnak. Magas párhuzamossági szinten a routing és a memóriamozgatás csökkentheti az MoE előnyét. A tényleges eredmények függnek hardvertől, pontosságtól, inferencia keretrendszertől és modellspecifikus megoldásoktól (például Nemotron Lightning Mamba-2 rétegei és spekulatív dekódolása).
A MoE-k kulcsfontosságú előnye, hogy szétválasztják a memóriaigényt (teljes paraméterszám → VRAM/host) a tényleges számítási igénytől (aktív paraméterek → FLOPs/token). Dense modelleknél a tárolás és az inferencia költsége együtt skálázódik; MoE esetén a memória költsége előre fizetendő (minden szakértőt be kell tölteni), a számítás viszont per token csökken, mert sok szakértő „nyugalmi” állapotban van.
Batch size 1 esetén a dekódolás gyakran memóriakorlátozott, itt az MoE jól teljesít, mert tokenenként kevesebb súlyt kell olvasni. Nagyobb batchméretnél a tokenek összességében több szakértőt használnak, így az előny szűkül, de a tokenenkénti munkamennyiség csökkenése megmarad. A modern inferencia keretrendszerek általában úgy kezelik a routingot, hogy nem dobják el a tokeneket, viszont az összes szakértőnek egyszerre a GPU memóriában kell lennie, ami csökkenti a rendelkezésre álló helyet a KV cache számára egy hasonló méretű dense modellhez képest.
Példa összehasonlítás (változók és mért adatok)
Egy szolgáltatói összevetés (Artificial Analysis, 10K-token input, adatok lekérése: 2026. augusztus 31.) több, ~30B körüli modellt hasonlít össze. Kiemelt adatok a táblázatból:
- Gemma 4 31B (dense multimodal): 31B összparaméter, 31B aktív, kb. 61 GB BF16 VRAM (1×H100), kimeneti sebesség 36.9–222.4 token/s, ~$/M output $0.40.
- Qwen3.8-27B (dense hibrid): 27B összparaméter, 27B aktív, kb. 56 GB BF16 (1×H100), kimeneti sebesség 46.8 token/s, ~$3.00/M output.
- Nemotron 3.5 Lightning (MoE + Mamba-2 hibrid): ~30B összparaméter, ~3B aktív paraméter tokenenként, kb. 60 GB BF16 (1×H100), kimeneti sebesség 235.7–494.2 token/s, ~$0.22/M output.
- Mistral Small 4 (MoE multimodal): 119B összparaméter, 6B aktív (8B embeddinggel), kb. 121 GB FP8 (4×H100), kimeneti sebesség 147.3 token/s, ~$0.60/M output.
Ezek az adatok azt mutatják, hogy két hasonló teljes paraméterméretű modell nagyon különböző throughput- és költségprofilokat adhat, ha az egyik dense, a másik MoE. Például Lightning többszörös kimeneti sebességet érhet el Qwen3.8-27B-hez képest lényegesen alacsonyabb költséggel, miközben általános képességben (capability) alacsonyabb lehet.
Mikor melyik architektúrát válasszuk?
Néhány alapvető mérlegelési pont:
-
Memória-költségvetés: a memóriafelhasználás a teljes paraméterszámot követi: egy 30B MoE és egy 30B dense modell egyaránt nagyjából ugyanannyi VRAM-ot igényel. A kérdés inkább az, hogy mit kapsz ezért a memóriáért: dense → több képesség (capability), MoE → nagyobb áteresztőképesség (throughput).
-
Párhuzamosság (concurrency): egyetlen kérést figyelembe véve az MoE előnye egyértelmű. Ahogy nő a párhuzamosság, az előny megmarad a throughput tekintetében, de a késleltetésbeli különbség csökken. Alacsony késleltetésnél magas párhuzamosság mellett érdemes mindkettőt benchmarkolni.
-
Finomhangolási tervek: dense modelleket könnyebb finomhangolni, mert minden paraméter aktiválódik és a gradiens egyenletesen terjed. MoE-knél a teljes finomhangolás eltolhatja a routert, bizonyos szakértők túlnépszerűek vagy teljesen inaktívak lehetnek. LoRA/PEFT megközelítések és a router fagyasztása gyakori gyakorlat. NVIDIA NeMo receptje például specifikusan kezeli a Lightning finomhangolását.
-
Kvantálás: a checkpoint natív pontossága számít (például Mistral Small 4 natív FP8), és az architektúrák különböző moduljai kvantálódnak rosszabbul. MoE-knél a router különösen érzékeny, mert kis perturbációk diszkrét routing döntéseket változtathatnak meg.
Összefoglaló: a fő kompromisszum
A dense és az MoE architektúrák két különböző válasz egy közös problémára: hogyan osszuk meg a képességet paraméterenként és a számítás terhelését tokenenként. A dense egyszerűbb, minden aktív, könnyebb finomhangolni és kiszolgálni. Az MoE a memóriát használja fel, hogy tokenenként kevesebb számítást igényeljen, így jobb throughputot kínál, viszont bonyolultabb a szolgáltatás és a finomhangolás kezelése.
A Nemotron 3.5 Lightning nyíltan elérhető súlyokkal, adatokkal és receptekkel rendelkezik, így igény szerint adaptálható és bárhol telepíthető; a fájlok letölthetők például Hugging Face-ről vagy ModelScope-ról, és kipróbálható build.nvidia.com-on vagy OpenRouteren keresztül.
A gyakorlatban a választás a konkrét üzemeltetési igényektől függ: ha nagy volumenű, jól definiált lépések végrehajtása a cél (agentic workloads), az MoE előnyös lehet; ha egyetlen, nehéz érvényű gondolkodási passz dönt mindenről, akkor a dense modell lehet jobb választás.
