Jak uruchomić GLM na VPS zamiast GLM 5.2?

Czy można uruchomić GLM 5.2 na VPS?

Nie, a powód warto poznać przed wynajęciem jakiejkolwiek infrastruktury. Według stanu na 18 sierpnia 2026, GLM 5.2 w bibliotece Ollama posiada dokładnie jeden tag, glm-5.2:cloud. Tag :cloud działa na serwerach Ollama. Twoja maszyna wysyła prompt i odbiera tokeny, więc wagi nigdy nie trafiają na Twój dysk. Model posiada 756 miliardów parametrów. Cztery bity na parametr przy 756 miliardach parametrów to około 378 GB wag, a jest to czysta matematyka przed uwzględnieniem kontekstu, aktywacji czy systemu operacyjnego. Żaden standardowy plan VPS nie oferuje takiej ilości pamięci.

Modelem GLM, który mieści się na wynajętym serwerze, jest glm-4.7-flash. Jest on publikowany z wagami możliwymi do pobrania w 4 tagach. Jest to model typu mixture-of-experts, co oznacza, że dla każdego tokena uruchamiana jest tylko niewielka część sieci, a Z.ai opisuje go jako 30B-A3B: łącznie 30 miliardów parametrów, około 3 miliardy aktywne na token. Niniejszy przewodnik odpowiada zatem na pytanie, w oparciu o które można podjąć działania. Przypnij tag, dobierz rozmiar maszyny, zmierz własną prędkość i zachowaj prywatność punktu końcowego.

Zweryfikuj tag przed skopiowaniem jakiejkolwiek komendy, w tym tych zawartych w tym dokumencie. Biblioteka Ollama zmienia się bez powiadomienia. Otwórz listę tagów glm-4.7-flash i potwierdź, że tag nadal istnieje. Jeśli pojawiło się nowsze wydanie GLM z lokalnymi wagami, wybierz je i zanotuj, który tag faktycznie przetestowano.

Jeśli mimo wszystko chcesz korzystać z GLM 5.2, ollama run glm-5.2:cloud działa po ollama signin i z perspektywy klienta zachowuje się jak każdy inny model Ollama. Zrozum, na co wyrażasz zgodę: prompt opuszcza Twój serwer. Jeśli powodem samodzielnego hostowania jest wymóg pozostania danych na własnej maszynie, tag :cloud nie spełnia tego założenia.

Dostępne tagi GLM i wybór wersji do przypięcia

W tym kontekście istotne są trzy oficjalne wpisy GLM. glm-5.2 oraz glm-5.1 dotyczą wyłącznie chmury. glm-4.7-flash to wersja lokalna; poniżej przedstawiono opublikowane tagi wraz z rozmiarem pobierania wskazywanym przez Ollama dla każdego z nich.

[
  {
    "label": "q4_K_M",
    "download_gb": 19
  },
  {
    "label": "latest",
    "download_gb": 19
  },
  {
    "label": "q8_0",
    "download_gb": 32
  },
  {
    "label": "bf16",
    "download_gb": 60
  }
]

Są to wartości podane na stronie biblioteki, a nie wyniki pomiarów. Zarówno latest, jak i q4_K_M mają przypisaną wartość 19 GB, dlatego latest wskazuje obecnie na kompilację Q4. Może się to zmienić przy każdej ponownej publikacji, dlatego nie należy umieszczać samego ollama pull glm-4.7-flash w skryptach ani plikach Dockerfile. Należy wskazać kwantyzację. Największy tag, bf16, wymaga pobrania 60 GB danych i zawiera niekwantyzowane wagi bfloat16.

Wyszukiwanie w bibliotece zwraca również przesłane pliki z przestrzenią nazw, zawierające ukośnik w nazwie, takie jak someuser/glm-5.2. Ukośnik oznacza, że plik został opublikowany przez konto użytkownika, jest to więc ponowne przesłanie przez społeczność, a nie oficjalny wpis. Nikt nie gwarantuje, jakie wagi znajdują się wewnątrz. Należy traktować taki plik jak każdy niepodpisany plik binarny znaleziony w sieci.

Instalacja Ollama i pobranie konkretnego tagu

Instalator Ollama dla systemu Linux to pojedyncze polecenie.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version

Instalator tworzy usługę systemd, która działa jako użytkownik ollama. Przed pobraniem czegokolwiek należy potwierdzić, że usługa została uruchomiona.

systemctl status ollama --no-pager

Active: active (running) oznacza, że API nasłuchuje na porcie 11434. Jeśli jednostka nie istnieje, instalator wykonał instalację binarną, a dokumentacja Ollama dla systemu Linux zawiera plik usługi, który należy utworzyć ręcznie.

Strona glm-4.7-flash zawiera listę minimalnych wersji Ollama. Starsza wersja binarna nie powoduje wolnego działania modelu, lecz jego odrzucenie: pobieranie kończy się niepowodzeniem z komunikatem, że model wymaga nowszej wersji Ollama. Aby dokonać aktualizacji, należy ponownie uruchomić skrypt instalacyjny. Na dzień 18 sierpnia 2026 r. aktualne wydanie to 0.32.14, co znacznie przewyższa wymagane minimum.

Teraz należy pobrać jeden tag według nazwy.

ollama pull glm-4.7-flash:q4_K_M
ollama ls

ollama ls powinno wyświetlić glm-4.7-flash:q4_K_M o rozmiarze zbliżonym do opublikowanego 19 GB. Przerwane pobieranie nie pozostawia żadnych uruchamialnych plików, dlatego należy ponownie wykonać to samo polecenie. Najczęstszą przyczyną nieudanego pobierania w przypadku małych planów jest zapełnienie dysku, a nie problemy z siecią, ponieważ model jest zapisywany w /usr/share/ollama/.ollama/models na głównym systemie plików. Przed rozpoczęciem należy sprawdzić stan za pomocą df -h /usr/share/ollama.

Ile pamięci RAM wymaga każda kwantyzacja?

Należy przyjąć rozmiar pliku do pobrania jako wartość minimalną, a następnie dodać do niej odpowiedni zapas. Wagi modelu muszą znajdować się w pamięci operacyjnej. Oprócz nich w pamięci przechowywana jest pamięć podręczna KV (key/value cache), wykorzystywana przez środowisko uruchomieniowe do zapamiętywania tokenów z bieżącej konwersacji, a także bufory obliczeniowe oraz zasoby zajmowane przez system operacyjny. Serwer posiadający dokładnie 19 GB pamięci RAM nie uruchomi modelu oznaczonego jako 19 GB.

Nie istnieje jeden uniwersalny mnożnik, ponieważ rozmiar pamięci podręcznej KV rośnie wraz z dopuszczalną długością kontekstu, a pozostałe parametry zmieniają się w zależności od wersji środowiska uruchomieniowego. Zamiast szacować, należy dokonać pomiaru. Wczytaj model z prostym zapytaniem, a następnie sprawdź ilość pamięci zarezerwowaną przez serwer.

ollama run glm-4.7-flash:q4_K_M "Reply with the single word: ready"
ollama ps

ollama ps wyświetla wczytany model wraz z kolumnami SIZE oraz PROCESSOR. Wartość SIZE określa ilość pamięci faktycznie zarezerwowaną przez środowisko uruchomieniowe i to właśnie ten parametr należy porównać z posiadanymi zasobami. PROCESSOR wskazuje miejsce wykonywania obliczeń, przy czym 100% CPU oznacza, że procesor graficzny nie został wykorzystany.

Jeśli model nie mieści się w pamięci, błąd nie jest sygnalizowany wprost i przybiera jedną z dwóch form. Przy włączonej partycji wymiany (swap) wczytywanie pozornie kończy się sukcesem, lecz generowanie tekstu jest skrajnie powolne, ponieważ strony pamięci są przenoszone między dyskiem a RAM przy każdym tokenie. Bez partycji swap proces jest natychmiastowo przerywany, a journalctl -k | grep -i "out of memory" pokazuje w dzienniku jądra Out of memory: Killed process linię wskazującą na ollama. Należy sprawdzić oba te miejsca, ponieważ w terminalu, w którym wprowadzono polecenie, nie pojawia się żaden użyteczny komunikat.

Przejście z wariantu Q4 o rozmiarze 19 GB na wariant Q8 o rozmiarze 32 GB jest głównym sposobem na kontrolę zużycia pamięci. Kwantyzacja Q4 wiąże się z pewną utratą jakości wyjściowej, której skala zależy od rodzaju zadania; strukturalne dane wyjściowe oraz długie procesy wnioskowania cierpią bardziej niż swobodna konwersacja. Przed podjęciem decyzji warto zapoznać się z artykułem Różnice między Q4, Q8 i FP16 w praktyce, ponieważ w przypadku serwerów VPS bez GPU wybór kwantyzacji zazwyczaj decyduje o tym, czy model w ogóle zostanie uruchomiony.

Co dzieje się na serwerze VPS bez GPU

Większość planów VPS nie oferuje GPU, a Ollama uruchomi model na CPU bez żadnego ostrzeżenia. To, czy wynik będzie użyteczny, zależy od obciążenia oraz cierpliwości użytkownika.

Architektura mixture-of-experts poprawia szybkość działania. Dla każdego tokena wykorzystywane są tylko około 3 miliardy z 30 miliardów parametrów, więc liczba operacji arytmetycznych na token jest znacznie mniejsza niż w przypadku gęstego modelu 30B. Nie zmniejsza się natomiast zapotrzebowanie na pamięć. Każdy ekspert musi pozostawać w pamięci, ponieważ router może wybrać dowolnego z nich dla kolejnego tokena. Zatem serwer wyposażony tylko w CPU nadal wymaga pełnych 19 GB lub więcej dla tagu Q4, a przepustowość jest ograniczona głównie przez przepustowość pamięci, a nie przez taktowanie procesora.

Ma to praktyczne konsekwencje: dwa plany o tej samej liczbie rdzeni i tej samej ilości pamięci RAM mogą generować tekst z zauważalnie różną prędkością, ponieważ różnią się podsystemami pamięci. Plan współdzielony wprowadza drugą zmienną, ponieważ czas kradzieży CPU przez sąsiedni proces objawia się jako liczba tokenów na sekundę, która zmienia się z godziny na godzinę. Jest to powód, dla którego opublikowane wyniki innych osób nie przewidują wydajności Twojego serwera, oraz powód, dla którego kolejna sekcja zawiera metodologię pomiaru zamiast tabeli wyników.

Pomiar własnej liczby tokenów na sekundę

Punkt końcowy generate w Ollama zwraca pola czasowe w końcowym obiekcie JSON. Należy podzielić liczbę wygenerowanych tokenów przez czas trwania generowania, aby uzyskać wynik dla danego planu i zapytania.

sudo apt install -y jq
curl -s http://localhost:11434/api/generate -d '{
  "model": "glm-4.7-flash:q4_K_M",
  "prompt": "Write a 200 word explanation of how TCP congestion control works.",
  "stream": false,
  "options": {"num_ctx": 8192}
}' | jq '{
  tokens: .eval_count,
  tokens_per_second: (.eval_count / .eval_duration * 1e9),
  prompt_seconds: (.prompt_eval_duration / 1e9),
  load_seconds: (.load_duration / 1e9)
}'

eval_count oznacza liczbę wygenerowanych tokenów, a eval_duration to czas w nanosekundach poświęcony na ich wygenerowanie, zatem eval_count / eval_duration * 1e9 to liczba tokenów na sekundę. prompt_eval_duration obejmuje odczyt zapytania, co użytkownik odczuwa jako czas oczekiwania na pojawienie się pierwszego tokena. load_duration to czas ładowania modelu z dysku; jest on duży przy pierwszym wywołaniu po restarcie i bliski zeru przy kolejnych.

Należy wykonać test trzykrotnie i zachować drugi oraz trzeci wynik, ponieważ pierwszy uwzględnia czas ładowania. Następnie należy powtórzyć test z znacznie dłuższym zapytaniem, ponieważ przetwarzanie zapytania skaluje się wraz z długością danych wejściowych, podczas gdy szybkość generowania pozostaje stała. Warto zapisać wyniki obok nazwy planu i zastosowanej kwantyzacji. Taka dokumentacja jest bardziej wartościowa niż jakikolwiek przeczytany benchmark, ponieważ została zmierzona na sprzęcie, za który ponoszone są opłaty.

Jak długość kontekstu zwiększa zużycie pamięci

Ollama domyślnie ustawia kontekst na 4096 tokenów. Model deklaruje znacznie większą wartość, 198K tokenów dla glm-4.7-flash, jednak nie jest ona dostępna domyślnie, a jej aktywacja wiąże się z kosztami zasobów.

Pamięć podręczna KV przechowuje jeden wektor klucza i jeden wektor wartości dla każdego tokena w każdej warstwie. Jej rozmiar rośnie liniowo wraz z liczbą dozwolonych tokenów. Zwiększenie z 4096 do 32768 tokenów oznacza ośmiokrotne powiększenie kontekstu, co przekłada się na mniej więcej ośmiokrotny wzrost rozmiaru pamięci podręcznej KV. Na maszynie, której pamięć jest dopasowana jedynie do wag modelu, ta dodatkowa alokacja powoduje przejście do swap. Jest to przyczyna, dla której serwer poprawnie odpowiadający na krótkie zapytania drastycznie zwalnia po wklejeniu długiego dokumentu.

Wartość tę można ustawić dla każdego żądania za pomocą num_ctx w obiekcie opcji, tak jak w powyższym poleceniu curl, lub zmienić ustawienie domyślne serwera.

sudo install -d -m 755 /etc/systemd/system/ollama.service.d
printf '[Service]\nEnvironment="OLLAMA_CONTEXT_LENGTH=16384"\n' \
  | sudo tee /etc/systemd/system/ollama.service.d/override.conf
sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

Ostatnie polecenie powinno wyświetlić wartość OLLAMA_CONTEXT_LENGTH. Jeśli wynik dla Environment= jest pusty, oznacza to, że plik nadpisujący konfigurację znajduje się w niewłaściwym katalogu lub pominięto przeładowanie. Po ponownym załadowaniu modelu, ollama ps powinno wskazywać wyraźnie większą wartość SIZE niż przy 4096. Należy zwiększać tę wartość stopniowo i za każdym razem monitorować ten parametr. Ustawianie długości kontekstu Ollama za pomocą num_ctx opisuje, jak wpływa to na parametr keep-alive oraz żądania równoległe, z których każde zwielokrotnia ten sam koszt. Jeśli z serwera będzie korzystać więcej niż jeden klient, limity współbieżności należy ustalić jednocześnie z długością kontekstu, ponieważ każdy slot równoległy posiada własną pamięć podręczną KV, a ustawienie kolejki decyduje o tym, czy drugie żądanie zostanie wstrzymane, czy odrzucone.

Kiedy API jest tańsze niż własny serwer

Samodzielne hostowanie nie zawsze jest tańsze, a w przypadku tej rodziny modeli opublikowane cenniki wyraźnie to potwierdzają.

[
  {
    "label": "GLM-5.2 input",
    "usd_per_million_tokens": 1.4
  },
  {
    "label": "GLM-5.2 output",
    "usd_per_million_tokens": 4.4
  },
  {
    "label": "GLM-4.7-Flash input",
    "usd_per_million_tokens": 0
  },
  {
    "label": "GLM-4.7-Flash output",
    "usd_per_million_tokens": 0
  }
]

Według stanu na 18 sierpnia 2026, Z.ai wycenia GLM-5.2 na $1.4 za milion tokenów wejściowych oraz $4.4 za milion tokenów wyjściowych. Model GLM-4.7-Flash, który w tym przewodniku uruchamiamy lokalnie, wyceniono na $0 w obu kierunkach. Są to ceny oficjalne, które ulegają zmianom, dlatego przed zaplanowaniem budżetu należy sprawdzić aktualną stronę cennika.

Zatem argument finansowy przemawiający za samodzielnym hostowaniem glm-4.7-flash jest obecnie słaby. Serwer VPS z odpowiednią ilością pamięci RAM generuje co miesiąc realne koszty, podczas gdy wydawca udostępnia ten sam model bez dodatkowych opłat. Wartość samodzielnego uruchomienia modelu jest inna: zapytania pozostają na maszynie, którą kontrolujesz, a wersja modelu nie zmieni się, dopóki sam jej nie zaktualizujesz. To dobre powody, by hostować samodzielnie. Koszt w przypadku tego modelu i tych cen do nich nie należy.

Rachunek zmienia się, gdy wybrany model nie jest darmowy lub gdy dane zgodnie z prawem nie mogą opuścić sieci lokalnej. Punkt opłacalności między VPS z GPU a tokenami API szczegółowo omawia te obliczenia z uwzględnieniem wszystkich zmiennych. Jeśli nadal wybierasz maszynę, rzeczywisty miesięczny koszt VPS stanowi drugą połowę tego zestawienia.

Utrzymanie punktu końcowego na localhost

To krok, który jest często pomijany, a ma kluczowe znaczenie.

Ollama domyślnie wiąże się z adresem 127.0.0.1 na porcie 11434, dzięki czemu jest dostępna wyłącznie z poziomu samego serwera. Należy to zweryfikować na własnej maszynie, zamiast zakładać, że tak jest w istocie.

ss -ltnp | grep 11434

Oczekiwany wynik to 127.0.0.1:11434. Zobaczenie 0.0.0.0:11434 lub *:11434 oznacza, że API nasłuchuje na wszystkich interfejsach, w tym na publicznym.

Jest to istotne, ponieważ API Ollama nie posiada mechanizmów uwierzytelniania. Brak jest haseł, tokenów czy list dozwolonych adresów. Każdy, kto uzyska dostęp do portu 11434, może wyświetlić listę modeli, uruchamiać generowanie na opłacanych przez użytkownika zasobach, pobierać nowe modele do wyczerpania miejsca na dysku oraz usuwać istniejące. Port 11434 jest stały i powszechnie znany, więc skanery szybko wykrywają otwarte instancje.

Nie należy ustawiać OLLAMA_HOST=0.0.0.0. Wiele poradników sugeruje to jako rozwiązanie problemu z połączeniem klienta z laptopa, jednak jest to błędne podejście. Zamiast tego należy przekierować port.

ssh -N -L 11434:127.0.0.1:11434 you@your-server

To rozwiązanie mapuje port 11434 na laptopie do adresu loopback serwera za pośrednictwem SSH. Dzięki temu każdy klient skonfigurowany na http://localhost:11434 działa bez zmian, a żadne nowe zasoby nie są wystawiane na zewnątrz. W przypadku pracy grupowej lub wielu maszyn należy umieścić serwer w prywatnej sieci tunelowej i powiązać Ollama z adresem tunelu, nigdy z 0.0.0.0.

Weryfikację należy przeprowadzić z urządzenia innego niż serwer. Z poziomu laptopa, przy zamkniętym tunelu SSH:

curl -m 5 http://your-server-ip:11434/api/tags

curl: (28) Connection timed out lub curl: (7) Failed to connect to prawidłowy wynik. Wyświetlenie listy modeli w formacie JSON oznacza, że port jest otwarty na świat i wymaga natychmiastowego zabezpieczenia. Sieciowy firewall dostawcy jest odrębnym mechanizmem od tego działającego na maszynie, dlatego należy sprawdzić oba. Szersze zagadnienie bezpieczeństwa hostingu VPS omawia pozostałe podstawowe kwestie dla maszyny pozostawionej w trybie ciągłej pracy.

Jeśli glm-4.7-flash jest nadal zbyt duży

Gdy tag Q4 nie mieści się w planie, rozwiązaniem jest mniejszy model, a nie mniejszy kontekst. Ograniczanie kontekstu w celu zmieszczenia modelu powoduje, że model się uruchamia, ale zawodzi przy pierwszym dłuższym zapytaniu. Qwen 3 w wersjach 8B i 27B na VPS opisuje tę samą ścieżkę instalacji dla rozmiarów odpowiednich dla mniej wydajnych serwerów, a ogólny przewodnik po self-hostingu LLM za pomocą Ollama na VPS omawia elementy, które pozostają niezmienne niezależnie od wybranego modelu. Niezależnie od wyboru, należy przypiąć tag, przeprowadzić pomiary na własnej infrastrukturze i pozostawić punkt końcowy na interfejsie loopback.

FAQ

Czy GLM 5.2 może działać lokalnie na VPS?

Nie. Według stanu na 18 sierpnia 2026, GLM 5.2 występuje w bibliotece Ollama wyłącznie jako glm-5.2:cloud, czyli tag działający w infrastrukturze Ollama i wymagający ollama signin do poprawnego funkcjonowania. Model posiada 756 miliardów parametrów, więc nawet przy czterech bitach na parametr same wagi zajmują setki gigabajtów, co znacznie przekracza zasoby standardowych planów VPS. Modelem GLM z możliwymi do pobrania wagami, który mieści się na wynajętym serwerze, jest glm-4.7-flash.

Ile pamięci RAM wymaga glm-4.7-flash?

Należy przyjąć rozmiar pobierania tagu jako wartość minimalną i dodać do niej miejsce na KV cache oraz system operacyjny. Ollama podaje rozmiar tagu Q4 jako 19 GB, Q8 jako 32 GB, a tag bfloat16 jako 60 GB. Nie istnieje jeden uniwersalny mnożnik, ponieważ KV cache rośnie wraz z ustawioną długością kontekstu. Załaduj model, uruchom ollama ps i odczytaj kolumnę SIZE, aby poznać rzeczywiste zużycie na własnej maszynie.

Jak zmierzyć liczbę tokenów na sekundę na własnym VPS?

Wyślij jedno żądanie do http://localhost:11434/api/generate za pomocą "stream": false, a następnie odczytaj eval_count oraz eval_duration z odpowiedzi. Liczbę tokenów na sekundę oblicza się jako eval_count / eval_duration * 1e9, ponieważ eval_duration jest raportowane w nanosekundach. Pomiń pierwsze uruchomienie, ponieważ load_duration w tym przypadku obejmuje odczyt wag z dysku. Powtórz test również z długim promptem, ponieważ prompt_eval_duration rośnie wraz z długością danych wejściowych, podczas gdy prędkość generowania pozostaje stała.

Dlaczego nie należy ustawiać OLLAMA_HOST na 0.0.0.0?

Ponieważ API Ollama nie posiada uwierzytelniania, więc powiązanie go z 0.0.0.0 wystawia nieautoryzowany punkt końcowy na publiczny Internet. Każdy, kto uzyska dostęp do portu 11434, może generować treści na Twoim sprzęcie i zmieniać zainstalowane modele. Pozostaw domyślne powiązanie 127.0.0.1, sprawdź je za pomocą ss -ltnp | grep 11434 i uzyskuj dostęp do API ze swojego laptopa poprzez tunel SSH, taki jak ssh -N -L 11434:127.0.0.1:11434 you@your-server.