Udało mi się uruchomić model językowy o 284 miliardach parametrów na laptopie zaledwie z 3,2 GB pamięci RAM, używając wyłącznie czystego C99 i dysku NVMe. Trikiem było strumieniowanie wag ekspertów modelu zamiast ładowania całego 160-gigabajtowego checkpointu do pamięci, co udowadnia, że nawet największe modele typu mixture-of-experts (MoE) można zmieścić na sprzęcie konsumenckim.

Dlaczego to ma znaczenie

Duże modele językowe (LLM) napędzają generowanie kodu, wsparcie badawcze i wiele innych zastosowań, ale ich rozmiar zazwyczaj zmusza użytkowników do korzystania z kosztownych serwerów wieloprocesorowych (multi-GPU) lub do stosowania silnej kwantyzacji, która obniża jakość. Wykazanie, że model MoE o 284 miliardach parametrów może działać przy użyciu zaledwie kilku gigabajtów pamięci RAM, otwiera drzwi dla hobbystów, małych startupów i badaczy z ograniczonym budżetem do eksperymentowania z najnowocześniejszymi modelami bez poświęcania ich precyzji.

Model i wąskie gardło sprzętowe

DeepSeek-V4-Flash przechowuje 284 miliardy parametrów w 256 ekspertach na każdą warstwę transformera. Surowy checkpoint zajmuje na dysku około 160 GB – rozmiar, który przytłacza 3,2 GB pamięci RAM w typowym laptopie. Tradycyjne potoki wnioskowania (inference pipelines) próbują załadować cały checkpoint do pamięci, co szybko wyczerpuje budżet RAM i prowadzi do awarii.

Strumieniowanie wag ekspertów: główna idea

Architektury MoE aktywują tylko niewielki podzbiór ekspertów dla każdego tokenu. W DeepSeek-V4-Flash router wybiera sześciu ekspertów spośród 256 na warstwę. Ponieważ obliczenia nigdy nie dotykają nieaktywnych ekspertów, silnik wnioskowania może pominąć ich ładowanie.

Implementacja traktuje checkpoint jako źródło strumieniowe. Gdy router decyduje, których ekspertów potrzebuje dla bieżącego tokenu, silnik pobiera te bloki wag z dysku NVMe do pamięci podręcznej LRU (least-recently-used) znajdującej się w RAM-ie. Jeśli pamięć podręczna jest wystarczająco duża, ci sami eksperci są ponownie wykorzystywani dla kolejnych tokenów, co generuje trafienia w pamięci podręcznej (cache hits); jeśli jest zbyt mała, silnik częściej czyta z dysku. Wynikiem jest szczytowe zużycie pamięci na poziomie 3,23 GB, co mieści się w limitach laptopa, przy jednoczesnym zachowaniu wag o pełnej precyzji i braku konieczności akceleracji GPU.

Trudne lekcje wyciągnięte z implementacji

1. Płynny tekst nie jest dowodem poprawności Błędny kernel może wciąż generować wiarygodnie brzmiące zdania, zwłaszcza gdy wzorce językowe modelu maskują błędy numeryczne. Zweryfikowałem każdą z 14 krytycznych operacji względem świeżej referencji PyTorch, sprawdzając, czy różnica numeryczna mieści się w bardzo małej tolerancji. Pominięcie tego kroku pozwoliłoby na przeoczenie subtelnych odchyleń.

2. Wspólne tryby awarii mogą oszukać testy Błąd uszkodzenia pamięci spowodował, że wybory routingu ograniczyły się do garstki ekspertów, co sztucznie zwiększyło współczynnik trafień w pamięci podręcznej z 52% do 95%, dając złudzenie ogromnego przyspieszenia. Ponieważ zestaw testów porównywał dwie wersje tego samego błędnego kodu, nie wykrył problemu. Rozwiązaniem jest dodanie niezależnej ścieżki referencyjnej – kodu, który nie dzieli żadnej logiki z główną implementacją – aby wspólna wada nie przeszła niezauważona.

3. Mierz, zanim zaczniesz optymalizować Założyłem, że kopiowanie pamięci zajmuje 1 ms i poświęciłem czas na jego optymalizację. Profilowanie wykazało, że operacja ta zajmuje w rzeczywistości 3,6 ms, czyli 22% całkowitego czasu wnioskowania. Lekcja: nigdy nie polegaj na intuicji w sekcjach krytycznych dla wydajności; precyzyjny pomiar to jedyny niezawodny przewodnik.

4. Warunki termiczne drastycznie wpływają na przepustowość Uruchomienie benchmarków na „nagrzanym” laptopie dało czasy wykonania nawet trzykrotnie wolniejsze niż na zimnym urządzeniu. Podwyższona temperatura ograniczała przepustowość dysku NVMe i spowalniała procesor, zniekształcając wyniki. Zawsze rejestruj stan termiczny systemu, gdy publikujesz liczby dotyczące wydajności.

Jak wyglądają liczby

  • Rozmiar modelu na dysku: ~160 GB
  • Szczytowe zużycie RAM: 3,23 GB
  • Eksperci na token: 6 (z 256)
  • Współczynnik trafień w pamięci podręcznej: zmienia się wraz z ilością RAM; przy 3,2 GB ulega wahaniom.
  • Brak kwantyzacji: wagi o pełnej precyzji są strumieniowane, co zachowuje jakość modelu.

Jeśli budżet RAM spadnie poniżej około 3,21 GB, pamięć podręczna nigdy się nie zapełni, a silnik będzie strumieniował dane przy każdym tokenie, co spowoduje gwałtowny spadek wydajności.

Kod źródłowy jest publicznie dostępny pod adresem github.com/ronak-create/deepseek-v4-in-c. Dla osób chcących powtórzyć lub rozszerzyć eksperyment istnieje kanał dyskusyjny społeczności pod adresem t.me/GyaanSetuAi.

Wnioski

Strumieniowanie wyłącznie tych ekspertów, których faktycznie używa model MoE, pozwala na uruchomienie modelu LLM o 284 miliardach parametrów na skromnym laptopie, bez kwantyzacji czy akceleracji GPU. Eksperyment pokazuje, że sprytne przemieszczanie danych, rygorystyczna walidacja i zdyscyplinowane pomiary pozwalają ominąć ograniczenia sprzętowe, które wielu uznaje za niezmienne.