Karta graficzna i procesor mają różne zadania w aplikacji AI. GPU może wykonywać obliczenia modelu, a CPU obsługiwać wyszukiwanie dokumentów, bazę danych i import plików. Sprawdzamy, jak zmienia się obciążenie procesora, gdy model pracuje na karcie lub część jego pracy trafia do CPU i RAM. Obok procentów pokazujemy czas oczekiwania na odpowiedź.
W serii CORE 1.1 zestawiamy modele 8B, 32B i 72B umieszczone na GPU oraz ten sam model 72B z częścią obliczeń przeniesioną na CPU i RAM. Wspólna metodyka testów LLM ustala jednakowe długości wejścia i odpowiedzi, rozgrzewkę oraz liczbę pomiarów. Dzięki temu przy modelu 72B można porównać koszt zmiany sposobu pracy bez jednoczesnej zmiany modelu.
CPU, GPU i czas odpowiedzi w jednym porównaniu
Litera B w nazwie modelu oznacza miliardy parametrów, a nie gigabajty. Q4_K_M jest oszczędniejszym sposobem ich zapisu; te oznaczenia wyjaśnia słownik AI i GPU.
Poniższe zestawienie dotyczy jednego zapytania naraz: 2048 tokenów wejścia i 256 tokenów odpowiedzi. Tokeny to fragmenty słów i znaków, które przetwarza model. Każda konfiguracja ma pięć mierzonych rund po osobnej rozgrzewce. Czas odpowiedzi jest środkowym wynikiem tych pięciu prób.
W kolumnie CPU 100% oznacza wykorzystanie łącznego czasu wszystkich 32 wątków sprzętowych serwera, nie jednego rdzenia. Mierzymy udział programu obsługującego model; pozostałe usługi nie są częścią tego odczytu.
| Model, format i rozmieszczenie | CPU procesu względem całego serwera | Wykorzystanie GPU, średnia próbek | Cała odpowiedź, mediana |
|---|---|---|---|
| Qwen3-8B Q4_K_M — Model na GPU | 3,1 % | 94,2 % | 1,5 s |
| Qwen3-32B Q4_K_M — Model na GPU | 3,1 % | 99,0 % | 5,5 s |
| Qwen2.5-72B-Instruct Q4_K_M — Model na GPU | 3,1 % | 100,0 % | 11,6 s |
| Qwen2.5-72B-Instruct Q4_K_M — GPU + CPU: mniejsze zajęcie VRAM | 47,0 % | 5,8 % | 249,2 s |
| Qwen2.5-72B-Instruct Q4_K_M — GPU + CPU: jeszcze mniejsze zajęcie VRAM | 47,5 % | 5,9 % | 363,5 s |
Przy trzech modelach działających na GPU proces obsługi modelu wykorzystywał średnio 3,1% łącznego czasu CPU serwera. Dla tego samego modelu 72B przeniesienie części pracy na CPU podniosło ten udział do 47,0–47,5%, a typowy czas odpowiedzi z 11,6 s do 249,2 s lub 363,5 s. Pozostawienie modelu na GPU dało więc krótsze oczekiwanie i mniejsze obciążenie procesora — korzystny punkt wyjścia do sprawdzenia dodatkowych usług aplikacji.
Obciążenie CPU w tabeli dotyczy procesu obsługującego model, a nie wszystkich programów na serwerze. Odczyt GPU pokazuje osobno aktywność karty podczas obsługi mierzonych zapytań. Żaden z tych procentów sam nie mówi, ile osób można obsłużyć: istotne jest również, jak długo pojedyncze zadanie zajmuje zasoby.
Co procesor robi przed odpowiedzią modelu?
Wyobraź sobie pracownika pytającego asystenta o zasady reklamacji. Model nie musi otrzymać od razu całej bazy dokumentów. Aplikacja najpierw sprawdza dostęp użytkownika, odnajduje właściwy dokument, wybiera fragmenty i przygotowuje tekst zapytania. Dopiero potem wysyła go do programu uruchamiającego model. Po odpowiedzi może jeszcze sprawdzić format danych i zapisać wynik.
Wiele z tych czynności angażuje procesor, pamięć lub bazę danych. Jeśli do systemu właśnie trafia nowa paczka PDF-ów, dochodzi także ich odczyt i przygotowanie do wyszukiwania. To przykład przepływu pracy, nie dodatkowy zmierzony scenariusz. Pokazuje jednak, dlaczego do wyboru serwera nie wystarcza sam wynik generowania tekstu na GPU.
W praktyce warto rozdzielić dwa pytania: ile CPU potrzebuje obsługa modelu oraz ile potrzebują usługi, które dostarczają mu zadania? Nasz pomiar odpowiada na pierwsze z nich w podanej konfiguracji. Zapas dla drugiego należy ocenić na własnej aplikacji.
Jaką skalę mają procenty CPU?
W tym artykule 100% CPU oznacza łączny czas wszystkich 32 wątków sprzętowych serwera. Niektóre narzędzia systemowe używają innej skali, w której 100% odpowiada jednemu logicznemu CPU. Dla przykładu taki odczyt trzeba tu podzielić przez 32: daje około 3,1% w skali całej maszyny. To wyjaśnienie sposobu liczenia, nie osobny wynik testu.
Nie znaczy to, że program przez cały czas zajmował jeden fizyczny rdzeń. Wątki mogą wykonywać się na różnych rdzeniach, a średnia ukrywa krótsze zmiany obciążenia. Nie wynika z niej też, że ograniczenie programu do jednego wątku zachowałoby szybkość — takiego eksperymentu nie wykonaliśmy.
Odczyt CPU najlepiej zestawiać z czasem odpowiedzi. Jeżeli użytkownik czeka coraz dłużej, warto sprawdzić, czy zadanie czeka na przygotowanie dokumentu, dostęp do bazy czy wolne miejsce w kolejce modelu. Niski średni odczyt całego serwera sam nie wyklucza opóźnienia w jednym z tych etapów.
Kiedy CPU zaczyna wykonywać obliczenia samego modelu?
Inaczej wygląda sytuacja, gdy część modelu pracuje na CPU z pamięcią RAM. Taki podział nazywamy offloadem. Procesor nie tylko przygotowuje wtedy zadania, ale bierze udział w tworzeniu odpowiedzi.
W osobnym porównaniu modelu 72B na GPU i z udziałem RAM przyglądamy się właśnie temu kompromisowi. Mniejsze zajęcie pamięci karty może oznaczać dłuższe oczekiwanie na wynik. Dlatego w tabeli obok CPU jest czas odpowiedzi: wykorzystanie dodatkowych zasobów ma sens, jeśli pozwala wykonać potrzebne zadanie w akceptowalnym czasie.
Przykładem jest opracowanie dokumentów w kolejce nocnej. Dłuższe pojedyncze zadanie może być dopuszczalne, jeżeli wyniki mają być gotowe rano. W interaktywnym asystencie priorytet bywa odwrotny: użytkownik chce zobaczyć odpowiedź szybko. To przykłady zastosowań, nie dodatkowe zmierzone scenariusze. Dobór wymaga sprawdzenia własnej kolejki zadań i oczekiwanego czasu obsługi.
Jak wykorzystać wynik przy planowaniu aplikacji?
Zacznij od prostego przepływu z rzeczywistym zapytaniem. Sprawdź odpowiedź modelu bez pozostałych usług, następnie dodaj wyszukiwanie dokumentów i kontrolę wyniku. Na końcu uruchom typową pracę w tle, na przykład import plików. Porównuj czas oczekiwania oraz obciążenie procesu i całego hosta w tych samych przedziałach.
Wniosek: patrz na CPU jako część całej usługi. Jeśli model pozostawia zapas, można ocenić wykorzystanie go przez wyszukiwanie i inne zadania. Jeśli sam model angażuje procesor, usługi działające obok muszą dzielić z nim zasoby. Pomiar daje punkt odniesienia do tych decyzji, nie gotowy limit liczby użytkowników.
Poradnik o RAM uzupełnia ten obraz, a słownik AI i GPU wyjaśnia pojęcia. Sprawdź konfigurację serwera lub opisz swoją aplikację.
Szczegóły techniczne
Zakres bieżącej serii
Aktualne wyniki pochodzą z gsh-llm-core/1.1. Tabela główna wybiera scenariusz 2048 tokenów wejścia, 256 tokenów wyjścia, C1 i jeden slot. Warianty GPU obejmują Qwen3-8B Q4_K_M, Qwen3-32B Q4_K_M i Qwen2.5-72B-Instruct Q4_K_M. Dwa warianty częściowego przeniesienia obliczeń używają tego samego modelu 72B, rewizji i kwantyzacji. Różni się liczba warstw przeniesionych na GPU; dokładne ustawienia pozostają w danych do pobrania.
Porównanie różnych modeli jest zestawieniem konfiguracji, nie izolowanym testem wpływu ich wielkości ani jakości odpowiedzi. Testy szybkości API opisują także dłuższe wejście i obsługę kilku zapytań.
Sprzęt i sposób pomiaru
| Element | Konfiguracja pomiaru |
|---|---|
| CPU | AMD EPYC 4565P, 16 rdzeni / 32 wątki |
| GPU | RTX PRO 6000 Blackwell Max-Q Workstation Edition, 96 GB VRAM |
| RAM systemowy | 96 GB |
| System i sterownik | Rocky Linux 10.2, NVIDIA 595.91.07 |
| Silnik | llama.cpp b11146, 16 wątków silnika |
Wspólne ustawienia obejmują jedną pełną rundę rozgrzewki i pięć rund pomiarowych dla każdej długości wejścia. Lokalne API ma kontekst 8704 tokenów, KV cache F16 i Flash Attention. Używamy mmap, bez lazy loading, bez automatycznego dopasowania i bez cache promptu. Sprawdzenie sum plików poprzedza ładowanie; nie opisujemy startu jako zimnego ani nie przypisujemy całego cache jednemu modelowi.
Liczniki i okna pomiarowe
Czas CPU procesu pochodzi z przyrostu liczników /proc między migawkami bezpośrednio przed rundą i po niej. Średni udział wyznaczamy z sumy czasu CPU podzielonej przez sumę długości tych okien i liczbę logicznych CPU. Jest to średnia ważona czasem, a nie średnia dowolnie wybranych odczytów. Licznik obejmuje cały proces: nie rozdziela obliczeń, obsługi sterownika i aktywnego oczekiwania. Nie ograniczaliśmy procesu do jednego rdzenia.
Średnia aktywność GPU pochodzi z próbek wewnątrz przedziałów ukończonych odpowiedzi. Jej okno różni się nieznacznie od migawek CPU obejmujących rundę. Czas odpowiedzi kończy się na zdarzeniu zakończenia generowania; nie jest samym czasem pracy CPU ani GPU. Próbkowanie odbywa się nominalnie co sekundę, a eksport podaje liczbę odczytów i największą przerwę. Linux opisuje liczniki procesu i systemu w dokumentacji /proc.
Dane bieżące i archiwum
Pliki core-v1-results.json, core-v1-results.csv i core-v1-chart.json opisują bieżącą serię. Wcześniejsze results.json, results.csv i chart.json pozostają dostępne w archiwum danych poniżej, bez zmian w ich zawartości. Nie łączymy dawnych trzech powtórzeń ani innej konfiguracji slotów z pięcioma rundami CORE.