Lokalny model językowy (self-hosted LLM)

Lokalny model językowy składa się z trzech elementów: wag modelu, serwera inferencji i sprzętu, na którym oba działają. Wagi to pliki publikowane przez twórcę modelu na określonej licencji, na przykład Gemma od Google albo polskie modele Bielik i PLLuM. Serwer inferencji wczytuje wagi do pamięci GPU, przyjmuje zapytania i generuje odpowiedź token po tokenie. Aplikacja łączy się z nim po HTTP, tak samo jak z API dostawcy.

vLLM to popularny serwer inferencji o otwartym kodzie. Pamięć podręczną atencji (cache klucz-wartość) trzyma w blokach o stałym rozmiarze. Autorzy nazwali tę metodę PagedAttention i opisali ją na konferencji SOSP 2023. Dzięki niej jedno GPU obsługuje wiele zapytań naraz i nie rezerwuje pamięci na najdłuższą możliwą odpowiedź. vLLM wystawia też API HTTP zgodne ze specyfikacją OpenAI. Kod napisany pod API w chmurze zwykle wystarczy przestawić na lokalny model, zmieniając adres bazowy i nazwę modelu.

O sprzęcie decydują rozmiar modelu i precyzja. Dokumentacja Google podaje, że Gemma 4 26B A4B potrzebuje około 57,7 GB pamięci w precyzji 16-bitowej, 28,8 GB po kwantyzacji do 8 bitów i 14,4 GB do 4 bitów. Do tego dochodzi cache aktywnych rozmów, który rośnie z liczbą równoległych sesji i długością tekstów. Niższa precyzja oszczędza pamięć, ale może obniżyć jakość, a ten koszt trzeba zmierzyć na własnym zadaniu.

Modele typu mixture-of-experts (MoE) dzielą część warstw na wiele podsieci, tak zwanych ekspertów, i każdy token przechodzi tylko przez kilka z nich. Gemma 4 26B A4B ma 26 mld parametrów, a na jeden token aktywuje około 4 mld. Generuje więc szybciej niż gęsty model tej samej wielkości, ale wszystkie 26 mld parametrów i tak musi się zmieścić w pamięci GPU, więc sprzęt dobiera się do pełnego modelu.

Określeń LLM on-premise, prywatny i lokalny używa się dość swobodnie. Określenie on-premise zwykle oznacza własne centrum danych organizacji, a prywatny często oznacza dedykowane wdrożenie u dostawcy chmury. Słowo "lokalny" bywa rozumiane wąsko, nawet jako laptop. W tym haśle oznacza model na infrastrukturze, którą kontrolujesz. Kupujący zadaje w każdym przypadku to samo pytanie: kto obsługuje maszynę, która widzi zapytania, i gdzie ona stoi.

Przy własnym modelu Twój zespół przejmuje utrzymanie, które przy API robi dostawca modelu. Wymagania dla każdego systemu z własnym modelem:

• Moc GPU dobiera się do liczby równoległych sesji. Pamięć na cache zależy od współbieżności i długości zapytań oraz odpowiedzi; realną wartość daje test obciążenia na prawdziwych dokumentach.
• Wersja modelu jest przypięta, a jej zmiana to wydanie. Nowy model, kwantyzacja albo prompt systemowy przechodzą ten sam zestaw ewaluacyjny co poprzednia wersja, zanim zobaczą je użytkownicy (zob. ewaluacja modeli językowych).
• Serwer inferencji ma kontrolę stanu (health check) i sam wraca po awarii. Dostawca może odebrać wynajętą instancję GPU, a jeśli nic nie uruchomi nowej, funkcja AI przestaje działać.
• Zapytania mają limit czasu, maksymalny rozmiar wejścia i limit kolejki, a użytkownik dostaje jasny komunikat, gdy model jest zajęty.
• Zapytania i odpowiedzi to dane osobowe, gdy tylko użytkownicy wklejają własne dokumenty. O logowaniu, retencji i anonimizacji decyduje się przed zapisaniem pierwszej linii logu (zob. anonimizacja danych).
• Licencję wag sprawdza się pod kątem użycia komercyjnego i zapisuje razem z wersją modelu.
• Ktoś odpowiada za aktualizacje. Serwer inferencji, sterowniki GPU, obraz bazowy i wagi modelu mają osobne cykle wydań.

RODO nie wymaga modelu na własnej infrastrukturze, ale wpływa na tę decyzję. Dostawca, który przetwarza zapytania w Twoim imieniu, jest podmiotem przetwarzającym w rozumieniu art. 28 i potrzebuje umowy z elementami, które ten artykuł wymienia. Art. 32 wskazuje pseudonimizację i szyfrowanie jako środki bezpieczeństwa, które administrator bierze pod uwagę. Rozdział V ogranicza przekazywanie danych osobowych poza Europejski Obszar Gospodarczy, więc lokalizacja GPU i personelu wsparcia z dostępem do nich ma takie samo znaczenie jak umowa. Otwarte modele mają własne licencje, czasem z ograniczeniami użycia, i licencja powinna przejść przegląd zakupowy razem z umową hostingową.

Dla PSONI budujemy Generator ETR, aplikację webową i mobilną, która przerabia skomplikowane teksty na tekst łatwy do czytania. Specyfikacja projektu przewiduje lokalnie hostowany model: Gemma 4 26B A4B serwowany przez vLLM i zwymiarowany na maksymalnie 45 000 zapytań miesięcznie i 100 równoległych sesji. W trakcie projektu przetestowaliśmy też dwa polskie modele: Bielika i PLLuM 12B.

Nasze skrypty wdrożeniowe uruchamiają instancję GPU, instalują vLLM z wagami Gemmy 4 i wystawiają API zgodne z OpenAI. Przed testami akceptacyjnymi PSONI we wrześniu 2026 r. okazało się, że odebrana instancja GPU nie jest automatycznie zastępowana nową, przez co środowisko testowe zostawało bez modelu. Tymczasowo przeszliśmy na stałą pulę GPU. W październiku 2026 r. trwa jeszcze analiza docelowej infrastruktury produkcyjnej dla modelu.