DGX Spark vs RTX PRO 6000 vs HGX B200 to nie jest wybór między lepszym a gorszym sprzętem, tylko wybór szczebla, na którym jest dziś Twój projekt AI. Proponujemy prostą drabinę: prototyp, zespół, produkcyjna inferencja i trening. Przy każdym szczeblu pokazujemy, kto z niego korzysta, jakie modele się mieszczą, jaki sprzęt ma sens i jak wejść wyżej bez przepisywania aplikacji.
Najczęstsze błędy przy zakupie sprzętu AI są dwa. Pierwszy to serwer z ośmioma GPU HBM kupiony na pilotaż, który po trzech miesiącach okazuje się niepotrzebny. Drugi to urządzenie do prototypowania, które z braku czasu staje się systemem produkcyjnym i nie wytrzymuje ruchu. Oba wynikają z tego, że sprzęt dobiera się do wyobrażenia o docelowej skali, a nie do bieżącego etapu projektu. Poniżej opisujemy etapy po kolei, z ofertą, jaką mamy na każdym z nich w naszej serwerowni Tier III w Polsce.
Dlaczego sprzęt AI warto wybierać jak drabinę
Przy wyborze sprzętu do LLM liczą się trzy zmienne:
- Rozmiar modelu, który wyznacza potrzebną pamięć. Wagi to liczba parametrów razy bajty na parametr (BF16 = 2 B, FP8 = 1 B, 4 bity ≈ 0,5 B), do tego KV cache i 10–20% zapasu. Szczegóły w artykule Ile VRAM potrzebuje model językowy.
- Współbieżność, czyli ilu użytkowników i aplikacji pyta model jednocześnie. Tu decyduje przepustowość pamięci i moc obliczeniowa GPU, a pamięć potrzebna na KV cache rośnie z każdą równoczesną sesją.
- Wymagana dostępność. Prototyp może mieć przerwę w działaniu, system obsługi klienta – nie. Wysoka dostępność oznacza co najmniej dwa serwery.
Te zmienne rosną razem z projektem, ale w różnym tempie. Na etapie prototypu liczy się głównie rozmiar modelu, w produkcji – współbieżność i dostępność. Dlatego najtańszy sensowny sprzęt jest inny na każdym etapie. Szczegółowe porównanie samych GPU (B300, B200, H200, RTX PRO 6000, Gaudi 3) znajdziesz w artykule Jaki GPU do LLM w 2026.
DGX Spark vs RTX PRO 6000 vs HGX B200: tabela szczebli
| Szczebel | Typowi użytkownicy i współbieżność | Rozmiar modeli | Sprzęt | Model dostarczenia | Przejście wyżej |
|---|---|---|---|---|---|
| 1. Prototyp | pojedynczy programiści, zespół R&D; zapytania pojedynczo | do ok. 200B w 4 bitach na 1 urządzeniu; ok. 400B / 700B w klastrze 2 / 4; fine-tuning do 70B (LoRA, QLoRA) | NVIDIA DGX Spark (1, 2 lub 4 szt.); dla małych modeli VPS z GPU | usługa | API zgodne z OpenAI od pierwszego dnia, obrazy kontenerów dla arm64 i x86 |
| 2. Zespół lub dział | użytkownicy wewnętrzni; umiarkowana współbieżność w godzinach pracy | małe i średnie modele w FP8 lub BF16, modele ok. 120B–320B w 4 bitach | serwer z 1–4 kartami RTX PRO 6000 (96–384 GB GDDR7) | usługa (serwer GPU) albo zakup i kolokacja | ten sam serwer inferencji (vLLM, SGLang, NIM), więcej kart lub kolejny serwer |
| 3. Produkcyjna inferencja | cała firma lub klienci zewnętrzni; wysoka, ciągła współbieżność, wymagania SLA | od średnich modeli dla wielu użytkowników po duże MoE: do ok. 1T w 4 bitach (8× RTX PRO 6000); ok. 750B w FP8 lub ok. 1,65T w 4 bitach (HGX B200) | serwer 8× RTX PRO 6000 (768 GB) lub HGX B200 (8× 180 GB HBM3e); co najmniej 2 serwery dla HA | usługa (bare metal, klaster) albo zakup Supermicro i kolokacja | skalowanie poziome za load balancerem; to samo API |
| 4. Trening | zespół ML; długotrwałe zadania, nie ruch użytkowników | pełny fine-tuning dużych modeli, dalsze trenowanie, własne modele | HGX B200 / B300 w wielu węzłach, GB300 NVL72; alternatywnie Intel Gaudi 3 | zakup i kolokacja w szafach chłodzonych cieczą albo dedykowany klaster jako usługa | – |
Zakresy modeli są orientacyjne: zależą od precyzji, długości kontekstu i liczby równoczesnych sesji. Koszty celowo pomijamy, bo przy sprzęcie Blackwell i usłudze DGX Spark przygotowujemy wyceny indywidualne, a porównywanie cen katalogowych bez kosztu zasilania, chłodzenia i administracji wprowadza w błąd.
Szczebel 1: prototyp na DGX Spark
Na tym etapie odpowiadasz na jedno pytanie: czy model radzi sobie z Twoimi danymi i zadaniem. Potrzebujesz dużo pamięci, żeby porównać modele różnej wielkości, ale nie potrzebujesz szybkiej obsługi wielu użytkowników.
DGX Spark pasuje do tego bardzo dobrze. Układ GB10 Grace Blackwell ze 128 GB pamięci zunifikowanej uruchamia modele do ok. 200B parametrów i pozwala dostrajać modele do 70B. Ma też ten sam stos oprogramowania co duże systemy NVIDIA: NeMo, RAPIDS, PyTorch i mikroserwisy NIM. Gdy chcesz sprawdzić model 400B–700B, dwa lub cztery urządzenia łączymy w klaster. Usługę opisujemy w artykułach NVIDIA DGX Spark jako usługa i Klaster DGX Spark: modele 400B–700B.
Granice tego szczebla są jasne. Przepustowość pamięci 273 GB/s ogranicza szybkość generowania, więc DGX Spark nie obsłuży dużej liczby równoczesnych użytkowników. Jedno urządzenie to też jeden punkt awarii. Jeśli Twój prototyp to mały model (np. Bielik-11B albo Gemma 4 12B), wystarczy nawet VPS z dedykowanym GPU.
Szczebel 2: zespół na serwerze z RTX PRO 6000
Pilotaż się sprawdził i dział zaczyna używać modelu codziennie. Teraz liczy się nie tylko to, czy model działa, ale też, jak szybko odpowiada kilku osobom naraz. To moment na GPU z szybszą pamięcią.
NVIDIA RTX PRO 6000 Blackwell Server Edition to karta PCIe z 96 GB pamięci GDDR7 ECC i przepustowością ok. 1,6 TB/s, czyli blisko sześć razy większą niż w DGX Spark. Supermicro oferuje dla niej ponad 20 systemów, w tym serwer MGX na 4 karty i platformę 5U na 8 kart. Przykłady dopasowania:
- 1 karta (96 GB): Qwen3.8-27B w BF16 (ok. 56 GB wag) albo gpt-oss-120b w 4 bitach (ok. 59 GB) z zapasem na KV cache.
- 2 karty (192 GB): Mistral Small 4 (119B) w FP8, ok. 119 GB wag.
- 4 karty (384 GB): Qwen3.8-Flash-Next (180B) w FP8 albo GLM-5.3-Flash (ok. 321B) w 4 bitach, z dużym zapasem na kontekst i wielu użytkowników.
Karty RTX PRO 6000 komunikują się przez PCIe, bez NVLink znanego z systemów HGX. Dla inferencji, także z modelem rozłożonym na kilka kart, to zwykle wystarcza. Dobrze sprawdza się też podział „jeden model na kartę” dla kilku zespołów lub aplikacji.
Kiedy na tym szczeblu zamiast serwera z RTX PRO 6000 wybrać klaster DGX Spark? Gdy ważniejszy jest rozmiar modelu niż liczba użytkowników. Klaster czterech urządzeń ma 512 GB pamięci, ale wyraźnie mniejszą przepustowość. Serwer z RTX PRO 6000 to odwrotny kompromis. Oba warianty oferujemy jako usługę; jak działa wynajem sprzętu AI bez kupowania serwerów, opisujemy w artykule GPU jako usługa.
Szczebel 3: produkcyjna inferencja na 8× RTX PRO 6000 lub HGX B200
Model obsługuje całą firmę albo klientów zewnętrznych. Ruch jest ciągły, a czas odpowiedzi ma znaczenie biznesowe. Do tego dochodzi wysoka dostępność: co najmniej dwa serwery za load balancerem, żeby awaria lub aktualizacja jednego nie zatrzymywała usługi.
Serwer 8× RTX PRO 6000
Osiem kart w platformie 5U to 768 GB GDDR7. Taki serwer obsłuży wiele średnich modeli jednocześnie albo jeden duży model MoE w 4 bitach, np. DeepSeek-V4.1-Flash (ok. 763B, ok. 382 GB wag) czy GLM-5.3 (ok. 753B), z dużym zapasem na KV cache. W 4 bitach zmieści się tu nawet Mistral Large 4 (ok. 1T, ok. 500 GB wag), choć już z mniejszym zapasem. To dobry wybór, gdy obciążenie jest zróżnicowane i zależy Ci na korzystnym stosunku ceny do wydajności.
HGX B200
Osiem GPU po 180 GB HBM3e, łącznie ok. 1,44 TB, połączonych przez NVLink 1,8 TB/s. Modele dzielone między GPU (równoległość tensorowa) pracują tu znacznie wydajniej niż przez PCIe czy sieć. HGX B200 pozwala uruchomić duże modele w FP8 zamiast 4 bitów (DeepSeek-V4.1-Flash to ok. 763 GB wag w FP8), DeepSeek-V4-Pro (ok. 1,65T) w 4 bitach albo obsłużyć długi kontekst przy dużej liczbie użytkowników. Supermicro dostarcza go w wersjach 8U/10U chłodzonych powietrzem i 4U chłodzonych cieczą. Według Supermicro w szafie chłodzonej powietrzem mieści się do 32 GPU, a w szafie chłodzonej cieczą do 96.
Oba warianty oferujemy jako serwery bare metal w modelu usługi albo jako sprzęt Supermicro do zakupu z kolokacją w naszej serwerowni. Jesteśmy partnerem Supermicro i NVIDIA.
Szczebel 4: trening na HGX B200, B300 i chłodzenie cieczą
Pełny fine-tuning dużego modelu, dalsze trenowanie na własnym korpusie albo trening od zera wymagają pamięci nie tylko na wagi, ale też na gradienty i stany optymalizatora, czyli wielokrotności rozmiaru modelu. Do tego potrzebna jest szybka komunikacja między GPU i między serwerami.
Tu wchodzą systemy HGX B300: 8 GPU Blackwell Ultra po 288 GB HBM3e (ok. 2,3 TB na system), do 1 100 W na GPU i zintegrowana sieć ConnectX-8 800 Gb/s. Supermicro oferuje wersję 8U chłodzoną powietrzem oraz wersje 4U i 2-OU OCP chłodzone cieczą. Przy takim poborze mocy to chłodzenie cieczą pozwala zmieścić w szafie sensowną liczbę GPU. Największe projekty sięgają po GB300 NVL72: 72 GPU i 36 procesorów Grace w jednej domenie NVLink, w skali całej szafy. Alternatywą dla NVIDIA jest Intel Gaudi 3 (8 akceleratorów po 128 GB HBM2e, wbudowane porty 800 GbE, wsparcie PyTorch i vLLM).
Uczciwie: większość firm tego szczebla nie potrzebuje. Dostrajanie metodą LoRA da się zrobić na szczeblach 1–3, a trening własnych modeli od podstaw to rzadkość. Jeśli jednak tu jesteś, sprzęt najczęściej kupuje się na własność i stawia w kolokacji z szafami chłodzonymi cieczą, bo biuro ani typowa serwerownia firmowa nie dostarczą takiej mocy i chłodzenia.
Jak przejść szczebel wyżej bez przepisywania aplikacji
Drabina ma sens tylko wtedy, gdy przejście na wyższy szczebel nie oznacza budowania aplikacji od nowa. Kilka decyzji podjętych na etapie prototypu oszczędza później tygodnie pracy:
- API zgodne z OpenAI od pierwszego dnia. vLLM, SGLang, NVIDIA NIM i Ollama wystawiają ten sam interfejs. Aplikacja zna tylko adres endpointu, nazwę modelu i klucz, które trzymasz w konfiguracji. Zmiana sprzętu pod spodem nie wymaga zmian w kodzie. Serwery inferencji porównujemy w artykule Ollama, vLLM, SGLang czy NVIDIA NIM.
- Kontenery dla dwóch architektur. DGX Spark to Arm (arm64), a serwery z RTX PRO 6000 i HGX działają na x86 (Intel Xeon 6 lub AMD EPYC). Buduj obrazy dla obu architektur od początku. CUDA i stos NVIDIA są wspólne.
- Oddzielona warstwa aplikacji. Logika RAG, agenci, prompty i integracje nie powinny zależeć od tego, gdzie działa model. Wtedy zmieniasz tylko warstwę serwowania.
- Własny zestaw testowy. Kilkadziesiąt do kilkuset prawdziwych pytań z oczekiwanymi odpowiedziami. Uruchamiasz go po każdej zmianie modelu, kwantyzacji lub sprzętu i wiesz, czy jakość się nie pogorszyła.
- Pomiary, które mówią, kiedy wejść wyżej. Czas do pierwszego tokenu, liczba tokenów na sekundę na użytkownika, długość kolejki zapytań i zajętość pamięci GPU. Gdy kolejka rośnie w godzinach szczytu, a czas odpowiedzi przekracza akceptowalny poziom, to sygnał do zmiany szczebla.
Jest też argument organizacyjny. Gdy wszystkie szczeble są w jednej serwerowni, dane, VPN, monitoring i zespół administracyjny zostają te same. Przejście na wyższy szczebel to zmiana sprzętu, a nie migracja między dostawcami.
FAQ: najczęściej zadawane pytania
DGX Spark vs RTX PRO 6000 – co wybrać?
DGX Spark daje 128 GB pamięci przy przepustowości 273 GB/s, więc uruchomi duży model, ale odpowiada wolniej i obsłuży niewielu użytkowników naraz. RTX PRO 6000 ma 96 GB pamięci na kartę i ok. 1,6 TB/s, więc lepiej sprawdza się, gdy model ma obsługiwać zespół lub dział. Do prototypu wybierz DGX Spark, do codziennej pracy wielu osób – serwer z RTX PRO 6000.
Jaki serwer do inferencji LLM dla firmy?
To zależy od rozmiaru modelu i liczby równoczesnych użytkowników. Dla działu zwykle wystarcza serwer z 1–4 kartami RTX PRO 6000. Dla całej firmy lub klientów zewnętrznych – serwer z 8 kartami RTX PRO 6000 albo HGX B200, w konfiguracji z co najmniej dwoma serwerami.
Kiedy potrzebuję HGX B200?
Gdy uruchamiasz duże modele w FP8 lub BF16, potrzebujesz długiego kontekstu przy wielu użytkownikach, chcesz uruchomić model powyżej ok. 1T parametrów (np. DeepSeek-V4-Pro w 4 bitach) albo planujesz trening. Dla mniejszych obciążeń HGX B200 jest zwykle przewymiarowany.
Wynająć czy kupić serwer GPU?
Wynajem sprawdza się przy niepewnym obciążeniu, pilotażach i projektach o ograniczonym czasie. Zakup z kolokacją zaczyna się opłacać przy stałym, przewidywalnym wykorzystaniu przez dłuższy czas. Sposób liczenia opisujemy w tekście o TCO chmury i kolokacji serwerów GPU.
Czy przejście z DGX Spark na serwer GPU wymaga przepisania aplikacji?
Nie, jeśli od początku korzystasz z API zgodnego z OpenAI i kontenerów budowanych dla arm64 i x86. Wtedy zmieniasz adres endpointu i ewentualnie precyzję modelu, a logika aplikacji zostaje bez zmian.
Nie wiesz, na którym szczeblu jest Twój projekt? Opisz nam model, liczbę użytkowników i wymagania co do danych, a zaproponujemy sprzęt na dziś i ścieżkę na kolejne etapy. Ofertę znajdziesz na stronie serwery GPU, a zapytanie wyślesz przez formularz kontaktowy.