Dostępna wersja Qwen3.8-Flash-Next na kartach RTX 3090 z użyciem mechanizmu offloadingu tensorów w llama.cpp
Dlaczego model rzadki o pojemności 88 GB i 180 miliardów parametrów pasuje do kart graficznych konsumenckich, oraz w jaki sposób flagi takie jak -ot, -ncmoe i mmap w llama.cpp rozkładają jego zasoby pomiędzy VRAM, RAM i NVMe.
Qwen3.8-Flash-Next to model otwarty składający się z około 180 miliardów parametrów, a jego skwantyzowane pliki zajmują 88 GB, mimo to ludzie donoszą o uruchamianiu go na pojedynczej karcie RTX 3090 z 24 GB pamięci VRAM. Na papierze jest to o rzęd wielkości za mało. Działa to dzięki architekturze modelu, a nie dzięki sprytnemu skwantyzowaniu czy niezwykle potężnej karcie graficznej – duże części modelu w ogóle nie muszą znajdować się na karcie graficznej. Ten artykuł wyjaśnia cztery decyzje projektowe, które to umożliwiają, a następnie przedstawia kompletną konfigurację llama.cpp dla zestawu z trzema kartami graficznymi oraz maszyny z jedną kartą, w tym co oznacza każda ważna flaga i jaki przepustowość można realistycznie oczekiwać.
Dlaczego Flash-Next warto uruchamiać lokalnie
Alibaba opublikowała Flash-Next w sierpniu. Według dostępnych wyników, model ten wyprzedza Qwen3.8-27B, DeepSeek V4 Flash (0731) oraz, w kilku testach związanych z agentami, Opus 4.6, przy jednoczesnym wykorzystaniu zaledwie 6 miliardów parametrów na token. Rankingi w testach zmieniają się szybko, dlatego przed uznaniem tych porównań za ostateczne warto sprawdzić aktualne oceny. Ważniejszy jest sposób strukturyzacji modelu, ponieważ to właśnie ta struktura decyduje o tym, jaki sprzęt może go obsługiwać.
Cztery rozwiązania architektoniczne, które przenoszą obliczenia z GPU
Flash-Next łączy w sobie cztery różne koncepcje. Każda z nich przenosi część kosztownych obliczeń z drogiego sprzętu na tańszy lub je całkowicie eliminuje.
Ultra-sparse mixture of experts
Modell składa się z 48 warstw, a każda z nich zawiera 512 specjalistycznych podsieci. Każdy token przechodzi tylko przez 11 z nich: 10 wybranych przez router, który analizuje token i wybiera najbardziej odpowiednich specjalistów, plus 1 wspólnego specjalistę, którego używa każdy token bez konieczności routingu. Innymi słowy, około 2% specjalistów wykonuje pracę dla danego tokena.
Pomocnym porównaniem jest szpital z 512 specjalistami na dyżurze oraz jednym lekarzem rodzinnym, który zawsze przebywa w pomieszczeniu. Każdy pacjent otrzymuje dziesięć konsultacji dopasowanych do jego objawów, a pozostali 501 specjalistów nie bierze udziału. Kluczowym aspektem przy lokalnej inferencji jest to, że „na dyżurze” oznacza po prostu „dostępny”. Specjalista nie musi znajdować się na karcie GPU, aby być dostępnym.
Wspólny ekspert istnieje dlatego, że projekty oparte wyłącznie na routingu mają tendencję do utraty ogólnej wiedzy, której potrzebuje każdy token. Umieszczenie tej wiedzy w zawsze aktywnym generaliście pozwala ekspertom routowanym specjalizować się bardziej intensywnie. Większość obecnych projektów typu MoE zawiera takiego generalistę, a jego parametry stanowią część 6 miliardów aktywnych elementów.
Gated DeltaNet plus Qwen Sparse Attention
Standardowy transformer przechowuje wpis klucz/wartość dla każdego tokena, który przetworzył. Ten cache KV rośnie liniowo wraz z długością kontekstu i staje się ogromny przy dużych rozmiarach. Flash-Next w dużej mierze unika tego problemu. Trzy z czterech warstw wykorzystują Gated DeltaNet, który kompresuje historię do małego stanu o stałej wielkości. Pozostała warstwa w każdej grupie używa Qwen Sparse Attention, który odczytuje dane z ustalonego budżetu składającego się z 512 bloków i 2 048 tokenów, niezależnie od tego, czy kontekst zawiera 32 K, czy milion tokenów.
Efekt praktyczny jest znaczący: przy kontekście 178K pamięć KV w podanych konfiguracjach zajmuje około 6 GB, podczas gdy porównywalny model o dużej gęstości potrzebowałby około dziesięciokrotnie więcej pamięci. To właśnie dlatego karta o pojemności 24 GB może w ogóle obsłużyć długą rozmowę.
Zamknięty, wielotorowy strumień resztkowy
Klasyczne transformery kierują wszystko przez jeden strumień resztkowy od pierwszej do ostatniej warstwy, a w głębokich sieciach wcześnie wykryte cechy mają tendencję do rozcieńczania się w miarę postępu. Flash-Next poszerza tę ścieżkę do czterech równoległych torów, przy czym nauczone bramy kontrolują to, co wpływa do każdego toru i z niego wychodzi. Podczas treningu jeden z tych torów specjalizował się jako kanał długodystansowy, który przenosi wczesne informacje głęboko do wnętrza sieci. Jest to niewielka zmiana architektoniczna, która zwiększa możliwości bez znaczących kosztów.
Tabela embeddingów n-gramowych
Czwarty element to tabela zawierająca 51 miliardów parametrów, więcej niż wszystkie pozostałe elementy modelu razem wzięte, która w ogóle nie wykonywa żadnych mnożeń macierzy. Jest to struktura wyszukiwania, a ona jest głównym powodem, dla którego pojedyncza karta graficzna do gier może być wystarczająca.
Tabela n-gramów: wiedza, która nie wymaga karty graficznej
W zwykłym modelu językowym każdy token jest mapowany na identyfikator, a model wyszukuje ten identyfikator w tabeli embeddingów – jedna linia na token. Linia odpowiadająca pojedynczemu tokenowi zawiera bardzo mało informacji o kontekście. W przypadku frazy takiej jak „Dostojewski napisał Braci”, embedding słowa „the” nic nie mówi o Karamazowach; model musi samodzielnie wywnioskować dalszy ciąg za pomocą swoich kosztownych warstw, i musi to robić za każdym razem, gdy pojawia się ten wzorzec.
Flash-Next dodaje drugą tabelę, której wiersze są oznaczane krótkimi frazami zamiast pojedynczymi tokenami. Koncepcyjnie wpisy wyglądają jak poniższy szkic: po lewej stronie haszowana fraza, a po prawej rodzaj wskazówki, którą koduje jej wyuczony wektor.
Drawer "born on october" → hint: 1985, Honolulu, singer
Drawer "dostoevsky brothers" → hint: Karamazov, novel, 1880
Drawer "def main(" → hint: python entry point
Podczas odczytu model haszuje najnowsze tokeny, pobiera odpowiadający wiersz i otrzymuje w zasadzie za darmo uprzednio obliczoną wskazówkę. Nikt nie wpisywał tych wierszy ręcznie. Podczas treningu, za każdym razem gdy fraza była następowana przez określoną kontynuację, jej wiersz był lekko dostosowywany w tym kierunku, tak że po bilionach tokenów każdy wiersz przybliża to, co zwykle następuje dalej. Tabela zawiera około 20 milionów wpisów bigramowych i trigramowych, a jej wynik jest wstrzykiwany raz, na wczesnym etapie, w warstwie 2. W rzeczywistości jest to zapamiętywanie częstych sformułowań, a duża część rzeczywistego tekstu składa się z takich sformułowań.
Różnica między tymi dwoma rodzajami wiedzy w modelu jest tym, co umożliwia rozdzielenie sprzętu. Poniższe porównanie je podsumowuje.
| | Neural network | N-gram table |
|------------------|-------------------------|-------------------------|
| Work per token | Matrix math (expensive) | Drawer lookup (no math) |
| Needs the GPU? | Yes, every millisecond | No — CPU can fetch it |
| Lives in | VRAM | RAM. Even SSD. |
Kluczową cechą jest to, że wiersz do pobrania zależy wyłącznie od tekstu wejściowego, a nie od żadnego ukrytego stanu w sieci. Gdy tylko prompt zostanie ztokenizowany, CPU dokładnie wie, które wiersze będą potrzebne, więc może je wcześniej pobrać, podczas gdy GPU jest nadal zajęte wcześniejszymi warstwami.
To pozwala rozmieścić model w hierarchii pamięci zgodnie z tym, co każdy poziom potrafi robić najlepiej:
- VRAM (szybka, droga): około 6 miliardów parametrów, które są faktycznie obliczane dla każdego tokena.
- Pamięć RAM systemowa (umiarkowana, tania): niewykorzystywane wagi ekspertów oraz tabela n-gramów o pojemności 29 GB.
- Pamięć NVMe (powolna, najtańsza): dane przekraczające dostępną pamięć, ładowane dynamicznie w momencie potrzeby.
Karta graficzna przestaje być miejscem przechowywania całego modelu i staje się miejscem, gdzie odbywa się aktywna obliczanie.
Konfiguracja z trzema kartami graficznymi do codziennego użytku
Rozważmy serwer zbudowany z trzech kart RTX 3090 (łącznie 72 GB pamięci VRAM), 48 GB pamięci systemowej DDR4 oraz dysku PCIe Gen3 NVMe przechowującego wagi modelu. Nic w tym nie przypomina sprzętu klasy stacji roboczej; to typ maszyny, którą wielu programistów buduje z starszych kart do gier.
Plik modelu użyty tutaj to wersja UD-IQ4_XS z repozytorium unsloth’s GGUF dla tego modelu na Hugging Face, o rozmiarze około 88 GB podzielonego na trzy fragmenty: mniej więcej 59 GB wag głównych modelu plus 29 GB tabeli n-gramów. Obsługa tej architektury jest stosunkowo nowa, więc przed jej wypróbowaniem pobierz najnowszy kod źródłowy llama.cpp i go zbuduj ponownie.
Poniższy polecenie uruchamia llama-server na trzech z GPU znajdujących się w maszynie. Większość flag jest standardowa (host, port, parametry próbkowania, rozmiary partii, długość kontekstu), więc należy zwrócić uwagę na flagi przekazywania obciążenia, flagi dzielenia oraz tryb ładowania, o których mowa zaraz dalej.
CUDA_VISIBLE_DEVICES=0,2,3 CUDA_SCALE_LAUNCH_QUEUES=4x llama-server \
-m /mnt/data_2t/ai_models_all/llm_hf_models/unsloth/Qwen3.8-Flash-Next-GGUF/Qwen3.8-Flash-Next-UD-IQ4_XS-00001-of-00003.gguf \
--alias Qwen3.8-Flash-Next \
--jinja \
--metrics \
--host 0.0.0.0 \
-ngl 99 \
--batch-size 4096 \
--ubatch-size 512 \
--flash-attn on \
--temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0 --repeat-penalty 1.0 \
--split-mode layer \
--tensor-split 0.9,0.95,1.0 \
--fit off \
--main-gpu 0 \
--ctx-size 178000 \
--parallel 1 \
--image-min-tokens 1024 \
--reasoning-format none \
--timeout 1200 \
--ctx-checkpoints 8 \
--port 8082 \
--load-mode mmap \
--cache-type-k q8_0 --cache-type-v q8_0 \
-ot '^per_layer_token_embd\.weight$=CPU' \
--reasoning-effort low \
-t 14
Przytwierdzenie tabeli n-gramów do pamięci RAM systemowej
-ot '^per_layer_token_embd\.weight$=CPU' to opcja nadpisu, która mówi llama.cpp, że każdy tensor, którego nazwa pasuje do wyrażenia regularnego, powinien być przechowywany w pamięci CPU zamiast w VRAM. Tabela n-gramów jest przechowywana pod nazwą tensora per_layer_token_embd.weight, więc ta jedna linijka zapobiega umieszczaniu całych 29 GB tej informacji w kartach graficznych. Gdy token wymaga danej rzędu, CPU je pobiera i przekazuje dalej, co jest dokładnie tym mechanizmem wcześniejszego pobierania danych opisanym powyżej. Symboli ^ i $ są istotne – zapewniają one, że wzorzec pasuje tylko do tego konkretnego tensora i nie przenosi przypadkowo innych wag.
Zezwalanie systemowi operacyjnemu na zarządzanie lokalizacją danych za pomocą mmap
--load-mode mmap mapuje plik modelu w pamięci, zamiast wcześniej odczytywać go do RAM. System operacyjny następnie przechowuje często używane strony w dostępnym buforze stron, a rzadko używane strony pozostawia na SSD. Przy 48 GB RAM i tabeli o rozmiarze 29 GB jest to właściwa równowaga – jądro decyduje, co zasługuje na pozostanie w pamięci. Na maszynie z dużą ilością pamięci, np. 128 GB, lepszym rozwiązaniem jest użycie opcji none, ponieważ cały plik jest odczytywany tylko raz, a później nie występują błędy strony.
Rozdzielenie warstw między kartami
--split-mode layer w połączeniu z --tensor-split 0.9,0.95,1.0 dzieli 59GB masy danych głównej na kolejne grupy warstw, po jednej grupie na każdą kartę GPU, przy nieco nierównych proporcjach, aby pierwsza karta miała zapas mocy na dodatkowe obowiązki jako --main-gpu. Parametr -ngl 99 umieszcza wszystkie 48 warstw na kartach GPU, co daje około 20GB na każdą kartę. Pamięć cache KV, skwantyzowana do formatu q8_0 za pomocą --cache-type-k i --cache-type-v, znajduje się obok wag modelu i pomieści 178K tokenów w około 6GB.
Zmierzona przepustowość na trzech kartach
W tym ustawieniu podano poniżej przedstawione liczby.
Decode: 30-50 tokens/second
Prefill: 400-700 tokens/second
Context: 178,000 tokens
To jest szybsze niż prędkość odczytu modelu z klasy zbliżonej do najnowszych rozwiązań, uruchamianego na zwykłych kartach konsumenckich w obudowie typu mid-tower.
Konfiguracja z jedną kartą GPU i jej ograniczenia
Jedna karta 3090 wystarczy, jeśli spełniasz jedno warunek: przynajmniej 64 GB pamięci RAM systemowej. Tabela n-gramów oraz przeniesione elementy sztucznej inteligencji potrzebują miejsca do przechowywania, a pamięć systemowa jest zazwyczaj najtańszym ulepszeniem dla lokalnej maszyny AI.
Polecenie wykorzystuje tę samą plik GGUF. Istotne różnice to nowy flag -ncmoe, pojedyncza widoczna karta GPU, użycie --load-mode none zamiast mmap, oraz mniej wątków CPU.
CUDA_VISIBLE_DEVICES=0 llama-server \
-m /mnt/data_2t_3/ai_models_all/unsloth/Qwen3.8-Flash-Next-GGUF/Qwen3.8-Flash-Next-UD-IQ4_XS-00001-of-00003.gguf \
--alias Qwen3.8-Flash-Next \
--jinja \
--metrics \
--host 0.0.0.0 \
-ngl 99 \
-ncmoe 38 \
--batch-size 4096 \
--ubatch-size 1024 \
--flash-attn on \
--temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0 --repeat-penalty 1.0 \
--ctx-size 178000 \
--parallel 1 \
--image-min-tokens 1024 \
--reasoning-format none \
--timeout 1200 \
--ctx-checkpoints 8 \
--port 8083 \
--load-mode none \
-ot '^per_layer_token_embd\.weight$=CPU' \
--reasoning-effort low \
-t 8
Co robi -ncmoe 38
-ncmoe 38 przechowuje wagi elementów sztucznej inteligencji pierwszych 38 warstw w pamięci RAM CPU, podczas gdy ostatnie 10 warstw przechowuje je w VRAM. Dzięki temu około 43 GB wag elementów sztucznej inteligencji znajduje się w pamięci systemowej. Komponenty odpowiedzialne za uwagę oraz wspólne elementy każdej warstwy nadal działają na karcie GPU dzięki użyciu flagi -ngl 99.
Zapisywanie tak dużej ilości danych w pamięci RAM nadal jest możliwe dzięki niskiej gęstości informacji. Każdy token aktywuje 10 z 512 ekspertów na każdej warstwie, więc łącznie dotyka jedynie około 1,3 GB wag tych ekspertów. Eksperti przechowywani w RAM są obliczani na procesorze CPU, gdzie się znajdują, bez konieczności kopiowania ich na kartę graficzną GPU, natomiast eksperci w VRAM działają bezpośrednio na karcie. Procesor CPU jest znacznie wolniejszy od modelu 3090, więc występuje rzeczywisty koszt, ale skala ten problemu odpowiada mniej więcej 2% wag, z którymi ma do czynienia każdy token, a nie całej ilości przechowywanych danych.
Ponieważ w tym przypadku RAM może przechowywać tak dużo danych, opcja --load-mode none odczytuje plik w całości podczas uruchamiania, zamiast polegać na błędach strony, co jest kolejnym powodem, dla którego istotna jest minimalna ilość pamięci 64 GB.
Dostosowywanie do innych kart
To samo polecenie działa na kartach RTX 4090 lub 5090; tylko parametr -ncmoe wymaga dostosowania do dostępnej ilości pamięci VRAM. Zalecane wartości początkowe są wymienione poniżej.
| GPU | VRAM | Suggested -ncmoe | Experts in RAM |
|------------|------|------------------|----------------|
| RTX 3090 | 24GB | 38 | ~43GB |
| RTX 4090 | 24GB | 38 | ~43GB |
| RTX 5090 | 32GB | 28-30 | ~32GB |
Za każdym razem, gdy zmniejszasz wartość -ncmoe, ekspertowie jednego warstwy, czyli około 1,1 GB pamięci, wracają na GPU. Po załadowaniu modelu sprawdź wyniki komendy nvidia-smi i postaraj się zachować około 500 MB wolnej pamięci VRAM; działanie karty z pełną ilością danych powoduje błędy braku pamięci, gdy rozmiar kontekstu rośnie.
Ustalanie realistycznych oczekiwań
Na pojedynczej karcie 3090 dekodowanie odbywa się z prędkością 15 do 20 tokenów na sekundę. Jest to wartość przydatna, ale jedynie minimalnie – wystarczająco szybka, by móc czytać wraz z procesem, ale na tyle wolna, że długie generacje wydają się powolne, ponieważ część obliczeń faktycznie odbywa się na CPU w pamięci RAM systemowej. Jako dowód koncepcyjny lub aby wykorzystać maszynę, którą już posiadasz, uruchomienie modelu klasy 180B z prędkością czytania na jednej karcie do gier jest imponujące.
Aby mieć asystenta dostępnego przez cały dzień do programowania i codziennej pracy, potrzeba trzech lub czterech karty 3090, aby zapewnić komfortową wydajność. Różnica pomiędzy około 18 a 40 tokenami na sekundę oznacza różnicę pomiędzy narzędziem demonstracyjnym a codziennym narzędziem. Jeśli zamiast tego rozważasz mniejsze lokalne modele Qwen do programowania agentowego, przewodnik na tworzenie lokalnej gry za pomocą Qwen3.8-27B pokazuje lżejszą konfigurację.
Przewidywanie wielu tokenów: kolejny element, który warto obserwować pod kątem przyspieszenia
Flash-Next zawiera w sobie wyszkolony moduł predykcji wielu tokenów (MTP) – niewielki dodatkowy moduł, który jednocześnie proponuje kilka kolejnych tokenów, dzięki czemu główny model może je sprawdzać równolegle. Jest to dekodowanie spekulatywne z komponentem wstępnym, wyszkolonym end-to-end specjalnie dla tego modelu. Według doniesień z vLLM zapewnia ono około 2,5-krotny wzrost szybkości dekodowania przy rzeczywistych zapytaniach.
W chwili pisania tego tekstu llama.cpp obsługuje samą architekturę Flash-Next, ale jej wersja robocza MTP jeszcze nie obejmuje tego modelu. Istnieje natomiast obsługa pokrewnych modeli, więc zmiana powinna być niewielka, jednak przed założeniem dostępności tego modelu sprawdź aktualne notatki wydawnicze llama.cpp. Gdy zostanie to wdrożone, prędkość przetwarzania 30 do 50 tokenów na sekundę w konfiguracji z trzema GPU może rozsądnie wzrosnąć do około 60 do 100 na tym samym sprzęcie, wyłącznie dzięki aktualizacji oprogramowania. Traktuj to jako szacunek, dopóki nie będziesz mógł to zmierzyć.
Główne wnioski
- Flash-Next pasuje do sprzętu konsumenckiego dzięki swojemu projektowi, a nie siłie brutальnej: ultra-rzadka architektura MoE, stała wielkość stanu uwagi oraz tabela n-gramów służąca wyłącznie do wyszukiwania – wszystko to zmniejsza ilość danych muszących być przechowywanych w VRAM.
-ot w połączeniu z precyzyjnym regex służy do umieszczenia tego elementu tam.-ncmoe jest głównym parametrem dla konfiguracji z jedną kartą GPU: obniżaj go, aż VRAM będzie prawie pełna, zachowując niewielki margines bezpieczeństwa.mmap, gdy pamięć RAM jest ograniczona i chcesz, aby system operacyjny zarządzał jej wykorzystaniem; wybierz none, gdy pamięć RAM jest obfita i chcesz przewidywalną latencję po załadowaniu.Literatura pokrewna
- Budowanie lokalnego klonu Angry Birds za pomocą Qwen3.8-27B i Pi — Dowiedz się, jak skonfigurować w pełni lokalny proces programowania z wykorzystaniem AI, używając LM Studio oraz agenta Pi, aby stworzyć gralny poziom Angry Birds z Qwen3.8-27B.
- Projektowanie SaaS do rozmów z AI przy użyciu Next.js, FastAPI, Credits i SSE — Przejrzyj architekturę rozmów z AI typu full-stack, w której wykorzystano bramkarza FastAPI, rejestr kredytów, ograniczenia szybkości działania Redis oraz strumieniowanie SSE, a także wskazano najważniejsze luki do uzupełnienia.