Kiedy warto wybrać VPS z GPU zamiast CPU?

Czy potrzebny jest VPS z GPU, czy wystarczy CPU?

VPS z GPU zmienia dwie kwestie w samodzielnym uruchamianiu 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 obejmuje skwantowany model czatowy od 7B do 27B odpowiadający jednej osobie jednocześnie, zadanie embeddingu przy niskim wolumenie lub transkrypcję mowy za pomocą Whisper small, zwykły VPS z CPU i odpowiednią ilością RAM w zupełności wystarczy. Należy zacząć od CPU, zmierzyć parametr, który jest niezadowalający, a następnie dokonać migracji na mocniejszy sprzęt.

Przyczyną 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.7 GB na dysku i mniej więcej tyle samo w pamięci, więc wygenerowanie tokena oznacza przesłanie około 4.7 GB danych. Podzielenie przepustowości pamięci maszyny przez tę wartość wyznacza górny limit liczby tokenów na sekundę. To proste dzielenie wyjaśnia niemal każdy benchmark, z którym można się spotkać.

Co faktycznie zyskujesz dzięki GPU

Przepustowość. Pamięć DDR5 serwera na nowoczesnym hoście przesyła dziesiątki gigabajtów na sekundę. Pamięć GPU (VRAM) przesyła setki, a nawet ponad tysiąc. 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. Będzie on działał, jednak w tempie bliższym czytaniu niż prowadzeniu rozmowy. GPU pomaga w tym przypadku tylko wtedy, gdy model mieści się w VRAM, ponieważ w momencie, gdy warstwy modelu zostaną przeniesione do pamięci systemowej RAM, ponownie zaczyna dominować wolniejsza ścieżka przetwarzania.

Przepustowość przetwarzania wsadowego (batching). Jest to aspekt często niedoceniany. GPU generujące odpowiedź dla jednego użytkownika pozostawia większość swoich zasobów obliczeniowych w stanie bezczynności, ponieważ oczekuje na dane z pamięci. Obsługa 20 żądań jednocześnie sprawia, że ten sam odczyt wag służy wszystkim 20 procesom. Łączna liczba generowanych tokenów na sekundę wzrasta kilkukrotnie, podczas gdy szybkość dla pojedynczego użytkownika spada w minimalnym stopniu. CPU nie oferuje takiej wydajności. Dwóch jednoczesnych użytkowników na jednostce CPU powoduje spadek wydajności dla każdego z nich o około połowę. Jeśli tworzysz API wywoływane przez wielu klientów, przetwarzanie wsadowe jest silniejszym argumentem za użyciem GPU niż sama szybkość pojedynczego strumienia.

Przetwarzanie promptów. Odczyt długiego promptu jest ograniczony mocą obliczeniową, a nie przepustowością pamięci, i to właśnie tutaj GPU wygrywają z największą przewagą. Kontekst 30 000 tokenów, który 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.

Szacunkowe wartości i sposób ich interpretacji

Poniższy blok zawiera typowe, opublikowane dane dla pojedynczego strumienia modelu 8B przy kwantyzacji 4-bitowej, aktualne na lipiec 2026 roku. Są to wartości rzędu wielkości, a nie gwarancja wydajności. Wyniki będą się różnić w zależności od zastosowanej kwantyzacji, długości kontekstu oraz silnika wnioskowania.

[
  {
    "label": "8 vCPU, DDR4",
    "mem_bandwidth_gbs": 40,
    "tokens_per_sec": 6
  },
  {
    "label": "16 vCPU, DDR5",
    "mem_bandwidth_gbs": 75,
    "tokens_per_sec": 11
  },
  {
    "label": "24GB GPU",
    "mem_bandwidth_gbs": 300,
    "tokens_per_sec": 50
  },
  {
    "label": "40GB data-centre GPU",
    "mem_bandwidth_gbs": 1555,
    "tokens_per_sec": 130
  }
]

Wiersz dla GPU 24 GB wskazuje 50 tokenów na sekundę w porównaniu do 11 dla jednostki CPU z pamięcią DDR5. Jest to różnica około pięciokrotna, co odzwierciedla stosunek przepustowości, a nie różnicę w surowej mocy obliczeniowej. Rzeczywista przepustowość jest również niższa niż wynik dzielenia przepustowości przez rozmiar modelu, ponieważ mechanizm attention przy rosnącym kontekście generuje dodatkowe obciążenie, którego proste dzielenie nie uwzględnia.

Dla porównania, człowiek czyta z prędkością około 5 do 10 słów na sekundę. Każda wartość na poziomie 15 tokenów na sekundę lub wyższa jest odbierana przez pojedynczego użytkownika jako prędkość typowego pisania na klawiaturze. Dlatego tak wiele konfiguracji opartych wyłącznie na CPU sprawdza się w praktyce.

Dobór pamięci VRAM przed zakupem

Rozmiar pliku modelu stanowi wartość minimalną, a nie docelowe wymaganie. Należy uwzględnić wagę modelu, pamięć podręczną KV (key-value cache, pamięć na token przechowywana przez mechanizm atencji) oraz około 1 GB narzutu.

Praktyczna zasada na lipiec 2026 roku: należy wziąć rozmiar pliku modelu w gigabajtach i dodać 20 procent dla typowego kontekstu od 8k do 16k. Model 8B o rozmiarze 4.7 GB wymaga około 6 GB pamięci VRAM. Model 27B w kwantyzacji 4-bitowej zajmuje około 16 GB i wymaga w przybliżeniu 20 GB. Model 70B w kwantyzacji 4-bitowej zajmuje około 40 GB i wymaga karty 48 GB lub dwóch mniejszych jednostek. Ta sama arytmetyka sprawdza się znacznie powyżej tych wartości, a matematyka VRAM dla modelu o 2.8 biliona parametrów, takiego jak Kimi K3 pokazuje, w którym momencie wybór karty przestaje być jedynym problemem.

Długie konteksty naruszają tę zasadę. Pamięć podręczna KV rośnie liniowo wraz z długością kontekstu, a przy 128k tokenów może przekroczyć rozmiar samych wag. W przypadku planowanego wykorzystania długich kontekstów należy najpierw dobrać rozmiar pod kątem pamięci podręcznej i sprawdzić, jakie opcje kwantyzacji cache oferuje używany silnik.

Weryfikacja zasobów sprzętowych maszyny

Na instancji z GPU przed wykonaniem jakichkolwiek innych czynności należy potwierdzić, czy sterownik wykrywa kartę.

nvidia-smi

Celem jest uzyskanie tabeli zawierającej nazwę GPU, wersję sterownika oraz wykorzystanie pamięci w stosunku do całkowitej dostępnej pojemności. Komunikat NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver oznacza brak sterownika lub niepowodzenie przebudowania modułu jądra po aktualizacji systemu. W standardowym obrazie Ubuntu rozwiązaniem jest zazwyczaj sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, a następnie restart systemu w celu załadowania nowego modułu.

W przypadku kontenerów sam sterownik jest niewystarczający. Docker wymaga narzędzia 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 zweryfikować, 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. Komunikat docker: Error response from daemon: could not select device driver, wskazujący na niespełnioną zdolność GPU, oznacza, że zestaw narzędzi jest zainstalowany, ale Docker nie został ponownie skonfigurowany lub zrestartowany. W takim przypadku należy ponownie wykonać polecenie nvidia-ctk i zrestartować usługę. W pliku Compose odpowiednikiem jest wpis deploy.resources.reservations.devices, którego driver to nvidia, a lista możliwości zawiera gpu. Element ten umieszcza się w standardowych definicjach 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 kosztują kilkukrotnie więcej niż porównywalne instancje CPU i są rozliczane za każdą godzinę działania, a nie za wygenerowane tokeny. Utrzymywanie stale działającego GPU do obsługi kilku zapytań dziennie jest najdroższym możliwym sposobem uruchamiania inferencji. Punktem równowagi jest stopień wykorzystania: obciążone GPU jest tanie w przeliczeniu na token, natomiast bezczynne generuje wyłącznie straty.

Skuteczne są trzy uczciwe wzorce postępowania. Stałe zadania o niskim wolumenie należy utrzymywać na VPS z procesorem CPU. Sporadyczne, wymagające zapytania warto kierować do zewnętrznego API, płacąc za każdy token. GPU należy wynajmować godzinowo wyłącznie do zadań wsadowych, dostrajania modeli lub masowego generowania embeddingów, a po zakończeniu pracy usuwać instancję. Łączenie tych metod jest standardem, a dyscyplina budżetowa opisana w kontrola kosztów agentów AI na stale działającym VPS ma tu również zastosowanie, z tą różnicą, że źródłem strat jest czas bezczynności, a nie liczba tokenów.

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 6 GB dla 4-bitowego skwantyzowanego modelu 8B przy standardowym kontekście od 8k do 16k. Wagi zajmują około 4,7 GB, reszta to pamięć podręczna KV oraz około 1 GB narzutu. Karta 12 GB zapewnia wystarczający zapas dla dłuższych kontekstów. W przypadku planowania pracy z kontekstem 128k należy osobno oszacować rozmiar pamięci podręcznej, ponieważ może ona przekroczyć rozmiar wag modelu.

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 oczekiwać wydajnoś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 jest wartością zbliżoną do tempa czytania dla jednego użytkownika. Długie prompty stanowią główny problem w przypadku CPU, ponieważ przetwarzanie 30 000 tokenów kontekstu jest ograniczone mocą obliczeniową i trwa znacznie dłużej niż generowanie odpowiedzi.

Dlaczego moje GPU jest niewiele szybsze od 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ń. Uruchom ollama ps i sprawdź, czy kolumna PROCESSOR wskazuje 100% GPU. Jeśli widoczny jest podział, należy użyć mniejszej kwantyzacji lub mniejszego modelu. Inna częsta przyczyna to krótki benchmark, w którym czas ładowania modelu dominuje nad wynikiem pomiaru.

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

Zazwyczaj nie. Jedna osoba czyta z prędkością 5 do 10 słów na sekundę, a serwer z samym CPU generuje tokeny szybciej niż to tempo dla modeli o rozmiarze do około 13B. 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 obsłużyć dwadzieścia żądań w cenie zbliżonej do kosztu obsługi jednego.

Czy lepiej wynajmować GPU godzinowo, czy utrzymywać instancję stale uruchomioną?

Wynajmuj godzinowo, gdy praca ma charakter skokowy: dostrajanie, masowe przetwarzanie embeddingów lub wsadowa transkrypcja. Utrzymuj instancję stale uruchomioną tylko wtedy, gdy karta jest stale obciążona, ponieważ instancja GPU jest rozliczana za czas istnienia, a nie za wygenerowane tokeny. Asystent o niskim natężeniu ruchu jest tańszy na VPS z CPU lub w modelu API płatnym za token, niż na bezczynnym GPU.