Jak uruchomić lokalnie Qwen3.8-Flash-Next jako agenta do kodowania z OpenCode

Architektura Qwen3.8-Flash-Next

To główny model MoE z 125 mld parametrów, ale na token aktywowanych jest tylko ok. 6 mld parametrów. Dodatkowo zawiera 51 mld parametrów w osadzeniach n-gramowych.

Architektura wprowadza kilka pomysłów, które Qwen eksploruje dla Qwen4:

• Gated DeltaNet + Qwen Sparse Attention (QSA) dla wydajniejszego przetwarzania długiego kontekstu
• Gated Residual connections, aby poprawić przepływ informacji między warstwami
• Osadzenia n-gramowe, które zwiększają pojemność modelu bez konieczności aktywnego przeliczania wszystkich tych parametrów

Źródło: Qwen 

Model ma natywną długość okna kontekstu wynoszącą 262 144 tokeny i teoretycznie można ją rozszerzyć do 1 miliona tokenów przy użyciu YaRN.

Jak Qwen3.8-Flash-Next radzi sobie z kodowaniem?

Jest też zaskakująco mocny w kodowaniu. Oto niektóre z wyników raportowanych przez zespół Qwen w porównaniu z Qwen3.8-27B:

To oceny własne Qwena, więc traktowałbym je jako wyniki raportowane przez dostawcę, ale dość dobrze pokrywają się z moim doświadczeniem z modelem przy kodowaniu.

Przygotowanie serwera GPU pod Qwen3.8-Flash-Next

Użyłem RTX PRO 6000 z 96 GB VRAM, ale niekoniecznie potrzebujesz aż tyle VRAM.

To w gruncie rzeczy jeden z ciekawszych aspektów Qwen3.8-Flash-Next. Ponieważ llama.cpp potrafi przenieść część modelu do pamięci RAM, możesz użyć GPU z mniejszym VRAM, o ile masz dużo dostępnej pamięci operacyjnej.

Kwantyzacja Unsloth UD-Q4_K_XL, której używamy, ma około 111 GB i jest podzielona na cztery pliki GGUF.

W mojej konfiguracji polecałbym mieć co najmniej 140 GB łącznej użytecznej pamięci RAM i VRAM, aby zapewnić wystarczająco miejsca na model, kontekst, cache KV i narzut środowiska uruchomieniowego.

Gdybyś miał np. H200, praktycznie wszystko mógłbyś trzymać na GPU. Ja wybrałem złoty środek. 

Zacznij od sprawdzenia GPU:

nvidia-smi

Powinieneś zobaczyć swoją kartę, wersję sterownika, wersję CUDA i dostępny VRAM.

Następnie zainstaluj wymagane pakiety:

sudo apt update

sudo apt install -y \
  git \
  cmake \
  build-essential \
  curl \
  libcurl4-openssl-dev \
  python3-pip

Budowanie llama.cpp z obsługą Qwen3.8-Flash-Next

Qwen3.8-Flash-Next używa nowej architektury qwen4_exp, która bardzo różni się od zwykłego wczytania innego modelu Qwen3.8.

Wsparcie jest wciąż bardzo świeże, więc użyłem gałęzi Qwen3.8-Flash-Next utrzymywanej przez Unsloth, zamiast polegać na starszym buildzie llama.cpp, który mógłby nie rozpoznać architektury. Odpowiadające prace w llama.cpp dodają nową architekturę qwen4exp, QSA, osadzenia n-gramowe i inne komponenty specyficzne dla modelu.

Przejdź do katalogu roboczego:

cd /workspace

Sklonuj gałąź Unsloth:

git clone \
  --branch qwen4exp/qwen3.8-flash-next \
  https://github.com/unslothai/llama.cpp.git

Wejdź do katalogu:

cd llama.cpp

Zbuduj llama.cpp z CUDA:

cmake -B build \
  -DGGML_CUDA=ON \
  -DCMAKE_BUILD_TYPE=Release

cmake --build build \
  --config Release \
  -j"$(nproc)"

Na koniec potwierdź, że llama-server został poprawnie zbudowany:

./build/bin/llama-server --version

U mnie zwróciło:

version: 0.3.0-dev (build 10656, commit 035e22731)
built with GNU 13.3.0 for Linux x86_64

Pobieranie modelu Qwen3.8-Flash-Next w formacie GGUF

Pobranie modelu było w zasadzie jednym z najbardziej uciążliwych etapów tej konfiguracji.

Najpierw próbowałem ModelScope, ale prędkość nie była świetna. Na Hugging Face pobieranie początkowo osiągało niezłe tempo, po czym nagle spadało do KB/s.

Hugging Face używa teraz backendu Xet do pobierania dużych modeli i zwykle automatycznie włącza adaptacyjną współbieżność. Zapewnia też zmienną HF_HUB_DISABLE_XET do wyłączenia Xet, gdy sprawia problemy.

W moim przypadku wyłączenie Xet i pobieranie czterech shardów GGUF równolegle działało znacznie lepiej.

Zainstaluj CLI Hugging Face:

pip install -U huggingface_hub

Wyłącz Xet dla tego pobrania:

export HF_HUB_DISABLE_XET=1
unset HF_XET_HIGH_PERFORMANCE
unset HF_XET_NUM_CONCURRENT_RANGE_GETS
unset HF_HUB_ENABLE_HF_TRANSFER

HF_HUB_ENABLE_HF_TRANSFER i tak jest już przestarzałe, ponieważ Hugging Face przeniósł duże transfery do Xet.

Utwórz katalog na model:

cd /workspace
mkdir -p Qwen3.8-Flash-Next-GGUF

Teraz pobierz wszystkie cztery shard'y równolegle:

for i in 1 2 3 4; do
  shard=$(printf "%05d" "$i")

  hf download unsloth/Qwen3.8-Flash-Next-GGUF \
    "UD-Q4_K_XL/Qwen3.8-Flash-Next-UD-Q4_K_XL-${shard}-of-00004.gguf" \
    --local-dir Qwen3.8-Flash-Next-GGUF &
done

wait

Kompletny quant UD-Q4_K_XL ma około 111 GB.

Uruchamianie Qwen3.8-Flash-Next z llama.cpp

Wróć do katalogu llama.cpp:

cd /workspace/llama.cpp

Uruchom serwer:

./build/bin/llama-server \
  -m /workspace/Qwen3.8-Flash-Next-GGUF/UD-Q4_K_XL/Qwen3.8-Flash-Next-UD-Q4_K_XL-00001-of-00004.gguf \
  --alias qwen3.8-flash-next \
  --host 0.0.0.0 \
  --port 8080 \
  --ctx-size 131072 \
  --parallel 1 \
  --flash-attn on \
  --fit on \
  --fit-target 4096 \
  --jinja \
  --batch-size 1024 \
  --ubatch-size 512 \
  --temp 1.0 \
  --top-p 0.95 \
  --top-k 20 \
  --min-p 0.0

Celowo użyłem okna kontekstu 131 072 tokeny zamiast pełnego natywnego 262K.

Do agentów kodujących 131K to już ogromnie dużo i daje OpenCode sporo miejsca na pliki źródłowe, wyniki narzędzi, logi terminala i długie rozmowy, bez marnowania jeszcze większej ilości pamięci na kontekst, którego prawdopodobnie nie wykorzystam.

Kluczowe ustawienia to:

1. --fit on pozwala llama.cpp automatycznie określić, jaką część modelu trzymać na GPU.

2. --fit-target 4096 mówi, by zostawić około 4 GB pamięci GPU wolnej, co daje środowisku uruchomieniowemu trochę luzu zamiast pracować na limicie VRAM. llama.cpp oficjalnie wspiera zarówno automatyczne dopasowanie, jak i konfigurowalny margines pamięci.

3. Ustawienia próbkowania też nie są przypadkowe. Qwen zaleca temperature=1.0, top_p=0.95, top_k=20 i min_p=0.0 podczas korzystania z trybu myślenia.

Nawet po załadowaniu pełnego modelu miałem sporo pamięci w zapasie — około 13 GB VRAM dostępnego dla okna kontekstu, cache KV i innych aplikacji.

Testowanie serwera Qwen3.8-Flash-Next przy użyciu CURL

llama-server wystawia API zgodne z OpenAI.

Sprawdź dostępny model:

curl http://127.0.0.1:8080/v1/models

Powinieneś zobaczyć qwen3.8-flash-next.

Teraz przetestujmy wygenerowanie odpowiedzi:

curl http://127.0.0.1:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3.8-flash-next",
    "messages": [
      {
        "role": "user",
        "content": "Write a Python function that checks whether a number is prime."
      }
    ]
  }'

Jeśli dostaniesz poprawną odpowiedź, lokalny serwer jest gotowy.

W mojej konfiguracji początkowo widziałem około 80 tokenów na sekundę, co mnie zaskoczyło, biorąc pod uwagę, że część modelu siedziała w pamięci RAM.

Wraz ze wzrostem kontekstu prędkość zbliżyła się do 64 tokenów na sekundę.

To wciąż bardzo użyteczne jak na model tej wielkości, a architektura pomaga zrozumieć dlaczego. Mimo że model ma 125 mld głównych parametrów, na token aktywowanych jest tylko ok. 6 mld.

Testowanie Qwen3.8-Flash-Next w WebUI llama.cpp

Jedna z rzeczy, które naprawdę lubię w llama.cpp, to że llama-server od razu daje proste WebUI.

Otwórz http://localhost:8080. Jeśli wszystko działa poprawnie, model powinien być już dostępny.

Do pierwszego porządnego testu poprosiłem o zbudowanie kompletnej strony działu IT administracji publicznej za jednym zamachem:

Create a modern, professional government IT department portfolio website in a single index.html file.
Use HTML, CSS, and JavaScript featuring a clean official design and responsive layout with smooth animations, interactive elements, and accessible government-style navigation.
It should display department overview, key services, digital transformation projects, achievements, technology initiatives, statistics, leadership/team section, latest updates, contact information, 

To było całkiem duże generowanie. Model poświęcił sporo tokenów na myślenie, a potem wygenerował całą stronę w jednym pliku HTML. Zajęło to około 13 minut, a prędkość generacji stopniowo spadała wraz ze wzrostem kontekstu.

Ale efekt był lepszy, niż się spodziewałem.

Zawierał wykresy, animacje, zakładki, różne sekcje, responsywne style, interakcje w JavaScripcie i zaskakująco dopracowany ogólny układ.

Co ciekawe, to było właściwie jednorazowe generowanie. Nie prosiłem wprost o wiele z tych drobniejszych detali.

To był pierwszy moment, w którym zdałem sobie sprawę, że ten model może być szczególnie dobry do zadań kodowania, gdzie dajesz mu trochę swobody zamiast precyzować każdy detal implementacji.

Łączenie Qwen3.8-Flash-Next z OpenCode

Rozmowa jest fajna, ale głównie chciałem przetestować Qwen3.8-Flash-Next jako agentowy model do kodowania.

Do tego użyłem OpenCode. Najpierw zainstaluj:

curl -fsSL https://opencode.ai/install | bash

Zrestartuj terminal i sprawdź instalację:

opencode --version

U mnie była to wersja 1.18.23.

Teraz utwórz konfigurację OpenCode:

mkdir -p ~/.config/opencode

Dodaj lokalnego providera llama.cpp, którego zbudowaliśmy wcześniej:

printf '%s\n' '{"$schema":"https://opencode.ai/config.json","model":"llama.cpp/qwen3.8-flash-next","provider":{"llama.cpp":{"npm":"@ai-sdk/openai-compatible","name":"Qwen3.8 Flash Next Local","options":{"baseURL":"http://127.0.0.1:8080/v1"},"models":{"qwen3.8-flash-next":{"name":"Qwen3.8 Flash Next","limit":{"context":65536,"output":32768}}}}}}' > ~/.config/opencode/opencode.json

Najważniejszy jest adres http://127.0.0.1:8080/v1. 

OpenCode wspiera niestandardowych dostawców zgodnych z OpenAI poprzez @ai-sdk/openai-compatible, co sprawia, że połączenie z llama.cpp jest bardzo proste.

Ustawiłem w OpenCode roboczy kontekst na 65K, mimo że sam serwer llama.cpp ma dostępne 131K.

Daje to spory zapas na długie wyjścia i powstrzymuje sesje agenta przed zbyt agresywnym zapełnianiem całego kontekstu serwera.

Korzystanie z Qwen3.8-Flash-Next jako lokalnego agenta do kodowania

Przejdź do katalogu projektu i uruchom OpenCode:

cd /workspace/my-project
opencode

Teraz możesz zlecać modelowi normalne zadania agentowe związane z kodowaniem. Na przykład poleciłem Qwenowi zbudować pulpit analityczny:

Build a modern system analytics and task-management dashboard. 
It should monitor CPU, RAM, VRAM, GPU usage, temperatures, disk usage, running processes, and temporary files. 
Users should be able to safely terminate tasks, free unused RAM/VRAM, clear caches, and clean temporary files from one interface.

Model zaczął od stworzenia listy zadań i zaplanowania aplikacji, zanim cokolwiek napisał.

W ciągu kilku minut powstała pierwsza działająca wersja pulpitu. Nie spodobał mi się jednak pierwszy interfejs — był zbyt rozstrzelony i miał kilka problemów z użytecznością.

Więc po prostu powiedziałem agentowi, co mi się nie podoba, i poprosiłem o przebudowę interfejsu w bardziej kompaktowe centrum sterowania systemem.

Druga wersja była dużo lepsza.

Skończyłem z kompaktowym pulpitem, na którym mogłem monitorować w czasie rzeczywistym CPU, RAM, VRAM, użycie GPU, przestrzeń dyskową, aktywność sieci i działające procesy. Dodał też kontrolki do czyszczenia cache, usuwania plików tymczasowych i zarządzania procesami.

Ciekawe było to, jak Qwen podchodził do implementacji. Testowałem go na dwóch różnych aplikacjach i często preferował proste, czyste HTML, CSS i JavaScript zamiast od razu instalować Reacta, paczki Node czy inny duży framework.

To zachowanie akurat mi się spodobało. Jeśli nie wskazywałem frameworka, próbował znaleźć najprostszy układ, który rozwiąże problem, zamiast dokładać zbędne zależności.

Minus jest taki, że to zajmuje czas. Dużo rozumowania, dużo generowanych tokenów i czasem sporo debugowania. Czuć, że model poświęca tokeny na przemyślenie problemu.

Ale finalne projekty na ogół wydawały się znacznie bardziej kompletne niż to, co zwykle dostaję od mniejszych lokalnych modeli.

Kilka słów na koniec

Po testach Qwen3.8-Flash-Next przy generowaniu stron i agentowym kodowaniu uważam, że to wyraźny krok naprzód względem Qwen3.8-27B. Największa różnica to podejście do projektów. Bardziej dba o strukturę, detale i praktyczną implementację, zamiast po prostu generować kod. Jeśli chcesz uruchomić ten model lokalnie, przeczytaj nasz tutorial Qwen3.8-27B.

Podobało mi się też, że często opierał się na prostym HTML, CSS, JavaScript i Pythonie, zamiast dodawać niepotrzebne frameworki i zależności.

Główny minus to rozmiar. UD-Q4_K_XL w GGUF to ok. 111 GB, a model potrafi zużyć dużo tokenów na rozumowanie i wyjście, zwłaszcza podczas debugowania.

Poza tym konfiguracja była zaskakująco prosta. Jeśli masz wystarczająco RAM i VRAM, Qwen3.8-Flash-Next to jeden z najmocniejszych lokalnych modeli do kodowania, jakie dotąd testowałem.