Modele dense kontra mixture-of-experts (MoE): kompromisy od routingu po serwowanie

Model dense używa każdego parametru dla każdego tokenu. Model mixture-of-experts (MoE) kieruje każdy token przez niewielki podzbiór parametrów. To najważniejszy kompromis architektoniczny w obecnych LLM-ach, a właściwa odpowiedź zależy od tego, czy płacisz za trening, pamięć czy przepustowość. Notatka o MoE na jednym GPU omawia serwowanie na jednej karcie; ta omawia samą architekturę.

Router

W warstwie MoE blok feed-forward zostaje zastąpiony routerem i E modułami eksperckimi (experts), z których każdy jest osobną siecią feed-forward. Dla każdego tokenu router liczy wynik dla każdego modułu eksperckiego, zostawia k najwyżej ocenionych i łączy wyjścia wybranych modułów eksperckich, ważąc je ich wynikami:

scores = softmax( W_router · x )                 jeden wynik na moduł ekspercki
y      = Σ po top-k modułach eksperckich  score_e · Expert_e(x)

Warstwy atencji zwykle pozostają gęste (dense). Pomysł jest stary: Shazeer i in. (2017) doprowadzili zaszumione bramkowanie top-k (noisy top-k gating) do skali tysięcy modułów eksperckich. GShard (Lepikhin i in., 2020) i Switch Transformer (Fedus i in., 2021, który używał k = 1) sprawiły, że zadziałało to w skali transformerów.

Jaka część modelu pracuje na token

Model	Wszystkie parametry	Aktywne na token	Aktywny ułamek
Mixtral 8x7B (8 modułów eksperckich, top-2)	46,7B	12,9B	~28%
Qwen3.6-35B-A3B	~35B	~3B	~9%
DeepSeek-V3 (256 routowanych + 1 współdzielony, top-8)	671B	37B	~5,5%

Trend jest wyraźny: modułów eksperckich jest coraz więcej i są coraz mniejsze, a aktywny ułamek maleje. Obliczenia na token zależą od aktywnych parametrów. Pamięć zależy od wszystkich parametrów.

Najtrudniejsza część: równoważenie obciążenia

Pozostawione same sobie, routery się zapadają. Kilka modułów eksperckich wcześnie zaczyna działać dobrze. Są częściej wybierane, więcej trenowane i stają się jeszcze lepsze, a reszta głoduje. Dwa standardowe środki zaradcze:

• Pomocnicza funkcja straty. Switch Transformer dodaje α · E · Σ f_e · P_e, gdzie f_e to ułamek tokenów wysłanych do modułu eksperckiego e, a P_e to średnie prawdopodobieństwo, jakie przypisuje mu router. Ta funkcja osiąga minimum, gdy obciążenie jest równomierne. Działa, ale konkuruje z funkcją celu modelowania języka.
• Limity pojemności. Każdy moduł ekspercki dostaje na partię bufor o stałym rozmiarze, około (tokens / experts) × capacity factor. Tokeny, które przekraczają pojemność modułu eksperckiego, są w tej warstwie odrzucane i przechodzą tylko przez połączenie rezydualne. Wyższy współczynnik pojemności (capacity factor) odrzuca mniej tokenów, ale marnuje obliczenia na dopełnienie.

DeepSeek-V3 obszedł się bez pomocniczej funkcji straty dzięki przesunięciu routingu (bias) dla każdego modułu eksperckiego, korygowanemu po każdym kroku tak, żeby popychać obciążenie w stronę równowagi bez ruszania treningowej funkcji straty (szczegóły są w notatce o DeepSeek). Pomagają też drobnoziarniste moduły eksperckie i zawsze aktywny współdzielony moduł ekspercki: wspólna wiedza mieści się we współdzielonym module eksperckim, a wiele małych modułów eksperckich może się specjalizować.

Co daje MoE

Obliczenia treningowe na jednostkę jakości. Przy stałym budżecie obliczeniowym model rzadki (sparse) może pomieścić znacznie więcej parametrów niż model dense i osiągnąć niższą stratę. W pracy o Switch Transformerze podano, że osiągał tę samą jakość kilka razy szybciej niż model dense o takich samych obliczeniach na token. Dlatego największe otwarte modele to MoE: ich pojemność wyznacza pamięć, ale koszt treningu i inferencji na token wyznaczają aktywne parametry.

Ile kosztuje MoE

• Pamięć. Wszystkie moduły eksperckie trzeba przechowywać, więc MoE 671B potrzebuje pamięci modelu 671B, choć liczy jak model 37B.
• Komunikacja. W rozproszonym treningu i serwowaniu moduły eksperckie znajdują się na różnych GPU, a każda warstwa MoE wymaga wymiany all-to-all, żeby wysłać tokeny do ich modułów eksperckich i z powrotem. Duża część pracy inżynierskiej nad DeepSeek-V3 poszła na ukrycie tego ruchu.
• Wydajność batchingu. Różne tokeny wybierają różne moduły eksperckie, więc duża partia angażuje wiele modułów eksperckich i traci część przewagi z batchingu, jaką mają modele dense.
• Niestabilność treningu. Zapadanie się routera, skoki straty i wrażliwość na precyzję są częste. Przepisy są bardziej kruche niż dla modeli dense.
• Zachowanie. W moim własnym benchmarku agentów Qwen3.6-35B-A3B uzyskał 742,2 przy wyniku dyscypliny pętli 65,9, wobec 816,2 i 89,0 dla Qwen3.6-27B w wersji dense. To jeden harness i jedna para modeli, ale przypomina, żeby mierzyć na Twoim zadaniu (wszystkie dziesięć modeli jest w rankingu).

Wybór

Sytuacja	Skłaniaj się ku
Ograniczeniem jest budżet treningowy, pamięci jest dużo	MoE
Serwowanie dla wielu użytkowników na klastrze	MoE, z równoległością modułów eksperckich
Jedno GPU z małą ilością pamięci VRAM, dużo systemowej pamięci RAM	MoE z offloadem modułów eksperckich
Jedno GPU, wystarczająco dużo pamięci VRAM, agentowe używanie narzędzi	Dense: przetestuj oba, jak sugeruje mój benchmark
Małe projekty fine-tuningu	Dense: prostszy w trenowaniu i dostosowaniu

Zasady, których się trzymam

1. Podawaj obie liczby: wszystkie parametry dla pamięci, aktywne dla obliczeń i szybkości.
2. Pilnuj obciążenia modułów eksperckich przy fine-tuningu MoE. Nierównowaga to pierwszy znak, że przepis zaczyna się sypać.
3. Mierz zachowanie, a nie tylko stratę. Ta sama wartość perplexity nie oznacza tej samej dyscypliny narzędzi.

Źródła: Shazeer i in., Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer (2017). Lepikhin i in., GShard (2020). Fedus, Zoph i Shazeer, Switch Transformers (2021). Jiang i in., Mixtral of Experts (2024). Dai i in., DeepSeekMoE (2024). DeepSeek-AI, DeepSeek-V3 Technical Report (2024). Liczby z benchmarku pochodzą z mojego rankingu amber-bench.