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

Ta instrukcja powstała z poleceń, które rzeczywiście obsługiwały Qwen3.8-27B na domowym PC z RTX 3090. Wybrany profil to jedna sesja Qwen Code, kontekst 150k, wagi W4A16 AutoRound, pamięć kontekstu FP8, MTP-3 i zewnętrznie zmodyfikowany vLLM. Profilem zapasowym jest llama.cpp z Dynamic V3 Q4_K_M i kontekstem 120k.

Uruchomienie modelu wymaga trzech osobnych kontroli: proces serwera musi działać, serwer musi wystawiać właściwy model i limit kontekstu, a krótki test powinien potwierdzić prawidłową odpowiedź. Sam zielony adres /health sprawdza tylko pierwszy punkt.

Dokumentacja vLLM opisuje jego interfejsy zgodne z OpenAI, a oficjalna karta Qwen3.8-27B podaje natywny kontekst 262 144 tokenów. Limit 150k pochodzi z zachowanego profilu domowego eksperymentu. Producent nie zaleca przez to dokładnie tej konfiguracji, a pojedynczy przebieg nie dowodzi użytecznej jakości dla każdego wejścia tej długości.

Ścieżki, nazwy użytkownika, adres w sieci lokalnej i sekret są zredagowane. Materiał służy do odtworzenia eksperymentu. Firmowy wykaz wersji wymaga dodatkowych kontroli opisanych na końcu.

Co ma zrobić jedna komenda startowa

Komenda qwen-engine vllm wykonywała pięć operacji:

1. zatrzymywała usługę llama.cpp, ponieważ oba serwery nie mieszczą się jednocześnie na jednej karcie;
2. uruchamiała właściwy profil Docker Compose;
3. sprawdzała /health co sekundę;
4. przerywała czekanie, jeśli kontener zakończył pracę;
5. dopiero po gotowości zwracała sukces.

Redagowany rdzeń wygląda tak:

#!/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, 150k, port 18020"
    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

To niewielka różnica względem docker compose up -d, ale praktycznie ważna. Klient uruchomiony za wcześnie daje serię błędów połączenia, które łatwo pomylić z wadą modelu lub protokołu.

Sam test stanu serwera nie potwierdza właściwego profilu

Serwer może odpowiadać poprawnie, a jednocześnie wystawiać profil zapasowy 120k, DFlash2 64k albo inny model. Skrypt uruchamiający klienta sprawdzał więc /v1/models i oczekiwany limit 150 000. Sekret był czytany z osobnego pliku i nie trafiał do repozytorium.

KEY_FILE="/srv/qwen/secrets/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'

W wersji dla firmy sprawdzamy co najmniej model ID, wersję obrazu, limit kontekstu i krótki wynik generacji. Samo pole max_model_len było wystarczające do domowego przełącznika, bo tylko jeden profil na tym porcie deklarował 150k. Nie byłoby wystarczające w środowisku współdzielonym.

Skrypt Qwen Code blokuje błędny start

Po sprawdzeniu sekretu, stanu usługi i profilu skrypt uruchamiający ustawiał osobny katalog konfiguracji, wyłączał sztuczne limity czasu strumienia i uruchamiał Qwen Code z jawnym modelem:

export QWEN_VLLM_API_KEY="$QWEN_API_KEY"
export QWEN_HOME="/srv/qwen/profiles/daily"
export QWEN_STREAM_IDLE_TIMEOUT_MS=0
export QWEN_STREAM_MAX_LIFETIME_MS=0

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

Właściwa nazwa zmiennej ma znaczenie. W jednej zachowanej próbie klient dostał klucz pod złą nazwą i zakończył pracę przed wysłaniem choćby jednego tokena. Ten przebieg został wykluczony z oceny modelu, ale trafił do testów skryptu uruchamiającego.

Konfiguracja klienta deklarowała ten sam kontekst 150k, który wystawiał serwer. Używała wysiłku medium, ustawień losowania z karty modelu i zachowania myślenia między turami. Usunęliśmy stałe max_tokens: 8192, ponieważ wyłączało adaptacyjną próbę Qwen Code i ucinało dłuższe zapisy narzędzi.

Status w jednej linijce

Skrypt qwen-engine status odpowiadał na trzy pytania: który silnik działa, czy API vLLM odpowiada i co robi GPU.

systemctl --user is-active qwen.service || true
curl -fsS http://127.0.0.1:18020/health >/dev/null
nvidia-smi \
  --query-gpu=memory.used,utilization.gpu \
  --format=csv,noheader

Rozszerzony podgląd dodawał wykorzystanie GPU i pamięci oraz stan procesu. To wystarczało do eksperymentu. Usługa firmowa potrzebuje metryk w czasie, alertu, kolejki, przyczyny zakończenia i wersji profilu przypisanej do każdego żądania.

Profil zapasowy ma inną komendę i inne oczekiwania

Przełączenie na profil zapasowy wykonywało kontrolowane wyłączenie kontenera, a następnie uruchamiało usługę llama.cpp z profilem 120k i średnim poziomem rozumowania:

docker compose --profile single down
exec /srv/qwen/bin/qwen-context 120k medium

Nie próbujemy utrzymywać obu silników w pamięci. Po przełączeniu należy ponownie wykonać test profilu, bo klient 150k nie powinien zakładać, że serwer 120k przyjmie tę samą sesję. Rozwiązanie zapasowe ma odzyskać możliwość użytecznej pracy. Parametry wydajności mogą się zmienić.

W jednej dopasowanej próbie cały profil llama.cpp potrzebował 24:29, a wybrany profil vLLM 8:22. Były to różne formaty wag, pamięć kontekstu i limity kontekstu, więc wynik wybiera profil operacyjny. Nie izoluje przewagi samego silnika.

Pięciominutowy test po starcie

Przed dopuszczeniem normalnego zadania warto automatycznie sprawdzić:

Po aktualizacji obrazu dochodzi zestaw regresji na rzeczywistym zadaniu. Dla naszego profilu takim testem była naprawa błędów json.Marshal; krótki test podstawowy nie wykryłby niedeterministycznego zachowania awaryjnego, który później zdyskwalifikował wynik Codex.

Co z tego robimy dla klienta

Syntalith przekłada eksperymentalną instrukcję na wdrożenie należące do firmy: wersjonowany obraz, wykaz wag i licencji, zarządzanie sekretami, prywatny adres API, kolejkę, panel stanu, test po restarcie i sprawdzony powrót do poprzedniej wersji. Do tego dochodzi ocena na procesie klienta oraz szkolenie osób, które mają usługę utrzymać.

Audyt procesu AI od 4990 zł netto kończy się architekturą, kryteriami odbioru i stałą wyceną. Pełna aplikacja AI zaczyna się od 25 000 zł netto. Domowy RTX 3090 jest tu źródłem wniosków i awarii do przećwiczenia. Infrastrukturę produkcyjną dobieramy dopiero do procesu klienta.