GPU wykonuje obliczenia modelu, ale aplikacja nadal potrzebuje procesora. Trzeba przyjąć zapytanie, przygotować dane, uruchamiać kolejne etapy i wysłać odpowiedź. Obok modelu mogą działać także wyszukiwanie dokumentów, baza danych czy logika Twojej aplikacji.
Dlatego „model mieści się na GPU” nie oznacza „CPU nie ma nic do zrobienia”. Z drugiej strony wysoki odczyt procentowy pojedynczego procesu nie musi oznaczać, że cały serwer jest przeciążony.
Co zarejestrowaliśmy przy Qwen3-8B
W obu krótkich scenariuszach proces llama-server zużywał średnio czas odpowiadający około jednemu logicznemu CPU, czyli około 3,1% sumy czasu dostępnego na 32 wątkach sprzętowych. To obserwacja procesu obsługującego model na GPU, nie test minimalnej liczby rdzeni potrzebnej do wdrożenia.
| Scenariusz | CPU procesu: 100% = 1 logiczny CPU | Udział czasu całej maszyny | Mierzone rundy |
|---|---|---|---|
| Wejście 2048 tokenów, 1 zapytanie naraz | 99,67% | 3,11% | 3 |
| Wejście 8192 tokeny, 4 zapytania naraz | 100,27% | 3,13% | 3 |
Podajemy średnią arytmetyczną z trzech rund. W pierwszym scenariuszu odczyty procesu wynosiły 99,42–100,15%, a w drugim 100,19–100,40%. Licznik obejmuje czas całego procesu, nie tylko przygotowanie tekstu; nie rozdzielamy tu obliczeń, obsługi sterownika i aktywnego oczekiwania. Nie ograniczaliśmy liczby dostępnych CPU, więc z tych wyników nie wynika, że przydzielenie jednego wątku zachowałoby tę samą szybkość.
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 |
| Model i silnik | Qwen3-8B Q4_K_M, llama.cpp b11146; 16 wątków silnika, model na GPU |
Po rozgrzewce wykonaliśmy po trzy rundy z 256 nowymi tokenami na odpowiedź. API działało lokalnie, miało cztery sloty po 8704 tokeny, KV cache F16 i Flash Attention; cache promptu był wyłączony. Przed każdym scenariuszem GPU schładzało się do najwyżej 40°C.
Czas CPU pobieraliśmy z /proc na początku i końcu każdej rundy. Dodatkowe odczyty pamięci i GPU wykonywaliśmy co około dwie sekundy. Systemowy cache modelu był ciepły po sprawdzeniu sumy pliku. Wyniki nie obejmują bazy dokumentów ani innych składników aplikacji RAG. Pełne rundy i ustawienia są w JSON; dodatkowa telemetria odróżnia ten pomiar od wcześniejszego benchmarku szybkości.
Jedno GPU, kilka rodzajów pracy procesora
Rozdziel dwa przypadki. W pierwszym warstwy modelu są na GPU, a CPU obsługuje otaczającą je aplikację. W drugim część modelu celowo zostaje po stronie CPU — wtedy procesor bierze udział także w obliczeniach modelu.
llama.cpp pozwala osobno ustawiać liczbę wątków generowania, przetwarzania wejścia i obsługi HTTP, a także liczbę warstw na GPU. Opisuje to dokumentacja użytej rewizji llama-server. Sam parametr wątków nie gwarantuje, że proces będzie stale zajmował tyle rdzeni.
Dlaczego CPU może pokazywać ponad 100%
Są dwie przydatne skale. W skali procesu 100% odpowiada czasowi jednego logicznego CPU; praca wielu wątków może przekroczyć 100%. W skali całej maszyny 100% oznacza sumę dostępnego czasu wszystkich logicznych CPU.
Nasz EPYC 4565P udostępnia 32 wątki sprzętowe. Przeliczając odczyt procesu na udział całej maszyny, dzielimy go przez 32. Nie nazywamy jednak tego liczbą zajętych rdzeni fizycznych: wątki sprzętowe współdzielą zasoby, a system może przenosić zadania między nimi.
Obciążenie liczymy z przyrostu czasu CPU w określonym oknie, nie z pojedynczej migawki. Linux udostępnia liczniki procesu i całego systemu przez interfejs /proc. Tak można zestawić tę samą rundę zapytań z jej czasem odpowiedzi.
Jak rozpoznać, że warto przyjrzeć się CPU
Sprawdzaj kilka sygnałów razem. Jeżeli rośnie czas oczekiwania na odpowiedź, GPU ma przestoje, a jeden lub kilka wątków aplikacji pracuje intensywnie, warto zbadać etap wykonywany po stronie CPU. Przyczyną może być także odczyt danych lub oczekiwanie na inną usługę, więc sam procent CPU nie daje rozstrzygnięcia.
W aplikacji z dokumentami oddziel czas wyszukiwania i przygotowania kontekstu od pracy silnika LLM. Test samego modelu nie mierzy parsera PDF, bazy wektorowej ani zapytań do zewnętrznego API.
Jak dobierać liczbę wątków
Zacznij od działającej konfiguracji i zmieniaj jeden parametr naraz. Dla tego samego zestawu zapytań zapisuj czas pierwszego tokena, czas odpowiedzi i użycie CPU. Więcej wątków nie jest celem samym w sobie — liczy się sprawniejsza aplikacja i pozostawienie zasobów pozostałym usługom.
Jeśli wszystkie składniki działają na jednej maszynie, uwzględnij je w końcowym teście. Dobre wyniki samotnego procesu LLM są punktem wyjścia, a nie pomiarem całego rozwiązania.
Zobacz również RAM i pamięć podręczną serwera LLM oraz wpływ kontekstu i równoległości na API.
Sprawdź konfigurację serwera lub opisz aplikację, którą chcesz na nim uruchomić.