VPS z GPU czy CPU: kiedy warto dopłacić za moc?

Czy potrzebny jest VPS z GPU, czy wystarczy CPU?

VPS z GPU zmienia dwie kwestie w kontekście samodzielnego uruchamiania modelu: szybkość generowania tokenów oraz maksymalny rozmiar modelu, który mieści się w pamięci. Nie zmienia niczego innego. Jeśli obciążenie stanowi skwantowany model czatowy o rozmiarze od 7B do 27B obsługujący jedną osobę jednocześnie, zadanie embeddingu przy niskim wolumenie lub transkrypcja mowy przy użyciu Whisper small, zwykły VPS z procesorem CPU i odpowiednią ilością pamięci RAM wykona to zadanie. Należy zacząć od CPU, zmierzyć wartość, która jest niewystarczająca, a następnie dokonać migracji na mocniejszy sprzęt.

Powodem jest przepustowość pamięci. Gdy model językowy generuje jeden token, odczytuje z pamięci wszystkie wymagane wagi. Model 8B skwantowany do 4 bitów zajmuje około 4.9 GB na dysku i mniej więcej tyle samo w pamięci, więc wygenerowanie tokena oznacza przeniesienie około 4.9 GB danych. Podzielenie przepustowości pamięci maszyny przez tę wartość wyznacza górny limit liczby tokenów na sekundę. To pojedyncze dzielenie wyjaśnia niemal każdy benchmark, z którym można się spotkać.

Co faktycznie zyskujesz dzięki GPU

Przepustowość. Pamięć DDR5 na nowoczesnym serwerze przesyła dziesiątki gigabajtów na sekundę. Pamięć GPU (VRAM) przesyła od setek do ponad tysiąca. Stosunek tych wartości określa przyspieszenie, które jest znaczne.

Pojemność w połączeniu z szybkością. Jednostka CPU z 64 GB pamięci RAM może załadować model 70B w kwantyzacji 4-bitowej. Model zadziała, jednak tempo pracy będzie bliższe czytaniu niż prowadzeniu rozmowy. GPU pomaga w tym przypadku tylko wtedy, gdy model mieści się w VRAM, ponieważ w momencie, gdy warstwy modelu trafiają do pamięci systemowej, ponownie ogranicza nas wolniejsza ścieżka dostępu.

Przepustowość przetwarzania wsadowego (batching). Jest to aspekt często niedoceniany. GPU generujące odpowiedź dla jednego użytkownika pozostaje w większości bezczynne, ponieważ oczekuje na dane z pamięci. Obsługa 20 żądań jednocześnie pozwala wykorzystać ten sam odczyt wag dla wszystkich 20 procesów. Łączna liczba generowanych tokenów na sekundę wzrasta kilkukrotnie, podczas gdy szybkość dla pojedynczego użytkownika spada w minimalnym stopniu. Silniki wnioskowania oparte na CPU, takie jak llama.cpp, również wspierają przetwarzanie wsadowe, a zyski zależą od sprzętu i obciążenia. Jeśli tworzysz API wywoływane przez wielu klientów, przetwarzanie wsadowe jest głównym argumentem przemawiającym za użyciem GPU, ważniejszym niż czysta szybkość pojedynczego strumienia.

Przetwarzanie promptów. Analiza długiego promptu jest ograniczona mocą obliczeniową, a nie przepustowością pamięci, i to właśnie tutaj GPU zyskują największą przewagę. Kontekst 30 000 tokenów, który procesor CPU przetwarza w minutę, na GPU zajmuje kilka sekund. Systemy wyszukiwania informacji (retrieval), które umieszczają dokumenty w każdym żądaniu, odczuwają tę różnicę nieustannie.

Przybliżone wartości i sposób ich interpretacji

Rzeczywista przepustowość jest niższa niż wynik dzielenia przepustowości łącza przez rozmiar modelu, ponieważ mechanizm uwagi (attention) przy rosnącym kontekście zwiększa nakład pracy, czego proste dzielenie nie uwzględnia.

Dla porównania, średnie tempo cichego czytania tekstów w języku angielskim wynosi około 4,0 do 4,3 słowa na sekundę: 238 słów na minutę w przypadku literatury faktu i 260 w przypadku beletrystyki. Każda wartość na poziomie 15 tokenów na sekundę lub wyższa jest odbierana przez pojedynczego użytkownika jako tempo typowego pisania na klawiaturze. Z tego powodu wiele konfiguracji opartych wyłącznie na CPU jest w zupełności wystarczających.

Szacowanie zapotrzebowania na VRAM przed zakupem

Rozmiar pliku modelu to wartość minimalna, a nie rzeczywiste wymaganie. Należy uwzględnić wagi, pamięć podręczną KV (key-value cache, pamięć dla każdego tokena wykorzystywana przez mechanizm uwagi) oraz około 1 GB zapasu na narzut systemu.

Zamiast dodawać sztywny procent, należy obliczyć pamięć podręczną, ponieważ kwantyzacja wag nie obejmuje pamięci podręcznej. Dla każdego tokena model typu full-attention przechowuje klucz i wartość dla każdej warstwy oraz każdej głowicy KV, przy 2 bajtach na liczbę w formacie FP16, co jest domyślnym typem pamięci podręcznej w Ollama. Metadane modelu Ollama, sprawdzone w dniu 2026-10-27, wskazują, że Llama 3.1 8B posiada 32 warstwy i 8 głowic KV o wymiarach 128, co daje 128 KiB na token: około 1,07 GB przy kontekście 8k i 2,15 GB przy 16k. Zatem model 8B o rozmiarze 4,9 GB wymaga około 7 GB VRAM przy 8k i około 8 GB przy 16k. Model 27B w 4 bitach zajmuje około 17 GB (Gemma 3 27B w bibliotece Ollama). Metadane Gemma 3 wskazują na okno przesuwne o długości 1024 tokenów, co ogranicza wzrost pamięci podręcznej, więc należy zaplanować 20 GB lub więcej. Model 70B w 4 bitach zajmuje około 43 GB (Llama 3.3 70B). Przy 80 warstwach pamięć podręczna FP16 dodaje około 2,7 GB przy 8k i 5,4 GB przy 16k, co oznacza, że wymagana jest karta 48 GB z niewielkim zapasem lub dwie mniejsze karty. Ta sama arytmetyka sprawdza się znacznie powyżej tych wartości, a obliczenia VRAM dla modelu o 2,8 biliona parametrów, takiego jak Kimi K3 pokazują, w którym momencie wybór karty przestaje być głównym problemem.

Długie konteksty mają tu kluczowe znaczenie. W modelach typu full-attention, takich jak Llama 3.1, pamięć podręczna KV rośnie liniowo wraz z długością kontekstu, a przy 128k tokenów może przekroczyć rozmiar samych wag. Modele z mechanizmem uwagi typu sliding-window lub chunked attention działają inaczej: dokumentacja Transformers od Hugging Face wymienia Mistral, Gemma 2 oraz Llama 4 jako przykłady, w których pamięć podręczna na tych warstwach przestaje rosnąć po osiągnięciu rozmiaru okna lub fragmentu, dzięki czemu całkowite zużycie rośnie wolniej. W przypadku planowania pracy z długimi kontekstami należy najpierw oszacować pamięć podręczną i sprawdzić, jakie opcje kwantyzacji pamięci podręcznej oferuje silnik. W Ollama OLLAMA_KV_CACHE_TYPE=q8_0 zużywa około połowę pamięci w porównaniu do domyślnego f16, a kwantyzacja pamięci podręcznej ma zastosowanie tylko przy włączonym Flash Attention. Należy również jawnie ustawić długość kontekstu. Ollama dobiera wartość domyślną na podstawie VRAM: 4k poniżej 24 GiB, 32k od 24 do 48 GiB oraz 256k przy 48 GiB i więcej. Na karcie 48 GB z uruchomionym modelem 70B to ustawienie domyślne wymaga znacznie więcej pamięci podręcznej, niż karta jest w stanie pomieścić.

Weryfikacja faktycznej konfiguracji maszyny

Na instancji z GPU w pierwszej kolejności należy potwierdzić, czy sterownik wykrywa kartę.

nvidia-smi

Wskazane jest uzyskanie tabeli zawierającej nazwę GPU, wersję sterownika oraz wykorzystanie pamięci w stosunku do całkowitej dostępnej ilości. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver oznacza, że NVIDIA-SMI nie może połączyć się ze sterownikiem; należy sprawdzić, czy sterownik jest zainstalowany i czy moduł jądra został załadowany. W standardowym obrazie Ubuntu rozwiązaniem jest zazwyczaj sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, a następnie restart w celu załadowania nowego modułu. W przypadku maszyn obliczeniowych dokumentacja serwerowa Ubuntu zaleca sudo ubuntu-drivers install --gpgpu, co pozwala wybrać gałąź sterowników serwerowych.

W przypadku kontenerów sam sterownik jest niewystarczający. Docker wymaga NVIDIA Container Toolkit, aby przekazać urządzenie do wnętrza kontenera.

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Następnie należy sprawdzić, czy przekazywanie urządzenia działa z poziomu kontenera:

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

Powinna wyświetlić się ta sama tabela. Wiersz docker: Error response from daemon: could not select device driver, wskazujący na niespełnioną możliwość GPU, oznacza, że Docker nie mógł znaleźć sterownika urządzenia zgodnego z żądaniem; należy sprawdzić, czy zestaw narzędzi jest zainstalowany, a następnie ponownie wykonać polecenie nvidia-ctk i zrestartować usługę. W Compose odpowiednikiem jest wpis deploy.resources.reservations.devices, którego driver to nvidia, a lista możliwości zawiera gpu, co pasuje do standardowych definicji usług opisanych w Docker Compose na VPS.

Pomiary przed aktualizacją

Uruchom model, którego faktycznie zamierzasz używać, na posiadanym serwerze CPU i zarejestruj wyniki. W przypadku samodzielnego hostowania LLM przez Ollama na VPS wymaga to użycia jednej flagi:

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

Dane wyjściowe kończą się pomiarami czasu. eval rate to szybkość generowania wyrażona w tokenach na sekundę. prompt eval rate określa szybkość odczytu danych wejściowych przez maszynę. Te dwie wartości wskazują, która aktualizacja przyniesie korzyści: niska wartość eval rate oznacza problem z przepustowością pamięci, natomiast niska wartość prompt eval rate przy długich danych wejściowych wskazuje na problem z mocą obliczeniową.

Na maszynie wyposażonej w GPU sprawdź, czy model faktycznie został załadowany do pamięci karty:

ollama ps

Kolumna PROCESSOR przyjmuje wartość 100% GPU, gdy cały model mieści się w pamięci, lub wartość typu 43%/57% CPU/GPU, gdy tak nie jest. Częściowe przeniesienie modelu do GPU zazwyczaj skutkuje gorszą wydajnością niż oczekiwano, ponieważ każdy token nadal oczekuje na przetworzenie przez wolniejszą część systemu.

Kwestia kosztów

Instancje GPU są rozliczane za czas udostępnienia mocy obliczeniowej, a nie za tokeny, przy czym stawki oraz opłaty za zatrzymane instancje są ustalane przez dostawcę. Działające w trybie ciągłym GPU, obsługujące zaledwie kilka zapytań dziennie, większość opłaconego czasu spędza w stanie bezczynności. Punktem zwrotnym jest utylizacja: intensywnie wykorzystywane GPU jest tanie w przeliczeniu na token, natomiast bezczynne generuje czyste straty.

Sprawdzają się trzy uczciwe wzorce. Stałe zadania o niskim wolumenie należy utrzymywać na VPS z procesorem CPU. Sporadyczne, wymagające zapytania warto kierować do hostowanego API i płacić za token. Instancję GPU można wynajmować godzinowo na potrzeby zadań wsadowych, dostrajania modeli lub masowego generowania embeddingów, a po zakończeniu pracy – usuwać. Łączenie tych metod jest standardem, a dyscyplina budżetowa opisana w Kontrola kosztów agenta AI na VPS działającym w trybie ciągłym ma tu również zastosowanie, z tą różnicą, że to czas bezczynności, a nie liczba tokenów, stanowi źródło strat.

Co działa poprawnie bez GPU

Embeddingi przy małym obciążeniu. Niewielki model embeddingowy przetwarza setki krótkich dokumentów na minutę przy użyciu kilku rdzeni CPU, a indeks budowany jednorazowo nie wymaga dużej szybkości działania.

Modele Whisper w wersjach small i base do transkrypcji. Biblioteka faster-whisper na CPU dokonuje transkrypcji w czasie zbliżonym do rzeczywistego dla modelu small, co jest wystarczające dla potoku przetwarzania uruchamianego w nocy.

Skwantyzowane modele czatowe do około 27B, dla jednego lub dwóch użytkowników. Działają wolno, ale są czytelne i użyteczne.

Wszystko, co można określić mianem zadania wsadowego (batch job). Jeśli nikt nie obserwuje ekranu, czas wykonania zadania jest kwestią harmonogramowania, a nie wymogiem technicznym.

Co faktycznie wymaga GPU: trenowanie lub dostrajanie (fine-tuning) wykraczające poza mały adapter, obsługa wielu jednoczesnych użytkowników, generowanie obrazów i wideo oraz przetwarzanie mowy w czasie rzeczywistym, gdzie opóźnienie jest kluczowym parametrem produktu.

FAQ

Ile pamięci VRAM potrzeba dla modelu 7B lub 8B?

Około 7 GB dla 4-bitowego skwantowanego modelu 8B przy kontekście 8k oraz około 8 GB przy 16k, przy założeniu domyślnej pamięci podręcznej FP16 w Ollama. Wagi zajmują około 4,9 GB, pamięć podręczna KV dodaje około 1,07 GB przy 8k lub 2,15 GB przy 16k, a reszta to około 1 GB narzutu. Karta 8 GB mieści model przy 8k i działa na granicy przy 16k, podczas gdy karta 12 GB zapewnia zapas dla dłuższych kontekstów. Przełączenie pamięci podręcznej na q8_0 zmniejsza jej udział mniej więcej o połowę. W przypadku planowania pracy z kontekstem 128k należy zaplanować rozmiar pamięci podręcznej oddzielnie, ponieważ może ona urosnąć do rozmiarów większych niż same wagi.

Czy można uruchomić Ollama bez GPU?

Tak. Ollama automatycznie przełącza się na CPU i wymaga jedynie wystarczającej ilości pamięci RAM do załadowania modelu. Należy spodziewać się prędkości rzędu 5 do 12 tokenów na sekundę dla 4-bitowego modelu 8B, w zależności od szybkości pamięci, co odpowiada tempu czytania dla jednego użytkownika. Długie prompty stanowią główny problem na CPU, ponieważ przetwarzanie 30 000 tokenów kontekstu jest ograniczone mocą obliczeniową i trwa znacznie dłużej niż generowanie odpowiedzi.

Dlaczego GPU działa niewiele szybciej niż CPU?

Najczęstszą przyczyną jest fakt, że model nie zmieścił się w całości w pamięci VRAM, przez co niektóre warstwy działają na CPU, a każdy token czeka na wolniejszą część obliczeń. Należy uruchomić ollama ps i sprawdzić, czy kolumna PROCESSOR wskazuje 100% GPU. Jeśli widoczny jest podział, należy użyć mniejszej kwantyzacji lub mniejszego modelu. Inną częstą przyczyną jest krótki test wydajności, w którym czas ładowania modelu dominuje nad pomiarem.

Czy GPU VPS opłaca się dla jednego użytkownika?

Zazwyczaj nie. Przeciętne tempo czytania w języku angielskim wynosi od 4,0 do 4,3 słowa na sekundę, a przed porównaniem wydajności serwera CPU z tym tempem należy przeliczyć tokeny na sekundę na słowa na sekundę. Przypadki uzasadniające koszt dla jednego użytkownika to długie prompty, generowanie obrazów oraz dostrajanie (fine-tuning). Obsługa wielu użytkowników jednocześnie jest najsilniejszym argumentem, ponieważ przetwarzanie wsadowe pozwala jednemu GPU współdzielić odczyty wag między żądaniami.

Czy lepiej wynajmować GPU godzinowo, czy utrzymywać je stale uruchomione?

Wynajem godzinowy jest wskazany przy pracy o charakterze skokowym: dostrajaniu, masowym przetwarzaniu embeddingów lub wsadowej transkrypcji. Utrzymywanie stale uruchomionej instancji jest opłacalne tylko wtedy, gdy karta jest stale obciążona, ponieważ za udostępnione zasoby GPU płaci się za czas, a nie za wygenerowane tokeny. Asystent o niskim natężeniu ruchu jest tańszy w utrzymaniu na serwerze CPU VPS lub poprzez płatne za token API niż na bezczynnym GPU.