Lokalny LLM na serwerze firmowym: jakie wymagania sprzętowe (GPU, VRAM)
Ile realnie sprzętu potrzebuje lokalny model językowy w fabryce. Jak rozmiar modelu przekłada się na VRAM i klasę karty, dlaczego liczy się realne wykorzystanie, a nie szczyt, i kiedy wystarczy jedna karta.
Spis treści
Lokalny LLM na serwerze firmowym: jakie wymagania sprzętowe (GPU, VRAM)
Czas czytania: ok. 7 minut
Krótka odpowiedź na wstępie: wymagania sprzętowe lokalnego modelu językowego wyznacza przede wszystkim rozmiar modelu, a nie „moc" karty w potocznym sensie. Kluczowa liczba to VRAM, czyli pamięć karty graficznej. Model o 8 miliardach parametrów spokojnie mieści się na jednej karcie z 24 GB VRAM i wystarcza do większości zastosowań asystenckich. Model 70B potrzebuje zwykle kilku kart klasy centrum danych. Poniżej rozkładam to na czynniki, bez marketingu.
Dlaczego to VRAM decyduje, a nie „szybkość" karty
Żeby model odpowiadał, jego wszystkie parametry (wagi) muszą zmieścić się w pamięci karty. Jeśli się nie mieszczą, albo dokładacie kolejne karty, albo model w ogóle nie ruszy z sensowną wydajnością. Dopiero gdy wagi się mieszczą, znaczenie ma przepustowość i architektura karty, bo one decydują, jak szybko lecą odpowiedzi.
Z grubsza wagi zajmują tyle:
- Pełna precyzja (FP16): około 2 bajty na parametr. Model 8B to więc około 16 GB, model 70B około 140 GB.
- Kwantyzacja 4-bit: około 0,5 bajta na parametr. Model 8B spada do około 5 do 6 GB, model 70B do około 40 GB.
Do tego dochodzi narzut na kontekst (tak zwany KV cache), który rośnie razem z długością rozmowy i liczbą jednoczesnych użytkowników. W praktyce zostawcie zapas rzędu 20 do 40 procent ponad sam rozmiar wag.
Kwantyzacja: tańszy sprzęt kosztem odrobiny jakości
Kwantyzacja to zapisanie wag z mniejszą precyzją. Pozwala zmieścić większy model na mniejszej karcie i przyspiesza odpowiedzi. Cena jest realna, ale zwykle mała: przy 4-bit większość zadań asystenckich i wyszukujących (RAG) działa praktycznie nieodróżnialnie od pełnej precyzji. Przy zadaniach wymagających precyzyjnego rozumowania różnica bywa zauważalna. Zasada praktyczna: zacznijcie od kwantyzacji, zejdźcie z niej tylko, gdy testy pokażą realny spadek jakości na waszych przypadkach.
Ile karty pod jaki model
Poniższa tabela to orientacja, nie wyrocznia. Realny dobór zależy od długości kontekstu i liczby jednoczesnych zapytań.
| Rozmiar modelu | Typowe zastosowanie w fabryce | VRAM (4-bit) | VRAM (FP16) | Orientacyjna karta |
|---|---|---|---|---|
| 7 do 8B | Asystent serwisowy, RAG na dokumentacji, proste podsumowania | ok. 6 do 10 GB | ok. 16 do 20 GB | jedna karta 24 GB (klasa RTX 4090 / RTX 6000) |
| 13 do 14B | Trudniejszy RAG, lepsza jakość odpowiedzi | ok. 10 do 16 GB | ok. 28 do 32 GB | jedna karta 24 do 48 GB (klasa L40S) |
| 32 do 34B | Zaawansowane rozumowanie, dłuższy kontekst | ok. 20 do 28 GB | ok. 64 do 70 GB | jedna karta 48 GB lub dwie mniejsze |
| 70B | Najwyższa jakość, złożone zadania | ok. 40 do 48 GB | ok. 140 GB | dwie karty 48 do 80 GB (klasa H100) |
Dla większości średnich firm punkt startowy to model z przedziału 8 do 14B na jednej dobrej karcie. To wystarcza do asystenta serwisowego i wyszukiwania w dokumentacji, a koszt wejścia jest znośny.
Liczba użytkowników zmienia rachunek
Sam rozmiar modelu to jedno. Drugie to ilu ludzi pyta jednocześnie. Każde równoległe zapytanie zajmuje pamięć na kontekst i konkuruje o czas karty. Dziesięciu techników pytających sporadycznie to zupełnie inne obciążenie niż pięćdziesięciu piszących naraz na zmianie.
Tu wchodzi wybór silnika inferencji, czyli oprogramowania, które obsługuje model. Narzędzia projektowane pod obciążenie potrafią obsłużyć wielokrotnie więcej zapytań na tej samej karcie niż proste narzędzia deweloperskie, bo lepiej pakują równoległe zapytania. Innymi słowy: zanim dołożycie sprzęt, sprawdźcie, czy nie brakuje wam po prostu właściwego silnika.
Pułapka: liczenie na szczytowe wykorzystanie
Częsty błąd w planowaniu to założenie, że karta pracuje na 90 procent możliwości. W realnych wdrożeniach produkcyjnych utylizacja to raczej 40 do 65 procent, bo ruch jest nierówny, a zapas trzeba trzymać na szczyty. Jeśli policzycie potrzeby na szczytowym wykorzystaniu, wyjdzie wam za mało zasobów w godzinach największego obciążenia. Lepiej planować z zapasem i realistyczną utylizacją.
Czego jeszcze potrzebuje serwer poza kartą
Karta to nie wszystko, choć to ona kosztuje najwięcej. Do tego dochodzą:
- Pamięć RAM i dysk na dokumentację, indeks wyszukiwania i logi. Przy RAG to zwykle nie jest problem, ale trzeba to przewidzieć.
- Zasilanie i chłodzenie. Karty centrum danych pobierają dużo prądu i grzeją. To realna pozycja w kosztach utrzymania, często niedoszacowana.
- Sieć i dostęp. Kto i skąd łączy się z asystentem, jak jest zabezpieczony dostęp.
O pełnym rachunku kosztów, w którym prąd i ludzie potrafią przewyższyć cenę samej karty, piszę osobno przy okazji decyzji on-premise kontra chmura.
Czego ten post nie pokrywa
Nie wchodzę tu w wybór konkretnego modelu ani w to, czy sensowniej postawić sprzęt u siebie, w kolokacji, czy wynająć. Nie rozstrzygam też, kiedy lokalny model wygrywa z chmurą, bo to osobna decyzja kosztowa i regulacyjna. Tu chodziło o jedno praktyczne pytanie: jaki sprzęt trzeba mieć, żeby lokalny LLM w ogóle ruszył i obsłużył wasz zespół.
Powiązane notatki
Powiązane notatki
AI on-premise czy w chmurze dla fabryki: co wybrać i kiedy
Kiedy trzymać AI u siebie, a kiedy w chmurze. Uczciwa lista przesłanek: wrażliwość danych, wolumen, koszty ukryte (ludzie, prąd), latencja, NIS2 i wariant hybrydowy.