Routing Mixture-of-Experts zmienia obliczenia lokalnego modelu, przesyłając każdy token tylko przez niewielki podzbiór eksperckich sieci feed-forward zamiast aktywować wszystkich ekspertów.
Sprawia to, że duży model MoE wygląda nietypowo na serwerze domowym: jego cały checkpoint może być ogromny, a obliczenia eksperckie wykonywane dla jednego tokenu mogą przypominać obciążenie znacznie mniejszego aktywnego modelu. Zaletą jest rzadka arytmetyka, a nie darmowa pamięć. Wagi ekspertów nadal trzeba przechowywać, a routing między urządzeniami może zamienić część zaoszczędzonych obliczeń w komunikację.
Gęsty transformer aktywuje te same parametry feed-forward dla każdego tokenu
W zwykłej warstwie gęstego transformera każdy token przechodzi przez tę samą sieć feed-forward. Zwiększanie liczby parametrów feed-forward zwiększa więc zarówno rozmiar modelu, jak i ilość obliczeń wykonywanych dla każdego tokenu.
Switch Transformer zestawia to z rzadko aktywowanymi warstwami Mixture-of-Experts, w których różne tokeny mogą wybierać różne podzbiory parametrów.
W przypadku lokalnego wnioskowania prowadzi to do pierwszego rozróżnienia w MoE: całkowita liczba parametrów określa, ile stanu modelu trzeba przechowywać, natomiast aktywowane parametry w dużej mierze określają obliczenia eksperckie wykonywane dla każdego tokenu.
Router ocenia każdy token względem dostępnych ekspertów
W warstwie MoE niewielki router analizuje reprezentację tokenu i generuje wyniki lub prawdopodobieństwa dla kandydatów na ekspertów. Następnie środowisko uruchomieniowe wybiera ich ograniczoną liczbę, zazwyczaj top-1 lub top-k, zależnie od architektury.
NVIDIA Megatron Core udostępnia router określający, do których ekspertów trafia każdy token. Decyzja routera zmienia macierze ekspertów, które przetworzą dany token.
Dwa tokeny w tym samym zapytaniu mogą więc aktywować różne wagi ekspertów, mimo że korzystają ze wspólnych mechanizmów attention i innych gęstych części modelu.
Rzadka aktywacja ogranicza obliczenia eksperckie, ale nie całkowity rozmiar przechowywanych wag
Jeśli warstwa zawiera ośmiu ekspertów, ale każdy token jest kierowany do dwóch, dla tego tokenu wykonywane są tylko obliczenia wybranych ekspertów. Pozostałe macierze ekspertów pozostają bezczynne w tym kroku.
Badania nad Expert Choice opisują MoE jako sposób na zwiększenie liczby parametrów przy zachowaniu względnie ograniczonej liczby obliczeń na token. Dlatego checkpoint MoE może deklarować bardzo dużą całkowitą liczbę parametrów, ale znacznie mniejszą liczbę parametrów aktywnych.
Serwer domowy nadal musi mieć pełny zestaw wag ekspertów dostępny w jakimś miejscu, chyba że środowisko uruchomieniowe przesyła je strumieniowo lub stosuje offloading. Rzadkie obliczenia nie są tym samym co rzadkie przechowywanie.
Rozmieszczenie ekspertów może zamienić routing w komunikację między urządzeniami
Na jednym GPU wybór eksperta zmienia głównie to, które lokalne bloki wag są odczytywane. Na kilku GPU ekspertów można rozdzielić tak, aby reprezentacja tokenu musiała trafić do urządzenia przechowującego wybranego eksperta, a następnie wrócić do głównego przepływu warstwy.
Projekt wnioskowania MoE w DeepSpeed przydziela grupy ekspertów za pomocą równoległości ekspertów między GPU. Routing obejmuje więc zarówno komunikację, jak i mnożenie macierzy.
Mały domowy serwer z wieloma GPU może zatem zostać ograniczony przez połączenie między urządzeniami, nawet gdy obliczenia dla każdego tokenu są rzadkie. Topologia PCIe i obsługa komunikacji peer-to-peer mają większe znaczenie, niż sugerowałaby sama liczba aktywnych parametrów.
Nierównomierny routing tworzy przeciążonych ekspertów i niewykorzystaną moc obliczeniową
Rzeczywiste zapytania nie muszą rozdzielać tokenów równomiernie. Jeśli wiele tokenów wybierze tego samego eksperta, dane urządzenie lub kernel stanie się wąskim gardłem, podczas gdy pozostali eksperci będą czekać.
MoETuner wskazuje nierównomierny routing tokenów i aktywację ekspertów jako praktyczne wąskie gardła obsługi, ponieważ niektóre urządzenia mogą gromadzić więcej kierowanych zadań i komunikacji niż inne.
W lokalnym wnioskowaniu nierównomierny routing może powodować zmienne opóźnienie generowania tokenów między zapytaniami, nawet gdy długość kontekstu i rozmiar modelu są podobne. Model dynamicznie wybiera inną ścieżkę obliczeń.
Planuj pojemność lokalnego MoE osobno na podstawie całkowitych wag i aktywnej ścieżki
Przydatne oszacowanie sprzętowe powinno uwzględniać całkowity rozmiar wag modelu, liczbę aktywnych ekspertów na token, koszt warstw gęstych, pamięć podręczną KV, kwantyzację oraz to, czy eksperci znajdują się na jednym akceleratorze, kilku GPU, w pamięci RAM CPU czy na nośniku danych.
Omówienie lokalnej pamięci AI i planowania akceleratorów w ZimaSpace przedstawia szerszy kontekst pojemności serwera domowego. MoE dodaje jeszcze jeden podział między pojemnością rezydentną a aktywnymi obliczeniami.
Testuj zapytania z różnych zadań, ponieważ wzorce routingu mogą się zmieniać. Mierz liczbę tokenów na sekundę, wykorzystanie poszczególnych urządzeń, obciążenie ekspertów, ruch komunikacyjny i obecność danych w pamięci, zamiast zakładać, że deklarowana liczba aktywnych parametrów przewidzi zachowanie całego systemu.
W przypadku szczególnie dużych lokalnych checkpointów analiza wdrażania dużych modeli w ZimaSpace dotyczy powiązanej kwestii pojemności. Routing zmienia aktywne obliczenia, ale to całkowita obecność wag w pamięci i ich rozmieszczenie między urządzeniami nadal decydują o praktyczności modelu.
Centrum Technologii i Sztucznej Inteligencji
Więcej do przeczytania

Czy kamery domowe mogą synchronizować zdarzenia bez korzystania z chmurowych usług czasu?
Wyjaśnienie działania czasu kamery bez chmury, jego kompromisów związanych ze współdzielonymi zasobami, trzy często zadawane pytania dotyczące rozsyłania zapytań oraz praktyczny protokół weryfikacji.

Czy lokalna usługa AI może wykryć uszkodzone warstwy modelu przed wnioskowaniem?
Wyjaśnienie wykrywania uszkodzeń warstwy modelu oparte na mechanizmach, kompromisy związane ze współdzielonymi zasobami, trzy najczęściej zadawane pytania dotyczące rozgałęziania zapytań oraz praktyczny protokół weryfikacji.

Czy system RAG można przywrócić bez ponownego generowania wszystkich wektorów embeddingowych?
Wyjaśnienie działania mechanizmu przywracania RAG bez ponownego tworzenia osadzeń, kompromisy związane ze współdzielonymi zasobami, trzy często zadawane pytania dotyczące rozsyłania zapytań oraz praktyczny protokół...

