Jak złożyć komputer do lokalnego uruchamiania dużych modeli językowych LLM w firmie

Po co w firmie własny komputer do LLM zamiast chmury

Korzyści biznesowe i organizacyjne z lokalnego uruchamiania LLM

Stacja robocza lub serwer do lokalnego uruchamiania dużych modeli językowych LLM daje przede wszystkim kontrolę. Nie chodzi tylko o to, że sprzęt stoi fizycznie w Twoim biurze, ale o pełną kontrolę nad tym, jakie dane trafiają do modelu, jakie logi są przechowywane i jak wygląda konfiguracja zabezpieczeń. Dla wielu firm to kluczowa przewaga nad korzystaniem wyłącznie z publicznych API w chmurze.

Drugi aspekt to przewidywalne koszty. Przy stałym obciążeniu – gdy z modelu korzysta codziennie zespół handlowy, marketing, IT i dział prawny – koszty API potrafią rosnąć bardzo szybko. Własny komputer do AI i dużych modeli wymaga większej inwestycji na starcie, ale miesięczny koszt realnie zaczyna się sprowadzać do energii, amortyzacji i ewentualnego serwisu. Przy średnim i wysokim obciążeniu lokalne uruchamianie LLM w firmie bywa tańsze już po kilku–kilkunastu miesiącach.

Do tego dochodzi kwestia opóźnień. Komputer on-premise stoi w tej samej sieci co użytkownicy, więc zapytanie trafia do serwera LLM szybciej niż przez publiczny Internet. Różnica w sekundach może wydawać się drobiazgiem, ale przy intensywnej pracy (np. przepytywanie modelu o duży zbiór dokumentów) wpływa na odczuwalną płynność pracy całego zespołu.

Na koniec aspekt psychologiczny: wielu pracowników łatwiej przekonać do korzystania z narzędzia, jeśli jasno komunikujesz, że dane nie wychodzą na zewnątrz. W środowiskach mocno regulowanych (kancelarie, domy mediowe, firmy inżynieryjne) to wręcz warunek konieczny, aby ktokolwiek odważył się wprowadzić do modelu wrażliwe informacje.

Kiedy chmura przestaje być opłacalna przy LLM

Chmura jest świetna na start – niski próg wejścia, żadnych inwestycji w sprzęt, płacisz tylko za zużycie. Problem zaczyna się, gdy model przestaje być gadżetem do testów, a staje się narzędziem codziennej pracy. Typowy scenariusz: w firmie powstaje wewnętrzny chatbot, który zna procedury, ofertę i dokumenty. Korzystają z niego dziesiątki osób, dzień w dzień.

Przy rosnącym użyciu pojawiają się trzy sygnały, że czas spojrzeć na własny sprzęt:

• rachunki za API są już stałym, zauważalnym składnikiem kosztów operacyjnych,
• rośnie liczba zapytań o możliwość przetwarzania poufnych dokumentów, których nie chcesz wysyłać do zewnętrznego dostawcy,
• zespół IT zaczyna tworzyć bardziej zaawansowane narzędzia, pipeline’y i integracje – a to wymaga stabilnego, przewidywalnego środowiska.

Granica opłacalności zależy od konkretnego cennika i skali wykorzystania, ale prosta zasada brzmi: jeśli model pracuje większość dnia roboczego, a nie tylko okazjonalnie, własny komputer do LLM bardzo szybko zaczyna się finansowo bronić. Nawet pojedyncza mocna stacja robocza może znacząco obniżyć koszty w porównaniu z „wynajmem” mocy w chmurze, zwłaszcza gdy używacie modeli open-source zamiast płatnych API.

Bezpieczeństwo danych, RODO i umowy z klientami

Dla firm działających w UE kluczowe są ograniczenia wynikające z RODO, NDA i zapisów umów z klientami. Wysyłanie dokumentów, raportów czy korespondencji przez zewnętrzne API może być trudne do uzasadnienia, jeśli nie masz bardzo precyzyjnie opisanych warunków przetwarzania danych. Konfiguracja serwera LLM on-premise rozwiązuje część tych problemów – dane nie opuszczają wewnętrznej sieci, a Ty masz kontrolę nad logami i retencją.

Własny komputer do LLM pozwala też stworzyć jasną politykę: co wolno użytkownikom, jak długo przechowywane są zapytania, kto administruje systemem. To przekłada się na realne bezpieczeństwo, ale też na spokój podczas audytów. W rozmowach z klientami łatwiej wytłumaczyć, że analizy robi „wewnętrzny asystent AI”, uruchamiany na firmowym serwerze niż „jakieś API w chmurze, ale obiecujemy, że jest bezpieczne”.

Jakie modele LLM chcesz uruchamiać i do czego je wykorzystasz

Rodzaje zadań – od prostego czatu po ciężkie przetwarzanie dokumentów

Zanim wybierzesz podzespoły, trzeba jasno określić, do czego komputer ma służyć. Sprzęt do lekkiego czatu dla kilku osób wygląda inaczej niż maszyna do masowego przetwarzania tysięcy PDF-ów czy trenowania wyspecjalizowanych modeli w dziale R&D.

Najczęstsze scenariusze użycia w MŚP:

• Asystent czatowy – odpowiedzi na pytania o ofertę, procedury, produkty, wsparcie sprzedaży. Zwykle kilka–kilkanaście równoległych sesji, stosunkowo krótkie odpowiedzi, ciągła praca w tle.
• Analiza dokumentów – streszczanie, porównywanie umów, wyciąganie kluczowych informacji z raportów, tworzenie krótkich syntez dla zarządu.
• Generowanie treści – opisy produktów, propozycje mailingów, pierwsze wersje ofert, teksty na stronę firmową (przy zachowaniu kontroli człowieka).
• Prototypowanie narzędzi wewnętrznych – generowanie skryptów, integracje z systemami, wspomaganie programistów i administratorów.

Każdy z tych scenariuszy inaczej obciąża sprzęt. Czat to przede wszystkim wiele krótkich zapytań – liczy się płynność odpowiedzi i dobra obsługa równoległych użytkowników. Analiza dokumentów to zaś długie konteksty, dużo wczytywania tekstu i intensywne wykorzystanie pamięci GPU oraz RAM. Dział R&D, który eksperymentuje z fine-tuningiem, żąda już zupełnie innej klasy GPU i znacznie mocniejszej platformy.

Rozmiar modelu a wymagania sprzętowe – co oznacza 7B, 13B, 34B, 70B

Liczba przy nazwie modelu – 7B, 13B, 34B, 70B – to liczba parametrów (billion parameters). Im więcej parametrów, tym model większy, zwykle dokładniejszy, ale też bardziej łakomy na VRAM i RAM. Dla uproszczenia można przyjąć, że większe modele zwykle potrzebują:

• więcej pamięci karty graficznej (VRAM), aby w ogóle się załadować,
• więcej RAM-u, jeśli część obliczeń lub warstw jest przerzucana na CPU,
• większego i szybszego dysku na same pliki modeli (kilkanaście–kilkadziesiąt GB na sztukę).

Dodatkowo w praktyce używa się różnych stopni kwantyzacji (np. 4-bit, 8-bit), co pozwala upchnąć większy model w mniejszej ilości VRAM. Przykładowo, dobrze zoptymalizowany model 7B po kwantyzacji może działać sensownie na karcie 8–12 GB VRAM, ale 70B nawet po mocnej kwantyzacji jest wyzwaniem bez co najmniej 48–80 GB dostępnej pamięci GPU (lub rozłożenia go na kilka kart).

Przykładowe modele open-source i typowe wymagania VRAM

Na rynku jest już sporo modeli open-source, które nadają się do lokalnego uruchamiania LLM w firmie. Aby oszacować wymagania sprzętowe, warto spojrzeć na typowe klasy:

• Modele ~7B parametrów (różne warianty LLaMA, Mistral, Qwen w tej klasie) – przy agresywnej kwantyzacji mogą działać na kartach 8–12 GB VRAM, choć komfortowo jest mieć 12–16 GB, zwłaszcza jeśli model ma obsługiwać kilku użytkowników jednocześnie.
• Modele 13B–15B – sensownie jest celować w 16–24 GB VRAM. Da się je zmieścić w 12 GB po kwantyzacji, ale kosztem prędkości i jakości; przy pracy firmowej lepiej mieć zapas.
• Modele 30–34B – tu zaczyna się realna potrzeba 24–48 GB VRAM, szczególnie gdy nie chcesz przesadnie kwantyzować modelu. Taka klasa modeli rzadko jest potrzebna do prostych chatbotów, ale przy złożonych zadaniach analitycznych może dawać przewagę jakości.
• Modele 65–70B – w praktyce domena maszyn wielo-GPU albo profesjonalnych kart z 80 GB VRAM. Przy średniej wielkości firmie najczęściej wystarczy dobrze dobrany model 7B–34B, chyba że dział R&D potrzebuje możliwie najwyższej jakości generacji tekstu on-premise.

Przy wyborze modeli open-source (LLaMA‑klony, Mistral, Qwen itp.) warto sprawdzić oficjalne lub społecznościowe rekomendacje VRAM dla danej wielkości modelu i wybranego poziomu kwantyzacji. Sprzęt warto dobrać tak, by nie jechać na samym minimum, tylko mieć przynajmniej 20–30% zapasu pod kątem kolejnych wersji modeli.

Scenariusze użytkowania a wymagany poziom sprzętu

Ułatwia wybór bardzo prosta segmentacja:

• Małe biuro (1–5 użytkowników) – podstawowy asystent czatowy, lekkie generowanie treści, sporadyczna analiza dokumentów. Wystarczy pojedyncza karta 12–24 GB VRAM, 64 GB RAM i sensowny CPU klasy desktopowej.
• Średni zespół (10–30 osób) – jednoczesne sesje czatu, bardziej intensywne obciążenie, pipeline’y do przetwarzania dokumentów. Tu przydaje się 24–48 GB VRAM (lub dwie karty 24 GB), 128 GB RAM, szybkie NVMe i solidny procesor wielordzeniowy.
• Dział R&D / data science – eksperymenty z wieloma modelami, fine-tuning, batchowe przetwarzanie danych. To już terytorium stacji roboczych klasy serwerowej: wielordzeniowe CPU (lub HEDT), 128–256 GB RAM, 48–80+ GB VRAM lub multi-GPU, rozbudowana przestrzeń na dyskach NVMe.

Warto jasno określić, na którym poziomie firma znajduje się dziś i gdzie realnie będzie za 1–2 lata. Dzięki temu zestaw podzespołów nie okaże się ciasny już po pierwszych wdrożeniach.

Procesor – fundament pod lokalne LLM

Rola CPU przy inferencji i trenowaniu lokalnych modeli

Przy LLM dużo uwagi skupia się na GPU, ale procesor nadal robi swoje. Nawet jeśli główna inferencja przebiega na karcie graficznej, CPU jest odpowiedzialne za:

• przygotowanie danych wejściowych (tokenizacja, parsowanie dokumentów),
• obsługę wielu równoległych zapytań, kolejkowanie i logikę aplikacji,
• część obliczeń, jeśli model nie mieści się w VRAM i musi „spadać” na RAM.

W skrajnym przypadku – przy modelach uruchamianych wyłącznie na CPU – wydajność procesora decyduje o wszystkim. To scenariusz raczej awaryjny lub testowy, ale w małych firmach bez GPU czasem się go spotyka. Taka konfiguracja potrafi działać, ale jest bardzo wolna dla większych modeli; stąd, nawet przy ograniczonym budżecie, lepiej przynajmniej jedna rozsądna karta graficzna.

Przy stacji roboczej do LLM sensownie jest celować w konfigurację, w której GPU jest „kierowcą wyścigowym”, a CPU nie jest wąskim gardłem. Zbyt słaby procesor będzie ograniczał kartę graficzną, generował opóźnienia i zmniejszał przepustowość całego systemu.

Liczba rdzeni, wątków i taktowanie – rozsądny kompromis

Do zastosowań LLM w firmie dobrze sprawdza się zasada: wiele „sensownych” rdzeni zamiast kilku super szybkich. Modele językowe i aplikacje je otaczające rzadko korzystają wyłącznie z jednego wątku, a jeśli masz kilku użytkowników jednocześnie, każdy proces dokłada kolejną porcję obciążenia.

Przykładowe poziomy:

• Stacja robocza do lekkiego LLM – 8–12 rdzeni / 16–24 wątki, wysokie taktowanie, nowoczesna architektura (np. aktualne generacje desktopowych Intel Core lub AMD Ryzen).
• Maszyna dla średniego zespołu – 16–24 rdzenie / 32–48 wątków, priorytet na dużą liczbę linii PCIe i obsługę większych ilości RAM.
• Rozwiązanie serwerowe / HEDT – 24+ rdzeni / 48+ wątków, wsparcie wieloprocesorowe lub ogromnych ilości RAM (np. linie Threadripper, Xeon, EPYC).

W praktyce niewielka różnica w taktowaniu rzędu 200–300 MHz nie ma aż takiego znaczenia jak możliwość uruchomienia większej liczby równoległych wątków. Dla stabilnej pracy lokalnego LLM w firmie ważniejsza będzie ogólna przepustowość obliczeń i I/O niż wyścig o najwyższe turbo na jednym rdzeniu.

Funkcje CPU przydatne przy AI: AVX, PCIe i linie pod GPU

Przy wyborze procesora warto zwrócić uwagę na kilka technicznych detali:

• Instrukcje SIMD (AVX/AVX2/AVX‑512) – wiele bibliotek do inferencji LLM (szczególnie przy obliczeniach na CPU i przy kwantyzacji) potrafi wykorzystać rozszerzone instrukcje wektorowe. Nie trzeba znać szczegółów, ale lepiej mieć CPU z pełnym wsparciem nowoczesnych instrukcji niż kilkuletni model bez nich.

Platforma, socket, chipset – gdzie ten procesor wsadzić

Sam wybór modelu CPU to połowa historii. Druga połowa to platforma, która musi unieść wymagania pod LLM: dużo RAM, dużo linii PCIe, stabilne zasilanie i możliwość rozbudowy. Tu często rozjeżdżają się oczekiwania („chcemy mocną maszynę na lata”) z budżetem („ale najlepiej w cenie biurowego desktopa”).

W uproszczeniu masz trzy główne klasy rozwiązań:

• Platformy desktopowe (consumer) – typowe płyty pod Intel Core / AMD Ryzen. Nadają się na pierwszą stację roboczą do LLM:
  • obsługują 64–192 GB RAM (zależnie od generacji i liczby slotów),
  • mają zwykle 1 złącze PCIe x16 pełnej prędkości (idealne dla jednej sensownej karty),
  • są relatywnie tanie, ale ograniczone, jeśli planujesz multi‑GPU lub >256 GB RAM.
• Platformy HEDT / workstation – Threadripper, Intel W‑seria i podobne:
  • kilka fizycznych slotów PCIe x16 z pełnym lub prawie pełnym bandwidth,
  • obsługa 256 GB RAM i więcej, często w konfiguracji z 8 slotami DIMM,
  • idealne, jeśli myślisz o 2–4 GPU i rozbudowanym storage.
• Platformy serwerowe (sockety EPYC, Xeon):
  • maksimum linii PCIe (pod wiele GPU, karty sieciowe 25/40/100 GbE, HBA),
  • obsługa bardzo dużej pamięci (512 GB–1 TB i więcej),
  • wyższa cena, ale także wsparcie pod ECC, redundantne zasilanie, rack 19″.

Dla małego i średniego zespołu często rozsądny jest mocny desktop lub pojedynczy Threadripper z dwoma slotami PCIe x16 dla GPU. Pełne platformy serwerowe zwykle wchodzą w grę dopiero przy wielokartowych konfiguracjach lub gdy dział IT i tak planuje sprzęt do szafy rack z istniejącą infrastrukturą.

Przed zakupem dobrze jest sprawdzić specyfikację płyty głównej pod kątem:

• liczby slotów PCIe x16 i ich prędkości przy obsadzeniu wszystkich,
• liczby gniazd RAM i maksymalnej obsługiwanej pojemności,
• liczby złącz M.2 NVMe i ewentualnego współdzielenia linii z innymi portami.

Unika się w ten sposób sytuacji, w której z pozoru „bogata” płyta po włożeniu drugiego GPU nagle obcina przepustowość wszystkim kartom i część slotów M.2 przestaje działać.

Chłodzenie i zasilanie CPU – cichy partner GPU

Przy inferencji LLM CPU potrafi przez długi czas pracować na wysokim obciążeniu. Stałe 70–90% na wszystkich rdzeniach przez wiele godzin nie jest niczym dziwnym. Jeśli chłodzenie i zasilanie są słabe, procesor zaczyna zbijać taktowanie, a cały serwer „zamyśla się” w najmniej dogodnym momencie.

Kilka praktycznych punktów:

• Chłodzenie powietrzem vs AIO – duży, dobrej klasy cooler powietrzny w wielu przypadkach wystarczy i jest mniej problematyczny serwisowo niż chłodzenie wodne. Przy CPU HEDT/serwerowych lub w ciasnym racku często stosuje się jednak dedykowane, wysokoobrotowe układy chłodzenia.
• Przepływ powietrza w obudowie – mocny CPU + gorące GPU w jednej obudowie potrafią szybko nagrzać wnętrze. Przy multi‑GPU potrzebne są dodatkowe wentylatory, czasem karta-blower zamiast „grubego” customa. GPU bez odpowiedniego przepływu zacznie zbijać taktowanie mimo świetnego chłodzenia na samym rdzeniu.
• Zasilacz – dla konfiguracji z jedną kartą graficzną często wystarczy markowy PSU 850–1000 W. Dwie mocne karty i wielordzeniowy CPU to już terytorium 1200 W i więcej. Liczy się też liczba i typ złącz zasilających pod GPU (12VHPWR/8‑pin).

Sprzęt do LLM pracuje często 24/7. Tanie cięcie na chłodzeniu i zasilaniu kończy się niestabilnością, błędami pod obciążeniem i nerwowym grzebaniem w logach, zamiast spokojnym używaniem modelu.

GPU – serce maszyny do LLM

Dlaczego VRAM jest ważniejszy niż surowa moc obliczeniowa

Przy klasycznych zastosowaniach GPU (gry, renderowanie) dużo mówi się o TFLOPS, rdzeniach CUDA czy jednostkach RT. Przy LLM kluczowy jest VRAM – po prostu pojemność pamięci karty. Model musi się do niego zmieścić (w całości lub prawie całości), inaczej zaczyna się żonglowanie warstwami między RAM a VRAM i prędkości lecą w dół jak kurs egzotycznej kryptowaluty.

Przy lokalnym uruchamianiu modeli typowo obserwuje się dwa scenariusze:

• Model w całości w VRAM – najlepsza sytuacja, GPU liczy, CPU podaje dane, wszystko płynie. Tu liczy się nie tylko sama ilość VRAM, ale i jego przepustowość (szerokość magistrali, typ pamięci).
• Model częściowo w VRAM, częściowo w RAM – rozkład warstw lub offloading. Daje możliwość uruchomienia większych modeli na słabszych kartach, ale kosztem opóźnień i mniejszej liczby równoległych zapytań.

Przy wyborze GPU pod LLM pojemność VRAM jest zwykle ważniejsza niż kilka procent różnicy w wydajności obliczeniowej. W praktyce karta z 24 GB VRAM „słabsza” o 10% od konkurencji z 16 GB będzie znacznie bardziej użyteczna do modeli 13B+.

Karty konsumenckie vs profesjonalne – co ma sens w firmie

Rynek GPU można podzielić na dwie główne grupy: karty konsumenckie (GeForce, Radeon) i profesjonalne (NVIDIA RTX A/Quadro, Tesla, AMD Instinct). Przy lokalnych LLM w firmie często sens ma pragmatyczne podejście:

• Karty konsumenckie:
  • zdecydowanie lepszy stosunek cena/VRAM,
  • świetna dostępność, duża społeczność, masa poradników,
  • czasem ograniczenia licencyjne w kontekście centrum danych (trzeba sprawdzić zapisy EULA, jeśli planujesz typowy „data center workload”).
• Karty profesjonalne:
  • zwykle więcej VRAM na kartę (np. 48–80 GB),
  • lepsza obsługa w środowisku serwerowym (sterowniki, certyfikaty, wsparcie producenta),
  • wysoka cena – często wielokrotność kosztu porównywalnej karty konsumenckiej.

Dla większości małych i średnich firm rozsądna jest konfiguracja z 1–2 mocnymi kartami konsumenckimi o dużej ilości pamięci (np. 24 GB), chyba że polityka IT lub wymagania formalne wymuszają certyfikowane rozwiązania serwerowe. Duże organizacje, które i tak mają infrastrukturę w szafach rack i kontrakty serwisowe, częściej sięgną po karty profesjonalne.

Multi‑GPU – kiedy warto, a kiedy tylko komplikuje życie

Dokupienie drugiej karty kusi: „będzie dwa razy szybciej”. W praktyce zysk zależy od tego, jak dokładnie oprogramowanie potrafi rozłożyć model i zadania między GPU. W świecie LLM można spotkać trzy typowe sposoby wykorzystania multi‑GPU:

• Równoległe sesje (data parallel) – każda karta obsługuje inne zapytania użytkowników. Proste do wdrożenia, zysk prawie liniowy przy wielu jednoczesnych użytkownikach.
• Dzielenie modelu na kilka GPU (tensor/model parallel) – duży model jest rozłożony warstwami lub blokami między karty, co pozwala uruchomić np. 70B na dwóch/trzech GPU. Wymaga wsparcia w frameworku i generuje narzut na komunikację między kartami.
• Mikstura obu podejść – w środowiskach R&D, przy fine‑tuningu i eksperymentach.

Multi‑GPU ma sens, gdy:

• masz wielu równoległych użytkowników i potrzebujesz większej przepustowości zapytań,
• planujesz pracę z modelami, które nie mieszczą się w pojedynczym VRAM,
• masz aplikacje i narzędzia (np. frameworki jak vLLM, text‑generation‑webui, własne mikroserwisy), które umieją efektywnie rozłożyć obciążenie.

Jeśli głównym celem jest pojedynczy chatbot dla kilku osób, a budżet jest ograniczony, jedna solidna karta często daje więcej spokoju niż skomplikowany setup z dwoma słabszymi GPU, mostkiem NVLink i wieczorami spędzonymi na debugowaniu konfiguracji.

Interfejs, przepustowość i fizyka – PCIe, NVLink, zasilanie

Sama karta to nie wszystko. Liczy się też sposób, w jaki komunikuje się z resztą systemu:

• PCIe 3.0 vs 4.0 vs 5.0 – LLM nie są aż tak wrażliwe na przepustowość magistrali jak np. niektóre obliczenia HPC, ale przy multi‑GPU i dużych batchach wąskie gardło PCIe potrafi „przyciąć” zyski. Dobrze, aby główne GPU działało przynajmniej na pełnym x16 PCIe 4.0, a przy nowszych platformach – 5.0.
• NVLink / mostki między GPU – przy dzieleniu jednego dużego modelu między dwie karty (model parallel) dodatkowy kanał o wysokiej przepustowości realnie pomaga. W prostych scenariuszach „każde GPU obsługuje inne zapytania” NVLink jest mniej istotny.
• Zasilanie i kable – nowoczesne GPU potrafią pociągnąć kilkaset watów. Dwie takie karty + wydajny CPU to spory prąd, który musi przejść przez realne przewody i złącza, a nie przez życzenia w Excelu. Zasilacz z odpowiednim zapasem mocy i prawidłowo poprowadzone kable to nie „fanaberia entuzjastów”, tylko warunek stabilności.

RAM, dyski i przepustowość – żeby GPU nie czekało

Ile RAM‑u pod LLM – praktyczne progi

RAM jest często niedoszacowywany, bo cała uwaga idzie w GPU. Tymczasem przy lokalnych LLM pamięć operacyjna trzyma nie tylko sam model (gdy jest częściowo offloadowany), ale też:

• bufory wejść/wyjść dla wielu równoległych zapytań,
• cache dokumentów przy przetwarzaniu tekstu,
• inne usługi działające na tej samej maszynie (baza wektorowa, serwer www, monitoring).

Dobrze jest myśleć o RAM‑ie w kategoriach poziomów:

• 64 GB – absolutne minimum dla małego biura i jednego modelu 7B/13B. Działa, ale nie zostawia dużego zapasu na inne usługi i duże konteksty.
• 128 GB – rozsądna wartość dla większości małych/średnich zespołów. Pozwala równocześnie utrzymać model, cache, kilka usług dookoła i nadal mieć luz.
• 256 GB i więcej – sensowne, gdy:
  • masz multi‑GPU i kilka modeli jednocześnie,
  • używasz agresywnego offloadingu warstw na CPU,
  • planowane są większe workflowy: łączenie LLM z klasyczną analityką, rozbudowane pipeline’y.

Przy planowaniu dobrze jest przewidzieć późniejszą rozbudowę – np. zacząć od 4×32 GB zamiast 2×32 GB, jeśli płyta ma 8 slotów. Ułatwia to dojście do 192–256 GB bez wymiany wszystkich modułów.

ECC czy nie ECC – stabilność ponad wszystko

Przy serwerach baz danych czy systemach finansowych ECC jest standardem. Przy LLM bywa traktowane jako „miły dodatek”, dopóki brak ECC nie spowoduje trudnego do wytłumaczenia błędu w trakcie długiego trenowania albo dziwnych crashy pod dużym obciążeniem.

Pamięć z korekcją błędów (ECC) ma sens, gdy:

• masz długotrwale obciążoną maszynę działającą 24/7,
• pracujesz z wrażliwymi danymi i nie możesz sobie pozwolić na losowe przekłamania,
• masz duże ilości RAM (256 GB+), gdzie statystyczna szansa na bity „które przewrócą się same z siebie” rośnie.

Platformy desktopowe najczęściej nie obsługują ECC (lub robią to w ograniczony sposób), za to Threadripper i serwerowe rozwiązania AMD EPYC/Intel Xeon już tak. Tu znowu – jeśli budżet i polityka IT pozwalają, ECC zwiększa spokój ducha administratora.

Dyski NVMe – ile, jak szybkie i do czego

LLM lubią szybki dostęp do danych. Chodzi nie tylko o samo ładowanie modelu przy starcie, ale też o:

• cache dokumentów i wektorów,
• logi i metryki (czasem bardzo obszerne),
• dane treningowe i rezultaty eksperymentów R&D.

Typowy sensowny podział wygląda tak:

• NVMe 1 – system + usługi – dysk na system operacyjny, narzędzia, docker, logi. 500 GB–1 TB zwykle wystarcza.

NVMe 2 – modele i dane LLM

Drugi szybki dysk dobrze wydzielić na rzeczy, które naprawdę „mielą się” przy pracy modelu:

• pliki modeli w różnych wariantach (8-bit, 4-bit, różne rozmiary),
• bazy wektorowe (np. Qdrant, Milvus, Chroma) jeśli działają lokalnie,
• cache embeddingów, shardów danych, snapshoty eksperymentów.

Dla komfortowej pracy przy kilku modelach 7B–70B i lokalnej bazie wektorowej przydają się co najmniej 2 TB. Przy R&D i własnych zbiorach tekstów spokojnie można rozważyć 4 TB lub więcej. Lepiej mieć jeden większy i szybki dysk NVMe niż kilka małych, z których każdy zapełnia się w tydzień.

Jeśli system ma służyć także do trenowania/fine‑tuningu, intensywnie używany będzie katalog z danymi treningowymi. Wtedy modele i dane użytkowe dobrze rozdzielić na dwa osobne NVMe, żeby uniknąć walki o IOPS między odczytem modeli a zapisem logów i checkpointów.

Dodatkowe HDD/SATA – archiwum zamiast śmietnika

Dyski talerzowe nie zniknęły z powodu LLM. Do przechowywania:

• starych checkpointów,
• rzadko używanych zbiorów danych,
• backupów konfiguracji i logów,

wystarczą zwykłe HDD podpięte przez SATA. Prędkość nie będzie rekordowa, ale za to cena za terabajt jest zupełnie inna niż przy NVMe. Częsty schemat: 1–2 NVMe na „gorące” dane i 1 duży HDD na rzeczy, których szkoda kasować, ale nie muszą być zawsze „pod ręką”.

RAID i redundancja – co faktycznie ma sens

Modele zawsze można ściągnąć ponownie, ale czasu i danych użytkowników już niekoniecznie. Dla serwera LLM w firmie rozsądny kompromis to:

• brak RAID na dysku z modelami – w razie awarii po prostu pobierasz je znowu,
• RAID1 lub RAID10 na dyskach z danymi biznesowymi, logami audytowymi i bazą wektorową zawierającą dane klientów,
• zewnętrzny backup (NAS, obiektówka, inny serwer) – szczególnie przy fine‑tuningu na własnych danych.

Kontrolery sprzętowe RAID mają sens przy większych wdrożeniach i wielu dyskach. Przy jednym–dwóch NVMe najczęściej wystarczy RAID programowy i sensowna strategia kopii zapasowych.

Przepustowość między CPU, RAM i GPU – gdzie rodzą się wąskie gardła

Wydajność LLM to nie tylko TFLOPS karty. Gdy model częściowo siedzi w RAM, a częściowo w VRAM, kluczowe stają się:

• przepustowość pamięci RAM – im wyższe taktowanie i szerszy kontroler (więcej kanałów), tym lepiej,
• liczba linii PCIe – żeby GPU działało na pełnym x16, a NVMe nie musiały dzielić jednej linii po x2,
• topologia płyty głównej – jak fizycznie rozkładają się sloty PCIe między CPU a chipset.

Przy dwóch GPU + kilku NVMe warto sprawdzić schemat PCIe w dokumentacji płyty. Zdarzają się konstrukcje, gdzie włożenie drugiej karty graficznej automatycznie przycina pierwszy slot do x8, a jeden z dysków NVMe przechodzi na tryb x2. Dla LLM to nie zawsze dramat, ale przy dużej liczbie równoległych zapytań różnica w przepustowości magistrali staje się odczuwalna.

Chłodzenie i hałas – serwer w biurze, nie w piwnicy

Maszyna LLM pod obciążeniem pracuje non stop: GPU na 80–100%, CPU też się nudzić nie będzie. To oznacza ciepło, hałas i zużycie komponentów. Kilka praktycznych zasad:

• obudowa z dobrym przepływem powietrza – dużo otworów wentylacyjnych, sensowny front, miejsce na filtry przeciwkurzowe,
• wentylatory systemowe jakościowe, nie „gratisowe” – 2–3 duże 140 mm często są cichsze i wydajniejsze niż 5 głośnych 120 mm,
• układ chłodzenia CPU – przy długotrwałym obciążeniu lepszy, przewymiarowany cooler (powietrze lub AIO) sprawi, że całość będzie stabilniejsza i cichsza.

Jeżeli serwer stoi w biurze obok ludzi, poziom hałasu szybko zaczyna być ważniejszy niż dodatkowe 5% wydajności. Wtedy opłaca się sięgnąć po karty z masywnym, trójwentylatorowym chłodzeniem, a nie najtańsze konstrukcje z małym radiatorem „na styk”. Przy obudowie rack 4U sytuacja jest inna – tam rządzą szybkie, głośne wentylatory i osobne pomieszczenie.

Zasilacz – ile watów naprawdę potrzeba

Dwie karty klasy 300 W + CPU biorący 200 W + reszta platformy i nagle robi się 800–900 W pod pełnym obciążeniem. Bezpieczny margines i stabilność są ważniejsze niż oszczędność na PSU.

• zasilacz markowy, minimum 80+ Gold – sprawność przy stałym obciążeniu ma znaczenie dla rachunków i temperatur,
• realny zapas 20–30% mocy ponad maksymalne przewidywane obciążenie,
• odpowiednia liczba linii i wtyczek PCIe/12VHPWR – bez kombinacji z przejściówkami „na skrętkę”.

Jeśli konfiguracja zakłada np. jedno GPU 350 W, CPU 150 W i kilka dysków, 850 W dobrej klasy najczęściej wystarczy. Przy dwóch takich GPU warto przeskoczyć od razu na 1200 W i mieć spokój – zwłaszcza jeśli planowane jest dalsze rozbudowywanie maszyny.

Płyta główna – fundament, na którym wszystko stoi

Przy typowych zestawach biurowych często wybiera się „byle coś działało”. Przy LLM podejście się zmienia, bo płyta decyduje o:

• dostępnych slotach PCIe x16 (ilość i prędkość),
• maksymalnym obsługiwanym RAM i liczbie kanałów,
• liczbie gniazd M.2 i ich przepustowości,
• obsłudze ECC (lub jej braku).

W praktyce, pod lokalne LLM w firmie przydają się płyty:

• z dwoma pełnowymiarowymi slotami PCIe x16 pod GPU (nawet jeśli na start używane będzie tylko jedno),
• z minimum trzema gniazdami M.2 NVMe, najlepiej bez dzielenia linii ze slotami GPU,
• z dobrą sekcją zasilania, jeśli procesor ma wiele rdzeni i ma pracować blisko limitów mocy.

Przed zakupem opłaca się przejrzeć manual i sprawdzić tabelkę „PCIe lane allocation”. To kilka minut, które później oszczędza godzin na zastanawianiu się, czemu drugie GPU działa nagle jak karta biurowa.

Obudowa i fizyczne wymiary – LLM też muszą się zmieścić

Najmocniejsze karty konsumenckie są ogromne, a serwer ma często trafić do zwykłej szafy biurowej. W praktyce:

• sprawdź długość i grubość GPU vs maksymalna długość karty w obudowie,
• zastanów się, czy dwa szerokie GPU zmieszczą się obok siebie bez „dusznej” szczeliny,
• upewnij się, że kable zasilające da się poprowadzić bez nadmiernego zginania nowoczesnych wtyczek 12VHPWR.

Jeśli komputer ma być przenoszony lub ustawiony w miejscu z ograniczonym dostępem, mała różnica w wymiarach obudowy potrafi mieć duże znaczenie. Konfiguracje desktopowe z dwiema kartami często wygodniej składa się w dużych towerach niż w efektownych, ale ciasnych konstrukcjach typu „kompakt gaming”.

Sieć – kiedy 1 GbE to za mało

W małej firmie serwer LLM często stoi w tym samym biurze, a użytkownicy łączą się przez sieć lokalną. Przy jednym–dwóch użytkownikach 1 GbE zwykle wystarczy. Problemy pojawiają się, gdy:

• z serwera korzysta wielu równoległych użytkowników,
• przesyłane są duże dokumenty do analizy (PDF, prezentacje, archiwa),
• serwer integruje się z innymi systemami analitycznymi, które stoją w innym segmencie sieci.

W takich scenariuszach 10 GbE (lub szybsze) na interfejsie serwera zdecydowanie ułatwia życie. Koszt przełącznika i okablowania rośnie, ale unika się sytuacji, gdzie GPU się nudzi, bo użytkownicy „duszą się” na wysyłaniu plików. Przy pracy hybrydowej (część systemów on‑prem, część w chmurze) ważna będzie też przepustowość i opóźnienie łącza zewnętrznego, szczególnie jeśli embeddingi lub wyniki inferencji mają krążyć tam i z powrotem.

System operacyjny i warstwa oprogramowania – co dobrze współpracuje z LLM

Sprzęt bez sensownego softu staje się drogą grzałką. W środowiskach firmowych sprawdzają się głównie dystrybucje linuksowe:

• Ubuntu LTS – najwięcej poradników, gotowe paczki, duża społeczność,
• Rocky/Alma Linux – jeśli infrastruktura oparta jest na „klimacie RHEL‑owym”,
• Debian – dla tych, którzy lubią stabilność i przewidywalne wydania.

Na warstwie aplikacyjnej dobrze jest od razu zaplanować:

• konteneryzację (Docker/Podman) – łatwiejsza aktualizacja modeli i izolacja usług,
• mechanizm orkiestracji (docker‑compose, Kubernetes, Nomad) przy większej liczbie usług i serwerów,
• monitoring (Prometheus, Grafana, loki/ELK) do śledzenia obciążenia GPU, RAM, dysków i samej aplikacji LLM.

Jeśli w firmie są już standardy co do systemów i monitoringu, serwer LLM powinien się w nie wpasować – inaczej każde drobne odchylenie od normy będzie wymagało „specjalnego traktowania” przez administratorów.

Bezpieczeństwo i izolacja – LLM to też system produkcyjny

LLM w firmie często mają dostęp do wrażliwych danych: dokumentów, bazy CRM, systemów finansowych. Sprzęt i konfiguracja powinny uwzględniać to od początku:

• izolacja sieciowa – osobny VLAN/segment dla serwera, kontrola dostępu z innych podsieci,
• uwierzytelnianie do interfejsu LLM (SSO, LDAP/AD, OIDC), a nie „otwarty port w LAN, bo przecież jesteśmy w jednej firmie”,
• szyfrowanie dysków z danymi użytkowników i logami, szczególnie na laptopach/serwerach w otwartych przestrzeniach.

Przy bardziej wymagających środowiskach przydają się także mechanizmy audytu: logowanie, kto, kiedy i do jakich danych miał dostęp poprzez LLM. To już nie jest „zabawka do eksperymentów”, tylko normalny system, który może podlegać compliance i kontrolom.

Scenariusze rozbudowy – nie zamykać sobie drogi

Firma często zaczyna od jednego modelu i kilku użytkowników, a po paru miesiącach okazuje się, że LLM obsługują pół działu. Sprzęt warto planować tak, aby:

• zostało wolne miejsce na dodatkowe GPU i linie PCIe,
• były zapasowe sloty RAM do dojścia np. z 128 GB na 256 GB,
• można było łatwo dodać kolejny dysk NVMe na nowe modele i dane.

Częsty błąd to „przybicie” konfiguracji do ściany: płyta z dwoma slotami RAM, jednym gniazdem M.2 i jednym PCIe x16. Taki zestaw wystarczy na start, ale przy naturalnym wzroście potrzeb kończy się wymianą połowy komponentów zamiast prostego dołożenia modułów.

Przykładowe profile konfiguracji – punkty odniesienia

Konfiguracje zmieniają się wraz z rynkiem, ale można wyznaczyć kilka typowych profili, które pomagają w rozmowie z działem IT lub dostawcą sprzętu:

• „Start w firmie” – pojedynczy model 7B/13B, kilku użytkowników:
  • CPU klasy desktop (12–16 rdzeni),
  • 1× GPU z 16–24 GB VRAM,
  • 128 GB RAM,
  • 2× NVMe (1 TB system, 2 TB modele + dane),
  • zasilacz 850 W, obudowa tower z dobrym chłodzeniem.
• „Zespół / małe R&D” – kilka modeli, kilkanaście osób:
  • CPU z większą liczbą rdzeni (Threadripper/WS, wysoki Ryzen/Intel),
  • 1–2× GPU 24 GB VRAM,
  • 128–256 GB RAM (preferencyjnie ECC przy serwerowych platformach),

  Najczęściej zadawane pytania (FAQ)

  Czy opłaca się kupić własny komputer do LLM zamiast korzystać z chmury?

  Przy okazjonalnym korzystaniu z LLM (kilka testów tygodniowo) chmura jest zwykle tańsza i wygodniejsza. Problem zaczyna się, gdy model działa codziennie, a korzysta z niego kilkanaście–kilkadziesiąt osób – wtedy rachunki za API stają się stałym, sporym kosztem operacyjnym.

  Jeśli model pracuje większość dnia roboczego, własna stacja robocza lub serwer z GPU często „zwraca się” po kilku–kilkunastu miesiącach. Od tego momentu realny miesięczny koszt to głównie energia, amortyzacja i ewentualny serwis, a nie ciągłe opłaty za każde zapytanie do chmury.

  Jaka karta graficzna (ile VRAM) do lokalnego uruchamiania LLM w firmie?

  Minimalnie do sensownej pracy z modelami 7B dobrze jest mieć kartę z 12–16 GB VRAM. Przy 13B–15B bezpiecznym wyborem jest 16–24 GB VRAM, a dla modeli 30–34B wchodzimy w okolice 24–48 GB VRAM, jeśli nie chcesz mocno ciąć jakości kwantyzacją.

  Modele 65–70B to już zwykle domena konfiguracji z wieloma GPU albo profesjonalnych kart z 80 GB VRAM i raczej nie są pierwszym wyborem dla typowego MŚP. W większości zastosowań biznesowych (czat, analiza dokumentów, generowanie treści) dobrze dobrany model 7B–34B na jednej mocnej karcie załatwia temat.

  Jakie modele LLM open‑source nadają się do uruchamiania lokalnie?

  W praktyce firmy najczęściej sięgają po rodziny modeli takie jak LLaMA‑klony, Mistral czy Qwen w wersjach 7B i 13B. Przy kwantyzacji 4‑ lub 8‑bitowej modele 7B można uruchomić na GPU z 8–12 GB VRAM, choć dla komfortu i kilku użytkowników na raz lepiej mieć 12–16 GB.

  Przy cięższych zadaniach (złożona analiza dokumentów, bardziej wymagające zastosowania R&D) sensowne są modele 13B–34B, ale wtedy rośnie zapotrzebowanie na VRAM oraz RAM. Dobrym nawykiem jest sprawdzenie oficjalnych lub społecznościowych rekomendacji VRAM dla konkretnego modelu i wybranej kwantyzacji, zamiast zgadywania „na oko”.

  Kiedy chmura przestaje być opłacalna przy LLM w firmie?

  Sygnalizują to zwykle trzy rzeczy naraz: rosnące, stałe rachunki za API, coraz częstsze pytania zespołu o możliwość wrzucania poufnych dokumentów do modelu oraz potrzeba budowania stabilnych, wewnętrznych narzędzi (chatboty, integracje, pipeline’y). Innymi słowy – gdy LLM przestaje być zabawką, a staje się codziennym narzędziem pracy.

  Jeśli model jest obciążony przez większość dnia, to kupno własnej stacji roboczej z GPU zaczyna być rozwiązaniem nie tylko wygodniejszym, ale i tańszym w horyzoncie kilkunastu miesięcy. Przy umiarkowanym obciążeniu może skończyć się na jednym, dobrze dobranym komputerze, a nie od razu na „mini‑serwerowni”.

  Czy lokalne LLM pomaga w RODO i bezpieczeństwie danych?

  Tak, bo dane nie opuszczają Twojej sieci firmowej, a Ty kontrolujesz logi, czas retencji i poziom dostępu. To ogromny plus przy RODO, NDA i zapisach umów z klientami, w których trudno wyjaśnić, że wrażliwe dokumenty lecą do „jakiegoś API w chmurze, ale podobno jest bezpiecznie”.

  Serwer LLM on‑premise pozwala jasno opisać zasady: kto może korzystać z systemu, co wolno wrzucać do modelu, jak długo trzymane są zapytania. Dla działów prawnych, kancelarii czy firm inżynieryjnych to często jedyna opcja, żeby pracownicy w ogóle odważyli się używać AI przy wrażliwych sprawach.

  Do jakich zadań w MŚP najbardziej opłaca się postawić własny serwer LLM?

  Najczęstsze zastosowania to: firmowy chatbot znający procedury i ofertę, analiza dokumentów (umowy, raporty, briefy), generowanie pierwszych wersji treści marketingowo‑sprzedażowych oraz wsparcie działu IT i programistów przy prototypowaniu narzędzi. Im bardziej codzienne i powtarzalne są te zadania, tym lepiej uzasadniona inwestycja w lokalny sprzęt.

  Przykład z życia: kilkunastoosobowy dział sprzedaży przepytuje na okrągło wewnętrznego bota o produkty i oferty. W chmurze każde takie pytanie to koszt. Na własnym serwerze, jeśli sprzęt i tak stoi w serwerowni, różnicę widzisz głównie na rachunku za prąd, a nie w tabelce z fakturą od dostawcy API.

  Czy do prostego czatu firmowego muszę kupować bardzo drogi sprzęt?

  Nie zawsze. Dla lekkiego czatu dla kilku–kilkunastu osób zazwyczaj wystarczy jedna solidna karta z 12–16 GB VRAM, sensowny procesor i 32–64 GB RAM. Kluczowa jest płynność odpowiedzi i obsługa kilku równoległych sesji, a nie od razu możliwość trenowania ogromnych modeli 70B.

  Dopiero gdy dochodzi ciężka analiza dokumentów, długie konteksty lub eksperymenty R&D z fine‑tuningiem, rosną wymagania względem GPU, RAM‑u i dysku. Na start bez problemu da się zbudować „rozsądny” komputer do LLM, który nie zrujnuje budżetu działu IT.