Blog / Enterprise AI / LLMs & Agents
ENTERPRISE AI · LLM & AGENTS
Lokalne modele LLM w praktyce: jak wykorzystujemy je w theBlue.ai
Autor: Aleksandra Osztynowicz / Opublikowano: sierpień 2026
Wokół dużych modeli językowych (LLM) ukształtowało się pewne domyślne podejście: gdy tylko pojawia się problem do rozwiązania z pomocą AI, wysyłamy dane do ChatGPT lub podobnego narzędzia chmurowego. W wielu przypadkach jest to wybór uzasadniony, ale nie zawsze. Dla całej klasy zadań lokalne uruchamianie modeli LLM, czyli praca z modelem open source na własnej, kontrolowanej infrastrukturze, okazuje się tańsze, bezpieczniejsze i łatwiejsze do nadzorowania niż korzystanie z usługi udostępnianej przez zewnętrzne API.
Nie jest to teza czysto teoretyczna. Opieramy ją na rzeczywistych systemach, które zbudowaliśmy i z których korzystamy w codziennej pracy. Poniżej opisujemy, jak wygląda to w praktyce: gdzie modele lokalne faktycznie dają przewagę, a gdzie napotykają swoje ograniczenia.
Czym jest lokalny LLM?
Lokalny LLM to model open source, na przykład z rodziny Gemma, Llama lub Qwen, uruchomiony na własnym sprzęcie, a nie na serwerze zewnętrznego dostawcy. Dla firmy istotne są dwie konsekwencje. Po pierwsze, dane nigdy nie opuszczają infrastruktury organizacji. Po drugie, nie ma opłaty za każde zapytanie. Razem te dwa czynniki zmieniają zarówno profil kosztowy, jak i profil ryzyka w szerokim zakresie zastosowań.
Trzy systemy, trzy lekcje
W praktyce uruchomiliśmy kilka takich systemów. Poniżej opisujemy trzy z nich, zaczynając od tego, który najlepiej ilustruje, co znaczy dopasowanie modelu do zadania: naszego portalu przetargowego.
1. Portal przetargowy: przesiewanie zamówień publicznych na dużą skalę
Pierwszym przykładem jest wewnętrzny portal, który automatycznie wyszukuje przetargi publiczne w interesujących nas obszarach i pobiera wszystkie dostępne informacje na ich temat: opisy, wymagania, załączniki i dokumentację uzupełniającą. Po wstępnym odfiltrowaniu danych pałeczkę przejmuje lokalny model Gemma 4 26B (26 miliardów parametrów) z warstwą MTP (multi-token prediction). Odpowiada on za dwa etapy procesu:
- Kwalifikacja wstępna: model odczytuje nagłówkowe dane każdego przetargu, tytuł, zamawiającego, kategorię, nazwy załączników, i wydaje krótkie rozstrzygnięcie: czy przetarg odpowiada profilowi naszej firmy, wraz z poziomem pewności i krótkim uzasadnieniem. Po tym etapie na liście pozostają wyłącznie postępowania istotne dla nas.
- Analiza dokumentacji: po pobraniu dokumentacji i załączników lokalny LLM analizuje je i zwraca ustrukturyzowane podsumowanie: krótki opis wymagań umownych, finansowych, kadrowych i dotyczących doświadczenia, wymaganych certyfikatów i zaświadczeń, wysokości i formy wadium, kluczowych terminów, ryzyka (na przykład kary umowne) oraz końcową rekomendację, REKOMENDACJA / DO ROZWAŻENIA / ODRZUCENIE, z uzasadnieniem.
Skala jest tu realna. W ciągu jednego dnia LLM przetwarza od 15 do 20 milionów tokenów, co odpowiada mniej więcej 15 000 stron A4. W skali roku daje to 5,5 do 7,3 miliarda tokenów. Dla porównania: obsłużenie tego samego obciążenia przez GPT-5 kosztowałoby 6875 do 9125 USD wyłącznie za tokeny wejściowe (według oficjalnego cennika OpenAI z lipca 2026 roku).
Wybór modelu nie był przypadkowy. W portalu użytkownik czeka na wynik, więc czas odpowiedzi ma znaczenie. Na naszym sprzęcie Gemma 4 26B generuje około 88 tokenów na sekundę. Większy wariant 31B (31 miliardów parametrów) spada do 40. Wersja 31B jest nieco dokładniejsza, ale po uwzględnieniu komfortu pracy użytkownika model 26B okazuje się właściwym kompromisem dla tego zastosowania. Swoją szybkość zawdzięcza warstwie MTP oraz architekturze mixture-of-experts (MoE), obie opisujemy dokładniej poniżej, które razem przyspieszają generowanie tokenów. Oferuje też duże okno kontekstowe, co pozwala nam analizować cały przetarg wraz z załącznikami w jednym przebiegu i dobrze radzi sobie z językiem polskim.
Dopasowaliśmy model do zastosowania, wyważyliśmy dokładność, opóźnienie, rozmiar okna kontekstowego, obsługę języka i wymagania sprzętowe. Efektem, w tym przypadku, jest możliwość przetwarzania dużych wolumenów przetargów bez obaw o koszty API czy limity zapytań.
2. Policy Insider: gdzie rozliczanie za zapytanie przestaje się bronić
Portal przetargowy pokazuje kosztową stronę tej historii. Policy Insider przenosi ją na inną skalę. Policy Insider to platforma analityczna oparta na AI, monitorująca zmiany regulacyjne i politykę. Pomaga zespołom zajmującym się sprawami publicznymi, kontaktem z administracją rządową i doradztwem strategicznym monitorować zmiany polityczne i regulacyjne na dużą skalę, bez konieczności polegania na ręcznym śledzeniu, arkuszach kalkulacyjnych czy rozproszonych narzędziach. Wykorzystujemy tu lokalny model Gemma 4 31B do analizy treści z dużej liczby serwisów poświęconych legislacji i polityce publicznej, około 28 milionów tokenów dziennie. Dla każdego serwisu model przygotowuje treść do dalszego przetwarzania, generuje podsumowanie i oznacza, czy materiał odpowiada danemu tematowi. Serwisy zaklasyfikowane jako istotne trafiają następnie do kolejnych opracowań: raportów, newsletterów i map ciepła pokazujących, gdzie zmiany są najbardziej intensywne.
Świadomie stosujemy tu większy i dokładniejszy model o 31 miliardach parametrów, a nie szybszy wariant 26B z poprzedniego przykładu. Policy Insider przetwarza dane w cyklicznych zadaniach uruchamianych w tle, więc nie ma znaczenia, czy jedna partia zajmie minutę, czy trzydzieści. Liczy się dokładność klasyfikacji, bo od niej zależy jakość powstających raportów. Zasada jest ta sama co wcześniej: dobieramy model do zadania, a nie odwrotnie.
To również przypadek, w którym rachunek ekonomiczny płatnego API przestaje się domykać. Miliony tokenów na cykl przekładałyby się na wysokie i stale rosnące koszty oraz nieustanne zmagania z limitami zapytań. W przypadku lokalnego LLM koszt przetworzenia kolejnego serwisu jest praktycznie zerowy: za sprzęt płacimy raz, a skala przestaje być ograniczeniem finansowym.
3. Wewnętrzny chatbot z RAG: dane, które nigdy nie opuszczają infrastruktury firmy
Koszty i skala to jedna strona medalu. Druga to kontrola nad danymi. Trzeci system zbudowaliśmy na własne potrzeby: to chatbot, który przeszukuje naszą wewnętrzną dokumentację i odpowiada na pytania zespołu. Zamiast ręcznie przekopywać się przez dziesiątki dokumentów, zadajemy pytanie w języku naturalnym, a model zwraca odpowiedź wraz ze wskazaniem źródła, z którego skorzystał. Rozwiązanie opiera się na wzorcu RAG (retrieval-augmented generation): system najpierw wyszukuje w naszych dokumentach fragmenty powiązane z pytaniem, zamiast polegać na wiedzy zdobytej podczas treningu; zadaniem modelu jest zrozumieć znalezione fragmenty i zbudować z nich odpowiedź.
System działa lokalnie, na naszych własnych kartach graficznych (GPU), tym razem z modelem spoza rodziny Gemma: Qwen3 30B. To najlepsza ilustracja zasady, która przewija się przez wszystkie trzy wdrożenia: dopasuj model do zadania i nie ograniczaj się do jednej rodziny modeli. Qwen3 dobrze prowadzi rozmowę, radzi sobie z długimi dokumentami i mimo nominalnych 30 miliardów parametrów pozostaje szybki, bo każde zapytanie aktywuje tylko ich część (architektura mixture-of-experts). Dzięki temu zachowuje responsywność nawet wtedy, gdy korzysta z niego wiele osób jednocześnie i przy każdej odpowiedzi może sięgać do obszernych fragmentów naszej dokumentacji.
Najważniejsze jest jednak to, gdzie odbywa się przetwarzanie: nasza wiedza wewnętrzna, projekty, oferty, know-how, nigdy nie trafia do zewnętrznego dostawcy. Dla nas to kwestia spokoju; dla klientów z sektorów regulowanych, takich jak finanse, ubezpieczenia, administracja publiczna czy ochrona zdrowia, może to być warunek, bez którego wdrożenie AI w ogóle nie wchodzi w grę.
Ograniczenia i kompromisy
Lokalne LLM nie są rozwiązaniem uniwersalnym. Warto mieć świadomość ich ograniczeń:
- Koszt początkowy: Sprzęt to inwestycja kapitałowa. Zwraca się przy odpowiednio dużej skali i wystarczająco długim horyzoncie czasowym; przy niewielkiej skali lub sporadycznym użyciu tańszym rozwiązaniem może być API w chmurze.
- Sprzęt jako górny pułap: Skoro model działa na naszych maszynach, jesteśmy ograniczeni ich mocą obliczeniową, pamięcią i architekturą. Największych i najbardziej zaawansowanych modeli może się po prostu nie dać uruchomić na danej konfiguracji. W chmurze nic z tego nie ma znaczenia, do API zewnętrznego dostawcy możemy sięgnąć ze starego laptopa, mając jedynie połączenie z internetem, bo cała moc obliczeniowa leży po stronie dostawcy.
- Różnica jakości w najtrudniejszych zadaniach: Przy najbardziej złożonych problemach, wymagających pogłębionego rozumowania, czołowe modele komercyjne wciąż potrafią dawać lepsze rezultaty. Sztuka polega na dopasowaniu modelu do zadania, bo nie każdy problem wymaga najwyższego poziomu rozumowania.
- Bieżące utrzymanie: Model trzeba hostować, monitorować i aktualizować. To realne obciążenie operacyjne, a nie jednorazowe wdrożenie.
Jak uruchamiać LLM lokalnie: na co zwrócić uwagę
Skuteczność lokalnego wdrożenia zależy w równym stopniu od tego, jak model jest uruchamiany, jak i od tego, który model został wybrany. Kilka decyzji technicznych w konfiguracji lokalnego LLM ma nieproporcjonalnie duży wpływ na koszty, jakość i szybkość.
- Kwantyzacja: Wagi modelu można przechowywać z mniejszą precyzją, na przykład 8- lub 4-bitową zamiast domyślnej. Niższa precyzja oznacza mniejsze zużycie pamięci GPU i zwykle szybszą inferencję. Im agresywniejsza kwantyzacja, tym większe oszczędności, ale też tym wyraźniejszy potencjalny spadek jakości wyników. Rzecz w tym, by znaleźć poziom, na którym model działa szybciej i zajmuje mniej pamięci, a utrata jakości pozostaje akceptowalna dla danego zadania. Dlatego wybrany poziom kompresji zawsze weryfikujemy testami jakości na własnych danych.
- Warstwa MTP (multi-token prediction): Standardowy model generuje odpowiedź token po tokenie, co ogranicza jego szybkość. Warstwa MTP pozwala modelowi przewidzieć kilka tokenów w jednym kroku, przyspieszając generowanie bez pogorszenia jakości. Skala efektu zależy od modelu: w naszym teście modelu wykorzystywanego w portalu przetargowym dodanie warstwy MTP podniosło przepustowość z około 72 do 88 tokenów na sekundę, a w przypadku większego wariantu 31B, z 16 do 40, czyli ponad dwukrotnie. Niestety, warstwa MTP nie jest dostępna dla każdego modelu i nieznacznie zwiększa jego rozmiar, więc nie jest domyślnym rozwiązaniem na każdą sytuację.
Diagram porównujący standardowe generowanie tokenów przez LLM (token po tokenie) z szybszym generowaniem z użyciem warstwy multi-token prediction (MTP).
- Mixture-of-experts (MoE): Zamiast uruchamiać wszystkie parametry dla każdego tokena (architektura gęsta, Dense), model MoE jest podzielony na wiele wyspecjalizowanych podsieci, „ekspertów", a niewielki router wybiera dla każdego tokena tylko kilku z nich. Na papierze model może mieć dziesiątki miliardów parametrów, ale pojedyncze zapytanie aktywuje jedynie ich część. W praktyce oznacza to, że model MoE o danym rozmiarze nominalnym działa znacznie szybciej i taniej niż model gęsty tej samej wielkości, zachowując przy tym większość korzyści jakościowych wynikających z dużego rozmiaru. Dobrym przykładem jest model wykorzystywany w naszym portalu przetargowym: mimo 26 miliardów parametrów przy pojedynczym zapytaniu aktywuje tylko około 4 miliardów, co właśnie zapewnia mu większą responsywność. Kompromis leży po stronie sprzętu: wszyscy eksperci muszą i tak zmieścić się w pamięci GPU, mimo że w danym momencie pracuje tylko część z nich.
Diagram porównujący gęstą architekturę (Dense) LLM, w której każde zapytanie aktywuje wszystkie parametry, z modelem mixture-of-experts (MoE), który kieruje każdy token tylko przez kilka wyspecjalizowanych podsieci.
- Okno kontekstowe i cache modelu: Im dłuższy tekst przekazany modelowi, na przykład cały przetarg z załącznikami, tym więcej pamięci GPU zajmuje cache (pamięć robocza modelu), w którym model przechowuje przetworzony dotąd kontekst (zwykle nazywany cache KV). Długość kontekstu faktycznie dostępna w praktyce zależy nie tylko od samego modelu, ale też od tego, ile pamięci pozostaje po wczytaniu jego wag. To jeden z czynników, które trzeba zaplanować od początku.
- Oprogramowanie serwujące: Stos serwujący decyduje o tym, jaką przepustowość uzyskamy na tym samym sprzęcie. Część rozwiązań (vLLM, SGLang) jest zoptymalizowana pod wysoką przepustowość i potrafi obsłużyć wiele równoległych zapytań jednocześnie, co odpowiada zastosowaniom produkcyjnym o dużej skali. Inne (Ollama, llama.cpp) łatwiej uruchomić i dobrze sprawdzają się w prototypowaniu lub mniejszych wdrożeniach, ale kosztem wydajności pod obciążeniem.
- Obsługa wielu zapytań jednocześnie: Gdy model jest używany przez wiele osób lub procesów równolegle, kluczową zdolnością staje się grupowanie równoległych zapytań w efektywne partie przetwarzania, mechanizm znany jako continuous batching. Dojrzałe oprogramowanie serwujące robi to automatycznie i właśnie dzięki temu ten sam sprzęt może obsłużyć kilka razy więcej zapytań, niż pozwoliłoby przetwarzanie sekwencyjne.
- Wybór sprzętu: Głównym ograniczeniem jest zwykle ilość pamięci GPU. Musi ona pomieścić wagi modelu, wspomniane wyżej okno kontekstowe oraz zapas na zapytania równoległe. Jeśli mamy swobodę w doborze sprzętu (nie jesteśmy przywiązani do tego, co już mamy), właściwym punktem wyjścia jest obliczenie, ile pamięci potrzeba do uruchomienia pożądanego modelu przy zakładanym poziomie kwantyzacji i przewidywanym obciążeniu, tak by rozmiar pamięci nie stał się wąskim gardłem.
Tych decyzji nie da się podejmować w oderwaniu od siebie. Kwantyzacja, stos serwujący i dobór pamięci sprzętowej wzajemnie na siebie oddziałują, a pomyłka w jednym miejscu zwykle objawia się słabą wydajnością w innym punkcie łańcucha.
Kiedy lokalny model ma sens, a kiedy nie
Każdy z trzech opisanych wyżej systemów trafia w punkt, w którym lokalne uruchomienie modelu jest faktycznie lepszym rozwiązaniem. Ale równie wiele jest przypadków, w których właściwą odpowiedzią jest API w chmurze.
Lokalny model ma zwykle sens, gdy:
- Dane nie mogą opuścić firmy: Dane osobowe podlegające RODO, dokumentacja medyczna, informacje finansowe, tajemnice przedsiębiorstwa czy dokumenty objęte regulacjami branżowymi (finanse, ubezpieczenia, ochrona zdrowia, administracja publiczna) albo w ogóle nie mogą być przekazywane zewnętrznemu dostawcy, albo tylko z zabezpieczeniami, które czynią całą operację cięższą niż uruchomienie modelu u siebie. W sektorach regulowanych wdrożenie lokalne często nie jest optymalizacją, jest warunkiem, bez którego projekt w ogóle nie powstanie.
- Wolumen jest duży i przewidywalny: Przy milionach tokenów dziennie w powtarzalnym schemacie koszty API rozliczane za zapytanie szybko przewyższają zamortyzowany koszt własnego sprzętu. Mieszczą się tu zarówno portal przetargowy, jak i Policy Insider.
- Potrzebna jest pełna kontrola nad modelem: Dostrajanie na własnych danych, zamrożenie wersji modelu, żeby jego zachowanie nie zmieniło się po aktualizacji u dostawcy, własne kwantyzacje czy niestandardowe konfiguracje serwowania, w przypadku zamkniętego API wszystko to jest albo niemożliwe, albo mocno ograniczone.
API w chmurze ma zwykle sens, gdy:
- Wolumen jest niewielki lub nieprzewidywalny: Przy sporadycznym użyciu amortyzacja sprzętu nigdy nie dogoni rozliczeń za pojedyncze zapytania.
- Potrzebna jest najwyższa możliwa jakość rozumowania: W najtrudniejszych zadaniach czołowe modele komercyjne wciąż mają przewagę. Jeśli o wartości całego systemu decyduje jakość odpowiedzi na najtrudniejsze zapytania, właśnie tam model chmurowy uzasadnia swój koszt. Trzeba jednak dodać, że modele lokalne systematycznie nadrabiają dystans, dobrym przykładem jest Kimi K3, więc z czasem ten argument może już nie wpływać na ostateczną decyzję.
- Brak osób do utrzymania infrastruktury: Wdrożenie lokalne nie jest projektem jednorazowym, ktoś musi utrzymywać GPU w dobrej kondycji, aktualizować stos serwujący i reagować na incydenty. Bez takich kompetencji w firmie, API jest najuczciwszym wyborem.
Kilka słów o bezpieczeństwie danych
Diagram porównujący wdrożenie LLM lokalnie i przez API w chmurze: model uruchomiony u siebie, gdzie dane pozostają w obrębie firmy, oraz zewnętrzny model chmurowy, w którym zapytania opuszczają organizację i trafiają do infrastruktury zewnętrznego dostawcy.
Argument bezpieczeństwa przemawiający za modelami lokalnymi jest mocniejszy niż „dane nie opuszczają firmy”, a jednocześnie bardziej złożony, niż sugeruje to sformułowanie.
Wdrożenie lokalne utrzymuje dane w infrastrukturze pozostającej pod kontrolą organizacji (on-premise), objętej jej politykami dostępu, logowaniem i zasadami retencji. Nie ma regulaminów zewnętrznego dostawcy, które trzeba pogodzić z własnymi obowiązkami regulacyjnymi, nie ma niejasności co do tego, czy zapytania mogą zostać wykorzystane do trenowania przyszłych wersji modelu, i nie ma zależności od poziomu zabezpieczeń po stronie dostawcy. W przypadku wdrożeń korporacyjnych w sektorach regulowanych skraca to często rozmowy o zgodności z regulacjami z miesięcy do dni.
Model działający na własnym sprzęcie nie jest jednak bezpieczny domyślnie. Jest bezpieczny tylko na tyle, na ile bezpieczne jest jego otoczenie. Dostęp musi być uwierzytelniany i audytowany, prompty i odpowiedzi wciąż mogą zawierać dane wrażliwe, z którymi trzeba obchodzić się ostrożnie, a systemy RAG dziedziczą uprawnienia dostępu z indeksowanego repozytorium dokumentów: chatbot, który zaindeksuje pliki niedostępne dla danego użytkownika, bez wahania pokaże mu ich treść.
Właściwy sposób myślenia o tym jest taki: model lokalny usuwa dużą kategorię ryzyka (wyprowadzanie danych poza organizację) i zastępuje ją mniejszą, lepiej znaną (bezpieczeństwo aplikacji i infrastruktury). Dla większości organizacji to korzystna wymiana, ale tylko pod warunkiem, że ta druga kategoria zostanie potraktowana poważnie.
Kluczowe wnioski
- →Lokalne LLM uzasadniają swoją pozycję wolumenem, wrażliwością danych albo jednym i drugim. Przy milionach tokenów dziennie koszty API rozliczane za zapytanie przewyższają zamortyzowany koszt sprzętu. Przy regulacjach sektorowych (finanse, ubezpieczenia, ochrona zdrowia, administracja publiczna) lub RODO model lokalny bywa jedyną opcją, która w ogóle przechodzi weryfikację prawną. Bez tych wymogów uczciwszym wyborem jest zwykle API w chmurze.
- →Dopasuj model do zadania, a nie odwrotnie. Gemma 4 26B pracuje u nas tam, gdzie liczy się czas odpowiedzi (użytkownik czeka, 88 tokenów na sekundę), a większy wariant 31B tam, gdzie dokładność jest ważniejsza niż opóźnienie (wsadowe zadania w tle). Rodzina modeli powinna być zmienną w projekcie, nie decyzją podjętą z góry.
- →Sposób serwowania modelu ma takie samo znaczenie jak jego wybór. Kwantyzacja, warstwa MTP, mixture-of-experts i stos serwujący potrafią więcej niż podwoić przepustowość na tych samych GPU. Samo dodanie warstwy MTP przyspieszyło działanie modelu Gemma 4 31B z 16 do 40 tokenów na sekundę, bez wpływu na jakość.
- →Rozwiązanie lokalne usuwa jedną klasę ryzyka i dodaje inną. Dane przestają opuszczać waszą infrastrukturę, co zwykle skraca uzgodnienia z działem bezpieczeństwa z miesięcy do dni. W zamian bierzecie na siebie zabezpieczenie aplikacji, kontrolę dostępu i to, że model LLM dziedziczy uprawnienia z repozytorium dokumentów, które przeszukuje. To korzystna wymiana tylko wtedy, gdy ta druga kategoria zostanie potraktowana poważnie.
- →Wdrożenie lokalne to zobowiązanie operacyjne, nie jednorazowy projekt. Ktoś musi utrzymywać GPU w dobrej kondycji, aktualizować stos serwujący i reagować na incydenty. Bez takich kompetencji w firmie uczciwszym punktem wyjścia jest zwykle zarządzane API, nawet przy wyższym koszcie jednostkowym.
Jak możemy pomóc
W theBlue.ai wdrażamy lokalne LLM w zastosowaniach korporacyjnych, zarówno dla naszych klientów, jak i wewnątrz własnej firmy. Przeszliśmy tę drogę na swoich systemach i zrealizowaliśmy takie wdrożenia dla innych, więc wiemy, gdzie leżą prawdziwe kompromisy i kiedy model lokalny jest naprawdę właściwą odpowiedzią, a kiedy lepszym rozwiązaniem będzie API w chmurze lub konfiguracja hybrydowa.
Jeśli rozważacie to dla konkretnego zastosowania, nasz Warsztat AI Discovery (od 1 do 3 tygodni) jest zaprojektowany właśnie po to, by odpowiedzieć na to pytanie i przekazać wam propozycję architektury, którą można od razu wdrożyć. Skontaktuj się z nami →
O autorce
Aleksandra Osztynowicz, AI Engineer, theBlue.ai
Aleksandra tworzy w theBlue.ai dedykowane rozwiązania AI od 2021 roku, koncentrując się na wdrożeniach agentowych oraz lokalnych LLM precyzyjnie dopasowanych do potrzeb dużych organizacji. Jako AI Engineer pomaga firmom automatyzować procesy za pomocą systemów gotowych do pracy produkcyjnej, od modeli open source działających na własnej infrastrukturze po oparte na RAG wewnętrzne bazy wiedzy dla branż regulowanych, i nieustannie rozwija swoją wiedzę w szybko zmieniającym się świecie sztucznej inteligencji.W swoich artykułach dzieli się praktycznym doświadczeniem z rzeczywistych projektów AI w przedsiębiorstwach i pokazuje, że wdrażanie AI w firmach nie musi być skomplikowane.