Track
Qwen3.8-27B bardzo szybko staje się jednym z najpopularniejszych modeli do lokalnej AI. Mimo że ma tylko 27 miliardów parametrów, oferuje wydajność konkurującą z o wiele większymi modelami w testach kodowania, rozumowania, pracy agentowej i zastosowań ogólnych. W kilku obszarach zbliża się nawet do modeli takich jak GLM-5.2, co sprawia, że jest szczególnie popularny wśród osób eksperymentujących z mocnym lokalnym sprzętem.
RTX 5090 wyjątkowo dobrze pasuje do Qwen3.8-27B, ponieważ jego architektura Blackwell obsługuje NVFP4, co pozwala uruchamiać model z bardzo wysoką szybkością przy zachowaniu wysokiej jakości wyników. W połączeniu ze spekulatywnym dekodowaniem poprzez multi-token prediction (MTP), zoptymalizowaną kompilacją llama.cpp i odpowiednim modelem GGUF, Qwen3.8-27B może generować grubo ponad 100 tokenów na sekundę na pojedynczym RTX 5090.
W tym przewodniku skonfigurujemy moim zdaniem jeden z najprostszych sposobów uzyskania najlepszego balansu między szybkością, dokładnością i wsparciem długiego kontekstu na RTX 5090 lub innym GPU Blackwell. Skompilujemy llama.cpp z natywną obsługą Blackwella, pobierzemy Qwen3.8-27B NVFP4-MTP GGUF, uruchomimy go z akceleracją GPU i spekulatywnym dekodowaniem MTP, przetestujemy API zgodne z OpenAI i wbudowany interfejs webowy, a na końcu połączymy go z Pi, aby używać Qwen3.8-27B jako w pełni lokalnego agenta do kodowania.
1. Skonfiguruj llama.cpp dla GPU Blackwell
Najpierw upewnimy się, że GPU jest poprawnie wykrywana i sprawdzimy wersję sterownika NVIDIA oraz CUDA.
nvidia-smi
Powinieneś zobaczyć swój RTX 5090, wersję sterownika, wersję CUDA, pamięć GPU i bieżące użycie GPU.
Uwaga: ta konfiguracja jest przeznaczona konkretnie dla GPU NVIDIA Blackwell, takich jak RTX 5090. Poniższa kompilacja celuje w SM120, czyli architekturę obliczeniową używaną przez RTX 5090.
Następnie pobierzemy i skompilujemy najnowszą wersję llama.cpp z obsługą CUDA.
cd /workspace
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build \
-DGGML_CUDA=ON \
-DCMAKE_CUDA_ARCHITECTURES=120
cmake --build build --config Release -j$(nproc)

Kluczowy jest tu parametr -DCMAKE_CUDA_ARCHITECTURES=120. Informuje on llama.cpp, by kompilować konkretnie pod architekturę Blackwell używaną przez RTX 5090.
Po zakończeniu kompilacji udostępnimy llama-server globalnie, aby można go było uruchamiać z dowolnego folderu:
sudo ln -sf "$(realpath ./build/bin/llama-server)" /usr/local/bin/llama-server
Teraz sprawdź, czy wszystko działa:
llama-server --version
Powinieneś zobaczyć wynik podobny do:
version: 0.1.1-dev (build 10479, commit 0021a77de)
built with GNU 13.3.0 for Linux x86_64
To wszystko. Mamy teraz kompilację llama.cpp z obsługą CUDA, która może wykorzystać RTX 5090 i jego natywne wsparcie NVFP4 dla Blackwella.
2. Pobierz model Qwen3.8-27B NVFP4-MTP
Teraz pobierzemy model Qwen3.8-27B.
Najpierw zainstaluj CLI Hugging Face:
pip install -U huggingface_hub
Utwórz folder, w którym będziemy trzymać model:
mkdir -p /workspace/models/qwen38
Następnie pobierz NVFP4-MTP GGUF:
hf download felippeburk/Qwen3.8-27B-NVFP4-MTP-GGUF \
--local-dir /workspace/models/qwen38

To wersja, której chcemy użyć w tej konfiguracji, ponieważ korzysta z NVFP4 i zawiera wsparcie MTP, czyli źródło dużej części przyspieszenia na RTX 5090.
3. Uruchom serwer Qwen3.8-27B
Teraz zaczyna się zabawa. Udostępnimy Qwen3.8-27B w całości na GPU z Flash Attention, oknem kontekstu 131K i spekulatywnym dekodowaniem MTP dla szybszej generacji.
Uruchom:
cd /workspace/llama.cpp
llama-server \
-m /workspace/models/qwen38/qwen3.8-27b-text-nvfp4-mtp.gguf \
--alias qwen3.8-27b \
--host 0.0.0.0 \
--port 8910 \
--ctx-size 131072 \
--n-gpu-layers all \
--flash-attn on \
--cache-type-k q8_0 \
--cache-type-v q8_0 \
--parallel 1 \
--spec-type draft-mtp \
--spec-draft-n-max 4 \
--spec-draft-p-min 0.75 \
--spec-draft-ngl all \
--spec-draft-type-k q8_0 \
--spec-draft-type-v q8_0 \
--reasoning-effort medium \
--jinja
Jest tu sporo opcji, ale większość z nich ma po prostu wycisnąć maksimum z 5090.
Najważniejsze to:
-
--ctx-size 131072daje nam okno kontekstu rzędu 131K. -
--n-gpu-layers allutrzymuje model na GPU. -
--flash-attn onwłącza Flash Attention. -
--cache-type-k q8_0i--cache-type-v q8_0pomagają zmniejszyć zużycie pamięci przez pamięć podręczną KV. -
--spec-type draft-mtpwłącza spekulatywne dekodowanie MTP w Qwen3.8. -
--spec-draft-n-max 4kontroluje, ile tokenów spekulatywnych MTP może generować jednocześnie.
W tej konfiguracji używamy n-max 4 jako punktu wyjścia dla RTX 5090. Możesz poeksperymentować z wartościami takimi jak 2 (co zaleca karta modelu dla tego GGUF) lub 3 później, ponieważ najszybsze ustawienie może się nieznacznie różnić w zależności od systemu.
Gdy llama-server zakończy ładowanie modelu, Qwen3.8 będzie dostępny lokalnie pod adresem http://127.0.0.1:8910.

Mamy już Qwen3.8-27B działający lokalnie. Dalej przetestujemy model zarówno przez API, jak i wbudowany interfejs przeglądarkowy.
4. Przetestuj szybkość i wydajność kodowania Qwen3.8-27B
Przy uruchomionym serwerze otwórz drugie okno terminala i wyślij żądanie testowe do API zgodnego z OpenAI:
curl http://127.0.0.1:8910/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "qwen3.8-27b",
"messages": [
{
"role": "user",
"content": "Write a Python FastAPI application that monitors GPU usage."
}
],
"max_tokens": 2000
}'

W tym teście Qwen3.8-27B wygenerował 2000 tokenów z prędkością 122 tokenów/sek. i imponującym współczynnikiem akceptacji MTP na poziomie 84,9%.
llama.cpp zawiera też interfejs przeglądarkowy, więc możesz testować model bez użycia API.
Otwórz http://127.0.0.1:8910 w przeglądarce, aby zobaczyć interfejs.

Do bardziej złożonego testu użyłem takiej prośby:
Create a stunning single-file animated HTML website with a dark futuristic
theme, smooth scrolling, glowing gradients, floating particles, animated cards,
hover effects, and responsive design using only HTML, CSS, and JavaScript.

Na moim RTX 5090 uzyskiwałem średnio około 142 tokenów na sekundę, a chwilami prędkość dochodziła do około 170 tokenów na sekundę, co jest niezwykle szybkie jak na lokalnie uruchamiany model 27B.

Qwen3.8-27B wygenerował dopracowaną, w pełni działającą stronę internetową, która działała od ręki. To dobry sposób, by szybko sprawdzić zarówno zdolności kodowania modelu, jak i szybkość lokalnej konfiguracji.
5. Używaj Qwen3.8-27B z Pi
W tej części podłączymy Qwen3.8-27B do Pi i użyjemy go jako w pełni lokalnego agenta do kodowania.
Pi to lekki, działający w terminalu agent do kodowania, który może pomóc ci budować, edytować, testować i debugować projekty bezpośrednio z wiersza poleceń.
Zainstaluj Pi poleceniem:
curl -fsSL https://pi.dev/install.sh | sh
Instalator wymaga Node.js i npm. Instaluje Pi w globalnym prefiksie npm. Jeśli nie masz jeszcze Node, najpierw zainstaluj go przez nvm lub menedżer pakietów.
Po zakończeniu instalacji uruchom ponownie terminal.
Następnie zainstaluj rozszerzenie pi-llama i wskaż Pi nasz lokalny serwer llama.cpp:
pi install git:github.com/huggingface/pi-llama
export LLAMA_BASE_URL=http://127.0.0.1:8910/v1
Utwórz nowy projekt i uruchom Pi:
mkdir new-project
cd new-project
Pi

W środku Pi uruchom /model, wyszukaj llama-cpp i wybierz Qwen3.8-27B.
Do testów dałem mu taki prompt:
Build a polished personal finance dashboard from scratch that imports CSV
bank statements, categorizes spending, shows monthly trends and charts, and
detects unusual expenses; also generate a realistic sample CSV, import it,
test the full app end-to-end, and fix any errors automatically.

Zbudował cały projekt w kilka minut.

Potem poprosiłem, by uruchomił serwer i przetestował zarówno frontend, jak i logikę aplikacji. Poświęcił więcej czasu na debugowanie i testy, żeby upewnić się, że wszystko działa poprawnie.

Gdy sam przetestowałem panel, aplikacja działała dobrze, wykresy wyglądały świetnie, a ogólne wrażenia były płynne.

Główną słabością były precyzyjne zmiany w UI. Po kilku kolejnych prośbach zaczął wprowadzać niepowiązane zmiany zamiast dokładnie zrozumieć, o co mi chodzi, więc w końcu na tym poprzestałem.
Na koniec
Qwen3.8-27B wciąż jest bardzo nowy, a społeczność aktywnie szuka najlepszego połączenia kwantyzacji i spekulatywnego dekodowania. MTP działa wyjątkowo dobrze, ale testowane są też nowsze podejścia, takie jak DFlash 2 i DSpark, a niektórzy użytkownicy zgłaszają jeszcze wyższe prędkości w zależności od sprzętu i obciążenia.
Unsloth właśnie wypuścił też Dynamic v3.0 GGUF dla Qwen3.8-27B, deklarując około 10% wyższą dokładność przy tym samym rozmiarze modelu w porównaniu z poprzednimi kwantyzacjami. To czyni Unsloth bardzo ciekawą opcją, jeśli chcesz lepszej jakości przy zachowaniu mniej więcej tej samej lokalnej konfiguracji inferencji.
Na teraz uważam, że NVFP4 + MTP + llama.cpp to jeden z najprostszych i najszybszych zestawów dla RTX 5090. Osiąganie około 140 tokenów na sekundę z modelu 27B, przy zachowaniu dużego okna kontekstu i wystarczających możliwości do uruchomienia realnego agenta do kodowania, robi wrażenie. Prawdopodobnie będzie jeszcze szybciej, gdy llama.cpp, Unsloth, DFlash 2 i DSpark będą się dalej rozwijać.
FAQ: uruchamianie Qwen3.8-27B lokalnie
Do uruchomienia Qwen3.8-27B lokalnie potrzebujesz RTX 5090?
Nie. Standardowe 4‑bitowe kwantyzacje GGUF Qwen3.8-27B mieszczą się mniej więcej w 16–19 GB VRAM, więc RTX 5080, 4090 lub Mac z 24 GB uruchomią model. RTX 5090 ma znaczenie w tej konkretnej konfiguracji, ponieważ NVFP4 wymaga rdzeni tensorowych Blackwell. Na starszych kartach pliki NVFP4 się uruchomią, ale dadzą tylko oszczędność pamięci, bez przyspieszenia.
Ile VRAM faktycznie zużywa ta konfiguracja?
NVFP4-MTP GGUF zajmuje na dysku około 19 GB, a to pamięć KV podbija łączny użytek wraz ze wzrostem kontekstu. Przy kwantyzacji K/V q8_0 i bardzo długim kontekście, publikowane uruchomienia na RTX 5090 mieszczą się w połowie zakresu 20‑kilku GB, więc karta 32 GB daje komfort. Przy 24 GB trzeba będzie obniżyć --ctx-size zdecydowanie poniżej 131072.
Co robi spekulatywne dekodowanie MTP i czy jest bezstratne?
Qwen3.8 dostarcza warstwy multi-token prediction wbudowane w GGUF, które działają jak wbudowany model szkicowy, bez potrzeby drugiego pliku. Głowa szkicowa proponuje kilka tokenów naraz, a pełny model je weryfikuje, więc zaakceptowane szkice kosztują ułamek normalnego przejścia w przód. Jakość wyjścia się nie zmienia, bo każdy zaakceptowany przez główny model token to taki, który i tak by wygenerował.
Lepiej użyć NVFP4 czy zwykłego Q4_K_M?
Wybierz NVFP4, jeśli masz GPU Blackwell i zależy ci na maksymalnej szybkości; wybierz standardowy GGUF, np. Q4_K_M, albo UD-Q4_K_XL od Unsloth, jeśli jesteś na Ampere lub Ada, albo jeśli bardziej zależy ci na jakości wyjścia w przeliczeniu na gigabajt. Wsparcie NVFP4 w llama.cpp jest też nowsze niż ścieżka K-quant, więc spodziewaj się większej liczby niedoróbek wokół konwersji i narzędzi.
Czy ta konfiguracja obsługuje obrazy, skoro Qwen3.8-27B jest modelem wizyjnym?
Qwen3.8-27B to natywny model językowo-wizualny, ale konwersje GGUF tylko tekstowe odcinają wieżę wizyjną. Aby używać obrazów, musisz przekazać multimodalny projektor wraz z modelem poprzez --mmproj, zazwyczaj plik mmproj publikowany w tym samym repo lub w repo GGUF Unsloth.
