Dobry test powinien pomóc odpowiedzieć na proste pytanie: czy ten serwer i model nadają się do mojego zadania? Ktoś budujący asystenta oczekuje sprawnej rozmowy. Osoba przetwarzająca dokumenty może poczekać dłużej, ale potrzebuje poprawnego wyniku. Dlatego sama liczba tokenów na sekundę nie wystarcza do oceny całego rozwiązania.
Ten artykuł zbiera wspólne zasady naszych pomiarów LLM, czyli modeli pracujących z językiem. Wyjaśnia, co mierzymy, jak porównujemy konfiguracje i gdzie kończą się wnioski z danego testu. Materiały przygotowuje GPU Server Hub / Bestconnect, dostawca opisywanej usługi.
Wspólny standard CORE 1.1 obejmuje przygotowanie, wykonanie i sprawdzenie testu. Stosujemy te same zasady w artykułach o szybkości, pamięci i pracy kilku zapytań naraz. Każdy wynik ma opis warunków oraz dostępne dane pomiarowe.
Zaczynamy od pytania, nie od listy parametrów
Przed pomiarem ustalamy, czego chcemy się dowiedzieć. Może chodzić o czas odpowiedzi jednej osobie, obsługę kilku pytań naraz albo uruchomienie modelu większego niż pamięć karty. Te zadania wymagają różnych prób, ale obowiązują je wspólne zasady: zapisane ustawienia, powtarzalne dane wejściowe i jasno określony sposób oceny.
Przy porównaniu sprzętu lub podziału pracy między GPU i procesor zachowujemy ten sam model oraz jego format. Gdy zmieniamy również model, odpowiadamy już na inne pytanie: porównujemy kompletne konfiguracje. Większy model może pracować inaczej i dawać inne odpowiedzi. Sam rozmiar nie jest oceną jakości.
Jak długo czeka się na odpowiedź?
Oddzielamy początek odpowiedzi od jej ukończenia. W rozmowie użytkownik może zacząć czytać, zanim model skończy pisać. Program pobierający dane z dokumentu zwykle musi zaczekać na cały wynik. Oba czasy są potrzebne, lecz opisują inne doświadczenie.
Niektóre modele wykonują dodatkowe obliczenia, zanim pokażą właściwą odpowiedź. W zadaniach praktycznych liczymy czas do pierwszego widocznego tekstu odpowiedzi końcowej. W teście obliczeniowym możemy mierzyć pierwszy wygenerowany fragment, nazywany tokenem. Nie przedstawiamy tych odczytów jako tej samej miary.
Podstawowy test szybkości korzysta z wejścia liczącego 2048 albo 8192 tokeny i odpowiedzi długości 256 tokenów. Token jest fragmentem tekstu, nie zawsze całym słowem. Stała długość zapobiega porównywaniu jednego zdania z całą stroną. To kontrolowana próba obliczeń; osobno sprawdzamy zwykłe zadania, w których model może zakończyć odpowiedź wcześniej.
Wynik mierzony wewnątrz serwera nie zawiera opóźnienia połączenia klienta przez Internet. Jeżeli później badamy całą aplikację, podajemy również miejsce połączenia i elementy znajdujące się po drodze.
Co zmienia kilka jednoczesnych pytań?
Serwer może wykonać łącznie więcej pracy, obsługując kilka zapytań naraz, choć pojedyncza osoba poczeka wtedy dłużej. Dlatego pokazujemy osobno czas odpowiedzi użytkownika i łączną pracę wykonaną przez serwer. Cztery zapytania w teście nie oznaczają limitu czterech zarejestrowanych osób.
To rozróżnienie przydaje się przy planowaniu firmowego asystenta. Kilkadziesiąt osób z dostępem do aplikacji nie musi korzystać z niej w tej samej sekundzie. Do doboru konfiguracji potrzebna jest wiedza o jednoczesnych zadaniach, długości dokumentów i dopuszczalnym oczekiwaniu. Nie wyliczamy liczby obsługiwanych pracowników wyłącznie z szybkości generowania tekstu.
Porównujemy jedno i cztery jednoczesne pytania. Dodajemy także próbę kontrolną: cztery miejsca obsługi są zarezerwowane, ale pracuje tylko jedno. Dzięki temu można oddzielić wpływ samej rezerwacji pamięci od wpływu dodatkowych zapytań. Szczegółowe ustawienia wszystkich trzech wariantów znajdują się niżej.
Co oznacza, że model mieści się w pamięci?
Samo otwarcie pliku modelu to początek. Model musi jeszcze przyjąć tekst i ukończyć odpowiedź. Sprawdzamy więc działanie przy określonej długości wejścia oraz liczbie równoczesnych zadań. Wynik dotyczy tego zestawu, a nie dowolnie długiej rozmowy.
VRAM jest pamięcią karty, a RAM pamięcią całego serwera. Oddzielnie opisujemy zużycie podczas ładowania i podczas odpowiedzi. Program może potrzebować więcej miejsca przy starcie niż później. Z kolei pamięć samego procesu nie obejmuje wszystkich potrzeb systemu i aplikacji pracujących obok.
Jeżeli część pracy wykonuje CPU z RAM, pokazujemy równocześnie korzyść pamięciową i zmianę czasu odpowiedzi. Dla odbiorcy ważne jest, co daje taki podział. Liczba warstw modelu przypisanych do karty pozostaje szczegółem odtworzenia konkretnej próby; nie jest procentem całej pamięci.
Czy odpowiedź jest przydatna i poprawna?
Szybki wynik może być bezużyteczny, jeśli zawiera błędne dane. Dlatego korzystamy ze stałego zestawu 24 krótkich zadań, po 12 w języku polskim i angielskim. Obejmują obliczenia, odczytywanie informacji, stosowanie podanej reguły i odpowiadanie wyłącznie na podstawie krótkiego tekstu. Oczekiwane odpowiedzi zapisujemy przed uruchomieniem modelu.
Sprawdzamy osobno treść i wymagany format. Przykładowo aplikacja może potrzebować nazwy firmy i regionu jako uporządkowanych pól. Poprawne wartości otoczone dodatkowym komentarzem mogą być czytelne dla człowieka, ale nie pasować do wejścia programu. Obie obserwacje warto pokazać, zamiast sprowadzać je do jednej ogólnej oceny.
Kilka przykładów z polskiej części naszego zestawu — polecenia są tutaj skrócone dla czytelności:
| Zadanie | Co ma zrobić model? | Oczekiwany wynik |
|---|---|---|
| Obliczenie | Od 7 paczek po 18 sztuk odjąć 29 zużytych sztuk | 97 sztuk |
| Odczyt danych | Z opisu zamówienia AZ-204 odczytać identyfikator i ilość 12, pomijając status | Identyfikator AZ-204 i ilość 12 |
| Zastosowanie reguły | Przypisać wartość 100 do kategorii, gdy medium obejmuje zakres od 100 do 200 | medium |
| Odpowiedź z notatki | Odczytać liczbę kopii dziennych pakietu Beta wyłącznie z podanego opisu | 2 kopie |
W rzeczywistym teście model ma oddać te wyniki w określonych polach JSON. Na przykład pierwsze zadanie wymaga dokładnie {"remaining":97}, bez komentarza. Takie próby pokazują małe czynności, z których można zbudować automatyczne przetwarzanie zgłoszeń lub dokumentów; same nie są jeszcze testem całego takiego systemu.
Takie zadania pomagają sprawdzić konkretne umiejętności. Nie zastępują oceny własnych dokumentów, stylu pisania czy poprawności długiego podsumowania. Przy zastosowaniach opisanych w artykule zaznaczamy, czy są przykładem możliwego użycia, czy zadaniem rzeczywiście wykonanym i ocenionym.
Wynik „dokładna zgodność wartości” zalicza odpowiedź tylko wtedy, gdy poprawne są zarówno wymagany format, jak i wartości. Nie wydobywamy poprawnej treści z odpowiedzi, która nie spełnia formatu.
Po co powtórzenia i dłuższa praca?
Pojedyncza próba może trafić na korzystniejszy moment. W podstawowym profilu wykonujemy pełną rundę rozgrzewkową, a następnie pięć mierzonych rund dla każdego scenariusza. Podajemy liczbę prób i ich rozrzut. Typowy czas pokazuje mediana, czyli środkowy wynik po uporządkowaniu pomiarów. Zestaw zadań praktycznych ma inną rolę: każde z 24 zadań wykonujemy raz.
Dłuższa próba odpowiada na dodatkowe pytanie: jak konfiguracja zachowuje się podczas kolejnych godzin pracy? Procedura obejmuje co najmniej cztery godziny od pierwszego mierzonego żądania do ostatniej ukończonej odpowiedzi, bez początkowego ładowania i rozgrzewki. Obserwujemy odpowiedzi, zasoby i chłodzenie. Zachowujemy też przerwy między rundami, zamiast nazywać cały ten czas pełnym obciążeniem GPU.
Czterogodzinny test jednego modelu nie staje się testem wszystkich pozostałych. Podobnie kilka szybkich odpowiedzi nie uzasadnia obietnicy zachowania usługi przez cały miesiąc. Zakres wniosku powinien odpowiadać zakresowi wykonanej pracy.
Jak wykorzystać artykuły przy własnym wyborze?
Zacznij od materiału odpowiadającego Twojemu zadaniu. Przy asystencie sprawdź czas odpowiedzi i jednoczesne zapytania. Przy większym modelu przeczytaj porównanie pamięci oraz pracę GPU z pomocą RAM. Do uruchomienia aplikacji prowadzi poradnik własnego API.
Przy wyniku sprawdź, co zmieniliśmy i co pozostało takie samo. Wspólna metodyka pomaga porównywać właściwe konfiguracje, bez sprowadzania różnych zadań do jednej liczby.
Jeżeli dopiero poznajesz nazwy, skorzystaj ze słownika AI i GPU. Możesz też opisać swoje zadanie — nazwa modelu, przykładowa długość tekstu i oczekiwana liczba jednoczesnych zapytań są dobrym początkiem rozmowy.
Szczegóły techniczne
Wersja i zapis warunków
Seria korzysta z gsh-llm-core/1.1. Przed rozpoczęciem utrwalamy plan: pliki modelu, sposób podziału tekstu na tokeny, szablon rozmowy, wersję silnika i sterownika, sprzęt, kolejność prób oraz limity czasu. Wykonawca testu sprawdza zgodność rzeczywistych plików i ustawień, a osobny program ponownie oblicza wyniki z zapisanych odpowiedzi i odczytów.
Szablon rozmowy opisuje sposób przekazania wiadomości do modelu. Zachowujemy oddzielne sumy kontrolne jego oryginalnych bajtów z GGUF oraz wersji faktycznie używanej przez silnik. Przypięte wydanie llama.cpp stosuje określone reguły zgodności i normalizację końców linii Jinja. Weryfikator odtwarza dokładnie te reguły i porównuje wynik z uruchomionym serwerem; nie akceptuje dowolnego przycinania tekstu ani zastępczego szablonu.
Środowisko obejmuje RTX PRO 6000 Blackwell Max-Q, procesor EPYC 4565P z 16 rdzeniami i 32 procesorami logicznymi oraz NVMe 4 TB. Testujemy z 96 GB RAM systemowego; konfiguracja ofertowa przewiduje 192 GB. Zainstalowaną pamięć potwierdzamy odczytem modułów, oddzielnie zapisując pamięć widoczną dla systemu. Oznaczenie 96 GB VRAM karty jest klasą produktu; rzeczywistą pojemność zgłaszaną przez sterownik przechowujemy osobno. Wersje systemu, sterownika i programu to dane konkretnego pomiaru, nie domyślne wartości z oferty.
Powtarzalny test obliczeń i równoległości
| Wariant | Zapytania naraz | Zarezerwowane miejsca | Łączny przydział kontekstu |
|---|---|---|---|
| Podstawowy C1 | 1 | 1 | 8704 tokeny |
| Kontrola C1 | 1 | 4 | 34816 tokenów |
| Równoległy C4 | 4 | 4 | 34816 tokenów |
Kontekst to miejsce na tekst obsługiwany przez model. Każdy wariant sprawdzamy oddzielnie z 2048 i 8192 tokenami wejścia oraz dokładnie 256 tokenami wyjścia. Powtarzamy i przycinamy tokeny tego samego zadeklarowanego tekstu źródłowego. Równa liczba tokenów między różnymi modelami nie oznacza identycznego tekstu — ich sposoby dzielenia słów mogą się różnić.
Przed pomiarem wykonujemy jedną pełną rundę rozgrzewki przy docelowej liczbie zapytań, potem pięć mierzonych rund. Oznacza to pięć odpowiedzi przy C1 i 20 przy C4, nie pięć niezależnych instalacji. Wyłączamy ponowne wykorzystanie gotowego wyniku przetwarzania promptu, aby powtórka nie mierzyła głównie działania pamięci podręcznej.
Do oceny samej równoległości służy kontrola C1/cztery miejsca zestawiona z C4/cztery miejsca. Porównanie podstawowego C1 z C4 pokazuje zmianę całej konfiguracji obsługi, ponieważ zmienia też rezerwację pamięci. Pozostałe wspólne ustawienia obejmują F16 KV, flash attention, 16 wątków, batch 2048, microbatch 512 i jawnie zapisane rozmieszczenie obliczeń.
Odpowiedzi, szybkość i zadania praktyczne
Czas odpowiedzi kończy się przy zdarzeniu ukończenia generacji, nie przy późniejszym zamknięciu połączenia. Oddzielamy pierwszy wygenerowany token od pierwszego widocznego tekstu odpowiedzi. Pomiary API wykonujemy lokalnie na serwerze, bez opóźnienia Internetu użytkownika.
Dla jednakowych scenariuszy pokazujemy mediany opóźnień i rozrzut. Średnia szybkości generowania pojedynczych odpowiedzi oraz łączna liczba tokenów podzielona przez czas wspólnego okna to różne wskaźniki. W pomiarach API tego wydania 256 tokenów odpowiedzi obejmuje 255 mierzonych kroków generowania po przetworzeniu wejścia. Osobny test silnika llama-bench mierzy 256 kroków decode; nie zamieniamy tych liczników. p95 publikujemy dopiero przy co najmniej 200 ukończonych żądaniach jednego scenariusza. To reguła prezentacji, nie gwarancja jakości usługi.
Zestaw praktyczny zawiera po sześć zadań z czterech rodzin, w równym podziale PL/EN. Po osobnej rozgrzewce każde zadanie wykonujemy raz, z naturalnym zakończeniem i limitem 1024 tokenów odpowiedzi. Zapisujemy ustawienie dodatkowego rozumowania dla danego modelu; różne ustawienia nie oznaczają jednakowego nakładu obliczeń.
Ocenę zgodności formatu JSON — uporządkowanych pól dla programu — oddzielamy od zgodności wartości. Główna ocena nie usuwa dodatkowych ramek ani komentarzy, nie zamienia tekstu na liczbę i nie korzysta z innego modelu jako sędziego. Niepoprawny format lub wartość pozostają wynikiem zadania. Pokazujemy je jako test tego zestawu, bez tworzenia ogólnego rankingu jakości modeli.
Pojemność, podział GPU/RAM i silnik
Kontrolowany test podziału GPU/CPU używa tego samego modelu 72B Q4 i tych samych ustawień wejścia oraz odpowiedzi. Zmieniamy tylko zadeklarowane rozmieszczenie pracy: pełne GPU albo wariant z 40 lub 20 warstwami na GPU. Te liczby służą odtworzeniu pomiaru; nie są procentami pamięci ani wydajności.
Dla Qwen3-235B Q5 używamy osobnego profilu pojemności hybrydowej: obliczenia uwagi kierowane są do GPU, eksperci 44 warstw do CPU/RAM. To jedna ustalona konfiguracja umożliwiająca sprawdzenie działania dużego modelu, nie porównanie zmiany jednej cechy ani dowód największego możliwego modelu. Ukończenie odpowiedzi przy zadanym kontekście jest mocniejszym sprawdzianem niż samo wczytanie pliku.
Test silnika 72B pozostaje odrębny od API. Osobno mierzy przetwarzanie wejścia i generowanie przy 2048, 8192 i 32768 tokenach, po pięć wewnętrznych próbek narzędzia w świeżym procesie z rozgrzewką. Odczyty zasobów obejmują wtedy także ładowanie i rozgrzewkę. Zakres 32768 tokenów nie jest nowym testem API 8B z tak długim wejściem.
CPU, RAM i energia z tych samych prób
Artykuły o procesorze, pamięci i mocy wykorzystują odczyty z tych samych wskazanych przypadków. Nie tworzymy osobnych, nieporównywalnych testów tylko po to, aby uzyskać kolejną tabelę. Rozdzielamy ładowanie, gotowość, rozgrzewkę, odpowiedzi i zamknięcie programu. Krótkie okna gotowości nie są wielominutowym pomiarem bezczynnego serwera.
Zużycie CPU procesu silnika modelu liczymy z przyrostu jego czasu procesora i odnosimy do 32 procesorów logicznych. Nie jest to łączne obciążenie całego hosta. Średnia obejmuje przedziały między odczytami przed rundą i po niej, nie wyłącznie samą generację tekstu. Wskaźnik 100% jednego procesora logicznego nie oznacza 100% całego serwera. PSS oznacza pamięć przypisaną procesowi z proporcjonalnym udziałem obszarów współdzielonych; nie jest całym zajętym RAM-em systemu. Osobno zachowujemy pamięć dostępną systemu i odczyty VRAM. Nie dodajemy maksimów występujących w różnych chwilach ani nie traktujemy szczytu próbek jako minimalnej wymaganej ilości RAM.
Moc dotyczy samej karty GPU, nie poboru całego serwera z gniazdka. Energię obliczamy z mocy i czasu metodą trapezów, z próbkami obejmującymi obie granice okna i bez przerw dłuższych niż trzy sekundy. Przy braku pokrycia wynik jest niedostępny. W długim teście cztery dokładne godzinne okna zaczynają się przy pierwszym mierzonym żądaniu; średnia moc jest ważona czasem i obejmuje również przerwy między rundami. Nie jest średnią ze starych zestawień dziesięciominutowych.
Procesy testowe działają w odrębnej grupie z limitem pamięci 81 GiB i bez możliwości użycia swapu. Dodatkowy nadzór wymaga zapasu ponad 12 GiB pamięci dostępnej dla systemu. To zabezpieczenia tej konfiguracji, nie wyznaczone eksperymentalnie minimum dla modeli. MemAvailable opisuje cały system: nie oznacza, że proces może przekroczyć własny limit.
Procedura czterogodzinna i ocena chłodzenia
Profil długiego API dotyczy Qwen3-32B Q4_K_M, wejścia 8192 tokeny, czterech zapytań naraz i 256 tokenów wyjścia. Po pełnej rozgrzewce rundy trwają do uzyskania co najmniej czterech godzin od pierwszego mierzonego żądania do ostatniej ukończonej odpowiedzi. Zapisujemy zarówno ten przedział, jak i czas faktycznej obsługi żądań oraz przerwy.
Przed rozpoczęciem utrwalamy kryteria oceny chłodzenia i wersję programu analizy. Sprawdzamy kompletność odczytów, zdarzenia ograniczenia termicznego i przebieg końcowej godziny. Zgodność zwykłego zegara z zegarem mierzącym upływ czasu jest weryfikowana, aby przesunięcie daty systemowej nie wydłużyło pozornie testu.
Określenie „temperatura stabilna” wymaga spełnienia zadeklarowanych kryteriów; samo ukończenie pracy nie wystarcza. Wydajność pokazujemy dodatkowo w stałych blokach dziesięciominutowych, bez dopisywania po teście progu zaliczenia. Ocena termiczna nie jest automatycznie oceną stabilności wydajności ani wszystkich modeli. Dokładne temperatury pozostają w prywatnej dokumentacji, a opis publiczny jest jakościowy.
Archiwa i możliwość sprawdzenia wyników
Starsze krótkie pomiary miały trzy powtórzenia, a starszy zestaw praktyczny trzy pojedyncze zadania. Poprzednie API rezerwowało cztery miejsca także dla jednego klienta i miało inną rozgrzewkę. Historyczna seria pojemności używała jednego miejsca. Te dane zachowujemy z oryginalnymi ustawieniami, nie łączymy ich rund z CORE 1.1. Historyczny długi test także pozostaje osobną serią; jego liczników i wyniku nie przenosimy do nowej procedury. Blender zachowuje własną metodykę renderowania.
Pełne zapisy odpowiedzi, odczytów i planów mają sumy kontrolne. Oddzielny weryfikator sprawdza pliki, przelicza czasy i oceny z zapisanej komunikacji oraz kontroluje granice pomiaru. Sumy SHA-256 potwierdzają zgodność danych z zachowanym zapisem, nie stanowią niezależnego sprzętowego poświadczenia serwera. Publiczne CSV/JSON są wybranymi, sprawdzonymi zestawieniami bez danych administracyjnych.
Zachowujemy rzeczywiste daty pomiarów, publikacji i aktualizacji. Wyświetlane wyniki zaokrąglamy bezpośrednio z pełnych danych do najwyżej jednego miejsca po przecinku, bez zmieniania wersji programów i sum kontrolnych. Nowe serie otrzymują osobne pliki; archiwalne pozostają niezmienione.