Uruchamianie modelu Qwen 27B przez Ollama na VPS

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

Aby uruchomić Qwen 3.8 27B na VPS, wymagany jest istniejący tag modelu. Według stanu na 4 sierpnia 2026 w bibliotece Ollama nie ma żadnego wpisu qwen3.8. Najbliższym wydanym tagiem 27B jest qwen3.6:27b: 27,8 miliarda parametrów, kwantyzacja Q4_K_M, licencja Apache 2.0. Każde polecenie i każda liczba poniżej wykorzystują ten tag w wersji Ollama v0.32.5, opublikowanej 27 lipca 2026.

Krótka odpowiedź brzmi: tak, na VPS z 32 GB RAM lub więcej, ale działanie będzie powolne. Gęsty model 27B w kwantyzacji Q4 wymaga około 17 GB pamięci RAM na same wagi, jeszcze przed zapisaniem choćby jednego tokena kontekstu. Wyklucza to całkowicie plany 8 GB i 16 GB. Na typowym dwukanałowym VPS z pamięcią DDR4 górna granica wydajności wynosi około 3 tokenów na sekundę, co jest tempem wolniejszym od przeciętnej prędkości czytania.

Skąd bierze się oznaczenie 3.8? Najprawdopodobniej z liczby parametrów. Strona Ollama dla qwen3.6:27b podaje 27,8 mld parametrów, a liczbę 27,8 łatwo później zapamiętać jako 3.8. Istnieje również qwen3.5:27b, czyli ta sama kompilacja Q4_K_M z poprzedniego wydania. Przed skopiowaniem jakiegokolwiek polecenia należy sprawdzić aktualną listę na stronie strona tagu Ollama qwen3.6. Jeśli w przyszłości pojawi się rzeczywisty model qwen3.8, powyższe obliczenia pozostaną aktualne, ponieważ zależą one 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 wyświetlenie czytelnego błędu, więc weryfikacja na serwerze przebiega szybko.

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ę dla posiadanego tagu. Jeśli wiersz parametrów zawiera 27.8B, a wiersz kwantyzacji Q4_K_M, oznacza to, że używana jest wersja, dla której przygotowano ten przewodnik. Biblioteka zawiera również qwen3.6:27b-q8_0 oraz qwen3.6:27b-bf16 dla tych samych wag przy wyższej precyzji, a także zestaw tagów 35b-a3b, które są modelami MoE (mixture of experts) i zachowują się zupełnie inaczej na procesorze CPU. Więcej informacji na ten temat znajduje się poniżej.

Liczba parametrów razy bajty 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 jednej linii. Bajty wag = parametry * bity na wagę / 8. Przy czystych 4 bitach, 27,8 miliarda parametrów zajęłoby 13,9 GB. Wydany tag Q4_K_M ma rozmiar 17 GB, co w praktyce daje 4.89 bita na wagę.

Ta różnica nie jest błędem. Formaty K-quant nie przechowują każdego tensora przy nominalnej szerokości. Tensory, które tracą najwięcej jakości podczas kompresji, są utrzymywane na poziomie 5 lub 6 bitów, a warstwy osadzeń tokenów (token embedding) oraz warstwy wyjściowe są zazwyczaj pozostawiane w formacie Q6_K lub Q8_0. Nazwa formatu odnosi się do średniej, która w tym przypadku wynosi około 4,9. Ten sam efekt występuje na drugim końcu skali: 56 GB dla BF16 to 16.1 bita na wagę, a nie równe 16, ponieważ plik zawiera również metadane oraz pełnoprecyzyjną tablicę osadzeń.

Dla tego modelu nie opublikowano tagu Q5_K_M, więc wiersz 19.8 GB został obliczony przy użyciu typowej dla tego formatu wartości 5,7 bita na wagę, zamiast pomiaru. Format Q8_0 niemal podwaja rozmiar Q4 do 30 GB. Na maszynie działającej wyłącznie na CPU to podwojenie zwiększa dwukrotnie obciążenie pamięci na token, co w przybliżeniu zmniejsza o połowę liczbę generowanych tokenów na sekundę. Z tego właśnie powodu Q4_K_M jest właściwym wyborem domyślnym.

Koszt pamięci podręcznej KV wraz ze wzrostem kontekstu

Wagi modelu stanowią koszt stały. Pamięć podręczna KV (key and value cache, czyli stan mechanizmu uwagi utrzymywany przez model dla każdego przetworzonego tokena) rośnie liniowo wraz z długością kontekstu i to właśnie ona jest najczęstszą przyczyną wyczerpania pamięci 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
  }
]

Powyższe wyliczenia zakładają architekturę stosowaną przez Qwen w ostatnich gęstych modelach tej klasy: 64 warstwy, 8 głowic klucza/wartości w ramach GQA (grouped-query attention) oraz wymiar głowicy równy 128. Daje to 256 KiB na token przy f16, co przekłada się na 8 GB przy 32k tokenów oraz 32 GB przy 128k. Nie należy polegać wyłącznie na tych obliczeniach; należy załadować model i odczytać kolumnę SIZE w ollama ps, która przedstawia sumaryczne zużycie pamięci przez wagi, pamięć podręczną oraz narzut.

Dlatego kontekst 256K podany w karcie modelu jest wartością marketingową, a nie planem operacyjnym. Wypełnienie go przy f16 wymagałoby 64 GB pamięci podręcznej ponad wagami, na maszynie, która już zużyła 17 GB na same wagi. Ollama domyślnie nie udostępnia pełnego okna kontekstowego. Ładuje znacznie mniejszy rozmiar, a użytkownik zwiększa go świadomie za pomocą OLLAMA_CONTEXT_LENGTH. Należy zwiększać go stopniowo i sprawdzać ollama ps po każdej zmianie.

Dwa ustawienia pozwalają zredukować zużycie pamięci podręcznej o połowę lub więcej. OLLAMA_KV_CACHE_TYPE=q8_0 przechowuje pamięć podręczną w 8 bitach zamiast 16, co redukuje zapotrzebowanie dla 32k tokenów z 8 GB do 4 GB. Wymaga to użycia flash attention, więc należy również ustawić OLLAMA_FLASH_ATTENTION=1 i zweryfikować spadek zużycia w ollama ps, zamiast zakładać, że zmiana została zastosowana. Równie istotne jest OLLAMA_NUM_PARALLEL=1. Ollama może obsługiwać kilka żądań jednocześnie, a każdy slot otrzymuje własny wycinek kontekstu, więc pozostawienie domyślnego poziomu równoległości powoduje ciche zwielokrotnienie zaplanowanego zużycia pamięci podręcznej. Jeśli z serwera korzysta więcej niż jedna osoba, to właśnie to zwielokrotnienie staje się źródłem problemów, a liczba jednoczesnych użytkowników, których może obsłużyć samodzielnie hostowany model zależy od liczby slotów pamięci podręcznej i głębokości kolejki na długo przed tym, zanim ograniczeniem stanie się liczba rdzeni procesora.

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."
  }
]

Poniższe dwie liczby należy interpretować jako tysiące tokenów kontekstu, które mieszczą się obok wag modelu przy pamięci podręcznej f16 na serwerze VPS z systemem Linux bez interfejsu graficznego, przy założeniu pozostawienia około 1,5 GB pamięci na potrzeby systemu operacyjnego oraz niewielkiego marginesu bezpieczeństwa. Wartość zero oznacza, że same wagi nie mieszczą się w pamięci, więc nie ma miejsca na żaden kontekst.

Wartości 8 GB i 16 GB nie są przypadkami granicznymi. 17 GB wag nie mieści się w 16 GB pamięci RAM i żadna zmiana ustawień kontekstu tego nie zmieni. Dodanie partycji swap również nie rozwiązuje problemu. Ollama mapuje plik GGUF do pamięci, więc gdy strony rezydentne przekroczą dostępną pamięć RAM, jądro zaczyna je usuwać i ponownie odczytywać, co sprawia, że każdy token wymusza odczyt gigabajtów danych z dysku. Serwer osiąga wysoki wskaźnik iowait i generuje znacznie mniej niż jeden token na sekundę.

32 GB to próg wejścia. Wagi zajmują 17 GB, co pozostawia około 13 GB wolnej pamięci, co 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 tej konfiguracji.

64 GB zapewnia komfort pracy. Kwantyzacja Q4 pozostawia miejsce na około 128k tokenów kontekstu, a wagi Q8_0 mieszczą się wraz z około 64k tokenami zapasu. Przed zakupem 64 GB pamięci w celu obsługi modelu Q8 należy dokładnie rozważyć cel: nieco lepsza jakość wyjściowa przy dwukrotnie mniejszej prędkości na maszynie, która już wcześniej była wolna. Dla większości użytkowników lepszym rozwiązaniem jest wybór Q4 z dłuższym kontekstem.

Jak szybka jest inferencja CPU na VPS?

Generowanie jednego tokena z modelu gęstego wymaga jednokrotnego odczytania wszystkich wag z pamięci. Nie tylko części, lecz wszystkich. Ograniczeniem prędkości nie jest zatem liczba rdzeni, lecz przepustowość pamięci podzielona przez rozmiar wag. Przy kwantyzacji Q4 oznacza to 17 GB ruchu w 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ść osiąga około 50 do 70 procent tej wartości, ponieważ opóźnienia pamięci i niedoskonałe 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ę, więc należy spodziewać się około 2. Serwer z dwukanałową pamięcią DDR5-4800 ma limit 4.5, więc należy spodziewać się około 3.

Duże serwery wymagają ostrożności. Dwunastokanałowa platforma EPYC oferuje 460.8 GB/s i limit 27.1 tokenów na sekundę, jednak użytkownik nie wynajmuje całego procesora EPYC. Przepustowość pamięci jest zasobem współdzielonym przez wszystkich użytkowników maszyny, więc wycinek 8 vCPU nie zapewnia wyłącznego dostępu do dwunastu kanałów. Poradniki skupione na GPU całkowicie pomijają ten aspekt, a jest to powód, dla którego dwa plany VPS z identyczną liczbą vCPU mogą różnić się trzykrotnie wydajnością w tym samym modelu.

Większa liczba vCPU przestaje pomagać bardzo szybko z tego samego powodu. Gdy rdzenie żądają danych szybciej, niż kontroler pamięci jest w stanie je dostarczyć, dodatkowe wątki wprowadzają jedynie narzut związany z szeregowaniem zadań. Ustaw OLLAMA_NUM_THREAD na liczbę fizycznych rdzeni, wykonaj pomiar, a następnie spróbuj ustawić połowę tej wartości. W wielu planach współdzielonych niższe ustawienie jest szybsze.

Przetwarzanie promptu zachowuje się inaczej. Prefill, czyli przejście przez dane wejściowe przed wygenerowaniem pierwszego tokena, jest ograniczone mocą obliczeniową, a nie przepustowością, więc skaluje się wraz z liczbą rdzeni. W praktyce oznacza to długą pauzę przed rozpoczęciem generowania przy dużym prompcie, po której następuje powolne, stałe tempo opisane powyżej. Mierz obie fazy oddzielnie za pomocą --verbose, co wyświetli prompt eval rate oraz eval rate dla każdego żądania.

Jeśli gęsty model 27B jest zbyt wolny, sprawdź tagi qwen3.6:35b-a3b przed rezygnacją z CPU. Aktywują one około 3 miliardy parametrów na token zamiast wszystkich 27,8 miliarda, dzięki czemu ruch w pamięci na token spada niemal dziesięciokrotnie, mimo że plik na dysku jest większy. Zyskujesz prędkość kosztem zajętości pamięci RAM. Wybór środowiska uruchomieniowego również ma znaczenie, a Ollama i llama.cpp udostępniają różne opcje dostrajania CPU dla tego samego kodu inferencyjnego.

Kiedy warto wynająć czas 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
  }
]

Ta sama formuła zastosowana do opublikowanej przepustowości pamięci GPU daje inną kategorię odpowiedzi. Karta konsumencka o pojemności 24 GB ma limit 59 tokenów na sekundę dla tych wag. Obecna karta klasy data centre osiąga 197. To nie jest różnica, którą można zniwelować poprzez dostrajanie liczby wątków. Karta pracuje z przepustowością pamięci 1008 GB/s, podczas gdy Twój VPS osiąga wartości rzędu kilkudziesięciu GB/s.

Dlatego wyznacz granicę na podstawie obciążenia, a nie preferencji. Wnioskowanie na CPU jest właściwym rozwiązaniem, gdy praca jest asynchroniczna i nikt na nią nie czeka: nocne podsumowywanie stosu dokumentów lub nocne zadanie klasyfikacji, które wykonuje się podczas snu. Wynajmij GPU w momencie, gdy użytkownik czeka na wynik lub gdy żądania napływają częściej niż raz na 30 sekund, ponieważ serwer oparty wyłącznie na CPU nie ma zapasu na przetwarzanie wsadowe i kolejka po prostu rośnie.

Porównanie kosztów jest mniej oczywiste, niż się wydaje. VPS z 64 GB RAM jest rozliczany za każdą godzinę miesiąca, niezależnie od tego, czy model jest załadowany, czy nie, podczas gdy instancja GPU jest rozliczana tylko za godziny, w których pozostaje uruchomiona. Jeśli rzeczywiste wykorzystanie wynosi dwie godziny dziennie, wynajęte GPU może być zarówno szybsze, jak i tańsze. Najpierw określ swój cykl pracy, a następnie wyceń go. Wybór VPS z GPU zawiera informacje o tym, co sprawdzić na samej instancji, a vLLM wyprzedza Ollama, gdy obsługujesz równoległe żądania na GPU, ponieważ poprawnie je grupuje.

Istnieje trzecia opcja, o której ludzie zapominają. Pozostaw model 27B na CPU do pracy wsadowej i umieść hostowany model API przed ścieżką interaktywną. Nic nie wymaga, aby jeden model obsługiwał oba te zadania.

Instalacja Ollama i pomiar wydajności własnego serwera

Skrypt instalacyjny jest oficjalnym narzędziem, które konfiguruje usługę systemd działającą jako dedykowany użytkownik ollama.

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

ollama --version powinno wyświetlić 0.32.5 lub nowszą wersję. Sprawdź free -g przed pobraniem jakichkolwiek danych. Jeśli kolumna total w wierszu Mem wskazuje wartość poniżej 32, przerwij w tym miejscu i wybierz mniejszy model. Pobieranie 17 GB danych, których nie można uruchomić, powoduje stratę godziny czasu oraz dużej ilości miejsca na dysku.

Ustaw opcje środowiska uruchomieniowego w pliku override usługi systemd, a nie w powłoce użytkownika. Model działa wewnątrz usługi, więc nie ma dostępu do środowiska interaktywnego.

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 to pomiar, którego oczekiwano. eval rate oznacza liczbę tokenów na sekundę podczas generowania. prompt eval rate to szybkość przetwarzania wstępnego (prefill). load duration określa czas odczytu wag z dysku. Z tego powodu ustawiono OLLAMA_KEEP_ALIVE=60m: w przypadku procesora CPU, ponowne wczytywanie 17 GB z dysku przy każdym żądaniu kosztuje więcej niż samo żądanie.

Gdy model jest załadowany, sprawdź zajętość pamięci z poziomu drugiego terminala.

ollama ps

Kolumna SIZE przedstawia rzeczywiste zużycie pamięci, wliczając w to pamięć podręczną KV. Powinna ona być zbliżona do sumy wag oraz wartości z tabeli KV dla danej długości kontekstu. Przy 8192 tokenach i 8-bitowej pamięci podręcznej należy spodziewać się około jednego gigabajta narzutu ponad wagi, w porównaniu do 2 GB, gdyby pamięć podręczna pozostała w formacie f16. Kolumna PROCESSOR powinna wskazywać 100% CPU. Jeśli wyświetlana jest inna wartość, oznacza to, że inny proces zajął GPU, a wyniki szybkości przedstawione w tym przewodniku nie dotyczą Twojego serwera.

Tryby awarii i dokładne komunikaty, które zobaczysz

Model odmawia załadowania. Ollama wyświetla linię wymieniającą obie wartości w formacie model requires more system memory (18.6 GiB) than is available (15.2 GiB). Jest to pożądany sposób awarii, ponieważ Ollama przeprowadziła weryfikację przed alokacją, zamiast pozwolić na interwencję jądra systemu. Należy zmniejszyć długość kontekstu, przejść na mniejszy tag lub zwiększyć zasoby sprzętowe.

Proces znika w trakcie generowania odpowiedzi. Klient nie wyświetla żadnych użytecznych informacji, a journalctl -u ollama -n 50 wskazuje na restart usługi. Uruchom dmesg -T | tail; linia o treści Out of memory: Killed process ... (ollama) oznacza, że proces został zakończony przez mechanizm OOM killer jądra systemu. Dzieje się tak, gdy weryfikacja wstępna przebiegła pomyślnie, ale pamięć podręczna przekroczyła szacunki podczas długiej konwersacji. Należy zmniejszyć długość kontekstu.

Pobieranie kończy się natychmiastowym błędem. Error: pull model manifest: file does not exist oznacza, że tag nie znajduje się w bibliotece. Wpisanie qwen3.8:27b wywołuje dokładnie ten błąd, podobnie jak każda literówka w numerze wersji. Przed sprawdzeniem połączenia sieciowego potwierdź poprawność tagu na stronie biblioteki.

Wszystko działa, ale jest nieznośnie wolne. Wynik poniżej jednego tokena na sekundę na maszynie z wystarczającą ilością pamięci RAM wskazuje na stronicowanie, a nie na ograniczenia mocy obliczeniowej. Uruchom vmstat 1 podczas generowania. Niezerowa wartość w kolumnie si lub so oznacza, że jądro korzysta ze swapu; rozwiązaniem jest zmniejszenie kontekstu lub liczby załadowanych modeli. Stała, wysoka wartość wa przy braku aktywności swapu oznacza, że zmapowane w pamięci wagi są ponownie odczytywane z dysku, co oznacza, że w rzeczywistości nie mieszczą się w pamięci RAM.

Wygenerowanie pierwszego tokena zajmuje 30 sekund, a następnie prędkość rośnie. Jest to faza prefill i jest to zachowanie normalne. Długi prompt systemowy jest przetwarzany przy każdym żądaniu, które nie trafia do pamięci podręcznej, dlatego przed wprowadzaniem innych zmian należy skrócić prompt systemowy.

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

Należy oprzeć oczekiwania na liczbach, a nie na nadziejach. Przy prędkości od dwóch do czterech tokenów na sekundę, wygenerowanie odpowiedzi o długości 500 tokenów zajmuje od dwóch do czterech minut. Jest to czas nieakceptowalny w przypadku czatu, ale całkowicie wystarczający dla zadań kolejkowych. Podsumowywanie dokumentów, masowe tagowanie, ekstrakcja pól z zaległych plików oraz automatyczne przeglądy kodu tolerują takie opóźnienia, ponieważ nikt nie oczekuje natychmiastowej odpowiedzi. Wsparcie w programowaniu znajduje się na granicy użyteczności, dlatego skierowanie agenta programistycznego na hostowany model sprawdza się w zadaniach w tle, takich jak generowanie komunikatów commitów czy szkieletów testów, a nie w przypadku sugestii wewnątrz edytora, na które trzeba czekać.

Argument dotyczący prywatności jest kluczowy. Model działa na sprzęcie, który wynajmujesz i kontrolujesz, żadne żądanie nie opuszcza serwera i nie ma opłat za każdy token. W przypadku danych podlegających regulacjom jest to bardzo wartościowe, nawet przy prędkości trzech tokenów na sekundę. Należy uczciwie porównać to z alternatywą: samodzielne hostowanie modelu klasy frontier wymaga o rząd wielkości więcej sprzętu, a model 27B na CPU jest najtańszym punktem na tej krzywej, w którym wygenerowany tekst jest nadal wart przeczytania.

Jeśli jest to pierwsza instalacja Ollama, pełny przewodnik uruchamiania Ollama na VPS opisuje konfigurację usługi, API HTTP oraz reguły firewalla, które w tym poradniku uznano za już istniejące. Nie należy wystawiać portu 11434 do Internetu. Ollama nie posiada wbudowanego mechanizmu uwierzytelniania, więc każdy, kto uzyska dostęp do tego portu, może korzystać z modelu i odczytywać wysyłane zapytania.

FAQ

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

Nie. Według stanu na 4 sierpnia 2026 biblioteka Ollama nie posiada przestrzeni nazw qwen3.8. Istniejące tagi 27B to qwen3.5:27b oraz qwen3.6:27b; oba są kompilacjami Q4_K_M gęstego modelu o 27,8 miliarda parametrów. Liczba 3.8 w wyszukiwanym haśle to niemal na pewno błędnie zapamiętana liczba 27,8B parametrów. Sprawdź https://ollama.com/library/qwen3.6/tags, aby uzyskać aktualną listę, i wykonaj pull dla qwen3.6:27b, jeśli potrzebujesz najnowszego wydania 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?

32 GB to praktyczne minimum dla wersji Q4_K_M. Wagi zajmują 17 GB, system operacyjny wymaga około 1,5 GB, a pamięć podręczna KV dodaje około 1 GB na każde 4000 tokenów kontekstu przy f16. Plan 16 GB nie pomieści wag, a partycja swap nie pomoże, ponieważ plik jest mapowany w pamięci, a jądro odczytuje go z dysku przy każdym tokenie. 64 GB zapewnia przestrzeń na długi kontekst lub wagi Q8_0 o rozmiarze 30 GB.

Ile tokenów na sekundę osiągnie model 27B na procesorze CPU?

Podziel przepustowość pamięci przez rozmiar wag, a następnie przyjmij 50 do 70 procent tej wartości. Dwukanałowy VPS z DDR4-3200 ma limit w okolicach 3 tokenów na sekundę i dostarcza około 2. Maszyna z dwukanałową pamięcią DDR5-4800 ma limit w okolicach 4.5 i dostarcza około 3. Wielokanałowe platformy serwerowe wyglądają lepiej w specyfikacji, ale przepustowość pamięci jest współdzielona między wszystkich użytkowników na hoście, więc zmierz własną wydajność za pomocą ollama run qwen3.6:27b --verbose i odczytaj linię eval rate.

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

W niemal każdym przypadku Q4_K_M. Wersja Q8_0 zajmuje 30 GB w porównaniu do 17 GB, więc wymaga planu 64 GB i przesyła prawie dwa razy więcej danych z pamięci na token, co zmniejsza liczbę tokenów na sekundę o około połowę. Różnica w jakości między Q4_K_M a Q8_0 w modelu 27B jest w większości zadań pomijalna. Lepiej przeznaczyć RAM na dłuższy kontekst, ponieważ to zmienia możliwości modelu, a nie tylko sposób formułowania wypowiedzi.

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

Gdy cykl pracy jest krótki lub gdy użytkownik czeka na odpowiedź. GPU z 24 GB pamięci osiąga około 59 tokenów na sekundę dla tych wag, w porównaniu do 2 lub 3 na typowym VPS, a opłaty naliczane są tylko za godziny pracy. VPS z 64 GB RAM jest płatny przez cały miesiąc, niezależnie od tego, czy model jest załadowany. Oblicz, ile godzin dziennie faktycznie generujesz tokeny. Poniżej dwóch lub trzech godzin godzinowy wynajem GPU zazwyczaj wygrywa zarówno pod względem szybkości, jak i kosztów. Ciągłe zadania wsadowe o niskim priorytecie to obszar, w którym wygrywa zawsze włączony VPS.