Budowa Własnego Systemu AI

Pokusa DIY

Z zewnątrz wygląda prosto. Serwer, kilka GPU, modele open-source z Hugging Face — i masz własną, prywatną sztuczną inteligencję. Żadnych danych opuszczających budynek. Brak uzależnienia od dostawcy. Pełna kontrola.

Pokusa jest zrozumiała. Ceny GPU spadły. Modele open-weight stały się naprawdę użyteczne. YouTube jest pełen tutoriali pokazujących model 7B działający na domowym komputerze. Dystans między “ktoś uruchomił to w domu” a “to jest infrastruktura produkcyjna dla wrażliwej pracy prawniczej” jest niewidoczny — dopóki nie zamkniesz go samodzielnie, zazwyczaj napotykając każdy możliwy scenariusz awarii po kolei.

Ten artykuł dotyczy właśnie tego dystansu.

Czym Naprawdę Jest System AI

Zanim przejdziemy do omówienia sprzętu, warto zdefiniować, co właściwie budujemy. Pojęcie “system AI” obejmuje kilka odmiennych konfiguracji:

Serwer wnioskowania (inference server): Dedykowany sprzęt zoptymalizowany do uruchamiania jednego lub kilku modeli językowych w odpowiedzi na zapytania. To najczęstszy przypadek wdrożenia dla obciążeń związanych z analizą dokumentów — system odbiera zapytania, uruchamia model, zwraca odpowiedzi. Kluczowymi wymiarami wydajności są latencja i przepustowość.

Węzeł treningowy lub fine-tuningu: Sprzęt zdolny do aktualizowania wag modelu. Trening jest obliczeniowo o wiele bardziej intensywny niż wnioskowanie, wymaga innych wzorców dostępu do pamięci i rzadko jest odpowiedni dla wewnętrznych wdrożeń prawnych lub medycznych. Większość organizacji korzystających z AI on-premises powinna uruchamiać wyłącznie wnioskowanie.

Wdrożenie brzegowe (edge deployment): Ograniczony sprzęt uruchamiający mniejsze, skwantyzowane modele dla konkretnych zadań — klasyfikacja dokumentów, ekstrakcja encji, przetwarzanie formularzy. Inne cele optymalizacji niż pełny serwer wnioskowania.

W przypadku obciążeń prawnych i medycznych prawie zawsze mówimy o serwerach wnioskowania — systemach uruchamiających wstępnie wytrenowane modele do analizy zapytań dokumentowych. Ograniczenie to nadal pozostawia znaczną złożoność.

Wnioskowanie GPU vs. CPU

Nowoczesne modele językowe to maszyny do mnożenia macierzy. Zostały zaprojektowane z myślą o sprzęcie GPU i osiągają najlepsze wyniki, gdy ich obliczenia mogą być zrównoleglone na tysiącach rdzeni GPU.

Wnioskowanie na CPU jest możliwe dzięki skwantyzowanym modelom (llama.cpp jako kanoniczny przykład), ale jest wolniejsze o rząd wielkości dla modeli powyżej kilku miliardów parametrów. Dla interaktywnego użycia — prawnik analizujący dokument i oczekujący odpowiedzi w ciągu kilku sekund — wnioskowanie CPU jest niewystarczające dla czegokolwiek poza małymi modelami (7B parametrów i poniżej, i tylko z 4-bitową kwantyzacją).

Dla każdego produkcyjnego obciążenia z modelami o 13B parametrów i więcej, dedykowany sprzęt GPU nie jest opcjonalny.

Warstwa Sprzętowa: Więcej Niż Tylko GPU

GPU jest najbardziej widocznym komponentem, ale nie jedynym, który ma znaczenie.

Wybór GPU: VRAM Jest Ograniczeniem Decydującym

Przy wyborze GPU do wnioskowania, VRAM (pamięć wideo) jest ważniejsza niż przepustowość obliczeniowa. Cały model musi zmieścić się w VRAM podczas wnioskowania; jeśli nie mieści się, system albo odmawia załadowania modelu, albo zaczyna używać pamięci RAM jako przepełnienia — w którym to momencie szybkość wnioskowania spada do poziomów nienadających się do produkcji.

Związek między rozmiarem modelu a wymaganiami VRAM zależy od kwantyzacji, ale jako przybliżone wytyczne dla wnioskowania 16-bitowego (FP16/BF16):

Rozmiar Modelu	Minimalne VRAM	Zalecane VRAM
7B	14 GB	16 GB
13B	26 GB	32 GB
34B	68 GB	80 GB
70B	140 GB	2× 80 GB

Kwantyzacja (redukcja wag z 16-bitowych do 8-bitowych lub 4-bitowych) znacznie zmniejsza wymagania VRAM — model 7B w 4-bitowej kwantyzacji może działać w mniej niż 5 GB. Ale kwantyzacja wprowadza kompromisy dotyczące dokładności, które mają znaczenie w zadaniach prawniczego rozumowania, gdzie precyzja interpretacji języka jest sednem sprawy.

Konsumenckie GPU (RTX 3090, 4090) mają maksymalnie 24 GB VRAM. Produkcyjne obciążenia wnioskowania przy 34B+ parametrach wymagają GPU klasy serwerowej: NVIDIA A100 (40 GB lub 80 GB), H100 (80 GB) lub H200. Różnica w kosztach jest znaczna — GPU klasy serwerowej kosztują 40 000–120 000+ zł za kartę.

Wnioskowanie wielokartowe (używanie NVLink lub PCIe do podziału modelu między karty) jest technicznie wykonalne, ale wprowadza własną złożoność: latencję komunikacji między GPU, konfigurację sterowników, wsparcie frameworka i wyzwania debugowania, które mnożą się z każdą dodatkową kartą.

CPU i Pamięć RAM: Wąskie Gardło Przepustowości

Nawet z wydajnym GPU, procesor i pamięć systemowa wpływają na wydajność wnioskowania w sposób, który nie jest oczywisty.

Podczas ładowania modelu wagi są przenoszone z pamięci masowej do pamięci RAM, a następnie do VRAM GPU. Przepustowość pamięci — szybkość przesyłania danych między komponentami — często jest czynnikiem ograniczającym dla latencji pierwszego tokenu. Serwerowe procesory z kanałami RAM o wysokiej przepustowości (DDR5 ECC) i szybkimi połączeniami PCIe 5.0 mają większe znaczenie niż surowa liczba rdzeni.

W systemach obsługujących wielu równoczesnych użytkowników — realistyczny scenariusz w kancelarii prawnej — CPU obsługuje również planowanie zapytań, zarządzanie kontekstem i wszystkie obliczenia poza GPU. Niedoszacowanie CPU powoduje opóźnienia kolejkowania, które pojawiają się jako nieprzewidywalne skoki latencji pod obciążeniem.

Pamięć Masowa: NVMe dla Szybkiego Ładowania Modeli

Model o 70B parametrach waży około 140 GB w formacie FP16. Ładowanie z dysku talerzowego zajmuje minuty. Z dysku NVMe ładowanie trwa 30–60 sekund. W systemie, który może potrzebować zamiany modeli lub restartu po konserwacji, ta różnica ma znaczenie operacyjne.

Korporacyjne dyski NVMe (PCIe Gen 4 lub Gen 5) są niezbędne dla wdrożeń produkcyjnych. Konsumenckie dyski NVMe mają niższe oceny trwałości zapisu i nie są odpowiednie dla systemów obsługujących ciągłe operacje I/O.

Zasilanie i Chłodzenie: Tam Gdzie Infrastruktura Spotyka Elektrykę

Pojedynczy GPU NVIDIA H100 ma moc projektową (TDP) wynoszącą 700 watów. Serwer z dwoma GPU może pobierać 2 000–3 000 watów pod obciążeniem. To nie jest stacja robocza; to urządzenie przemysłowe z przemysłowymi wymaganiami zasilania.

Produkcyjne serwery AI wymagają:

Dedykowanych obwodów 230V/400V: Standardowe gniazdka biurowe są niewystarczające
UPS (Zasilacza Awaryjnego): Nagłe odcięcie zasilania podczas wnioskowania może uszkodzić aktywny stan; UPS zapewnia czas na bezpieczne wyłączenie
Właściwego chłodzenia rack: Serwerowe GPU wymagają przepływu powietrza, który zapewniają serwery rack; konfiguracje wieżowe w szafce serwerowej stanowią zagrożenie pożarowe
Planowania PUE: Efektywność Wykorzystania Zasilania — stosunek całkowitego zużycia energii obiektu do energii urządzeń IT — znacząco wpływa na koszty eksploatacji w skali

Wiele organizacji odkrywa te wymagania dopiero po dostarczeniu sprzętu. Same prace elektryczne mogą dodać tygodnie do harmonogramu wdrożenia.

Sieć: Korporacyjna Przepustowość dla Konfiguracji Wielowęzłowych

Wdrożenia jednowęzłowe wymagają standardowego okablowania 10GbE — wystarczającego dla większości obciążeń wnioskowania.

Konfiguracje wielowęzłowe (gdzie model rozciąga się na wiele serwerów) wymagają 25GbE lub szybszego połączenia między węzłami, a dla poważnych rozproszonych wdrożeń wnioskowania — sieci RDMA (Remote Direct Memory Access) — InfiniBand lub RoCE — aby zminimalizować latencję komunikacji między węzłami. Jest to wyspecjalizowana infrastruktura wymagająca ekspertyzy do konfiguracji i utrzymania.

Warstwa Oprogramowania: Niewidoczna Złożoność

Sprzęt jest widoczną częścią góry lodowej. Stos oprogramowania — i wymagana do jego zarządzania ekspertyza — znajduje się poniżej powierzchni.

Podstawowe Zabezpieczenie Systemu Operacyjnego

Produkcyjny serwer AI jest cennym punktem końcowym w sieci. Przechowuje wrażliwe dokumenty, uruchamia potężną infrastrukturę obliczeniową i obsługuje API dla użytkowników wewnętrznych. Wymaga tego samego zabezpieczenia, które stosowałbyś do dowolnego serwera produkcyjnego: minimalnej liczby zainstalowanych pakietów, wyłączonych niepotrzebnych usług, zapory z jawną listą dozwolonych adresów, automatycznego łatania systemu operacyjnego i sterowników oraz zdefiniowanej konfiguracji bazowej, która może być audytowana.

Uruchomienie oprogramowania do obsługi modeli na domyślnej instalacji Ubuntu Server nie jest zabezpieczoną konfiguracją bazową. Wypełnienie luki między domyślną instalacją a zabezpieczoną konfiguracją bazową wymaga znacznego wysiłku — i musi być utrzymywane w sposób ciągły wraz z aktualizacjami pakietów.

Stos Sterowników: Problem Macierzy Kompatybilności

Sterowniki GPU NVIDIA, CUDA, cuDNN, PyTorch i wybrany framework wnioskowania mają określone wymagania kompatybilności. Macierz obsługiwanych kombinacji nie jest pobłażliwa: niezgodność między wersją CUDA a wersją sterownika powoduje ciche błędy lub awarie, a nie informatywne komunikaty o błędach.

Gdy NVIDIA wydaje nowy sterownik, może on zerwać kompatybilność z wersją CUDA, dla której skompilowano framework wnioskowania. Gdy chcesz zaktualizować framework wnioskowania, może to wymagać nowszej wersji CUDA, która wymaga nowszego sterownika. Te kaskadowe zależności są zarządzalne, ale wymagają starannej uwagi i zdefiniowanego procesu aktualizacji.

W środowisku produkcyjnym — gdzie stabilność jest ważniejsza niż posiadanie najnowszej wersji — oznacza to utrzymywanie przetestowanego, przypiętego stosu oprogramowania i traktowanie każdej aktualizacji jako zdarzenia zarządzania zmianami z możliwością wycofania.

Frameworki Wnioskowania: Nie Wymienne

Główne frameworki wnioskowania oferują różne kompromisy:

vLLM: Wysokoprzepustowa obsługa z PagedAttention, silne wsadowanie wieloużytkownikowe, najlepszy dla produkcyjnych wdrożeń w stylu API. Wymaga środowiska uruchomieniowego Python, dobrego wsparcia CUDA, bardziej złożonej konfiguracji.

llama.cpp: Działa na CPU i GPU, silne wsparcie kwantyzacji, mniejsza latencja dla pojedynczych zapytań, łatwiejszy do uruchomienia. Mniej zoptymalizowany dla współbieżnych scenariuszy wieloużytkownikowych.

TensorRT-LLM: Produkcyjna biblioteka wnioskowania NVIDIA, najwyższa przepustowość na sprzęcie NVIDIA, ale wymaga kroków kompilacji modelu, które dodają złożoność i czas do wdrożenia i aktualizacji modeli.

Ollama: Przyjazna dla programistów nakładka na llama.cpp, doskonała do testowania, nie zaprojektowana dla produkcyjnych wdrożeń wieloużytkownikowych.

Wybór niewłaściwego frameworka dla charakterystyki obciążenia oznacza albo pozostawianie wydajności na stole, albo uruchamianie infrastruktury, która nie jest w stanie obsłużyć realistycznej współbieżności. Właściwy wybór zależy od rozmiaru modelu, oczekiwanej liczby równoczesnych użytkowników, wymagań dotyczących latencji i konfiguracji sprzętu — co wszystko wymaga analizy specyficznej dla wdrożenia.

Monitorowanie i Obserwowalność

Produkcyjny serwer wnioskowania wymaga monitorowania: wykorzystania GPU, użycia pamięci GPU (VRAM), przepustowości wnioskowania (zapytania na sekundę, tokeny na sekundę), głębokości kolejki i percentyli latencji (p50, p95, p99).

Bez monitorowania nie dowiesz się, kiedy system zbliża się do pojemności, kiedy aktualizacja sterownika spowodowała regresję ani kiedy określony wzorzec zapytań powoduje fragmentację VRAM. Dowiesz się o tym, gdy użytkownicy zgłoszą, że system jest wolny lub niereagujący.

Skonfigurowanie sensownego monitorowania wymaga zintegrowania telemetrii GPU (DCGM lub nvidia-smi), metryk aplikacji z frameworka wnioskowania i metryk infrastruktury w spójny pulpit nawigacyjny z alertami.

Ukryte Punkty Awarii

Poza podstawową złożonością, produkcyjna infrastruktura AI ma specyficzne tryby awarii, które nie są oczywiste, dopóki się ich nie napotka:

Dławienie termiczne pod stałym obciążeniem: GPU są zaprojektowane do zmniejszania taktowania, gdy się przegrzewają. W systemie bez odpowiedniego chłodzenia GPU, który działa doskonale podczas krótkich testów, będzie dławiony podczas wielogodzinnych stałych obciążeń, obniżając przepustowość. Objawia się to jako stopniowa degradacja wydajności, trudna do zdiagnozowania bez monitorowania temperatury.

Fragmentacja VRAM przy równoczesnych sesjach: Gdy wielu użytkowników wykonuje równoczesne zapytania, framework wnioskowania alokuje i zwalnia bloki VRAM. Z czasem, szczególnie przy danych wejściowych o zmiennej długości, VRAM może ulec fragmentacji — jest wystarczająca łączna wolna VRAM, ale nie w ciągłym bloku wystarczająco dużym do obsłużenia nowego zapytania. Skutkuje to losowo wyglądającymi awariami lub zawieszeniami zapytań pod obciążeniem.

Konflikty wersji sterowników i bibliotek: Opisane powyżej, ale warte podkreślenia: to najczęstsza przyczyna tajemniczych błędów wnioskowania w systemach, które “wczoraj działały”. Nieplanowane aktualizacje sterowników (z automatycznego łatania systemu operacyjnego) są szczególnie częstym wyzwalaczem.

Awaria komponentów i nieplanowany przestój: Serwery GPU klasy serwerowej mają Średni Czas Między Awariami (MTBF) mierzony w latach, ale w systemie produkcyjnym nawet szansa 1 na 1000 na rok jest nietrywalna. Gdy GPU ulegnie awarii, jaki jest proces odtwarzania? Czy jest części zamiennych? Czy wagi modeli są zarchiwizowane? Ile czasu zajmie przywrócenie usługi? Te pytania muszą mieć odpowiedzi przed awarią, a nie po.

Powierzchnia ataku tworzona przez API wnioskowania: Każdy punkt końcowy API obsługujący zapytania wnioskowania jest powierzchnią ataku. Bez właściwego uwierzytelniania, autoryzacji i ograniczania szybkości, lokalne API wnioskowania może być odpytywane przez dowolny system w tej samej sieci — potencjalnie ujawniając poufną zawartość dokumentów.

Co Zajmuje Lata, by się Nauczyć

Niektóre z najbardziej konsekwentnych decyzji w infrastrukturze AI nie są udokumentowane w żadnym przewodniku dla początkujących:

Optymalne strategie wsadowania: Frameworki wnioskowania mogą przetwarzać wiele zapytań jednocześnie (wsadowanie), wymieniając latencję poszczególnych zapytań na ogólną przepustowość. Optymalny rozmiar wsadu zależy od modelu, sprzętu, wzorców zapytań i wymagań dotyczących latencji. Nieprawidłowe ustawienie tego parametru albo marnuje pojemność GPU, albo sprawia, że system wydaje się wolny dla interaktywnego użycia.

Kompromisy kwantyzacji: Kwantyzacja zmniejsza rozmiar modelu i przyspiesza wnioskowanie kosztem pewnej dokładności. Ale wpływ na dokładność nie jest jednolity — różni się w zależności od typu zadania, a w przypadku analizy dokumentów prawnych, konkretne kompromisy mają znaczenie. Redukcja modelu z FP16 do 4-bitowego GGUF może spowodować błędne odczytywanie określonych typów klauzul, wprowadzić subtelne błędy w ekstrakcji encji lub utratę niuansów w interpretacji języka prawniczego. Ocena tych kompromisów dla konkretnego obciążenia wymaga ekspertyzy dziedzinowej.

Zarządzanie wersjami modeli: Wersje modeli open-weight proliferują szybko. Model, który działa dobrze dzisiaj, może zostać zastąpiony nową wersją o innych charakterystykach. Zarządzanie tym w środowisku produkcyjnym — testowanie nowych wersji, przeprowadzanie porównań A/B, wdrażanie aktualizacji bez zakłócania pracy użytkowników i wycofywanie, jeśli aktualizacja powoduje regresje — wymaga zdyscyplinowanego procesu.

Odtwarzanie po awarii dla wag modeli: Pliki wag modeli są duże (14–140 GB na model), niezmienne i krytyczne. Wymagają strategii tworzenia kopii zapasowych uwzględniających ich rozmiar: standardowe oprogramowanie do tworzenia kopii zapasowych często nie jest dobrze przystosowane do wielogigabajtowych bloków danych. Odtwarzanie z kopii zapasowej musi być testowane; kopia zapasowa, z której nigdy nie przywracano, to kopia zapasowa, której faktycznie nie masz.

Kiedy DIY Ma Sens — a Kiedy Nie

Czynnik	DIY	Zarządzane On-Premises
Czas do produkcji	Tygodnie do miesięcy	Dni do tygodni
Koszt początkowy	Tylko koszt sprzętu	Sprzęt + usługi profesjonalne
Bieżące utrzymanie	Wymagany wewnętrzny zespół	Objęte umową wsparcia
Pozycja zgodności	Ręczna konfiguracja, własny audyt	Wstępnie zwalidowana, udokumentowana
Ryzyko podczas integracji	Wysokie	Niskie
Wymagana ekspertyza	Głęboka (sprzęt + oprogramowanie)	Minimalna

DIY ma sens, gdy dysponujesz dedykowanymi inżynierami infrastruktury z konkretnym doświadczeniem we wdrożeniach AI, zespołem ds. zgodności, który może zbudować i audytować bazę zabezpieczeń, czasem na właściwe przygotowanie i tolerancją na bieżące utrzymanie. Ten profil opisuje niewielką liczbę dużych organizacji technologicznych.

Dla kancelarii prawnych i organizacji opieki zdrowotnej — gdzie kluczową kompetencją jest praca prawnicza lub kliniczna, a nie inżynieria infrastruktury — ryzyko i koszt czasowy DIY zazwyczaj przeważają nad oszczędnościami.

Podejście Tacitus

Protokół Supply Drop Tacitus został zaprojektowany specjalnie w celu wyeliminowania ryzyka integracji, które sprawia, że własnoręcznie budowana infrastruktura AI jest kosztowna.

Wstępnie zwalidowane konfiguracje sprzętowe są testowane pod kątem stosu oprogramowania przed dostawą. Wersje sterowników, CUDA, framework wnioskowania i oprogramowanie aplikacyjne są testowane razem jako jednostka — nie składane na miejscu po raz pierwszy. Baza zabezpieczeń jest zdefiniowana, udokumentowana i stosowana przed dostarczeniem systemu. Monitorowanie jest skonfigurowane. Procedury tworzenia kopii zapasowych są ustalone.

Wynikiem jest system gotowy do produkcji od pierwszego dnia, z określoną ścieżką wsparcia dla awarii komponentów i aktualizacji oprogramowania, które nieuchronnie nastąpią. Ekspertyza, której zgromadzenie zajęło lata, jest osadzona w projekcie systemu, a nie pozostawiona jako ćwiczenie dla zespołu instalacyjnego.

Jeśli oceniasz infrastrukturę AI on-premises i chcesz zrozumieć, jak wygląda wdrożenie klasy produkcyjnej dla Twojego konkretnego obciążenia i wymagań dotyczących zgodności, techniczny briefing jest dobrym punktem wyjścia.

Poproś o briefing, aby omówić swoje wymagania infrastrukturalne z zespołem Tacitus.