Możesz uruchomić model na własnym serwerze GPU i połączyć go z aplikacją. Służy do tego API — interfejs, przez który program wysyła pytanie i odbiera odpowiedź. Poniżej pokazujemy działający przykład z Qwen3-8B i llama.cpp, programem uruchamiającym model.
Instrukcja prowadzi od pobrania sprawdzonych plików do pierwszej odpowiedzi. Osobno zmierzyliśmy szybkość Qwen3-8B i sprawdziliśmy 24 krótkie zadania po polsku i angielsku według wspólnej metodyki testów. Dzięki temu można rozdzielić dwa pytania: czy usługa działa i czy nadaje się do zadania, które chcesz jej powierzyć.
Co otrzymasz po wykonaniu poradnika?
Model będzie działał na serwerze, a dostęp z Twojego komputera zapewni szyfrowany tunel SSH. Aplikacja wysyła przez niego żądanie, serwer wykonuje obliczenia i tą samą drogą przekazuje odpowiedź. Nie trzeba w tym celu otwierać publicznego portu API.
Taki punkt wyjścia może posłużyć do prototypu firmowego asystenta, narzędzia przygotowującego robocze opisy albo wyciągającego wybrane pola z tekstu. Własne uruchomienie pozwala decydować o modelu, jego wersji i sposobie połączenia z aplikacją. Nie dodaje jednak automatycznie interfejsu czatu ani dostępu do dokumentów firmy — te elementy trzeba zaprojektować osobno.
Jak szybko odpowiada ten model?
W kontrolowanym pomiarze Qwen3-8B kończył odpowiedź po 1,5 s przy krótszym wejściu i 2,3 s przy dłuższym. W obu wariantach generował tyle samo tekstu: 256 tokenów, czyli fragmentów, na które model dzieli słowa i znaki. Każdy wariant powtórzyliśmy pięć razy po rozgrzewce; poniżej podajemy środkowy wynik tych pięciu prób.
| Długość wejścia | Pierwszy token | Cała odpowiedź |
|---|---|---|
| 2048 tokenów | 0,2 s | 1,5 s |
| 8192 tokeny | 0,8 s | 2,3 s |
To 10 zakończonych odpowiedzi przy jednym zapytaniu naraz, mierzonych lokalnie na serwerze. Ten wariant ma jedno zarezerwowane miejsce obsługi (slot); test równoległości porównuje jedno i cztery aktywne zapytania przy czterech zarezerwowanych miejscach. Tabela pokazuje wpływ długości wejścia przy stałej długości odpowiedzi. Nie jest obietnicą czasu każdej rozmowy: tekst zadania, długość wyniku, obciążenie serwera i połączenie internetowe mogą go zmienić. Krótkie zapytanie z 32 tokenami w instrukcji poniżej służy tylko sprawdzeniu uruchomienia — nie odtwarza tego pomiaru.
Pierwsza kolumna czasu pokazuje, kiedy program pomiarowy odebrał pierwszy wygenerowany token. Nie zawsze jest to pierwszy fragment końcowej odpowiedzi widoczny dla użytkownika.
Szybka odpowiedź to dopiero połowa zadania
W oddzielnej próbie model dostał 24 proste zadania: obliczenia, odczytywanie pól z tekstu, przypisywanie kategorii według podanej reguły oraz odpowiedzi na podstawie krótkiego opisu. Każde wykonał tylko raz. Wszystkie 24 odpowiedzi miały wymagany format JSON, czyli zestaw nazwanych pól, który aplikacja może bezpośrednio odczytać. 17 odpowiedzi dokładnie zgadzało się z zapisanym wzorcem.
Model poprawnie rozwiązał wszystkie sześć zadań przypisywania kategorii i wszystkie sześć pytań opartych na dostarczonym opisie. Taki sposób pracy może być przydatny przy wstępnym porządkowaniu zgłoszeń: aplikacja podaje regułę, a model zwraca pole z kategorią. To sprawdzone małe przykłady, nie ocena dowolnego dokumentu czy każdej firmowej procedury.
Cztery rozbieżności dotyczyły obliczeń. Na przykład zadanie rozpoczęte o 09:45 i trwające 95 minut powinno kończyć się o 11:20, a model zwrócił 11:15. Pozostałe trzy dotyczyły dokładnego zapisu odczytanej nazwy — między innymi dodatkowej kropki lub słowa „Zespół”. Zachowujemy pierwotną, ścisłą ocenę: 17/24 oznacza zgodność z konkretnym wzorcem, a nie ogólną „trafność modelu”. W praktycznej aplikacji warto jasno ustalić format nazw, a obliczenia wymagające pewnego wyniku wykonywać w kodzie programu.
Jak wygląda uruchomienie krok po kroku?
Potrzebujesz konta na serwerze, dostępu SSH i działającego sterownika GPU. Polecenia są w rozwijanej części technicznej, ale warto najpierw wiedzieć, co robi każdy etap:
- Sprawdź kartę. System powinien widzieć właściwy GPU i sterownik. Ten krok oddziela problem sprzętu lub sterownika od późniejszych problemów z samym modelem.
- Pobierz i sprawdź pliki. Osobno potrzebne są program, jego biblioteki i wagi modelu, czyli pliki wykorzystywane w obliczeniach. Przypięte wersje i sumy kontrolne pomagają odtworzyć to samo środowisko. Nie przechodź dalej, jeżeli suma się nie zgadza.
- Uruchom model na serwerze. Proces ładuje dane i udostępnia lokalne API. Pozostaw jego terminal otwarty, aby widzieć gotowość lub komunikat błędu. Zajęcie pamięci GPU i obecność procesu pomagają potwierdzić, że korzystasz z karty.
- Otwórz tunel na własnym komputerze. To oddzielny terminal. Tunel łączy lokalny adres komputera z lokalnym adresem usługi na serwerze; nie uruchamia drugiej kopii modelu.
- Sprawdź gotowość i wyślij próbę. W kolejnym lokalnym terminalu najpierw pytasz o stan, a potem wysyłasz krótkie żądanie. Strumień pokazuje fragmenty odpowiedzi w miarę generowania, zamiast czekać na cały tekst.
- Zakończ próbę. Zatrzymaj proces modelu i tunel w ich terminalach. Nie wymaga to restartu serwera; sprawdzone pliki pozostają do kolejnego uruchomienia.
Po czym poznać, że pierwszy etap działa?
Warto rozdzielić trzy rzeczy: proces działa na GPU, API jest gotowe, a odpowiedź dociera do klienta. Sama obecność uruchomionego programu nie potwierdza wszystkich trzech. Instrukcja zawiera osobne sprawdzenie urządzenia, gotowości usługi i krótkiego strumienia, a także podpowiedzi dla najczęstszych błędów.
Pierwsze żądanie służy kontroli generowania przez /completion. Nie jest gotową rozmową czatową ani testem prawdziwości odpowiedzi. W aplikacji czatowej trzeba dobrać właściwy szablon rozmowy i sposób obsługi wyników. Odpowiedź HTTP 200 oznacza powodzenie żądania, nie automatyczną poprawność treści.
Od działającego API do przydatnej aplikacji
Po uruchomieniu wybierz niewielki zestaw zadań z oczekiwanymi odpowiedziami. Sprawdź zarówno zawartość, jak i wymagany format — na przykład czy aplikacja rzeczywiście otrzymuje same pola JSON. Następnie zmierz czas przy typowych długościach dokumentów i przewidywanej liczbie równoczesnych zapytań. Nasze testy API pomagają odróżnić oczekiwanie jednej osoby od łącznej przepustowości serwera.
Na etapie próby używaj danych testowych. Tunel ogranicza dostęp sieciowy, ale stała usługa nadal potrzebuje uwierzytelniania użytkowników, limitów żądań, zasad przechowywania danych i aktualizacji. Własny serwer daje kontrolę nad tymi decyzjami, nie zastępuje ich podjęcia.
Jeżeli dopiero poznajesz modele, zacznij od słownika AI i GPU. Zobacz konfigurację serwera lub opisz aplikację, którą planujesz uruchomić.
Szczegóły techniczne
Wcześniejsza kontrola instrukcji obejmowała jeden slot: lokalne /health i /completion zwróciły HTTP 200, a strumień zakończył generowanie 32 tokenów. Potwierdziliśmy proces na właściwym GPU i przeniesienie 37/37 warstw do GPU. Tę kontrolę gotowości zachowujemy oddzielnie od nowych pomiarów wydajności i zadań opisanych wyżej. Nie mierzyliśmy połączenia internetowego klienta.
Zakres pomiaru CORE 1.1
W nowej serii gsh-llm-core/1.1 użyliśmy Qwen3-8B Q4_K_M, jednego klienta, jednego slotu i kontekstu 8704 tokenów. Dla każdego wejścia — 2048 i 8192 tokenów — wykonaliśmy jedną pełną rundę rozgrzewki i pięć rund pomiarowych. Wyjście syntetyczne miało zawsze 256 tokenów; wyłączone były buforowanie wejścia i automatyczne dopasowywanie parametrów. Czas odpowiedzi kończy się na zdarzeniu zakończenia generowania, nie na późniejszym zamknięciu połączenia.
Próba praktyczna korzystała z /v1/chat/completions, przypiętego szablonu rozmowy, wyłączonego rozumowania i limitu 1024 tokenów. Po osobnej próbie transportu wykonaliśmy po jednym żądaniu dla każdego z 24 zadań: 12 polskich i 12 angielskich. Poprawność formatu wymagała jednego obiektu JSON z dokładnymi nazwami i typami pól; zgodność wartości wymagała także identyczności ze wzorcem. Nie usuwaliśmy znaczników Markdown, nie poprawialiśmy nazw i nie ponawialiśmy odpowiedzi w celu podniesienia wyniku. Wszystkie odpowiedzi zakończyły się przed limitem wyjścia.
Wyniki wyniosły 24/24 dla formatu oraz 17/24 dla dokładnej zgodności wartości: 9/12 po polsku i 8/12 po angielsku. Ten niewielki autorski zestaw nie uzasadnia rankingu jakości języków ani ogólnej wiedzy modelu. W zadaniach odczytywania nazw ścisły wzorzec nie obejmował wszystkich możliwych interpretacji tekstu; zachowaliśmy wynik i opisujemy jego znaczenie, zamiast zmieniać punktację po teście.
Załączniki core-v1-results.json i core-v1-results.csv zawierają zweryfikowane dane nowej serii. Polecenia poradnika pozostają prostą instrukcją uruchomienia, a nie pełnym programem odtwarzającym rozgrzewki, pomiary i zadania CORE.
Środowisko i zakres poradnika
| Element | Konfiguracja użyta w naszej serii testowej |
|---|---|
| GPU | NVIDIA RTX PRO 6000 Blackwell Max-Q Workstation Edition, 96 GB VRAM |
| System | Rocky Linux 10.2, x86-64 |
| Sterownik NVIDIA | 595.91.07 |
| RAM systemowy | 96 GB |
| Silnik | llama.cpp 0.5.0-dev, build b11146, CUDA 12.8 |
| Model | Qwen3-8B-GGUF, Q4_K_M, plik 5 027 783 488 bajtów |
Szczegóły wykonywania pomiarów opisuje metodyka testów.
Przypinamy llama.cpp do commitu 7fe450e19305b828c199d602c23a8337aaa1f03b. Wydanie b11146 jest oznaczone przez projekt jako pre-release. Wybraliśmy je do odtwarzania tej konkretnej serii, nie jako deklarację najnowszej stabilnej wersji produkcyjnej. Archiwa mają w nazwie Ubuntu, ale te konkretne binaria i biblioteki uruchomiliśmy na wskazanym Rocky. Nie oznacza to zgodności każdej paczki Ubuntu z każdym systemem.
Zanim pobierzesz model
Potrzebne są działający sterownik GPU, konto bez uprawnień roota, Bash, curl, tar, sha256sum i dostęp SSH. Komendy przygotowawcze wykonuj w tej samej sesji Bash na serwerze. Zostaw miejsce zarówno na pobrane archiwa, jak i ich rozpakowaną zawartość oraz model.
Najpierw sprawdź GPU:
nvidia-smi --query-gpu=name,driver_version,memory.total,power.limit --format=csv
Jeżeli polecenie nie działa albo nie pokazuje właściwej karty, najpierw trzeba naprawić instalację sterownika. Pobranie bibliotek CUDA nie zastąpi sterownika jądra. Pole „CUDA Version” w nvidia-smi również nie jest dowodem, że zainstalowano dokładnie tę wersję toolkitu — dotyczy możliwości sterownika. Zobacz opis NVIDIA-SMI i zasady zgodności CUDA.
Poniższe kroki nie instalują pakietów systemowych, nie zmieniają sterownika, firmware ani konfiguracji SSH. Biblioteki będą widoczne tylko dla uruchamianego procesu przez LD_LIBRARY_PATH.
Pobierz konkretne wersje i sprawdź sumy
Tworzymy nowy, prywatny katalog roboczy. Kolejne wykonanie tej komendy utworzy osobny katalog — nie nadpisze poprzedniego środowiska.
set -euo pipefail
umask 077
llm_dir="$(mktemp -d "$HOME/qwen3-api.XXXXXX")"
cd "$llm_dir"
mkdir downloads engine cuda models
Pobierz dwa oficjalne archiwa wydania: program oraz biblioteki CUDA. Flagi --proto ograniczają transfer i przekierowania do HTTPS.
llm_release='https://github.com/ggml-org/llama.cpp/releases/download/b11146'
curl --fail --location --proto '=https' --proto-redir '=https' \
"$llm_release/llama-b11146-bin-ubuntu-cuda-12.8-x64.tar.gz" \
--output downloads/llama.tar.gz
curl --fail --location --proto '=https' --proto-redir '=https' \
"$llm_release/cudart-llama-b11146-bin-ubuntu-cuda-12.8-x64.tar.gz" \
--output downloads/cudart.tar.gz
printf '%s %s\n' \
'c2ab9e19838513ff69d1af8d999ad717dd3c7ee4714ac04c7ed5ab9077c50e4e' downloads/llama.tar.gz \
'1466daea60aad1144819e151b2bae19d54556cf1da6c129c4f55a5ded2637c25' downloads/cudart.tar.gz \
| sha256sum --check
Obie pozycje muszą otrzymać wynik OK. Przy błędzie pobierania lub sumy nie rozpakowuj pliku i nie przechodź dalej. Suma kontrolna potwierdza zgodność z przypiętym artefaktem; sama nie zastępuje zaufania do jego wydawcy.
Model pobieramy z repozytorium autora i konkretnej rewizji 7c41481f57cb95916b40956ab2f0b139b296d974, a nie ze zmiennej gałęzi main:
llm_model_source='https://huggingface.co/Qwen/Qwen3-8B-GGUF/resolve/7c41481f57cb95916b40956ab2f0b139b296d974'
curl --fail --location --proto '=https' --proto-redir '=https' \
"$llm_model_source/Qwen3-8B-Q4_K_M.gguf" \
--output models/Qwen3-8B-Q4_K_M.gguf
printf '%s %s\n' \
'd98cdcbd03e17ce47681435b5150e34c1417f50b5c0019dd560e4882c5745785' \
models/Qwen3-8B-Q4_K_M.gguf | sha256sum --check
curl --fail --location --proto '=https' --proto-redir '=https' \
"$llm_model_source/LICENSE" --output models/LICENSE
curl --fail --location --proto '=https' --proto-redir '=https' \
"$llm_model_source/README.md" --output models/README.md
Tutaj również wymagany jest wynik OK przed uruchomieniem modelu. Zachowaj plik licencji i kartę modelu. Nazwa Q4_K_M określa wybrany wariant wag; nie oznacza tej samej jakości ani rozmiaru jak inne kwantyzacje.
Rozpakuj runtime i potwierdź dostęp do CUDA
Rozpakowujemy wyłącznie sprawdzone archiwa do wcześniej utworzonych, pustych katalogów:
tar --extract --gzip --file downloads/llama.tar.gz \
--directory engine --no-same-owner --no-same-permissions
tar --extract --gzip --file downloads/cudart.tar.gz \
--directory cuda --no-same-owner --no-same-permissions
llm_server="$llm_dir/engine/llama-b11146/llama-server"
llm_libraries="$llm_dir/engine/llama-b11146:$llm_dir/cuda/cudart-llama-b11146-bin-ubuntu-cuda-12.8-x64"
env LD_LIBRARY_PATH="$llm_libraries" CUDA_VISIBLE_DEVICES=0 \
"$llm_server" --list-devices
Wynik powinien wskazać urządzenie CUDA i właściwy GPU. Samo uruchomienie procesu na CPU nie potwierdza poprawnej konfiguracji GPU. Jeżeli brakuje biblioteki, sprawdź oba archiwa i ścieżki, zamiast kopiować przypadkowe pliki .so do katalogów systemowych.
Uruchom API tylko na serwerowym localhost
W tej samej sesji uruchom proces na pierwszym GPU. Wybieramy jeden slot i kontekst 8704 tokenów, bez automatycznego dopasowywania parametrów. To konfiguracja startowa do sprawdzenia integracji, nie ustawienie dobrane do każdej aplikacji.
env LD_LIBRARY_PATH="$llm_libraries" CUDA_VISIBLE_DEVICES=0 \
"$llm_server" \
-m "$llm_dir/models/Qwen3-8B-Q4_K_M.gguf" \
--host 127.0.0.1 --port 8080 \
-ngl 999 --fit off --load-mode mmap --lazy-mode off -fa on \
-t 16 -b 2048 -ub 512 -ctk f16 -ctv f16 \
-np 1 -c 8704 \
--cache-ram 0 --no-cache-idle-slots --no-context-shift
Zostaw ten terminal otwarty. Po wcześniejszym sprawdzeniu urządzenia CUDA użyj nvidia-smi w osobnej sesji SSH: powinien być widoczny proces llama-server i zajęta pamięć GPU, a podczas zapytania także aktywność GPU. Domyślny poziom logowania tej wersji nie musi wypisywać liczby warstw przeniesionych na GPU; brak takiego wiersza sam w sobie nie oznacza pracy na CPU. --host 127.0.0.1 jest tutaj istotny: nie zastępuj go 0.0.0.0 i nie otwieraj portu 8080 na routerze. Opcje i endpointy opisuje dokumentacja tej rewizji llama-server.
Połącz się ze swojego komputera
W drugim terminalu, na własnym komputerze, uruchom tunel. Zastąp gpu-server.example, login, ścieżkę klucza i port 22 danymi własnego serwera. Użyj portu wybranego przy instalacji, także jeśli jest to 3414 albo port losowy. Nie kopiuj klucza prywatnego na serwer.
ssh -N -T -a \
-i "$HOME/.ssh/gpu-server" -p 22 \
-o ExitOnForwardFailure=yes \
-o ServerAliveInterval=30 -o ServerAliveCountMax=3 \
-L 127.0.0.1:18080:127.0.0.1:8080 \
gpu@gpu-server.example
Przy pierwszym połączeniu zweryfikuj klucz hosta znanym, zaufanym kanałem. Nie wyłączaj sprawdzania jego tożsamości. Tunel wiąże lokalny port 18080 tylko z localhost Twojego komputera i prowadzi do portu 8080 widzianego przez serwer. Znaczenie -L i -N opisuje dokumentacja OpenSSH.
W trzecim terminalu, również na własnym komputerze, sprawdź gotowość:
curl --fail --show-error http://127.0.0.1:18080/health
Oczekiwana gotowość to HTTP 200 i {"status":"ok"}. Podczas ładowania modelu endpoint może odpowiadać HTTP 503. Następnie wykonaj krótkie zapytanie strumieniowe:
curl --fail --show-error --no-buffer \
http://127.0.0.1:18080/completion \
-H 'Content-Type: application/json' \
--data '{"prompt":"Write one sentence about GPU memory.","n_predict":32,"stream":true,"cache_prompt":false,"temperature":0}'
/completion służy tu do sprawdzenia lokalnego generowania i przesyłania odpowiedzi. To nie jest gotowy szablon czatu ani ocena jakości modelu. Nie należy traktować parametrów tego krótkiego sprawdzenia jako zalecanej konfiguracji Qwen dla wszystkich rozmów. Integrację czatową, szablon i ustawienia generowania dobierz do aplikacji, korzystając z karty modelu Qwen oraz dokumentacji serwera.
Co sprawdzić, kiedy coś nie działa
| Objaw | Następny krok |
|---|---|
| Błędna suma SHA-256 | Nie uruchamiaj pliku; sprawdź pełne pobranie i dokładny adres wersji. |
| Brak biblioteki CUDA lub urządzenia | Sprawdź sterownik, oba archiwa oraz LD_LIBRARY_PATH; nie akceptuj pracy CPU jako testu GPU. |
| Tunel zgłasza zajęty port | Wybierz inny lokalny port zamiast 18080 i używaj go w curl. |
| SSH odmawia przekierowania | Sprawdź z administratorem politykę przekierowań konta; nie obchodź jej wystawieniem API publicznie. |
| HTTP 503 | Sprawdź log ładowania modelu; jeśli proces się zakończył, przeczytaj błąd zamiast czekać bez końca. |
| Brak pamięci | Sprawdź inne procesy GPU, kontekst i liczbę slotów; nie zmieniaj kilku parametrów naraz. |
Aby zakończyć próbę, naciśnij Ctrl+C w terminalu serwera, a potem w terminalu tunelu. Nie wymaga to restartu maszyny. Pobrane pliki pozostają w oddzielnym katalogu do kolejnego uruchomienia.
Granice bezpieczeństwa i licencji
Loopback z tunelem ogranicza dostęp sieciowy, ale nie uwierzytelnia innych procesów lokalnych ani osób mających dostęp do konta. Na tym etapie korzystaj wyłącznie z danych testowych. Stała usługa potrzebuje osobnego projektu uwierzytelniania, limitów zapytań, aktualizacji i zasad przechowywania logów; udostępnienie API klientom jest kolejnym etapem, nie zmianą jednej flagi adresu.
Qwen3-8B-GGUF ma licencję Apache-2.0 w przypiętej rewizji, a llama.cpp licencję MIT. Biblioteki NVIDIA mają odrębne warunki CUDA. Nie przenoś automatycznie licencji tego modelu na inne warianty Qwen ani na pozostałe składniki środowiska. Wagi pobierasz bezpośrednio od ich wydawcy; GPU Server Hub nie rozpowszechnia ich w tym poradniku.
Jeżeli chcesz przejść od próby do własnej aplikacji, sprawdź konfigurację serwera albo opisz model, kontekst i przewidywany ruch. Testy i poradniki pomagają oddzielić działającą instalację od pomiaru jej wydajności.