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

Co decyduje o tym, które modele AI można hostować samodzielnie

O możliwości samodzielnego hostowania modeli AI decyduje jedna wartość: ilość pamięci RAM 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 zawiera obliczenia pozwalające to ustalić. Instalacja środowiska uruchomieniowego to osobne 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, o którym zapomina się do momentu, gdy model, który wczoraj się załadował, dzisiaj odmawia uruchomienia.

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 wag przy użyciu mniejszej liczby bitów niż w przypadku precyzji, z jaką model był trenowany, co wiąże się z niewielką utratą dokładności, ale znaczną 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 16 bitach, co odpowiada 2 GB na miliard parametrów. Dlatego prawie nikt nie uruchamia modeli w pełnej precyzji na serwerach VPS. Oto kwantyzacje, z którymi faktycznie przyjdzie się zetknąć, wraz z ich ś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 to rozsądne ustawienie domyślne na maszynach ograniczonych 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ą przechowywane z wyższą precyzją 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, który model przechowuje dla każdego tokena w bieżącej konwersacji) stanowi drugi koszt. Jest ona przydzielana 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ż waga 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 zakresu od 24 do 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 odzyskanie pamięci zajmowanej przez cache. Pierwszym jest ustawienie długości kontekstu zgodnie z rzeczywistymi potrzebami, a nie wartością deklarowaną w karcie modelu, ponieważ większość zadań związanych z czatem i programowaniem mieści się w zakresie od 8k do 32k. Drugim sposobem jest kwantyzacja 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, dopóki nie zostanie zwolniony

Ollama utrzymuje model w pamięci przez 5 minut od ostatniego żądania, po czym go zwalnia. To ustawienie domyślne sprawdza się na laptopie, ale 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ę rezydentnych modeli, przy czym kolumna SIZE pokazuje ilość zajmowanej pamięci, a kolumna UNTIL 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 kluczowe: zajmuje pamięć RAM niezależnie od tego, czy jest używany. Przypięty model nie stanowi wolnych zasobów. Na serwerze VPS z 16 GB pamięci RAM, model 8B z kontekstem 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 wynikającym z 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 modele o rozmiarze od 1B do 4B 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 jako rekomendacje. Nazwy modeli zmieniają się co kilka miesięcy, natomiast zasady matematyczne pozostają niezmienne.

Należy spodziewać 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 rozumowaniu oraz w pracy z kodem obejmującym wiele plików, a żadna technika promptowania tego nie naprawi.

Typowym problemem 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, a ponieważ generowanie pojedynczego tokena wymaga odczytania wszystkich wag modelu, 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 można uruchomić na VPS z 8 do 16 GB RAM

To jest poziom, na którym samodzielnie hostowany model staje się użyteczny. Na 8 GB RAM można uruchomić model 7B lub 8B przy 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 przy 4-bitach, 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.

Problemem jest szybkość. Model 8B na CPU generuje od 3 do 7 tokenów na sekundę, a model 14B od 1.5 do 3.5. Człowiek czyta z prędkością około 5 do 10 tokenów na sekundę, więc praca z modelem 8B na VPS z CPU przypomina obserwowanie powolnego pisania na maszynie. Jest to akceptowalne w zadaniach 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 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 stabilnie na 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.

Należy realistycznie ocenić wydajność. Model 32B na CPU generuje od 0.6 do 1.5 tokenów na sekundę, a model 70B od 0.2 do 0.5. Wygenerowanie odpowiedzi o długości 500 tokenów przez model 70B zajmuje około dwudziestu minut. Są to narzędzia do przetwarzania wsadowego. Jeśli kolejka dokumentów jest przetwarzana w nocy, prędkość nie ma znaczenia. W przypadku interfejsu czatu wydajność jest kluczowa.

Architektura Mixture of Experts zmienia ten rachunek 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 i 3B aktywnych na token wymaga pamięci dla 30B, ale generuje tekst z prędkością zbliżoną do gęstego modelu 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: łączna 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 procesorze?

Wygenerowanie jednego tokena wymaga jednokrotnego odczytania wszystkich aktywnych wag z pamięci. Nie da się tego uniknąć, dlatego szybkość generowania na procesorze (CPU) jest ograniczona przepustowością pamięci, a nie liczbą rdzeni. Górną granicę wyznacza iloraz: dostępna przepustowość pamięci podzielona 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 typowo 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 współdzieli te zasoby. Własną wydajność można zmierzyć przy użyciu dowolnego posiadanego modelu:

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 szybkość generowania. Należy pominąć 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 rezultaty często zaskakują użytkowników. Dodawanie vCPU przestaje przynosić korzyści bardzo szybko, ponieważ powyżej około 8 rdzeni dodatkowe jednostki czekają na pamięć, zamiast wykonywać obliczenia. Ponadto na planie współdzielonym 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 procesorowi minuty, a karcie graficznej sekundy. Jest to pierwsza bariera, na którą trafia się podłączając agenta programistycznego do hostowanego modelu, ponieważ każda iteracja wymaga ponownego przesłania kontekstu pliku i definicji narzędzi, zanim zostanie wygenerowany choćby jeden token odpowiedzi.

Co zmienia dodanie GPU

Obliczenia pozostają niezmienne, zmienia się jedynie pula zasobów. VRAM stanowi twardy limit, dlatego przed wynajęciem serwera należy sprawdzić, co się w nim 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 pamię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 funkcję. Część obliczana przez CPU wyznacza tempo pracy, ponieważ każdy token musi czekać na przetworzenie tych warstw. 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, ale 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 cache ponad rozmiar wag. Obsługa wielu użytkowników jednocześnie przy użyciu własnego modelu 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. Punkt rentowności między GPU VPS a tokenami API zawiera odpowiednie wyliczenia.

Czego nie można hostować samodzielnie

Istnieją dwie różne bariery i warto wiedzieć, na którą z nich trafiasz.

Pierwszą są zamknięte wagi. Wiodące modele komercyjne nie są udostępniane, więc nie ma pliku do pobrania i żadna zmiana ilości pamięci RAM tego nie zmieni. Możesz samodzielnie hostować wszystko wokół nich: interfejs, warstwę pobierania danych, 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 projekty typu mixture of experts o łącznej liczbie parametrów rzędu setek miliardó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, nie licząc pamięci podręcznej. To wymaga specjalistycznego sprzętu, a jego miesięczny wynajem kosztuje znacznie więcej niż większość osób wydaje na tokeny API w ciągu roku. Czego wymaga samodzielne hostowanie modelu klasy Kimi przedstawia rzeczywiste wymagania.

Uczciwa granica między tymi dwoma przypadkami: hostuj samodzielnie, gdy obciążenie jest stałe, a dane nie powinny opuszczać Twojego serwera. Kupuj tokeny, gdy obciążenie jest skokowe lub gdy jakość odpowiedzi wiodących modeli jest tym, czego faktycznie potrzebujesz.

Sprawdź zasoby przed dokonaniem wyboru

free -h
nproc
lscpu | grep 'Model name'

Planuj w oparciu o kolumnę available w free -h, a nie kolumnę total, ponieważ total uwzględnia pamięć już zajętą przez system. Odejmij około 1 GB na system operacyjny oraz serwer modelu. Pozostałą wartość podziel przez 0,6, aby uzyskać maksymalną liczbę parametrów w miliardach, którą można obsłużyć przy kwantyzacji 4-bitowej. Następnie odejmij pamięć KV cache dla wymaganego kontekstu. Wynik stanowi odpowiedź na pytanie o możliwości sprzętowe; w przeciwieństwie do listy nazw modeli, ta metoda 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 oznacza konieczność wyboru 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 po nasyceniu kanałów pamięci przez kilka rdzeni, pozostałe pozostają w stanie oczekiwania. Inną częstą przyczyną jest swap. Jeśli vmstat 1 wykazuje niezerowe wartości si i 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 powoduje znacznie większe opóźnienia, niż mogłoby się wydawać.

Czy dłuższe okno kontekstowe rzeczywiście 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 przydzielana w momencie ładowania modelu, a nie w miarę wzrostu konwersacji, więc zadeklarowanie kontekstu 128k rezerwuje tę pamięć natychmiast, nawet jeśli każdy wysyłany prompt ma tylko 200 tokenów.

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

Należy wybrać mniejszy model przy 4 bitach. Jakość spada powoli od 8 do 4 bitów, ale gwałtownie poniżej 4 bitów, więc model 70B skompresowany do 2 bitów zazwyczaj udziela gorszych odpowiedzi niż model 32B przy 4 bitach z tej samej generacji. Silna kwantyzacja objawia się powtarzaniem treści i pomijaniem 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 mogę samodzielnie hostować model o możliwościach porównywalnych z dużymi modelami komercyjnymi?

Nie na standardowym 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 w ogóle nie są udostępniane. Standardowy 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ólnym. Jeśli wymagana jest jakość klasy frontier, przed zakupem sprzętu należy porównać koszty z cenami API.