Bare-metal GPU dla firm · 96 GB VRAM · Katowice

TESTY I PORADNIKI

Jak testujemy i opisujemy serwery GPU

Zasady własnych testów GPU Server Hub: faktyczna konfiguracja, wersje narzędzi, powtórzenia, ograniczenia i publiczne zestawienia wyników.

Poglądowy moduł GPU z subtelnymi strumieniami danych.
Ilustracja AI.

Chcemy, aby wyniki pomagały wybrać serwer do konkretnego zadania. Publikujemy pomiary wykonane na naszym sprzęcie, a nie oszacowania na podstawie TFLOPS ani wyniki innych kart przedstawiane jako własne. Za opracowanie materiałów i utrzymanie tej metodyki odpowiada GPU Server Hub / Bestconnect — dostawca opisywanej usługi, a nie niezależne laboratorium.

Konfiguracja sprzętu

Każdy test opisuje sprzęt, na którym faktycznie wykonano pomiary: wariant karty GPU, jej VRAM i ustawiony limit mocy, procesor, RAM systemowy oraz nośnik. Wersje systemu, sterownika i narzędzi są częścią opisu środowiska.

Konfiguracja testowa: 96 GB RAM. Konfiguracja ofertowa: 192 GB RAM. RAM systemowy i 96 GB VRAM karty GPU to odrębne zasoby.

Co zapisujemy przed pomiarem

Konfiguracje bez pełnego przeniesienia modelu do GPU, z offloadem lub z innym formatem wag opisujemy oddzielnie. Nie sugerujemy, że różne kwantyzacje zapewniają identyczną jakość odpowiedzi.

Powtórzenia i rozrzut wyników

Dla porównywalnego scenariusza zakładamy rozgrzewkę i co najmniej trzy mierzone powtórzenia. Publikacja wskazuje faktyczną liczbę prób i sposób podsumowania. Jeżeli narzędzie raportuje średnią i odchylenie standardowe, nie nazywamy ich medianą ani zakresem minimum–maksimum.

Nie wybieramy tylko najszybszej próby. Zachowujemy wyniki pomiarów, ustawienia i informacje o nieudanych uruchomieniach. Jeżeli scenariusz wymaga innej procedury, opisujemy odstępstwo zamiast przedstawiać go jako identyczny test.

Nie każdy test LLM mierzy to samo

Mikrobenchmark obliczeń może osobno mierzyć przetwarzanie promptu i generowanie tokenów, bez warstwy HTTP, kolejki użytkowników i pełnej aplikacji. Taki wynik opisujemy jako mikrobenchmark; nie jest automatycznie czasem odpowiedzi działającej usługi.

Test obsługi zapytań wymaga zdefiniowanego serwera API, obciążenia i klientów testowych. Dopiero w takim scenariuszu opisujemy czas do pierwszego tokena, opóźnienia odpowiedzi, równoległość oraz odsetek błędów. Przepustowość całego serwera nie jest tym samym co prędkość generowania dla pojedynczego użytkownika.

Test pojemności pamięci pokazuje, czy konkretna konfiguracja uruchomiła się przy podanych ustawieniach. Samo wczytanie wag nie jest dowodem, że każda długość kontekstu i każda liczba użytkowników zmieszczą się w VRAM.

Renderowanie, ładowanie i dłuższe obciążenie

Przy renderowaniu podajemy scenę, wersję programu, backend GPU i ustawienia. Czasy wczytywania modelu oddzielamy od czasu obliczeń; wskazujemy, czy pomiar korzystał z rozgrzanej pamięci podręcznej.

Test trwający kilka minut nie staje się testem wielogodzinnym. Jeżeli publikujemy wyniki dłuższego obciążenia, podajemy rzeczywisty czas, próbki temperatur i mocy, obserwowane błędy oraz ewentualne zmiany wydajności. Nie zmieniamy firmware ani limitów mocy w celu upiększenia wyniku.

Publiczne dane i aktualizacje

Przy publikacjach z danymi do pobrania udostępniamy przygotowane zestawienia CSV lub JSON. Są to wybrane do publikacji wyniki i ustawienia, nie pełny zrzut systemu ani logów administracyjnych. Pliki mają sumy SHA-256 umożliwiające sprawdzenie ich zgodności.

Odróżniamy datę testu od daty publikacji i aktualizacji tekstu. Korekty wyników lub zmiany metody opisujemy przy materiale. Zmiana sterownika, modelu lub środowiska może wymagać powtórzenia testu; nie zastępujemy starej konfiguracji nową nazwą bez nowych pomiarów.

Jak korzystać z wyników

Wynik dotyczy wskazanego scenariusza, a nie gwarantowanej wydajności każdej aplikacji. Nie deklarujemy przewagi nad konkretnym konkurentem bez porównywalnych pomiarów jego sprzętu. Opisujemy również ograniczenia i sytuacje, w których potrzebna jest inna konfiguracja.

Przejdź do testów i poradników, sprawdź ofertę albo zapytaj o swój model i obciążenie.