Seria: dobór stacji pod lokalne AI · Część 06 / 06
Czas złożyć całą serię w jedną, praktyczną całość. Wiemy już, co obciąża sprzęt, jak dobrać GPU, procesor, pamięć, dysk, sieć i chłodzenie. Teraz przekładamy to na gotowe konfiguracje pod konkretne zastosowania, liczymy realny koszt posiadania i zostawiamy checklistę, która przeprowadzi Cię od wymagań do zamówienia.
To ostatnia część przewodnika. Jeśli dołączasz w tym miejscu, wcześniejsze odcinki tłumaczą każdy podzespół z osobna. Tu skupiamy się na decyzji końcowej: co kupić, w jakim układzie i czy w ogóle budować u siebie, czy wynająć w chmurze.
01 Ścieżka decyzji w siedmiu krokach
Dobór stacji pod lokalne AI to nie zgadywanie, lecz prosta sekwencja. Każdy krok wynika z poprzedniego, a całość streszcza dotychczasowe części serii.
- 1. Model i precyzja: jaki model i w jakim formacie (FP8, FP4, INT4) chcesz uruchomić. To wyznacza, ile model waży (część 1).
- 2. VRAM: wagi modelu plus KV cache (kontekst razy liczba sesji) plus około 15% narzutu. Tak liczysz potrzebną pamięć GPU (część 1).
- 3. GPU: dobierasz klasę karty pod ten VRAM i obciążenie, od RTX PRO 6000 po H200 i Blackwell (część 2).
- 4. CPU, RAM, platforma: dość rdzeni, linii PCIe i szybkiej pamięci, by nie głodzić karty. U nas Intel-first (część 3).
- 5. Dysk i sieć: szybkie NVMe pod modele i bazy RAG; sieć dopiero, gdy skalujesz na wiele węzłów (część 4).
- 6. Zasilanie, chłodzenie, forma: budżet mocy, powietrze czy ciecz, obudowa dopasowana do środowiska (część 5).
- 7. Model wdrożenia: on-premise czy chmura, w zależności od wykorzystania, prywatności i kosztu (ta część).
02 Wzór i przykład doboru
Sercem całej decyzji jest jeden wzór na zapotrzebowanie na pamięć GPU, który poznaliśmy w części 1:
VRAM ≈ wagi modelu + (KV cache na sesję × liczba sesji) + ~15% narzutu
Prześledźmy go na konkretnym przykładzie. Załóżmy model 70B w precyzji FP8 dla zespołu, z około 20 równoczesnymi sesjami.
Wagi modelu 70B w FP8 to około 70 GB. Doliczając KV cache dla 20 sesji i narzut, realnie potrzeba 90 do 110 GB pamięci. Mieści się to na jednej lub dwóch kartach RTX PRO 6000 (96 GB) albo na H200 (141 GB). Do tego procesor Intel Xeon w, 256 GB RAM ECC, macierz NVMe, sieć 25 GbE i obudowa rack 2U z redundantnym zasilaniem. Pobór mocy rzędu 2 do 3 kW.
Ten sam tok rozumowania działa w obie strony: mniejszy model albo mniej użytkowników to mniejsze wymagania, większy model MoE albo dłuższy kontekst to skok zapotrzebowania na pamięć. Wszystko zaczyna się od pierwszego kroku, czyli wyboru modelu i precyzji.
03 Gotowe scenariusze i konfiguracje
Poniższa tabela spina całą serię: dla każdego typowego wdrożenia podajemy spójny zestaw podzespołów, od karty po zasilanie. Traktuj ją jako punkt startowy, który potem dopina się do konkretnych wymagań.
| Profil wdrożenia | GPU | CPU i RAM | Dysk i sieć | Forma | Pobór |
|---|---|---|---|---|---|
| Prototyp, 1 deweloper | DGX Spark lub 1× RTX PRO 6000 | Intel Core Ultra / Xeon w, 64 GB | NVMe Gen5, 1/10 GbE | mini / tower | ~1 kW |
| Stacja AI zespołu | 2–4× RTX PRO 6000 | Intel Xeon w, 128–256 GB ECC | NVMe U.2 (RAID), 10/25 GbE | wieża workstation | 2–3 kW |
| Serwer inferencyjny on-prem | H200 lub 2–8× RTX PRO 6000 Server | Intel Xeon 6 (AMX), 256 GB–1 TB ECC | macierz NVMe + GDS, 25/100 GbE | rack 2–4U | 3–10 kW |
| Edge / hala produkcyjna | BoxPC z RTX Blackwell lub Jetson | Intel, pamięć unified / 64 GB | NVMe lokalnie | fanless BoxPC | 60–300 W |
| Skala / klaster | B200 / B300, platforma MGX | Grace lub Xeon 6 / EPYC | NVMe rack-scale, InfiniBand / Spectrum-X | MGX, chłodzenie cieczą | 30–140 kW / szafa |
Serwerowa platforma AI Elmatic pod karty NVIDIA RTX, do pracy 24/7. Zobacz model
Widać tu wszystkie zasady z poprzednich części w działaniu: im większa skala, tym szybsza pamięć, więcej kart, mocniejsza sieć i poważniejsze chłodzenie, ale też wyższy koszt. Najczęstszy wybór u klientów to wiersz wyróżniony, czyli serwer inferencyjny on-premise. Zobacz gotowe komputery Elmatic z kartami NVIDIA RTX.
04 Stack programowy
Sprzęt to połowa sukcesu. Ta sama karta potrafi obsłużyć dwa razy więcej użytkowników albo dwa razy mniej, w zależności od oprogramowania. Warto znać kluczowe elementy stosu.
- CUDA i sterowniki: fundament całego ekosystemu NVIDIA, podstawa pod wszystkie biblioteki.
- Silniki inferencyjne: vLLM i TensorRT-LLM dają maksymalną wydajność dzięki batchingowi i współdzieleniu prefiksu; Ollama i llama.cpp to proste wdrożenie lokalne, także na samym CPU.
- NVIDIA AI Enterprise: produkcyjne mikroserwisy NIM, wsparcie z SLA, wirtualizacja vGPU i orkiestracja, gdy wdrażasz dla realnych użytkowników (szczegóły w części 2).
- Intel AMX: akcelerator macierzowy w procesorach Xeon, który przyspiesza inferencję na samym CPU (część 3).
Dobór oprogramowania idzie w parze ze sprzętem. Serwer z vLLM, współdzieleniem prefiksu i właściwą kwantyzacją obsłuży znacznie więcej zapytań niż naiwna konfiguracja na tej samej karcie.
05 Chmura ma swoje problemy
Gdy konfiguracja jest już dobrana, pojawia się kuszące pytanie: po co w ogóle kupować sprzęt, skoro moc można wziąć z chmury. Chmura ma swoje miejsce, ale niesie też ograniczenia, które w lokalnym AI po prostu znikają.
Zależność i niepewność
Płacisz za czas i tokeny, a rachunek rośnie z użyciem i bywa trudny do zaplanowania. Dochodzi zależność od dostawcy oraz dane firmowe poza Twoją infrastrukturą.
Twój sprzęt, twoje zasady
Dane nie opuszczają firmy, koszt jest stały i policzalny, a o tym, jaki model i jak długo działa, decydujesz Ty. Niezależność od cudzych cenników i polityk.
Najczęstsze problemy chmury, które warto rozważyć, zanim oprze się na niej produkcję:
- Nieprzewidywalne i rosnące ceny: stawki za godzinę i za token potrafią się zmieniać, a koszt skaluje się wprost z użyciem. Trudno zaplanować budżet na rok.
- Zależność od dostawcy: zmiany API, limitów, dostępności GPU czy wycofanie modelu dzieją się poza Twoją kontrolą i potrafią wymusić przerabianie wdrożenia.
- Prywatność i suwerenność danych: wrażliwe dane firmowe trafiają do zewnętrznego operatora. To realne wyzwanie dla RODO, tajemnicy handlowej i wymogów branżowych.
- Latencja i zależność od łącza: każde zapytanie wędruje przez internet, a brak łącza oznacza brak AI. Na hali produkcyjnej czy na brzegu sieci to często dyskwalifikuje chmurę.
- Brak pełnej kontroli: współdzielone zasoby, kolejki i limity w godzinach szczytu oznaczają zmienną wydajność, na którą nie masz wpływu.
W lokalnym AI te problemy znikają u źródła. Dane zostają u Ciebie, koszt jest przewidywalny, a kontrola pełna. To nie tylko kwestia ceny, lecz niezależności i bezpieczeństwa, które dla wielu firm są warunkiem wejścia w AI.
06 Rachunek po stronie lokalnego AI
Do argumentów o kontroli i prywatności dochodzi twardy rachunek. Przy stałym, dużym ruchu inferencyjnym sprzęt u siebie jest po prostu tańszy, a kluczową zmienną jest wykorzystanie, czyli jak intensywnie maszyna realnie pracuje.
| Wykorzystanie | Zwrot z inwestycji on-premise | Najlepszy wybór |
|---|---|---|
| 90%+ (produkcja 24/7) | 7–14 miesięcy | lokalnie |
| 60–80% (aktywny development) | 14–24 miesiące | lokalnie przeważnie |
| 40–60% (okresowo) | 24–36+ miesięcy | zależnie |
| poniżej 40% / zrywami | dłużej | chmura na start |
Owszem, lokalny sprzęt ma swoje koszty: energia (serwer rzędu 10 kW pobiera prąd bez przerwy), chłodzenie, sieć i utrzymanie. Mimo to przy stałym, dużym obciążeniu rachunek wychodzi korzystnie, a koszt wygenerowania miliona tokenów bywa wielokrotnie niższy niż w API chmurowym.
Im stabilniejsze i większe obciążenie, tym wyraźniej wygrywa sprzęt u siebie. Chmura zostaje sensowna do prototypów i nagłych pików, ale serce produkcyjnego lokalnego AI najlepiej trzymać na własnym sprzęcie: taniej w dłuższym horyzoncie i bez oddawania danych na zewnątrz.
07 Podsumowanie serii
Przeszliśmy całą drogę doboru stacji pod lokalne AI, od fundamentów po gotową konfigurację:
- Część 1: fundamenty, czyli trzy liczby (VRAM, przepustowość, moc) i KV cache.
- Część 2: GPU i akceleratory NVIDIA, od RTX po Blackwell.
- Część 3: CPU, RAM i platforma, z naciskiem na Intela.
- Część 4: pamięć masowa i sieć, łącznie z układami komunikacyjnymi.
- Część 5: zasilanie, chłodzenie i form factor, od BoxPC po MGX.
- Część 6: dobór w praktyce, scenariusze i TCO (ta część).
Myśl przewodnia całej serii jest prosta: w lokalnym AI najpierw liczą się pojemność i przepustowość pamięci, a reszta podzespołów to konsekwencje tej decyzji. Kto rozumie te zależności, nie przepłaca ani nie kupuje sprzętu, który nie udźwignie modelu.
Jeśli planujesz wdrożenie lokalnego AI, nie musisz przechodzić tej drogi sam. Nasi inżynierowie pomogą przełożyć Twoje wymagania na konkretną, sprawdzoną konfigurację, od pojedynczej stacji po klaster. Przejrzyj ofertę Elmatic albo zacznij od naszego centrum wiedzy.
