Jakie modele AI można hostować samodzielnie na VPS?

Co decyduje o możliwości samodzielnego hostowania modeli AI

O możliwości samodzielnego hostowania modeli AI decyduje jedna wartość: ilość pamięci RAM dostępnej na serwerze. Rodzina modelu oraz framework mają znacznie mniejsze znaczenie niż to, czy wagi modelu mieszczą się w pamięci z odpowiednim zapasem. Niniejszy wpis przedstawia obliczenia niezbędne do ustalenia tych wymagań. Instalacja środowiska uruchomieniowego to odrębne zadanie, opisane w przewodniku uruchamiania Ollama na VPS.

O wyniku decydują dwa koszty. Wagi stanowią koszt stały, określony przez liczbę parametrów oraz kwantyzację. Okno kontekstowe stanowi koszt zmienny i jest to element pomijany przez użytkowników do momentu, w którym model załadowany wczoraj odmawia uruchomienia dzisiaj.

Arytmetyka rozmiaru: bity na parametr

Plik modelu składa się niemal wyłącznie z wag. Każda waga jest przechowywana z określoną liczbą bitów. Kwantyzacja oznacza przechowywanie ich przy użyciu mniejszej liczby bitów niż precyzja, w której model został wytrenowany, co wiąże się z niewielką utratą dokładności przy znacznej oszczędności pamięci. Rozmiar wynika bezpośrednio z tego faktu:

weights in GB = (parameters in billions x bits per weight) / 8

Modele są udostępniane w precyzji 16 bitów, co odpowiada 2 GB na miliard parametrów. Z tego powodu prawie nikt nie uruchamia modeli w pełnej precyzji na serwerach VPS. Oto kwantyzacje, z którymi faktycznie przyjdzie się zetknąć, wraz z ich rzeczywistą średnią liczbą bitów na wagę:

• Q8_0 przechowuje około 8,5 bita na wagę, czyli w przybliżeniu 1,1 GB na miliard parametrów.
• Q6_K przechowuje około 6,6 bita, czyli w przybliżeniu 0,83 GB na miliard.
• Q5_K_M przechowuje około 5,7 bita, czyli w przybliżeniu 0,71 GB na miliard.
• Q4_K_M przechowuje około 4,8 bita, czyli w przybliżeniu 0,6 GB na miliard.

Należy przyjąć 0,6 GB na miliard parametrów jako wartość roboczą. Q4_K_M jest rozsądnym ustawieniem domyślnym w przypadku ograniczeń pamięci: utrata jakości względem 8 bitów jest w większości zadań niewielka, a plik zajmuje niemal połowę mniej miejsca. Poniżej 4 bitów utrata jakości rośnie szybko, dlatego model 70B skompresowany do 2 bitów zazwyczaj odpowiada gorzej niż model 32B w 4 bitach z tej samej generacji. Gdy pamięci jest mało, lepiej zmniejszyć klasę modelu, niż schodzić poniżej 4 bitów.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

Powyższa kolumna wag uwzględnia zasadę 0,6 GB na miliard. Rzeczywiste pliki GGUF mieszczą się w granicach kilku procent tej wartości, ponieważ warstwy osadzeń (embedding) i wyjściowe są utrzymywane w wyższej precyzji niż reszta modelu. Model 3B w 4 bitach zajmuje około 1.8 GB. Model 8B zajmuje 4.8 GB. Model 32B zajmuje 19.2 GB, a model 70B zajmuje 42 GB.

Dlaczego długość kontekstu zużywa więcej pamięci RAM niż wagi modelu

Pamięć podręczna KV (ang. key value cache, czyli stan uwagi utrzymywany przez model dla każdego tokena w bieżącej konwersacji) stanowi drugi koszt pamięciowy. Jest ona alokowana podczas ładowania modelu, ma rozmiar dostosowany do zadeklarowanej długości kontekstu i rośnie liniowo wraz z tą długością.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

Przy domyślnym kontekście Ollama, model 8B zużywa pół gigabajta na pamięć podręczną. Przy 8192 tokenach zużycie wynosi 1 GB. Przy kontekście 128k, deklarowanym w karcie modelu, zużycie wynosi 16 GB, co stanowi ponad trzykrotność wagi modelu. W przypadku modelu 70B sytuacja jest odwrotna: jego pamięć podręczna przy 128k wynosi 40 GB, czyli mniej niż wagi samego modelu, ponieważ mechanizm grouped query attention sprawia, że koszt na token nie rośnie tak szybko, jak liczba parametrów.

Domyślna długość kontekstu w Ollama wynosi 4096 tokenów na serwerze działającym wyłącznie na CPU. Jeśli dostępny jest GPU, wartość domyślna jest dobierana na podstawie VRAM: 32k dla pamięci między 24 a 48 GiB oraz 256k dla 48 GiB i więcej. Wartość tę można zwiększyć za pomocą zmiennej OLLAMA_CONTEXT_LENGTH na serwerze, a następnie sprawdzić, jaką wartość otrzymał uruchomiony model w kolumnie CONTEXT narzędzia ollama ps. Arytmetyka pamięci stojąca za tym ustawieniem została wyjaśniona w artykule na temat num_ctx i długości kontekstu.

Istnieją dwa sposoby na zmniejszenie zużycia pamięci przez cache. Należy określić długość kontekstu niezbędną do pracy, zamiast używać wartości deklarowanej w karcie modelu, ponieważ większość zadań związanych z czatem i programowaniem mieści się w zakresie od 8k do 32k. Alternatywnie można zastosować kwantyzację samej pamięci podręcznej do 8 bitów, co zmniejsza jej rozmiar o połowę, kosztem pewnego spadku jakości odtwarzania informacji z długiego kontekstu.

Model rezydentny zajmuje pamięć RAM do momentu jego zwolnienia

Ollama utrzymuje model w pamięci przez 5 minut od ostatniego żądania, po czym go zwalnia. To ustawienie domyślne sprawdza się w laptopach, lecz jest nieodpowiednie dla serwera, gdzie każde pierwsze żądanie po okresie bezczynności wiąże się z ponownym czasem ładowania.

ollama ps
ollama stop qwen3:4b

ollama ps wyświetla listę modeli rezydentnych, przy czym kolumna SIZE wskazuje ilość zajmowanej pamięci, a kolumna UNTIL pokazuje czas wygaśnięcia. Aby przypiąć model na stałe, należy ustawić OLLAMA_KEEP_ALIVE=-1 w usłudze. Wartość 0 powoduje zwolnienie modelu natychmiast po zakończeniu każdej odpowiedzi.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

Wyślij jedno zapytanie, a następnie uruchom ollama ps ponownie po dziesięciu minutach. Model nadal znajduje się na liście, co jest kluczowym celem: zajmuje on pamięć RAM niezależnie od tego, czy jest aktualnie używany. Przypięty model nie stanowi wolnych zasobów. Na serwerze VPS z 16 GB pamięci RAM, model 8B przy kontekście 8k zajmuje około 6 GB przez cały czas działania usługi. Dlatego należy dobrać rozmiar serwera uwzględniając model oraz aplikację, a nie sam model. Przypinanie modelu w pamięci omawia kompromis między tym rozwiązaniem a opóźnieniem zimnego startu.

Co uruchomić na VPS z 4 GB RAM

Zarezerwuj około 1 GB na system operacyjny oraz serwer modelu, co pozostawia w przybliżeniu 3 GB wolnej pamięci. Taka ilość wystarcza na model o rozmiarze od 1B do 4B parametrów przy kwantyzacji 4-bitowej i domyślnym kontekście 4096 tokenów. Według stanu na sierpień 2026 roku, do tej klasy należą Llama 3.2 w wersji 3B, Qwen 3 w wersjach 1.7B i 4B oraz mniejsze wydania Gemma i Phi. Traktuj te nazwy jako przykłady rozmiarów, a nie rekomendacje. Nazwy modeli zmieniają się co kilka miesięcy, natomiast arytmetyka pozostaje niezmienna.

Spodziewaj się wydajności rzędu 6 do 14 tokenów na sekundę. Tak małe modele dobrze sprawdzają się w wąskich zadaniach: klasyfikacji, ekstrakcji tagów, krótkich podsumowaniach czy przeredagowywaniu akapitów zgodnie z przyjętym stylem. Są one słabe w wieloetapowym wnioskowaniu oraz w pracy z kodem obejmującym wiele plików; żadna technika promptowania tego nie naprawi.

Typowym objawem awarii na tym poziomie jest użycie swap. Jeśli model nie mieści się w pamięci, Linux nie odmawia jego załadowania. Zamiast tego przenosi dane do pamięci wymiany na dysku. Ponieważ generowanie pojedynczego tokena wymaga jednokrotnego odczytania wszystkich wag, szybkość generowania spada do poziomu sekund na token. Monitoruj free -h oraz kolumny si i so w narzędziu vmstat 1 podczas generowania odpowiedzi przez model. Wartości inne niż zero w polach swap in oraz swap out podczas generowania oznaczają, że model jest zbyt duży dla wybranego planu.

Co uruchomić na VPS z 8 do 16 GB RAM

To właśnie w tym przedziale własne modele stają się użyteczne. Na 8 GB RAM można uruchomić model 7B lub 8B w kwantyzacji 4-bitowej, co zajmuje około 4.8 GB wag przy kontekście 8k. Na 16 GB RAM można uruchomić model 13B lub 14B w kwantyzacji 4-bitowej, co zajmuje około 8.4 GB, lub pozostać przy modelu 8B w 8-bitach, jeśli priorytetem jest precyzja, a nie liczba parametrów.

Ograniczeniem jest szybkość. Model 8B na CPU generuje około 3 do 7 tokenów na sekundę, a model 14B około 1.5 do 3.5. Prędkość czytania człowieka to około 5 do 10 tokenów na sekundę, więc model 8B na VPS z samym CPU przypomina obserwowanie wolno piszącej osoby. Jest to akceptowalne w zadaniach działających w tle, ale męczące w interaktywnym czacie. Pomiary działania Qwen 3 w wersji 8B i większych na VPS pokazują, jak wygląda to w praktyce.

Co można uruchomić na VPS z 32 do 64 GB RAM

Model 32B przy kwantyzacji 4-bitowej zajmuje około 19.2 GB, więc mieści się w planie 32 GB przy krótkim kontekście i działa bez problemów na maszynach 48 GB lub 64 GB. Model 70B przy 4 bitach zajmuje około 42 GB, co oznacza, że wymaga 64 GB RAM jeszcze przed uwzględnieniem pamięci podręcznej (cache).

Następnie należy realistycznie ocenić szybkość. Model 32B działający na CPU generuje około 0.6 do 1.5 tokenów na sekundę, a model 70B — 0.2 do 0.5. Wygenerowanie odpowiedzi o długości 500 tokenów przez model 70B zajmuje około dwudziestu minut. Przy takim tempie żądanie zwykle kończy się błędem, zanim model zakończy generowanie, ponieważ wcześniej upływa limit czasu ustawiony przez klienta lub proxy przed Ollama. To właśnie powoduje błąd przekroczenia terminu kontekstu. Są to narzędzia do przetwarzania wsadowego. Można przekazać im kolejkę dokumentów do przetworzenia przez noc, ponieważ szybkość nie ma wtedy znaczenia. Umieszczenie ich za oknem czatu ma jednak duże znaczenie dla szybkości.

Architektura Mixture of Experts (MoE) zmienia te obliczenia i jest to jedyny szczegół techniczny, który warto poznać. Model MoE przesyła każdy token tylko przez niewielką część swoich wag. Model o łącznej liczbie 30B parametrów, z których 3B jest aktywnych na token, wymaga pamięci dla 30B, ale generuje tekst z prędkością zbliżoną do modelu gęstego 3B, ponieważ każdy token odczytuje tylko aktywne jednostki (ekspertów). Na serwerze z 32 GB RAM model MoE o takiej charakterystyce jest znacznie bardziej użyteczny niż gęsty model 30B. Główna zasada brzmi: całkowita liczba parametrów określa zapotrzebowanie na pamięć, a liczba aktywnych parametrów określa prędkość działania.

Jaka jest rzeczywista szybkość inferencji na CPU?

Wygenerowanie jednego tokena wymaga jednokrotnego odczytania wszystkich aktywnych wag z pamięci. Nie da się tego uniknąć, dlatego szybkość generowania na CPU jest ograniczona przepustowością pamięci, a nie liczbą rdzeni. Górny limit wyznacza dzielenie: dostępna przepustowość pamięci przez rozmiar wag w bajtach. Mały współdzielony VPS oferuje w praktyce od 10 do 25 GB na sekundę dla swoich vCPU, więc model o rozmiarze 4.8 GB osiąga maksymalnie od 2 do 5 tokenów na sekundę.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

Są to zakresy powszechnie raportowane na standardowym sprzęcie VPS, a nie wyniki benchmarku konkretnej maszyny. Uzyskana wartość zależy od generacji pamięci, liczby kanałów na hoście oraz tego, ilu sąsiadów rywalizuje o te zasoby. Własną wydajność można zmierzyć przy użyciu dowolnego modelu, który już posiadasz:

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

Podsumowanie wyświetlane po zakończeniu odpowiedzi kończy się linią zawierającą eval rate: ... tokens/s. Jest to Twoja szybkość generowania. Pomiń pierwsze uruchomienie w sesji, ponieważ load duration w tym samym podsumowaniu uwzględnia odczyt wag z dysku. Prawidłowy pomiar tokenów na sekundę opisuje, jak uzyskać wynik nadający się do porównania.

Dwa wyniki często zaskakują użytkowników. Dodawanie kolejnych vCPU szybko przestaje przynosić korzyści, ponieważ powyżej około 8 rdzeni dodatkowe jednostki czekają na pamięć, zamiast wykonywać obliczenia. Ponadto w planach współdzielonych to samo polecenie zwraca różne wyniki w zależności od godziny, co wynika z CPU steal time od hałaśliwego sąsiada, a nie z błędnej konfiguracji.

Przetwarzanie promptu to zadanie inne niż generowanie odpowiedzi. Przetwarzanie promptu jest ograniczone mocą obliczeniową, więc skaluje się wraz z liczbą rdzeni i to właśnie tutaj GPU zyskuje największą przewagę. Przeczytanie długiego dokumentu zajmuje CPU minuty, a GPU sekundy. Jest to pierwsza bariera, na którą trafisz, kierując agenta programistycznego na hostowany przez siebie model, ponieważ każda tura wymaga ponownego przesłania kontekstu pliku i definicji narzędzi, zanim zostanie wygenerowany choćby jeden token odpowiedzi.

Co zmienia dodanie GPU

Arytmetyka nie ulega zmianie, zmienia się jedynie pula zasobów, do której się odnosi. VRAM stanowi twardy limit, dlatego przed wynajęciem zasobów należy obliczyć, co się w nich zmieści:

• 8 GB VRAM mieści model 7B lub 8B przy kwantyzacji 4-bitowej z krótkim kontekstem.
• 16 GB mieści model 14B przy 4 bitach z pełnym kontekstem lub 8B przy 8 bitach.
• 24 GB mieści model 32B przy 4 bitach z ograniczonym kontekstem.
• 48 GB i więcej mieści model 70B przy 4 bitach z zapasem na cache i współbieżność.

Gdy model nie mieści się w całości, Ollama dzieli go: część warstw trafia na GPU, reszta na CPU. ollama ps raportuje podział w kolumnie PROCESSOR, na przykład jako 78%/22% CPU/GPU. Należy traktować to jako ostrzeżenie, a nie funkcjonalność. Część obliczana przez CPU wyznacza tempo pracy, ponieważ każdy token musi oczekiwać na przetworzenie tych warstw. W rezultacie model, którego jedna czwarta warstw znajduje się na CPU, działa z prędkością zbliżoną do CPU, a nie GPU. Jeśli podział nastąpił niezamierzenie, w pierwszej kolejności należy zmniejszyć długość kontekstu. Zazwyczaj to właśnie cache powoduje przekroczenie limitu.

Współbieżność to drugi powód, dla którego warto zwiększyć zasoby. Wagi modelu są współdzielone między jednoczesnymi żądaniami, jednak każde aktywne żądanie wymaga własnego cache KV. Dziesięciu użytkowników korzystających jednocześnie z modelu 8B przy kontekście 8k potrzebuje dziesięciokrotności 1 GB pamięci na sam cache, poza pamięcią zajmowaną przez wagi. Obsługa współbieżnych użytkowników z jednego modelu self-hosted wyjaśnia, gdzie znajduje się ten limit.

To, czy wynajęcie GPU jest opłacalne, również sprowadza się do obliczeń i zależy od liczby generowanych miesięcznie tokenów. Próg opłacalności między GPU VPS a tokenami API zawiera odpowiednie wyliczenia.

Czego nie można hostować samodzielnie

Istnieją dwie bariery, z którymi można się zetknąć; warto wiedzieć, na którą z nich trafiasz.

Pierwszą są zamknięte wagi. Wiodące modele komercyjne nie są udostępniane, więc nie istnieje plik do pobrania i żadna ilość pamięci RAM tego nie zmieni. Możesz samodzielnie hostować wszystko wokół nich: interfejs, warstwę wyszukiwania, pętlę agenta, logi. Sam model pozostaje zdalnym API. Czy można samodzielnie hostować Claude szczegółowo to wyjaśnia.

Drugą są otwarte wagi, które są po prostu zbyt duże. Największe otwarte wydania to konstrukcje typu mixture of experts, liczące łącznie setki miliardów parametrów. Obowiązuje tu ta sama zasada: model o łącznej liczbie 400B parametrów przy kwantyzacji 4-bitowej wymaga około 240 GB samej pamięci na wagi, jeszcze przed uwzględnieniem cache'u. To sprzęt specjalistyczny, a jego miesięczny wynajem kosztuje znacznie więcej niż większość użytkowników wydaje na tokeny API w ciągu roku. Czego potrzeba do samodzielnego hostowania modelu klasy Kimi przedstawia rzeczywiste wymagania. Ten sam podział widać w bibliotece Ollama, gdzie GLM 5.2 jest wymieniony tylko jako model chmurowy, a na VPS pobiera się jedynie jego znacznie mniejszy odpowiednik.

Uczciwa granica między tymi rozwiązaniami: hostuj samodzielnie, gdy obciążenie jest stałe, a dane nie powinny opuszczać Twojego serwera. Kupuj tokeny, gdy obciążenie jest skokowe lub gdy kluczowa jest jakość odpowiedzi oferowana przez wiodące modele.

Weryfikacja zasobów przed wyborem

free -h
nproc
lscpu | grep 'Model name'

Należy planować w oparciu o kolumnę available w free -h, a nie kolumnę total, ponieważ total uwzględnia pamięć już zajętą przez system. Należy odjąć około 1 GB na potrzeby systemu operacyjnego oraz serwera modelu. Pozostałą wartość należy podzielić przez 0,6, aby uzyskać maksymalną liczbę parametrów w miliardach, którą można obsłużyć przy kwantyzacji 4-bitowej. Następnie należy odjąć pamięć podręczną KV dla wymaganego kontekstu. Wynik stanowi ostateczną odpowiedź, która w przeciwieństwie do listy nazw modeli nie traci na aktualności.

FAQ

Ile pamięci RAM potrzeba do uruchomienia modelu 8B?

Około 4.8 GB na wagi przy kwantyzacji 4-bitowej, plus pamięć podręczna KV dla długości kontekstu, oraz około 1 GB na system operacyjny i serwer modelu. Przy kontekście 8192 tokenów pamięć podręczna zajmuje dodatkowe 1 GB, więc plan 8 GB jest wystarczający, a 4 GB nie. Jeśli wymagany jest pełny kontekst 128k deklarowany w karcie modelu, sama pamięć podręczna zajmuje 16 GB, co wymaga planu 32 GB.

Dlaczego model działa wolno, mimo że VPS ma wiele vCPU?

Ponieważ generowanie jest ograniczone przepustowością pamięci, a nie liczbą rdzeni. Każdy token wymaga pobrania całego zestawu aktywnych wag z pamięci RAM, więc gdy kilka rdzeni wysyci kanały pamięci, pozostałe oczekują na dane. Inną częstą przyczyną jest swap. Jeśli vmstat 1 wykazuje niezerowe wartości si oraz so podczas generowania odpowiedzi, oznacza to, że wagi nie mieszczą się w pamięci RAM i część każdego tokena jest odczytywana z dysku, co drastycznie obniża wydajność.

Czy dłuższe okno kontekstowe faktycznie wymaga więcej pamięci?

Tak, a wzrost zapotrzebowania jest liniowy względem liczby tokenów. Typowy model 8B zużywa około 128 KiB pamięci podręcznej KV na token, więc 8192 tokeny kosztują 1 GB, a 131072 tokeny kosztują 16 GB. Pamięć podręczna jest alokowana w momencie ładowania modelu, a nie w trakcie trwania konwersacji, więc zadeklarowanie kontekstu 128k rezerwuje tę pamięć natychmiast, nawet jeśli przesyłane zapytania mają tylko 200 tokenów.

Czy lepiej uruchomić duży model w 2 bitach, czy mniejszy w 4 bitach?

Należy wybrać mniejszy model w 4 bitach. Jakość spada powoli od 8 do 4 bitów, ale poniżej 4 bitów następuje gwałtowny spadek, więc model 70B skompresowany do 2 bitów zazwyczaj udziela gorszych odpowiedzi niż model 32B w 4 bitach z tej samej generacji. Silna kwantyzacja objawia się powtórzeniami i ignorowaniem instrukcji, a nie komunikatami o błędach, co utrudnia zdiagnozowanie problemu i prowadzi do błędnego obwiniania promptu. Należy traktować 4 bity jako dolną granicę i zamiast tego zmieniać liczbę parametrów modelu.

Czy można samodzielnie hostować model o możliwościach dużych modeli komercyjnych?

Nie na zwykłym VPS. Najpotężniejsze modele o otwartych wagach posiadają setki miliardów parametrów, co przy 4 bitach oznacza ponad 200 GB pamięci RAM przed uwzględnieniem pamięci podręcznej KV, a najsilniejsze modele komercyjne nie są w ogóle udostępniane. Zwykły sprzęt dobrze radzi sobie z uruchomieniem modelu od 8B do 32B do konkretnego zadania, gdzie wąski i dobrze spromptowany mały model często dorównuje modelom ogólnego przeznaczenia. Jeśli wymagana jest jakość klasy frontier, przed zakupem sprzętu należy porównać koszty API z kosztami infrastruktury.