Przejdź do treści
Wróć do bloga
qwen3.8Artykuł

Jak uruchomić Qwen3.8-27B na RTX 3090

Praktyczny schemat uruchomienia lokalnego Qwen3.8-27B: właściwy profil, kontrola API, pamięć GPU, wariant zapasowy i test po restarcie.

Autor

Syntalith

Opublikowano Zaktualizowano 4 min czytania

Poniższy schemat opisuje profil zmierzony na domowym PC z jedną kartą NVIDIA GeForce RTX 3090 24 GB. Qwen3.8-27B działał przez Qwen Code 0.21.13, z jednym aktywnym uruchomieniem modelu, limitem kontekstu 150 000, wagami W4A16 AutoRound, pamięcią kontekstu KV w formacie FP8, ustawieniem MTP-3 i zmodyfikowanym stosem vLLM. Wariant zapasowy używał llama.cpp, wag Unsloth Dynamic V3 Q4_K_M i limitu 120 000.

To jest krótka instrukcja kolejności kontroli. Ścieżki, nazwy usług, adresy i sekrety w przykładach są zastępcze. Sam fakt, że proces odpowiada na /health, mówi tylko, że serwer żyje. Przed uruchomieniem agenta trzeba jeszcze sprawdzić model, limit kontekstu i odpowiedź.

Dane liczbowe pochodzą z publicznego zestawienia pomiarów oraz metryk zadania 150k. Był to eksperyment po godzinach, z jedną kartą i jedną aktywną sesją. Ten zakres nie opisuje gotowości do pracy wieloosobowej.

Najpierw opisz profil

Limit kontekstu określa liczbę tokenów, które przyjmuje dany serwer. Token jest fragmentem tekstu używanym przez model. Karta modelu Qwen podaje natywny limit 262 144 tokenów, a serwer w zachowanym profilu zgłaszał limit 150 000. Te liczby opisują różne poziomy konfiguracji.

W4A16 to przybliżenie czterobitowych wag i szesnastobitowych aktywacji. Wagi zajmują wtedy mniej pamięci niż pełna precyzja. Pamięć KV przechowuje wartości pośrednie dla tokenów obecnych w kontekście, a jej format wpływa na dostępne miejsce. MTP to Multi-Token Prediction, mechanizm proponowania kolejnych tokenów. Publiczny zapis podaje dla tego profilu oznaczenie MTP-3; źródło nie rozstrzyga, jak dokładnie zaimplementowano tę liczbę w stosie.

Start serwera i kontrola gotowości

Poniższy szkielet pokazuje bezpieczną kolejność. Zatrzymanie drugiego silnika zwalnia VRAM, profil Compose uruchamia właściwy kontener, a pętla czeka na odpowiedź HTTP. Nazwa usługi i port wymagają dopasowania do własnego pliku Compose.

#!/usr/bin/env bash
set -euo pipefail

systemctl --user stop qwen.service
docker compose --profile single up -d --remove-orphans

while true; do
  if curl -fsS http://127.0.0.1:18020/health >/dev/null; then
    echo "Ready: Qwen3.8-27B, context 150000"
    break
  fi

  if [[ -n "$(docker compose --profile single ps --status exited -q single)" ]]; then
    echo "Server exited before health check passed" >&2
    exit 1
  fi

  sleep 1
done

/health jest sondą procesu. Pętla sprawdza również zakończenie kontenera, aby błąd startu nie wyglądał jak długie oczekiwanie klienta.

Sprawdź, co odpowiada pod adresem API

Serwer może działać, a mimo to wskazywać inny model albo limit. Klient powinien odczytać /v1/models, porównać identyfikator modelu i oczekiwane max_model_len, a następnie wykonać krótką generację.

KEY_FILE="/path/to/secret/api-key"

if [[ ! -s "$KEY_FILE" ]]; then
  echo "Missing API key" >&2
  exit 1
fi

read -r QWEN_API_KEY < "$KEY_FILE"

curl -fsS \
  -H "Authorization: Bearer $QWEN_API_KEY" \
  http://127.0.0.1:18020/v1/models \
  | grep -Eq '"max_model_len":[[:space:]]*150000'

Sekret powinien pochodzić z magazynu lub pliku z prawami dostępu; repozytorium nie jest jego miejscem. Wspólna usługa potrzebuje także wersji obrazu, wersji wag i rejestru profilu przypisanego do żądania.

Uruchom klienta z tym samym limitem

Klient agenta prowadzi sesję, wysyła polecenia i udostępnia narzędzia. W pomiarze klientem był Qwen Code 0.21.13, z poziomem rozumowania medium. Skrypt uruchamiający powinien jawnie wskazać model i osobny katalog konfiguracji:

export QWEN_VLLM_API_KEY="$QWEN_API_KEY"
export QWEN_HOME="/path/to/qwen/profile"
export QWEN_STREAM_IDLE_TIMEOUT_MS=0
export QWEN_STREAM_MAX_LIFETIME_MS=0

exec qwen --auth-type openai --model qwen3.8-27b "$@"

Nazwa zmiennej, adres i model muszą odpowiadać konfiguracji serwera. Warto zachować limit 150 000 po obu stronach i unikać stałego limitu odpowiedzi, który ucina długie zapisy narzędzi. Konkretne ustawienia klienta wymagają testu z używaną wersją Qwen Code.

Obserwuj kartę podczas pracy

nvidia-smi pokazuje stan sprzętu. O poprawności odpowiedzi przekonuje dopiero osobny test; na początek wystarczy obserwować zużycie pamięci i obciążenie GPU:

nvidia-smi \
  --query-gpu=memory.used,utilization.gpu,temperature.gpu \
  --format=csv,noheader

W zadaniu Go wybrany profil vLLM osiągnął maksymalnie 22 539 MiB VRAM. Przy karcie 24 GB zostaje niewielki margines, dlatego jedna aktywna sesja jest rozsądnym punktem startowym. Ten pomiar nie opisuje bezpiecznej współbieżności dla kilku osób.

Przełączenie na wariant zapasowy

Profil zapasowy ma własne wagi, limit i silnik. Po zatrzymaniu vLLM uruchom llama.cpp, a potem wykonaj te same kontrole modelu, limitu i krótkiej odpowiedzi:

docker compose --profile single down
exec /path/to/qwen-context 120k medium

Wariant 120k nie przyjmuje automatycznie sesji przygotowanej dla 150k. Przełączenie przywraca możliwość pracy, a czas odpowiedzi i liczba tokenów dostępnych w historii mogą się zmienić.

Test po każdym starcie

KontrolaCo potwierdza
/healthproces odpowiada przez HTTP
/v1/modelswłaściwy model i limit 150 000
krótka odpowiedź JSONklient odczytuje poprawny format
proste narzędzie tylko do odczytudziałają wywołania narzędzi
nvidia-smibrak nieoczekiwanego procesu i zapas VRAM
zadanie regresyjneprofil radzi sobie z rzeczywistą zmianą

W pomiarze zadanie regresyjne naprawiało dwa miejsca w Go, które ignorowały błędy json.Marshal. Testy skupione i kompilacja przeszły, a Codex ocenił rezultat na 100/100 według arkusza kryteriów Syntalith: 40 punktów za poprawność obsługi błędów, 20 za testy regresji, 15 za zgodność API, 10 za zakres, 10 za weryfikację i 5 za dokumentację. Ta ocena dotyczy jednego przebiegu i konkretnego zadania.

Granica między eksperymentem a wdrożeniem

Domowy profil pokazał, że taki stos da się uruchomić na jednej karcie. Wdrożenie dla firmy wymaga wersjonowanego obrazu i wag, kontroli sekretów, prywatnego adresu API, historii metryk, kolejki, testu po restarcie i sprawdzonego powrotu do działającej wersji. Trzeba też zmierzyć rzeczywisty proces klienta.

Audyt procesu AI pomaga zdefiniować taki test, a bezpłatny skan procesu ustala, czy lokalny model pasuje do zadania, danych i oczekiwanego czasu pracy.

Bezpłatny skan procesów

Zacznij od bezpłatnego skanu procesów.

  • 30 minut z inżynierem, który może prowadzić Twoje wdrożenie.
  • Przegląd procesów, które kosztują Cię najwięcej czasu i pieniędzy.
  • Pisemne podsumowanie: co zautomatyzować, w jakiej kolejności, z widełkami kosztów.

W 30 minut wybieramy proces do oceny, a w ciągu 2 dni roboczych dostajesz rekomendację, także gdy lepsza będzie prostsza droga.

0 zł

30 minut · pisemne podsumowanie w 2 dni robocze