Jak uruchomić sieć neuronową z 744 miliardami parametrów na zwykłym komputerze

Gdy otwierasz stronę modelu takiego jak GLM-5.2 z 744 miliardami parametrów lub Kimi K3 z 2,8 biliona, pierwsza myśl jest dość oczywista: potrzebujesz serwerowni z tuzinem GPU H100. Jeśli nie masz takich zasobów pod ręką, jedyną opcją pozostaje płacenie za wywołania API.

Niedawno natknąłem się na projekt JustVugg/colibri. Autor napisał lekki silnik inferencyjny w czystym C bez zewnętrznych zależności. Silnik jest w stanie uruchamiać ogromne modele MoE na zwykłym komputerze stacjonarnym lub laptopie z 24 GB RAM, pobierając wagi bezpośrednio z szybkiego dysku SSD.

W czym tkwi trick

Architektura Mixture-of-Experts (MoE) jest zaprojektowana tak, że cały model nie jest wymagany do wygenerowania jednego tokena. Na przykład w GLM-5.2 spośród 744 miliardów parametrów aktywnych jest tylko około 40 miliardów. Co więcej, od tokena do tokena zmienia się tylko około 11 GB wag, odpowiadających ekspertom wybranym przez router.

Zamiast próbować upchnąć 370 GB modelu do pamięci wideo, silnik rozkłada dane w hierarchii pamięci masowej:

• Gęsta część modelu (embeddings, attention, warstwy współdzielone) waży około 9,9 GB w kwantyzacji int4 i pozostaje na stałe w RAM.
• Prawie 20 000 ekspertów znajduje się na szybkim dysku NVMe SSD i jest ładowanych na żądanie poprzez asynchroniczne I/O.
• Często używani eksperci osiadają w cache LRU pamięci RAM lub VRAM.

Zasadniczo działa to jak kompilator JIT, tylko dla wag sieci neuronowych. Silnik śledzi statystyki dostępu, zapamiętuje gorące gałęzie i cache'uje dokładnie tych ekspertów, którzy są potrzebni w bieżącym kontekście.

Jak działa silnik

Kod źródłowy jest zwięzły. Rdzeń jest napisany w C (każda rodzina modeli jest oddzielona do własnego pliku, na przykład c/colibri.c dla GLM) i kompiluje się za pomocą gcc lub clang z obsługą OpenMP. Żadnych gigantycznych frameworków ani potworów runtime'owych. Python jest używany tylko do jednorazowej konwersji wag i opakowania interfejsu webowego.

Podczas generowania każdego tokena silnik wykonuje kilka kroków:

1. Oblicza routing jedną warstwę do przodu przez osobny wątek prefetch. Router przewiduje potrzebnego eksperta z dokładnością około 71%, więc odczyty z dysku odbywają się równolegle z obliczeniami.
2. Łączy żądania do identycznych ekspertów w batch, aby wyeliminować zduplikowane odczyty.
3. Odczytuje trzy macierze każdego eksperta w jednym wywołaniu systemowym pread.
4. Zapisuje statystyki trafień do pliku historii, aby przy kolejnych uruchomieniach gorące warstwy były wstępnie przypięte w pamięci.

Obsługa dwóch urządzeń pamięci masowej jest ciekawie zaimplementowana. Jeśli rozdzielisz kopie wag na dwa różne dyski SSD, silnik rozkłada żądania ekspertów proporcjonalnie do prędkości odczytu każdego dysku. Para dysków o prędkościach 9 GB/s i 3 GB/s przyspiesza odczyt o około jedną trzecią.

Do przyspieszania obliczeń obsługiwane są CUDA, Metal na chipach Apple Silicon oraz Vulkan. Wariant Vulkan działa nawet ze starszymi GPU, takimi jak AMD RX 580 przez sterownik RADV, dla którego producent dawno zamknął wsparcie dla najnowszego ROCm.

Paczka zawiera panel webowy z wizualizacją aktywności ekspertów. Na stronie Atlas możesz obracać trójwymiarową mapę tysięcy ekspertów i obserwować, jak różne grupy radzą sobie z kodem, tematami prawnymi czy językami obcymi.

Rzeczywiste liczby prędkości

Nie ma cudów, więc prędkość jest ograniczona przepustowością dysku i dostępną pamięcią.

Benchmarki projektu zarejestrowały następujące wyniki na modelu GLM-5.2:

• Laptop z 25 GB RAM i zimnym cache'em generuje skromne 0,05-0,1 tokena na sekundę. Jest wolny, ale model odpowiada bez zniekształceń logiki.
• Stacja robocza ze 128 GB RAM bez dedykowanego GPU dostarcza około 1,8 tokena na sekundę na rozgrzanym cache'u.
• Laptop z mobilnym RTX 5070 Ti przyspiesza do 1,07 tokena na sekundę dzięki potokowi GPU.
• Serwer z sześcioma kartami RTX 5090 trzyma ekspertów całkowicie w pamięci wideo i pokazuje 5,8-6,8 tokena na sekundę.

Obsługiwane modele

Oprócz bazowego GLM-5.2 autor dodał wsparcie dla czterech kolejnych architektur:

• Inkling (975B) — uruchomienie gęstej części w int4 wymaga około 25 GB RAM i 469 GB miejsca na dysku.
• Kimi K3 (2.8T) — olbrzym ważący 1,6 TB, odczytuje natywne wagi MXFP4 bezpośrednio z oryginalnych shardów bez konwersji.
• DeepSeek V4 Flash (284B) — działa z 167 GB wag w formacie fp4/fp8 i wymaga 16 do 22 GB RAM.
• OLMoE (7B) — kompaktowy wariant z 4 GB wag do szybkich eksperymentów na 8 GB RAM.

Jak uruchomić

Silnik jest dystrybuowany jako prebudowane binarki dla Linuksa, macOS i Windows lub może być zbudowany ze źródeł w ciągu minuty:

git clone https://github.com/JustVugg/colibri && cd colibri/c
./setup.sh

Po zbudowaniu pobierz skwantowane wagi dla wybranego modelu z Hugging Face (na przykład GLM-5.2 int4 zajmuje około 372 GB) i uruchom czat przez terminal:

COLI_MODEL=/path/to/glm52_i4 ./coli chat

Jeśli chcesz lokalny serwer kompatybilny z API OpenAI wraz z panelem webowym, uruchom:

./coli web --model /path/to/glm52_i4

Przed uruchomieniem warto sprawdzić rozkład pamięci za pomocą ./coli plan i przeprowadzić szybki test sprzętu za pomocą ./coli tune.

Kto znajdzie ten projekt użyteczny

Colibrì raczej nie sprawdzi się w produkcji o wysokim obciążeniu ze względu na opóźnienia odczytu dysku na sprzęcie konsumenckim. Jest jednak świetnym znaleziskiem dla badaczy, entuzjastów i deweloperów, którzy chcą przetestować rozumowanie najlepszych otwartych modeli lokalnie bez kupowania serwerowych GPU za miliony rubli. Rdzeń kodu jest zwięzły i przejrzysty, co czyni silnik wygodnym do użycia jako plac zabaw dla własnych eksperymentów z I/O i kwantyzacją.