Budowa serwera inferencyjnego 576 GB VRAM: dziennik uruchomienia

Większość opisów serwerów przedstawia maszynę, która została zamówiona. Ten opisuje maszynę, która została zbudowana — wraz z dwiema rzeczami, które były z nią nie tak przy pierwszym uruchomieniu, oraz tą jedną, której nigdy w pełni nie wyjaśniliśmy.

Konfiguracja: rack 7U · 2× AMD EPYC 7643 (96C/192T) · 512 GB DDR4 ECC · 6× NVIDIA RTX PRO 6000 Blackwell Max-Q, 576 GB GDDR7 · 2 TB + 4 TB NVMe
Zbudowano i uruchomiono: sierpień 2026, warsztat Kentino, Praga · Status: dostarczono

Uważamy, że to bardziej użyteczny artykuł. Listę części może skopiować każdy.

Czym to jest

Sześć kart RTX PRO 6000 Blackwell Max-Q po 96 GB każda, na dwuprocesorowej platformie EPYC Rome z 512 GB pamięci ECC. 576 GB VRAM w jednej obudowie, co wystarcza, by pomieścić model o 753 miliardach parametrów w 4 bitach, z zapasem na milion tokenów kontekstu.

Wariant Max-Q ma znaczenie. Przy 300 W na kartę zamiast 600 sześć z nich mieści się w budżecie cieplnym i elektrycznym, jaki warsztat — a później serwerownia — jest w stanie faktycznie zapewnić. Zmierzony pobór z gniazda przy pełnym obciążeniu wyniósł ~2.9 kW, czyli około 80% jednego obwodu 16 A/230 V.

Obudowa to nasz własny projekt 7U: dwa niezależnie chłodzone bloki po cztery zatoki GPU, dzięki czemu żadna karta nie stoi w strumieniu wylotowym więcej niż trzech innych.

Pierwsza usterka: dwa GPU po cichu pracujące z połową prędkości

System wystartował, wszystkie sześć kart zostało wykrytych, nvidia-smi wyglądało bez zarzutu.

Dwie z nich pracowały w trybie PCIe Gen4 x8 zamiast x16.

Nic nie zgłaszało błędu. Sterownik był zadowolony, karty działały, inferencja szła. Jedynym sposobem, by to zauważyć, był pomiar przepustowości host-urządzenie dla każdej karty i spostrzeżenie, że dwie z nich zwracały 13.9 GB/s tam, gdzie pozostałe zwracały 27.7.

Przyczyną była usterka warstwy fizycznej na dwóch złączach obudowy — nie kart, nie płyty, nie konstrukcji riserów. Oba łącza przeniesiono na zapasowe złącza i wszystkie sześć kart potwierdziło następnie Gen4 x16 pod obciążeniem. Dwa podejrzane złącza zostały imiennie odnotowane w dokumentacji konfiguracji i pozostają nieużywane przez cały okres życia maszyny.

GPU, które trenuje przy połowie szerokości magistrali, samo się nie zgłosi. Jeżeli proces uruchomieniowy nie mierzy przepustowości PCIe każdej karty pod obciążeniem, usterka taka zostanie wysłana wraz ze sprzętem i nikt się o niej nie dowie.

Druga usterka: wzorzec błędów ECC, który nie pochodził od pamięci

W trakcie uruchamiania dwa moduły DIMM zaczęły rejestrować korygowalne błędy ECC. Korygowalne oznacza, że sprzęt je wykrył i naprawił: bez utraty danych, bez błędnych wyników, bez wpływu na jakikolwiek rezultat. Ale dwa moduły zgłaszające błędy to zwykle dwa moduły do wymiany.

Nie wymieniliśmy ich, a powód jest tu najciekawszy.

Zdarzenia dzieliły 4 h 30 min oraz 4 h 01 min, a każde z nich wystąpiło na obu modułach w tej samej sekundzie. Dwa niezależnie osłabione moduły pamięci nie psują się w niemal stałych odstępach, a już na pewno nie psują się w tej samej sekundzie trzy razy z rzędu. Tak nie wygląda degradujący się krzem. To sygnatura czegoś zewnętrznego i okresowego.

Odstęp pokrywał się z dużym obciążeniem łączeniowym w otoczeniu stanowiska uruchomieniowego. Przeprowadziliśmy następnie ~20 godzin oprzyrządowanego wygrzewania przy trwałym, rzeczywistym obciążeniu, z telemetrią co minutę ze wszystkich sześciu GPU, procesora, pamięci, dysków i dziennika zdarzeń BMC. Zero zdarzeń ECC.

Moduły więc zostały.

Co mówimy z całą ostrożnością: nigdy nie skorelowaliśmy tych zdarzeń z zarejestrowanym cyklem podejrzewanego źródła. To przypisanie jest wnioskiem, nie dowodem. Zgłosiliśmy klientowi obserwację, odstęp czasu i okno testowe oraz powiedzieliśmy wprost, że nie jest to udowodniona przyczyna źródłowa. Jeżeli przyczyna była środowiskowa, nie podróżuje razem z maszyną — a dwadzieścia godzin ciszy pod obciążeniem to dobry dowód, nie gwarancja.

Jedna praktyczna uwaga, która kosztowała nas czas: ta platforma stosuje obsługę błędów w pierwszej kolejności przez firmware, więc liczniki ECC po stronie Linuksa pokazują zero niezależnie od tego, co się dzieje. Stan pamięci trzeba odczytywać z dziennika zdarzeń BMC. Monitorowanie wyłącznie edac to monitorowanie niczego.

Co ta maszyna faktycznie potrafi

Wszystkie wartości zmierzone na tym konkretnym systemie, nie wzięte z karty katalogowej.

Moc obliczeniowa i powtarzalność

Pomiar	Wynik
Gęste mnożenie macierzy FP16, na kartę	291–302 TFLOPS (rozrzut 3.5% między sześcioma kartami)
Przepustowość VRAM, na kartę	~1,471 GB/s (jednorodna do 0.2%)
Inferencja równoległa danymi na sześciu kartach	3,859 tok/s · 90.8% efektywności skalowania
Rozrzut między replikami na sześciu GPU	0.45%

Ten półprocentowy rozrzut między sześcioma kartami to liczba, na której zależy nam najbardziej. Oznacza, że żadna karta nie pracuje po cichu poniżej swoich możliwości — i ma to znaczenie tylko dlatego, że wcześniej znaleziono opisaną wyżej usterkę PCIe.

Inferencja dużych modeli

GLM-5.2 — 753 miliardy parametrów (40 mld aktywnych), 4 bity, 341 GB zajętych na sześciu kartach:

Równoczesne żądania	1	4	16	32	48
Generowanie tok/s	38.0	78.5	117–120	148.1	172.2

Na tym sprzęcie ładuje się również natywny kontekst 1,048,576 tokenów — 494 GiB VRAM, przy 6.6 GiB wolnych na najciaśniejszej karcie. To działa, ale jest to cienki margines i powiedzieliśmy to wprost.

Dostrojenie mikrowsadu prefill (-b/-ub 4096) podniosło przetwarzanie promptu z 403 do 606 tok/s, czyli o 50% przy zmianie jednej linii. Dekodowanie spekulatywne dodało +53% w pojedynczym strumieniu, ale kosztowało 6% przy pracy wsadowej z długimi promptami, więc włącza się je zależnie od obciążenia, a nie globalnie.

Wygrzewanie

810,033 mnożeń macierzy na sześciu GPU przy 100% obciążenia. Zero błędów obliczeniowych. Szczytowo 88 °C, trwałe 300 W na kartę, bez throttlingu termicznego — clocks_event_reasons wskazywało Not Active przez cały czas.

Gdzie ta maszyna jest na styk — i powiedzieliśmy to wprost

Margines termiczny wynosi ~2 °C. Szczyt 88 °C wobec progu throttlingu ~90 °C, przy temperaturze otoczenia 28–33 °C w nieklimatyzowanym warsztacie w sierpniu. W pomieszczeniu poniżej 25 °C zapas jest komfortowy. W ciepłym już nie. Trwałe, rzeczywiste obciążenia osiągały te same temperatury co syntetyczne wygrzewanie, więc nie jest to problem wyłącznie syntetyczny.

Oczywistą dźwignią jest ograniczenie mocy GPU — 260 W zamiast 300 W. Nie zmierzyliśmy, ile to kosztuje w przepustowości na tej maszynie, więc nie zalecaliśmy tego tak, jakbyśmy zmierzyli. Należy to przetestować na własnym obciążeniu.

Stos programowy jest specyficzny i wrażliwy. GLM-5.2 nie uruchomi się pod vLLM ani SGLang na tej generacji GPU — trzy odrębne ograniczenia po stronie upstreamu. Działającą ścieżką jest llama.cpp. Niezależnie od tego instalacja vLLM zawiera lokalną łatkę naprawiającą awarię przy współbieżności z modelami skwantyzowanymi, a ta łatka nie przetrwa polecenia pip install -U vllm. Wersje należy przypiąć.

Dwa gniazda procesorowe oznaczają NUMA. Przepustowość host-urządzenie dzieli się według gniazda: GPU 0–2 przy jednym, 3–5 przy drugim, z karą rzędu 20% dla buforów hosta zaalokowanych na niewłaściwym węźle. To nie usterka — to fizyka — ale tam, gdzie przepustowość host↔urządzenie ma znaczenie, trzeba przypinać przez numactl.

Jeden test jest rzeczywiście niekompletny. Końcowy etap łącznego maksymalnego obciążenia CPU+GPU został przerwany awarią warsztatowej aparatury rozdzielczej. Około 20 godzin testów wytrzymałościowych przy obciążeniu mieszanym pokrywa rzeczywisty przypadek eksploatacyjny, zgłosiliśmy więc tę lukę zamiast po cichu przemianowywać przebiegi wytrzymałościowe na brakujący test.

Dlaczego publikujemy usterki

Raport z uruchomienia, który mówi, że wszystko przeszło pomyślnie, nie mówi nic o ludziach, którzy go napisali. Każda maszyna o tej złożoności ma przy pierwszym uruchomieniu coś nie tak. Pytanie brzmi, czy zostanie to znalezione na naszym stanowisku, czy w Państwa racku.

W tej konstrukcji były to dwa złącza degradujące ćwiartkę struktury GPU do połowy prędkości, niewidoczne dla żadnego wskaźnika stanu w systemie. Znalezienie wymagało pomiaru, naprawa zajęła dziesięć minut.

Po to właśnie jest uruchomienie.