VPS z GPU czy CPU? Kiedy warto wybrać GPU

Czy potrzebujesz VPS z GPU, czy wystarczy CPU?

VPS z GPU wpływa na dwie kwestie związane z samodzielnym uruchamianiem modelu: szybkość generowania tokenów oraz maksymalny rozmiar modelu, który mieści się w pamięci. Nie zmienia niczego więcej. Jeśli obciążenie obejmuje skwantyzowany model czatowy od 7B do 27B, odpowiadający jednej osobie naraz, zadanie generowania embeddingów o małej intensywności albo transkrypcję mowy za pomocą Whisper small, zwykły VPS z CPU i wystarczającą ilością pamięci RAM już wystarczy. Należy rozpocząć od CPU, zmierzyć parametr, który powoduje problemy, a następnie zwiększyć zasoby.

Przyczyną jest przepustowość pamięci. Podczas generowania jednego tokenu model językowy odczytuje z pamięci wszystkie potrzebne wagi. Model 8B skwantyzowany do 4 bitów zajmuje około 4.7 GB na dysku i mniej więcej tyle samo w pamięci, więc wygenerowanie tokenu wymaga przeniesienia około 4.7 GB danych. Po podzieleniu przepustowości pamięci maszyny przez tę wartość otrzymuje się maksymalną teoretyczną liczbę tokenów na sekundę. To pojedyncze działanie wyjaśnia niemal każdy test wydajności, który można znaleźć.

Co GPU faktycznie zapewnia

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

Pojemność połączona z szybkością. Serwer z CPU i 64 GB pamięci RAM może załadować model 70B przy 4 bitach. Model będzie działać, ale w tempie bliższym czytaniu niż rozmowie. GPU pomaga w tym przypadku tylko wtedy, gdy model mieści się w pamięci VRAM, ponieważ po przeniesieniu warstw do systemowej pamięci RAM ponownie obowiązuje wolniejsza ścieżka przetwarzania.

Przepustowość przy przetwarzaniu wsadowym. Ten aspekt jest często niedoszacowany. GPU generujące odpowiedź dla jednego użytkownika pozostawia większość mocy obliczeniowej niewykorzystaną, ponieważ oczekuje na dane z pamięci. Obsługa 20 żądań jednocześnie pozwala wykorzystać ten sam odczyt wag dla wszystkich 20 żądań. Łączna liczba tokenów generowanych na sekundę wzrasta kilkukrotnie, a szybkość dla pojedynczego użytkownika spada nieznacznie. CPU nie działa w ten sposób. Dwóch użytkowników korzystających jednocześnie z serwera CPU dzieli jego wydajność mniej więcej po połowie. W przypadku budowy API wywoływanego przez wielu klientów przetwarzanie wsadowe jest argumentem przemawiającym za użyciem GPU, ważniejszym niż surowa szybkość obsługi pojedynczego strumienia.

Przetwarzanie promptu. Odczytywanie długiego promptu jest ograniczone mocą obliczeniową, a nie przepustowością pamięci. W tym obszarze przewaga GPU jest największa. Kontekst o długości 30,000 tokenów, który CPU przetwarza przez minutę, na GPU jest przetwarzany w kilka sekund. Konfiguracje RAG, które dołączają dokumenty do każdego żądania, stale odczuwają tę różnicę.

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

Poniżej przedstawiono typowe opublikowane wartości dla pojedynczego strumienia dla modelu 8B z kwantyzacją 4-bitową, aktualne w lipcu 2026. Są to dane orientacyjne określające rząd wielkości, a nie gwarantowane wartości. Zastosowana kwantyzacja, długość kontekstu i silnik wnioskowania mogą je zmienić.

[
  {
    "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 dotyczący GPU z 24 GB pamięci pokazuje 50 tokenów na sekundę w porównaniu z wartością 11 dla komputera z procesorem i pamięcią DDR5. To około pięciokrotnie więcej. Odpowiada to raczej stosunkowi przepustowości niż różnicy w surowej mocy obliczeniowej. Rzeczywista przepustowość jest również niższa niż iloraz przepustowości pamięci i rozmiaru modelu, ponieważ przetwarzanie uwagi dla rosnącego kontekstu wymaga dodatkowych operacji, których nie uwzględnia ten prosty iloraz.

Dla porównania człowiek czyta około 5 do 10 słów na sekundę. Wartość 15 tokenów na sekundę lub większa jest dla pojedynczego czytelnika odczuwana jako tempo zwykłego pisania. Dlatego wiele konfiguracji działających wyłącznie na CPU jest wystarczająco wydajnych.

Określanie wymaganej pamięci VRAM przed zakupem

Rozmiar pliku modelu wyznacza minimum, a nie rzeczywiste wymagania. Należy uwzględnić wagi, pamięć podręczną KV (key-value cache, pamięć na tokeny utrzymywana przez mechanizm attention) oraz około 1 GB narzutu.

Praktyczna zasada obowiązująca w lipcu 2026: należy przyjąć 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 przy 4 bitach zajmuje około 16 GB i wymaga około 20 GB. Model 70B przy 4 bitach zajmuje około 40 GB i wymaga karty 48 GB albo dwóch mniejszych kart.

Długie konteksty powodują, że ta zasada przestaje obowiązywać. Pamięć podręczna KV rośnie liniowo wraz z długością kontekstu, a przy 128k tokenach może przekroczyć rozmiar samych wag. W przypadku planowanego użycia długich kontekstów należy najpierw określić wymagany rozmiar pamięci podręcznej i sprawdzić, jakie funkcje kwantyzacji pamięci podręcznej oferuje używany silnik.

Sprawdzenie, co faktycznie znajduje się na maszynie

W przypadku instancji GPU najpierw należy potwierdzić, że sterownik wykrywa kartę.

nvidia-smi

Powinna zostać wyświetlona tabela zawierająca nazwę GPU, wersję sterownika oraz ilość używanej pamięci w odniesieniu do całkowitej pojemności. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver oznacza brak sterownika albo brak ponownej kompilacji modułu jądra po aktualizacji jądra. W standardowym obrazie Ubuntu rozwiązaniem jest zazwyczaj sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, a następnie ponowne uruchomienie systemu, aby załadować nowy moduł.

W przypadku kontenerów sam sterownik nie wystarcza. Docker wymaga NVIDIA Container Toolkit, aby przekazywać urządzenie do 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 potwierdzić działanie przekazywania urządzenia z poziomu kontenera:

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

Powinna zostać wyświetlona ta sama tabela. Wiersz docker: Error response from daemon: could not select device driver, zawierający nazwę funkcji GPU, której nie można spełnić, oznacza, że zestaw narzędzi jest zainstalowany, ale Docker nie został ponownie skonfigurowany lub uruchomiony. Należy ponownie wykonać wiersz nvidia-ctk i polecenie ponownego uruchomienia. W Compose odpowiednikiem jest wpis deploy.resources.reservations.devices, którego wartość driver to nvidia, a lista możliwości zawiera gpu. Taki wpis można dodać do standardowych definicji usług opisanych w Docker Compose na VPS.

Wykonaj pomiary przed modernizacją

Uruchom model, który ma być faktycznie używany, na posiadanym komputerze z procesorem CPU i zapisz wyniki. W przypadku samodzielnego hostowania LLM w Ollama na VPS wystarczy jeden przełącznik:

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

Dane wyjściowe kończą się informacjami o czasach. eval rate oznacza szybkość generowania, wyrażoną w tokenach na sekundę. prompt eval rate oznacza szybkość odczytu danych wejściowych przez komputer. Te dwie wartości wskazują, która modernizacja będzie pomocna: niska wartość eval rate oznacza problem z przepustowością pamięci, a niska wartość prompt eval rate przy długich danych wejściowych oznacza problem z mocą obliczeniową.

Na komputerze wyposażonym w GPU sprawdź, czy model rzeczywiście został załadowany do pamięci GPU:

ollama ps

Kolumna PROCESSOR zawiera wartość 100% GPU, gdy cały model mieści się w pamięci, lub wartość podobną do 43%/57% CPU/GPU, gdy tak nie jest. Częściowy podział modelu zwykle zapewnia gorszą wydajność, niż można oczekiwać, ponieważ każdy token nadal musi oczekiwać na wolniejszą część.

Kwestia kosztów

Instancje GPU kosztują kilka razy więcej niż porównywalne instancje CPU. Opłaty są naliczane za każdą godzinę ich działania, a nie za liczbę wygenerowanych tokenów. Zawsze działająca instancja GPU obsługująca kilka żądań dziennie to najdroższy sposób uruchamiania wnioskowania. Punkt opłacalności zależy od wykorzystania: zajęty GPU zapewnia niski koszt tokenu, a bezczynny GPU oznacza wyłącznie straty.

Sprawdzają się trzy praktyczne modele. Stałe zadania o małym wolumenie należy wykonywać na VPS z CPU. Sporadyczne, wymagające żądania można kierować do hostowanego API i płacić za tokeny. GPU można wynajmować na godziny do zadań wsadowych, dostrajania lub masowego generowania embeddingów, a następnie je usuwać. Łączenie tych modeli jest typowe. Opisana w kontrola kosztów agenta AI na zawsze działającym VPS dyscyplina budżetowa ma tu również zastosowanie, z tą różnicą, że źródłem strat jest czas bezczynności, a nie liczba tokenów.

Co nadal działa poprawnie bez GPU

Generowanie embeddingów przy małej liczbie danych. Niewielki model embeddingowy przetwarza setki krótkich dokumentów na minutę, korzystając z kilku rdzeni CPU. Indeks tworzony jednorazowo nie musi być generowany szybko.

Modele Whisper small i base do transkrypcji. Faster-whisper na CPU wykonuje transkrypcję w czasie zbliżonym do rzeczywistego dla modelu small. Wystarcza to w przypadku potoku uruchamianego przez noc.

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

Wszystko, co można uznać za zadanie wsadowe. Jeśli nikt nie obserwuje ekranu, czas wykonania jest kwestią harmonogramowania, a nie wymaganiem.

GPU jest rzeczywiście potrzebne do trenowania lub dostrajania wykraczającego poza użycie małego adaptera, obsługi wielu równoczesnych użytkowników, generowania obrazów i wideo oraz przetwarzania mowy w czasie rzeczywistym, gdy opóźnienie jest kluczowym elementem usługi.

FAQ

Ile VRAM jest potrzebne dla modelu 7B lub 8B?

Około 6 GB dla skwantyzowanego do 4 bitów modelu 8B przy typowym kontekście od 8k do 16k. Wagi zajmują około 4.7 GB, a pozostałe miejsce zajmują pamięć podręczna KV oraz około 1 GB narzutu. Karta o pojemności 12 GB zapewnia odpowiedni zapas dla dłuższych kontekstów. W przypadku planowanego kontekstu 128k należy osobno uwzględnić rozmiar pamięci podręcznej, ponieważ może ona stać się większa niż wagi.

Czy można uruchomić Ollama bez GPU?

Tak. Ollama automatycznie przełącza się na CPU i wymaga tylko ilości pamięci RAM wystarczającej do przechowania modelu. Dla skwantyzowanego do 4 bitów modelu 8B należy oczekiwać około 5 do 12 tokenów na sekundę, zależnie od szybkości pamięci. Dla jednego użytkownika jest to zbliżone do tempa czytania. Długie prompty stanowią główne ograniczenie na CPU, ponieważ przetwarzanie kontekstu zawierającego 30,000 tokenów jest ograniczone wydajnością obliczeniową i trwa znacznie dłużej niż generowanie odpowiedzi.

Dlaczego GPU jest niewiele szybsze niż CPU?

Najczęstszą przyczyną jest to, że model nie mieści się w całości w VRAM. Wtedy niektóre warstwy są uruchamiane na CPU, a wygenerowanie każdego tokenu wymaga oczekiwania na wolniejszą część. Należy uruchomić ollama ps i sprawdzić, czy kolumna PROCESSOR zawiera wartość 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 wczytywania modelu dominuje nad pomiarem.

Czy VPS z GPU jest opłacalny dla jednego użytkownika?

Zwykle nie. Jedna osoba czyta z szybkością od 5 do 10 słów na sekundę, a serwer CPU już generuje tokeny szybciej dla modeli do około 13B. Przypadki uzasadniające koszt dla jednego użytkownika to długie prompty, generowanie obrazów i dostrajanie modelu. Najsilniejszym argumentem jest jednoczesna obsługa wielu użytkowników, ponieważ przetwarzanie wsadowe pozwala jednemu GPU obsłużyć dwadzieścia żądań za koszt zbliżony do obsługi jednego żądania.

Czy należy wynajmować GPU na godziny, czy uruchamiać je stale?

GPU należy wynajmować na godziny, gdy obciążenie występuje okresowo, na przykład podczas dostrajania modelu, zbiorczego generowania embeddingów lub wsadowej transkrypcji. Stałe uruchomienie jest uzasadnione tylko wtedy, gdy karta jest intensywnie używana, ponieważ instancja GPU jest rozliczana za czas działania, a nie za liczbę wygenerowanych tokenów. Asystent o małym ruchu jest tańszy na VPS z CPU lub w hostowanym API rozliczanym za tokeny niż na bezczynnym GPU.