Qwen 3.8 27B na VPS z Ollama bez GPU

Czy można uruchomić Qwen 3.8 27B na VPS bez GPU?

Aby uruchomić Qwen 3.8 27B na VPS, najpierw trzeba użyć istniejącego tagu modelu. Na dzień 4 August 2026 biblioteka Ollama nie zawiera żadnego wpisu qwen3.8. Najbliższy wydany tag 27B to qwen3.6:27b: 27.8 billion parameters, kwantyzacja Q4_K_M, licencja Apache 2.0. Wszystkie poniższe polecenia i liczby dotyczą tego tagu w Ollama v0.32.5, opublikowanym 27 July 2026.

Krótka odpowiedź brzmi: tak, na VPS z co najmniej 32 GB RAM, ale działanie będzie powolne. Gęsty model 27B w kwantyzacji Q4 potrzebuje około 17 GB RAM tylko na wagi, zanim zostanie zapisany choćby jeden token kontekstu. To całkowicie wyklucza plany z 8 GB i 16 GB RAM. Na typowym VPS z dwukanałową pamięcią DDR4 górny limit wynosi około 3 tokenów na sekundę, czyli mniej, niż większość osób czyta.

Skąd wzięło się 3.8? Najprawdopodobniej z liczby parametrów. Strona Ollama dla qwen3.6:27b podaje 27.8B parameters, a wartość 27.8 można później łatwo zapamiętać jako 3.8. Istnieje również qwen3.5:27b, czyli ta sama kompilacja Q4_K_M z poprzedniego wydania. Przed skopiowaniem dowolnego polecenia należy sprawdzić aktualną listę na stronie tagu qwen3.6 w Ollama. Jeśli później zostanie wydany rzeczywisty qwen3.8, przedstawione obliczenia nadal będą obowiązywać, ponieważ zależą od liczby parametrów i liczby bitów na wagę, a nie od numeru wersji.

Który tag Ollama pobrać i jak to sprawdzić

Pobranie nieistniejącego tagu powoduje jednoznaczny błąd, więc można to szybko sprawdzić bezpośrednio na serwerze. Istniejący tag może jednak nadal nie dać się uruchomić lokalnie. To właśnie powoduje problemy w przypadku GLM 5.2, który znajduje się w bibliotece, ale jest udostępniany wyłącznie z chmury Ollama.

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show wyświetla architekturę, liczbę parametrów, długość kontekstu oraz kwantyzację faktycznie używanego tagu. Jeśli wiersz parametrów zawiera 27.8B, a wiersz kwantyzacji zawiera Q4_K_M, używana jest kompilacja, dla której napisano ten przewodnik. Biblioteka zawiera również qwen3.6:27b-q8_0 i qwen3.6:27b-bf16 dla tych samych wag w wyższej precyzji, a także zestaw tagów 35b-a3b, które oznaczają modele MoE (mixture of experts) i działają na CPU w zupełnie inny sposób. Więcej informacji znajduje się poniżej.

Liczba parametrów razy liczba bajtów na wagę

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

Wzór mieści się w jednym wierszu. Liczba bajtów wag = liczba parametrów * liczba bitów na wagę / 8. Przy dokładnie 4 bitach 27.8 miliarda parametrów zajmowałoby 13.9 GB. Dostarczony tag Q4_K_M ma 17 GB, co w praktyce odpowiada 4.89 bitom na wagę.

Ta różnica nie oznacza błędu. Formatów K-quant nie zapisuje się z nominalną szerokością dla każdego tensora. Tensory najbardziej podatne na utratę jakości podczas kompresji przechowuje się z użyciem 5 lub 6 bitów, a warstwy osadzania tokenów i wyjściowe zwykle pozostają w formacie Q6_K lub Q8_0. Nazwa formatu określa wartość średnią, która wynosi około 4.9. Ten sam efekt występuje na drugim końcu skali: 56 GB dla BF16 odpowiada 16.1 bitom na wagę, a nie stałej wartości 16, ponieważ plik zawiera również metadane i pełnoprecyzyjną tablicę osadzania.

Dla Q5_K_M nie opublikowano tagu dla tego modelu, dlatego wiersz 19.8 GB obliczono przy użyciu typowej dla tego formatu wartości 5.7 bitów na wagę, a nie na podstawie pomiaru. Q8_0 niemal podwaja rozmiar Q4 do 30 GB. Na komputerze używającym wyłącznie CPU takie podwojenie oznacza dwukrotnie większy transfer pamięci na token, a więc również w przybliżeniu dwukrotnie mniejszą liczbę tokenów na sekundę. Z tego powodu Q4_K_M jest tutaj właściwym ustawieniem domyślnym. Jeśli potrzebna jest ocena jakościowa tej decyzji zamiast oceny pod względem zużycia pamięci, dokładniejsze porównanie Q4, Q8 i fp16 pokazuje, w którym miejscu jakość wyjścia zaczyna się faktycznie pogarszać.

Koszt pamięci KV cache wraz ze wzrostem kontekstu

Wagi są kosztem stałym. Pamięć KV cache (cache kluczy i wartości, czyli stan mechanizmu attention przechowywany przez model dla każdego wcześniej przetworzonego tokenu) rośnie liniowo wraz z długością kontekstu. To właśnie w tym miejscu większość użytkowników faktycznie wyczerpuje pamięć RAM.

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

Podane wartości zakładają architekturę stosowaną przez Qwen w nowszych gęstych modelach tej klasy rozmiarowej: 64 warstwy, 8 głów kluczy/wartości w ramach GQA (grouped-query attention) oraz wymiar głowy równy 128. Daje to 256 KiB na token przy f16, czyli 8 GB dla 32k tokenów i 32 GB dla 128k tokenów. Nie należy przyjmować tych obliczeń bez weryfikacji na własnym komputerze. Należy załadować model i odczytać kolumnę SIZE w ollama ps. Zawiera ona łączny rozmiar wag, cache i narzutu.

Dlatego kontekst 256K podany w karcie modelu jest informacją nagłówkową, a nie gotowym planem konfiguracji. Wypełnienie go przy f16 wymagałoby 64 GB na cache, dodatkowo do wag, które na tej samej maszynie zajmują już 17 GB. Ollama domyślnie nie przydziela pełnego okna. Ładuje znacznie mniejsze okno, które należy celowo zwiększyć za pomocą OLLAMA_CONTEXT_LENGTH. Ta zmienna obowiązuje dla całego serwera, ale nie jest jedynym sposobem konfiguracji. Ustawienie num_ctx dla pojedynczego żądania pozwala zachować niski domyślny limit dla pozostałych zadań, a jednemu długiemu zadaniu przydzielić większe okno. Należy zwiększać tę wartość stopniowo i po każdej zmianie sprawdzać ollama ps.

Dwa ustawienia zmniejszają zużycie cache co najmniej o połowę. OLLAMA_KV_CACHE_TYPE=q8_0 zapisuje cache z użyciem 8 bitów zamiast 16, zmniejszając zużycie dla 32k tokenów z 8 GB do 4 GB. Wymaga to flash attention, dlatego należy ustawić również OLLAMA_FLASH_ATTENTION=1 i potwierdzić zmniejszenie wartości w ollama ps, zamiast zakładać, że konfiguracja została zastosowana. OLLAMA_NUM_PARALLEL=1 ma równie duże znaczenie. Ollama może obsługiwać kilka żądań jednocześnie, a każdy slot otrzymuje własny fragment kontekstu. Pozostawienie domyślnego poziomu równoległości powoduje więc niezauważalne zwielokrotnienie wcześniej zaplanowanego zużycia cache. Jeśli z tego komputera będzie korzystać więcej niż jedna osoba, właśnie to zwielokrotnienie powoduje problemy. Liczba jednoczesnych użytkowników, których może obsłużyć model uruchomiony lokalnie, zależy od liczby slotów cache i długości kolejki na długo przed tym, zanim ograniczeniem stanie się liczba rdzeni.

Co mieści się w 8, 16, 32 i 64 GB pamięci RAM

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

Odczytaj te dwie liczby jako tysiące tokenów kontekstu, które mieszczą się obok wag, przy cache f16, na bezgłowym VPS z systemem Linux, z około 1.5 GB pozostawionymi dla systemu operacyjnego i niewielkim dodatkowym marginesem. Zero oznacza, że same wagi się nie mieszczą, więc nie mieści się nic.

8 GB i 16 GB to nie są wartości graniczne. 17 GB wag nie mieści się w 16 GB pamięci RAM i żadna zmiana ustawienia kontekstu tego nie zmieni. Dodanie swapu również nie rozwiąże problemu. Ollama odwzorowuje plik GGUF w pamięci, więc gdy liczba stron rezydentnych przekroczy dostępną pamięć RAM, kernel zaczyna je usuwać i ponownie odczytywać. Wtedy wygenerowanie każdego tokenu wymaga odczytu gigabajtów danych z dysku. Serwer ma wysoki poziom iowait i generuje znacznie mniej niż jeden token na sekundę.

32 GB to dolna granica. Wagi zajmują 17 GB, więc pozostaje około 13 GB. To wystarcza na około 32k tokenów kontekstu f16 z zachowaniem marginesu. Wagi Q8_0 o rozmiarze 30 GB w ogóle nie mieszczą się w tym wariancie.

64 GB zapewnia komfortowy zapas. Przy Q4 pozostaje miejsce na około 128k tokenów kontekstu, a wagi Q8_0 mieszczą się z miejscem na około 64k tokenów. Przed wykupieniem 64 GB pamięci RAM w celu użycia Q8 należy jasno określić, co jest kupowane: nieco lepszy wynik przy dwukrotnie niższej szybkości, na maszynie, która już wcześniej działała wolno. Dla większości użytkowników lepszym kompromisem jest Q4 z dłuższym kontekstem.

Jak szybkie jest wnioskowanie CPU na VPS?

Wygenerowanie jednego tokenu z modelu gęstego oznacza jednokrotny odczyt wszystkich wag z pamięci. Nie tylko części z nich. Wszystkich. Ograniczeniem prędkości nie jest więc liczba rdzeni, lecz przepustowość pamięci podzielona przez rozmiar wag. Przy Q4 oznacza to 17 GB transferu z pamięci na token.

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

Są to wartości graniczne, a nie pomiary. Rzeczywista wydajność wynosi zwykle około 50–70 procent podanej wartości, ponieważ opóźnienia pamięci i niepełne pobieranie z wyprzedzeniem uniemożliwiają osiągnięcie teoretycznego maksimum. VPS z dwukanałową pamięcią DDR4-3200 ma limit 3 tokenów na sekundę, dlatego należy oczekiwać około 2. Serwer z dwukanałową pamięcią DDR5-4800 ma limit 4.5, dlatego należy oczekiwać około 3.

Wiersze dotyczące dużych serwerów wymagają dodatkowego zastrzeżenia. Platforma EPYC z dwunastoma kanałami pamięci ma przepustowość 460.8 GB/s i limit 27.1 tokenów na sekundę, ale nie wynajmuje się całej platformy EPYC. Przepustowość pamięci jest zasobem całego hosta, współdzielonym przez wszystkich użytkowników tej maszyny, dlatego fragment z 8 vCPU nie zapewnia dwunastu kanałów wyłącznej przepustowości. W poradnikach koncentrujących się na GPU ten aspekt jest całkowicie pomijany. To właśnie dlatego dwa plany VPS z identyczną liczbą vCPU mogą różnić się trzykrotnie wydajnością dla tego samego modelu.

Większa liczba vCPU również szybko przestaje pomagać z tego samego powodu. Gdy rdzenie żądają danych szybciej, niż kontroler pamięci może je dostarczyć, dodatkowe wątki zwiększają narzut planowania i nie przynoszą żadnej innej korzyści. Ustaw OLLAMA_NUM_THREAD na liczbę rdzeni fizycznych, wykonaj pomiar, a następnie wypróbuj połowę tej wartości. W wielu współdzielonych planach niższe ustawienie jest szybsze.

Przetwarzanie promptu działa inaczej. Prefill, czyli przejście przez dane wejściowe przed pojawieniem się pierwszego tokenu, jest ograniczone wydajnością obliczeniową, a nie przepustowością pamięci, dlatego skaluje się wraz z liczbą rdzeni. W praktyce przy dużym prompcie oznacza to długą przerwę przed rozpoczęciem generowania, a następnie stałe wolne tempo opisane powyżej. Obie części należy mierzyć osobno za pomocą --verbose, które dla każdego żądania wyświetla prompt eval rate oraz eval rate.

Jeśli gęsty model 27B działa zbyt wolno, przed rezygnacją z CPU należy sprawdzić znaczniki qwen3.6:35b-a3b. Aktywują one około 3 miliardów parametrów na token zamiast wszystkich 27.8 miliarda, dzięki czemu transfer danych na token zmniejsza się niemal o rząd wielkości, mimo że plik na dysku jest większy. W zamian za szybkość zwiększa się zużycie RAM. Wybór runtime również ma znaczenie, a Ollama i llama.cpp udostępniają różne mechanizmy dostrajania CPU dla tego samego bazowego kodu wnioskowania.

Kiedy zamiast tego wynająć godzinę GPU

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

Zastosowanie tego samego wzoru do opublikowanej przepustowości pamięci GPU prowadzi do innego wniosku. Karta konsumencka 24 GB osiąga dla tych wag maksymalnie 59 tokenów na sekundę. Obecna karta do centrów danych osiąga 197. Tej różnicy nie da się zniwelować dostrojeniem liczby wątków. Karta działa z przepustowością pamięci 1008 GB/s, podczas gdy VPS osiąga dziesiątki GB/s.

Dlatego granicę należy wyznaczać na podstawie obciążenia, a nie preferencji. Wnioskowanie na CPU jest właściwym rozwiązaniem, gdy zadanie działa asynchronicznie i nikt nie czeka na wynik: na przykład nocne podsumowywanie zbioru dokumentów albo nocne zadanie klasyfikacji uruchamiane podczas snu. GPU należy wynająć, gdy tylko na wynik czeka użytkownik albo gdy żądania napływają częściej niż raz na 30 sekund, ponieważ komputer korzystający wyłącznie z CPU nie ma zapasu wydajności na batchowanie, a kolejka zaczyna się powiększać.

Porównanie kosztów jest mniej oczywiste, niż się wydaje. VPS z 64 GB jest rozliczany za każdą godzinę miesiąca, niezależnie od tego, czy model jest załadowany, natomiast instancja GPU jest rozliczana tylko za czas jej działania. Jeśli rzeczywiste użycie wynosi dwie godziny dziennie, wynajęte GPU może być jednocześnie szybsze i tańsze. Najpierw oblicz współczynnik wykorzystania, a następnie porównaj ceny. Wybór VPS z GPU omawia elementy, które należy sprawdzić na samej instancji, a vLLM wyprzedza Ollama po uruchomieniu obsługi równoczesnych żądań na GPU, ponieważ prawidłowo je batchuje.

Istnieje również trzecia możliwość, o której często się zapomina. Model 27B można pozostawić na CPU do zadań wsadowych, a przed ścieżką interaktywną umieścić model dostępny przez hosted API. Nic nie wymaga, aby jeden model obsługiwał oba zastosowania.

Instalacja Ollama i pomiar własnego serwera

Skrypt instalacyjny jest oficjalnym skryptem i konfiguruje usługę systemd działającą z użyciem dedykowanego użytkownika ollama.

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

Polecenie ollama --version powinno wyświetlić 0.32.5 lub nowszą wersję. Przed pobraniem czegokolwiek sprawdź free -g. Jeśli kolumna total w wierszu Mem zawiera wartość mniejszą niż 32, przerwij i wybierz mniejszy model. Pobranie 17 GB modelu, którego nie można uruchomić, marnuje godzinę i dużo miejsca na dysku.

Opcje środowiska wykonawczego należy ustawić w nadpisaniu systemd, a nie w powłoce. Model działa wewnątrz usługi, więc nie ma dostępu do interaktywnego środowiska użytkownika.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

Dane wyjściowe --verbose zawierają pomiar, którego potrzebujesz. eval rate oznacza liczbę tokenów na sekundę podczas generowania. prompt eval rate oznacza szybkość prefillingu. load duration oznacza czas odczytu wag z dysku. Z tego powodu ustawiono OLLAMA_KEEP_ALIVE=60m: na CPU ponowne wczytywanie 17 GB z dysku przy każdym żądaniu trwa dłużej niż samo żądanie. Domyślny czas bezczynności wynosi pięć minut. Jest wystarczająco krótki, aby kolejka zadań wsadowych, w której między elementami występują przerwy, wielokrotnie ponosiła koszt wczytywania. Opcje utrzymywania modelu w pamięci obejmują zarówno pole keep_alive ustawiane dla pojedynczego żądania, jak i ustawienie zachowywane po restarcie.

Podczas wczytywania modelu sprawdź zajętość pamięci w drugim terminalu.

ollama ps

Kolumna SIZE przedstawia rzeczywiste zużycie pamięci, w tym pamięć podręczną KV. Wartość powinna być zbliżona do rozmiaru wag powiększonego o wiersz odpowiadający wybranej długości kontekstu w tabeli KV. Dla 8192 tokenów i 8-bitowej pamięci podręcznej należy oczekiwać około gigabajta ponad rozmiar wag. Dla pamięci podręcznej pozostawionej w formacie f16 byłoby to 2 GB. Kolumna PROCESSOR powinna zawierać 100% CPU. Jeśli zawiera inną wartość, jakiś proces używa GPU, a wartości prędkości podane w tym przewodniku nie opisują tego serwera.

Tryby awarii i dokładne komunikaty, które zostaną wyświetlone

Model odmawia załadowania. Ollama wyświetla wiersz zawierający obie wartości, w formacie model requires more system memory (18.6 GiB) than is available (15.2 GiB). To prawidłowy tryb awarii, ponieważ Ollama wykonała sprawdzenie przed przydzieleniem pamięci, zamiast pozostawić rozstrzygnięcie jądru. Należy zmniejszyć długość kontekstu, wybrać mniejszy tag albo przejść na większy plan.

Proces znika w trakcie generowania odpowiedzi. Klient nie wyświetla przydatnych informacji, a journalctl -u ollama -n 50 pokazuje ponowne uruchamianie usługi. Należy uruchomić dmesg -T | tail. Wiersz zawierający Out of memory: Killed process ... (ollama) oznacza, że jądro zakończyło proces za pomocą mechanizmu OOM killer. Dzieje się tak, gdy sprawdzenie przed załadowaniem zakończyło się powodzeniem, ale pamięć cache podczas długiej rozmowy przekroczyła wartość szacunkową. Należy zmniejszyć długość kontekstu.

Pobieranie kończy się natychmiast niepowodzeniem. Error: pull model manifest: file does not exist oznacza, że tagu nie ma w bibliotece. Wpisanie qwen3.8:27b daje dokładnie ten wynik. To samo dotyczy literówki w numerze wersji. Przed wskazaniem problemu z siecią należy potwierdzić tag na stronie biblioteki.

Wszystko działa, ale generowanie jest nieznośnie wolne. Mniej niż 1 token na sekundę na komputerze z wystarczającą ilością pamięci RAM wskazuje na stronicowanie, a nie na ograniczenia obliczeniowe. Podczas generowania należy uruchomić vmstat 1. Wartość różna od 0 w kolumnie si lub so oznacza, że jądro używa pamięci wymiany. Rozwiązaniem jest zmniejszenie kontekstu albo liczby załadowanych modeli. Stała wysoka wartość wa bez aktywności pamięci wymiany oznacza, że wagi mapowane do pamięci są ponownie odczytywane z dysku. Oznacza to, że w praktyce nie mieszczą się w pamięci.

Wygenerowanie pierwszego tokenu trwa 30 sekund, a następnie generowanie przyspiesza. Jest to faza prefill i jest to normalne działanie. Długi prompt systemowy jest przetwarzany przy każdym żądaniu, dla którego nie można użyć cache. Przed dostrajaniem innych parametrów należy skrócić prompt systemowy.

Do czego rzeczywiście nadaje się model 27B działający wyłącznie na CPU

Oczekiwania należy ustalać na podstawie liczb, a nie nadziei. Przy szybkości od dwóch do czterech tokenów na sekundę odpowiedź o długości 500 tokenów powstaje w ciągu od dwóch do czterech minut. W czacie jest to nieużyteczne, ale w kolejce zadań działa poprawnie. Model, który przed odpowiedzią wykonuje rozumowanie, wypada jeszcze gorzej, ponieważ ukryte tokeny rozumowania są generowane z taką samą małą szybkością jak odpowiedź. Dlatego dopasowanie poziomu wysiłku związanego z rozumowaniem do zadania jest jednym z niewielu sposobów na skrócenie odpowiedzi bez zmiany modelu. Podsumowywanie dokumentów, masowe oznaczanie, wyodrębnianie pól z zalegających plików oraz automatyczny przegląd kodu dobrze tolerują takie opóźnienie, ponieważ nie trzeba czekać na odpowiedź. Asystent programistyczny znajduje się dokładnie na granicy zastosowań. Dlatego skierowanie agenta programistycznego do hostowanego modelu sprawdza się w zadaniach wykonywanych w tle, takich jak tworzenie komunikatów commitów i szkieletów testów, ale nie w sugestiach wyświetlanych w edytorze, na które trzeba czekać.

Najważniejszym argumentem jest prywatność. Model działa na sprzęcie wynajmowanym i kontrolowanym przez użytkownika, żądania nie opuszczają serwera i nie ma opłat za tokeny. W przypadku danych objętych regulacjami ma to dużą wartość nawet przy szybkości trzech tokenów na sekundę. Należy jednak uczciwie porównać to z alternatywą: samodzielne hostowanie modelu o skali czołowych modeli wymaga o rząd wielkości większej ilości sprzętu, a model 27B na CPU jest najtańszym punktem tej krzywej, przy którym wynik nadal nadaje się do przeczytania.

Do przeprowadzenia takich testów potrzebne są rzeczywiste dane ustrukturyzowane, a większość publicznych API danych wymaga założenia konta jeszcze przed zmierzeniem przepustowości. Endpoint demonstracyjny Strasmore (prowadzimy go) wykonuje zapytania SQL tylko do odczytu dotyczące 22 lat danych rynku amerykańskiego, bez klucza i bez rejestracji. Żądanie GET do https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 zwraca JSON, który można bezpośrednio przekazać do pętli promptów, wraz z dokładnym zapytaniem SQL, które wygenerowało wynik. Dzięki temu model otrzymuje dane do podsumowania, które można niezależnie zweryfikować. Limity wynoszą 500 wierszy i 20 sekund na wywołanie, czyli znacznie więcej, niż zużyje serwer działający z szybkością dwóch tokenów na sekundę. Pełna lista kolumn znajduje się pod adresem https://api.strasmore.com/v1/schema.

Jeśli jest to pierwsza instalacja Ollama, pełny przewodnik uruchamiania Ollama na VPS obejmuje konfigurację usługi, HTTP API i reguły zapory sieciowej, które w tym przewodniku przyjęto jako już skonfigurowane. Nie należy wystawiać portu 11434 do Internetu. Ollama nie ma wbudowanego uwierzytelniania, dlatego każdy, kto uzyska dostęp do tego portu, może używać modelu i odczytywać prompty.

FAQ

Czy w Ollama jest dostępny model Qwen 3.8 27B?

Nie. Według stanu na 4 sierpnia 2026 biblioteka Ollama nie zawiera przestrzeni nazw qwen3.8. Dostępne tagi 27B to qwen3.5:27b i qwen3.6:27b. Oba oznaczają kompilacje Q4_K_M gęstego modelu z 27.8 miliarda parametrów. Liczba 3.8 w wyszukiwanym haśle niemal na pewno jest zapamiętaną liczbą parametrów 27.8B, potraktowaną jako numer wersji. Bieżącą listę można sprawdzić w https://ollama.com/library/qwen3.6/tags. Aby pobrać najnowszy wydany model 27B, należy użyć qwen3.6:27b. Próba użycia nieistniejącego tagu kończy się błędem Error: pull model manifest: file does not exist.

Ile pamięci RAM potrzeba do uruchomienia modelu Qwen 27B na VPS?

Dla Q4_K_M praktycznym minimum jest 32 GB. Wagi zajmują 17 GB, system operacyjny potrzebuje około 1.5 GB, a cache KV dodaje około 1 GB na każde 4000 tokenów kontekstu przy f16. Plan 16 GB nie pomieści samych wag. Swap nie rozwiązuje problemu, ponieważ plik jest mapowany w pamięci, a kernel odczytuje go ponownie z dysku przy każdym tokenie. 64 GB zapewnia miejsce na długi kontekst albo wagi Q8_0 o rozmiarze 30 GB.

Ile tokenów na sekundę zapewni model 27B na CPU?

Należy podzielić przepustowość pamięci przez rozmiar wag, a następnie przyjąć 50–70 procent otrzymanej wartości. VPS z dwukanałową pamięcią DDR4-3200 ma limit bliski 3 tokenów na sekundę i osiąga około 2. Maszyna z dwukanałową pamięcią DDR5-4800 ma limit bliski 4.5 i osiąga około 3. Platformy serwerowe z większą liczbą kanałów wyglądają znacznie lepiej na papierze, ale przepustowość pamięci jest współdzielona przez wszystkich dzierżawców hosta. Dlatego należy wykonać własny pomiar za pomocą ollama run qwen3.6:27b --verbose i odczytać wiersz eval rate.

Czy na VPS z procesorem CPU używać Q4 czy Q8?

W niemal każdym przypadku należy użyć Q4_K_M. Q8_0 zajmuje 30 GB w porównaniu z 17 GB, więc wymaga planu 64 GB i przesyła niemal dwa razy więcej danych pamięci przy każdym tokenie. Powoduje to spadek wydajności do około połowy tokenów na sekundę. Różnica jakości między Q4_K_M i Q8_0 w modelu 27B jest niewielka w przypadku większości zadań. Lepiej przeznaczyć pamięć RAM na dłuższy kontekst, ponieważ wpływa on na możliwości modelu, a nie tylko na sposób formułowania odpowiedzi.

Kiedy wynajem GPU jest tańszy niż VPS z dużą ilością pamięci RAM?

Gdy obciążenie jest niewielkie albo na wynik czeka użytkownik. GPU z 24 GB pamięci osiąga na tych wagach około 59 tokenów na sekundę, podczas gdy typowy VPS osiąga 2 lub 3. Opłata za GPU jest naliczana tylko za godziny jego działania. Za VPS z 64 GB płaci się przez cały miesiąc, niezależnie od tego, czy model jest załadowany. Należy obliczyć, przez ile godzin dziennie rzeczywiście generowane są tokeny. Przy czasie krótszym niż 2 lub 3 godziny wynajem GPU rozliczany godzinowo zwykle wygrywa pod względem szybkości i kosztu. VPS działający stale lepiej sprawdza się przy niskopriorytetowym przetwarzaniu wsadowym.