02.09.2026 · Sprzęt · ~10 min czytania

Kupiłem DGX Spark i co dalej — konfiguracja krok po kroku

DGX Spark konfiguracja to temat, który zaczyna się dopiero po dostawie — i zwykle wygląda inaczej, niż zakładał kupujący. Urządzenie stoi na biurku, włącza się, system startuje, układ graficzny jest widoczny. A mimo to nikt w firmie jeszcze z niego nie korzysta. Ten tekst jest o tym dystansie: między sprzętem, który działa, a narzędziem, z którego pracuje zespół.

Piszemy go dla kogoś, kto sprzęt już ma. Nie ma tu cen ani porównań, co kupić — te tematy omawiamy osobno. Jest natomiast uczciwa mapa tego, co trzeba zrobić, ile z tego da się zrobić samodzielnie i gdzie samodzielne wdrożenia najczęściej się zatrzymują. Świadomie nie podajemy poleceń ani numerów wersji — powód wyjaśniamy niżej.

Co dostajesz w pudełku, a czego nie

Zacznijmy od postawienia sprawy wprost, bo to oszczędza tygodnie rozczarowania: DGX Spark i ASUS Ascent GX10 to stacje dla osoby, która buduje rozwiązania AI, a nie urządzenia biurowe. Nie jest to wada produktu — NVIDIA sprzedaje je dokładnie jako to, czym są, i jako takie są bardzo dobre. Rozczarowanie bierze się z oczekiwania, że po podłączeniu zasilania firma dostanie gotowego asystenta.

Co masz po pierwszym uruchomieniu: działający system operacyjny przygotowany pod obliczenia AI, sterowniki i biblioteki dopasowane do układu, widoczną pełną pamięć zunifikowaną oraz środowisko, w którym da się uruchomić model językowy w kilkanaście minut. To naprawdę dużo — na zwykłej stacji roboczej sama ta warstwa potrafi zająć dzień.

Czego nie masz, a co składa się na „narzędzie firmowe":

• Adresu, pod który wchodzi pracownik. Nie ma interfejsu dla użytkownika, który nie zna terminala.
• Logowania i uprawnień. Nie ma kont pracowników ani powiązania z kontami firmowymi, a więc i rozdziału, kto co widzi.
• Dostępu do wiedzy firmy. Model nie zna Twoich umów, ofert ani procedur i nie sięgnie po nie sam.
• Połączenia z systemami. Poczta, CRM, dysk sieciowy i baza danych są poza jego zasięgiem, dopóki ktoś ich nie połączy.
• Utrzymania. Kopii zapasowych, monitoringu i kogoś, kto zareaguje, gdy usługa przestanie odpowiadać w środę o ósmej rano.

Kolejne sekcje przechodzą przez te braki po kolei — od najłatwiejszego do najtrudniejszego.

Środowisko uruchomieniowe — od czego się zaczyna

Stos, który trzeba złożyć, ma cztery warstwy i każda opiera się na poprzedniej.

1. System operacyjny. Urządzenia pracują pod DGX OS, systemem opartym na Ubuntu i przygotowanym pod ten sprzęt. Wersje, cykl wydań i zasady bezpiecznego aktualizowania opisaliśmy osobno — zajrzyj na stronę o DGX OS.
2. Sterowniki i stos obliczeniowy. Fabrycznie na miejscu. Problem pojawia się dopiero przy aktualizacjach, gdy warstwy przestają do siebie pasować.
3. Warstwa kontenerowa. W praktyce nieodzowna. Nie dlatego, że tak wypada, tylko dlatego, że izoluje wersje bibliotek od siebie — dzięki temu aktualizacja jednego narzędzia nie zatrzymuje wszystkich pozostałych.
4. Silnik inferencyjny i interfejs. Silnik uruchamia model i wystawia go jako usługę; prostszy nadaje się na start i do pojedynczych użytkowników, wydajniejszy obsługuje wiele równoległych zapytań. Nad tym stoi interfejs przeglądarkowy, czyli to jedyne, co zobaczy pracownik.

I teraz rzecz, którą trzeba powiedzieć wprost. Nie podajemy tu konkretnych poleceń ani numerów wersji, i jest to decyzja świadoma. Ten stos zmienia się z każdym wydaniem systemu i bibliotek, a nieaktualna komenda w poradniku jest gorsza niż jej brak: kosztuje czytelnika godzinę na diagnozowanie problemu, którego nie miał. NVIDIA utrzymuje własny, oficjalny zbiór ponad czterdziestu przewodników krok po kroku dla tego sprzętu — obejmują silniki inferencyjne, środowiska programistyczne, dostrajanie modeli i konfigurację sieci. To jest właściwe miejsce po polecenia, a link znajdziesz w źródłach na końcu.

Jedna niespodzianka warta uprzedzenia: platforma Grace Blackwell GB10 opiera się na architekturze ARM, nie x86. Większość dojrzałych narzędzi AI ma wydania dla ARM, ale nie wszystkie — i to jest najczęstszy moment, w którym gotowa instrukcja z internetu przestaje działać na tej maszynie. Warto sprawdzać to przed instalacją, a nie po.

Który model wybrać — i dlaczego ta odpowiedź zmienia się co miesiąc

Nie znajdziesz tu rankingu modeli. Nie dlatego, że go nie mamy, tylko dlatego, że ranking ułożony w sierpniu 2026 r. będzie mylący w listopadzie — a ten wpis ma być użyteczny dłużej. Zamiast listy nazw: cztery kryteria, które nie zestarzeją się razem z modelami.

Kolejność decyzji jest zawsze taka sama: najpierw zadanie, potem test na własnych danych, dopiero na końcu nazwa modelu. Aktualne karty modeli, które śledzimy pod kątem lokalnych wdrożeń, zebraliśmy w dziale modele.

Konsola: bez czego się nie obejdzie

Uczciwie, bo to pytanie wraca w każdej rozmowie: etap wdrożeniowy odbywa się w terminalu. Nie ma tu instalatora z przyciskiem „dalej".

Co realnie robi się z wiersza poleceń: konfigurację sieci i pierwsze uruchomienie, instalację warstwy kontenerowej i silnika, pobranie modelu, uruchomienie usługi jako serwisu systemowego — czyli tak, żeby wstawała sama po restarcie — konfigurację interfejsu webowego, a potem aktualizacje i diagnostykę.

Ile tego jest? To nie są setki poleceń; realnie kilkanaście operacji. Ale każda wymaga rozumienia, co robi. Różnica między „skopiowałem polecenie" a „wiem, co ono ustawia" ujawnia się dopiero przy pierwszej awarii — na przykład wtedy, gdy usługa uruchomiona ręcznie w oknie terminala nie wstaje po zaniku zasilania, a osoba, która ją stawiała, jest na urlopie.

Warto natomiast wiedzieć, że to obciążenie dotyczy wyłącznie osoby wdrażającej. Po poprawnym wdrożeniu użytkownik końcowy terminala nie widzi w ogóle — wchodzi na adres w przeglądarce, loguje się i pisze.

Spięcie z systemami firmy — tu zaczyna się programowanie

To jest sekcja, dla której powstał ten wpis. Uruchomienie modelu kończy część instalacyjną i otwiera część programistyczną — i dokładnie w tym miejscu zatrzymuje się większość samodzielnych wdrożeń. Nie z braku kompetencji, tylko dlatego, że zmienia się rodzaj pracy: dotąd było konfigurowanie, teraz jest pisanie i utrzymywanie kodu.

Trzy typowe kierunki i to, co w każdym z nich realnie trzeba zbudować:

• Poczta. Model sam nie sięgnie do skrzynki. Potrzebne jest połączenie z serwerem pocztowym, reguły decydujące, które wiadomości w ogóle podlegają obsłudze, kolejka, obsługa błędów i — przy odpowiedziach wychodzących — moment zatwierdzenia przez człowieka.
• Dokumenty firmy. Żeby model odpowiadał na podstawie umów i procedur, potrzebny jest proces indeksowania i baza wektorowa: kto indeksuje, jak często, co z plikami zmienionymi. Tu leży problem pomijany najczęściej: odwzorowanie uprawnień. Pracownik nie może dostać w odpowiedzi treści z dokumentu, do którego nie ma dostępu na dysku — a domyślnie właśnie tak to zadziała.
• CRM, ERP, baza SQL. Dostęp przez API albo bezpośrednio do bazy, mapowanie pól, ograniczenie zakresu danych i kontrola tego, czego model nie ma prawa zmienić.

Każde z tych połączeń to komponent, który ktoś musi napisać, przetestować i utrzymywać przy kolejnych zmianach po stronie systemu źródłowego. Jak wyglądają gotowe warianty takich połączeń, pokazujemy w dziale integracje.

Co się psuje najczęściej

Lista z praktyki, uporządkowana według tego, jak często wraca. Wspólny mianownik jest niepokojący: żaden z tych problemów nie ujawnia się pierwszego dnia.

1. Zależności i wersje. Aktualizacja sterownika albo biblioteki potrafi zatrzymać środowisko, które działało miesiącami. To główny powód, dla którego warstwa kontenerowa nie jest fanaberią.
2. Pamięć. Model mieścił się w testach, ale przy dłuższym dokumencie albo trzech osobach naraz zaczyna brakować miejsca na kontekst. Objawia się jako błąd albo drastyczne spowolnienie — zwykle przy pierwszym poważnym zadaniu, nie przy próbach.
3. Model, który nie chce się załadować. Niewłaściwy format pliku, brak wydania dla tej architektury albo przerwane pobieranie. Zwykle najszybszy do zdiagnozowania.
4. Usługa, która nie wstaje po restarcie. Klasyk: uruchomiona ręcznie w sesji terminala zamiast jako serwis systemowy. Wychodzi przy pierwszym zaniku zasilania.
5. Wydajność spadająca przy kilku osobach. Silnik skonfigurowany pod jednego użytkownika obsługuje zapytania po kolei. Objaw: „działało świetnie, dopóki nie dołączył dział".

Kiedy jedna jednostka to za mało

Jedna maszyna to jeden budżet pamięci — i to on, a nie moc obliczeniowa, wyznacza granicę tego, co da się uruchomić. Gdy potrzebny model przestaje się mieścić, dwie jednostki spina się bezpośrednio dedykowanym łączem, co daje wspólną, powiększoną pulę pamięci. Mechanikę tego rozwiązania, wraz z pomiarami, opisaliśmy osobno — szczegóły znajdziesz na stronie o klastrze dwóch jednostek.

Zrobić samemu czy zlecić — konkretne kryteria

Zacznijmy od zdania, którego zwykle nie pisze się w tekstach sprzedających wdrożenia: jeśli masz w firmie administratora Linuksa i programistę Pythona, zrób to sam. To rozsądna decyzja, sprzęt jest do tego przeznaczony, a wiedza zostaje w firmie. Poniższe szacunki pomogą to zaplanować.

Nakład czasu — szacunki z naszych wdrożeń, nie wartości gwarantowane, stan na sierpień 2026:

• Model z interfejsem przeglądarkowym dla kilku osób: jeden do dwóch dni roboczych osoby, która robiła to wcześniej. Przy pierwszym podejściu należy założyć wyraźnie więcej — najwięcej czasu zabiera nie instalacja, lecz dobór modelu i testy na własnych danych.
• Integracja z jednym systemem firmowym: tygodnie, nie dni. Tu jest kod, testy i odwzorowanie uprawnień.
• Utrzymanie: stały, niewielki narzut — aktualizacje, kopie zapasowe, reakcja na awarie.

Zlecenie ma sens w czterech sytuacjach, i warto sprawdzić, czy któraś opisuje Twoją:

1. Nie masz tych ludzi. Najprostszy przypadek. Nauka na produkcyjnym sprzęcie za kilkanaście tysięcy złotych jest kosztowna.
2. Masz ich, ale ich czas jest wart więcej. Jeśli jedyny programista firmy przez trzy tygodnie nie rozwija produktu, koszt wdrożenia liczy się jego stawką, a nie fakturą za usługę.
3. Wdrożenie dotyka danych objętych tajemnicą. Błąd w odwzorowaniu uprawnień do dokumentów kosztuje więcej niż cała usługa — i jest to błąd, którego nikt nie zauważy, dopóki ktoś nie zobaczy cudzej umowy.
4. Potrzebujesz, żeby ktoś odpowiadał. Różnica między „uruchomił" a „odpowiada za działanie" to umowa serwisowa i czas reakcji.

Jeśli chcesz porównać własny nakład z kosztem zlecenia, zakres prac i etapy opisaliśmy na stronie wdrożenia — analiza procesu i wycena są bezpłatne. A jeśli po tym wpisie uznasz, że zrobisz to sam, to również jest dobry wynik: tekst miał zostawić Cię mądrzejszym niezależnie od tego, czy zadzwonisz.

Najczęstsze pytania

Jak uruchomić DGX Spark po wyjęciu z pudełka?

Pierwsze uruchomienie przypomina konfigurację nowego komputera z Linuksem: zasilanie, sieć, kreator wstępnej konfiguracji, konto, aktualizacja. Po tym etapie masz działającą stację z widocznym układem graficznym i gotowym stosem bibliotek — ale nie masz jeszcze narzędzia dla zespołu. Procedurę opisuje oficjalny przewodnik NVIDIA, a dla ASUS Ascent GX10 dodatkowo dokumentacja producenta urządzenia.

Czy do konfiguracji DGX Spark potrzebna jest znajomość Linuksa?

Do etapu wdrożeniowego tak — to praca w terminalu. Nie są to setki poleceń, ale każde wymaga rozumienia, co robi, bo część błędów ujawnia się dopiero po tygodniach. Użytkownicy końcowi terminala nie widzą: po wdrożeniu pracują w oknie przeglądarki.

Jaki model uruchomić na DGX Spark?

Zamiast rankingu — cztery kryteria: zajętość pamięci po kwantyzacji wraz z zapasem na kontekst, jakość w języku polskim sprawdzona na własnych dokumentach, licencja dopuszczająca użycie komercyjne oraz akceptowalny stopień kwantyzacji. Dopiero te odpowiedzi wskazują konkretny model.

Czy ASUS Ascent GX10 konfiguruje się tak samo jak DGX Spark?

W warstwie oprogramowania procedura jest zbieżna — to ta sama platforma sprzętowa i ten sam system. Różnice dotyczą obudowy, chłodzenia, portów i kanału serwisowego, a wydania systemu oraz narzędzia instalacyjne udostępnia dla swojego urządzenia producent. Przed instalacją sprawdź stronę wsparcia właśnie tego modelu, który masz.

Ile trwa przygotowanie DGX Spark do pracy w firmie?

Model z interfejsem dla kilku osób — jeden do dwóch dni roboczych osoby doświadczonej, przy pierwszym podejściu więcej. Spięcie z systemami firmy — tygodnie, nie dni, bo wymaga kodu, testów i odwzorowania uprawnień. Są to szacunki z naszych wdrożeń, nie wartości gwarantowane.

Źródła

• NVIDIA, DGX Spark User Guide — pierwsze uruchomienie, konfiguracja systemu i opis dostarczanego oprogramowania
• NVIDIA, DGX Spark Playbooks — oficjalny zbiór przewodników krok po kroku: silniki inferencyjne, środowiska, dostrajanie modeli, konfiguracja sieci. Tu szukaj konkretnych poleceń.
• NVIDIA, strona produktowa DGX Spark
• ASUS, Ascent GX10 — pliki do pobrania i instrukcje oraz FAQ producenta

Stan na wrzesień 2026. Nie podajemy w tym wpisie konkretnych poleceń, numerów wersji ani wyników wydajności — stos oprogramowania zmienia się z każdym wydaniem, a nieaktualna instrukcja jest gorsza niż jej brak. Po polecenia odsyłamy do oficjalnej dokumentacji wymienionej wyżej. Podane nakłady czasu są szacunkami z naszych wdrożeń.