Własny model AI na firmowym serwerze. Kiedy to najlepsza decyzja roku, a kiedy droga zabawka

Co dokładnie znaczy „lokalny model”

Zacznijmy od uporządkowania pojęć, bo w rozmowach handlowych mieszają się trzy zupełnie różne rzeczy i tylko jedna z nich jest naprawdę lokalna.

Pierwsza to model open-weight uruchomiony na sprzęcie, który należy do firmy albo jest przez nią wynajęty — na serwerze w szafie w biurze, na maszynie w polskiej serwerowni, na VPS-ie z kartą graficzną. Dane wchodzą do modelu i wychodzą z niego w obrębie infrastruktury, którą kontrolujecie. To jest on-premise w ścisłym sensie i tylko o tym mówi ten tekst.

Druga to ten sam otwarty model, ale wystawiony jako usługa przez zewnętrznego dostawcę. Bywa tańszy od modeli zamkniętych i bywa hostowany w Unii, ale z punktu widzenia RODO to nadal powierzenie danych podmiotowi trzeciemu — z umową, z rejestrem, z całą resztą obowiązków.

Trzecia to model zamknięty w wersji firmowej, z zapewnieniem, że dane nie trafiają do trenowania i że przetwarzanie odbywa się w wybranym regionie. To wciąż chmura, tylko z lepszą umową. Dla ogromnej większości firm ta trzecia opcja jest wystarczająca i kończy temat — a warto to sprawdzić, zanim ktoś zamówi serwer.

Cztery sytuacje, w których on-premise naprawdę się broni

Są przypadki, w których lokalny model nie jest kaprysem, tylko jedynym rozsądnym rozwiązaniem. Wszystkie mają wspólną cechę: to nie kwestia preferencji, tylko ograniczenia, którego nie da się obejść umową.

1. Tajemnica zawodowa i dane, których nie wolno powierzyć. Kancelarie, gabinety, biura rachunkowe pracujące na pełnej dokumentacji klienta, firmy związane umowami NDA, które wprost wykluczają przekazywanie treści podmiotom trzecim. Tu nie chodzi o poczucie bezpieczeństwa, tylko o zapis w umowie albo w ustawie.
2. Duży, powtarzalny wolumen tego samego zadania. Klasyfikacja tysięcy zgłoszeń dziennie, tagowanie dokumentów, ekstrakcja pól z faktur, wstępne streszczanie korespondencji. Te zadania są proste, więc nie potrzebują najlepszego modelu na świecie — a jest ich tyle, że rachunek za API zaczyna być pozycją w budżecie.
3. Praca offline lub w odciętej sieci. Produkcja, obiekty bez stabilnego łącza, środowiska odseparowane od internetu z założenia. Model, który działa lokalnie, działa też wtedy, gdy nie działa nic innego.
4. Wymóg pełnej powtarzalności. Model w chmurze zmienia się bez pytania — dostawca aktualizuje wersję, a odpowiedzi na to samo zapytanie zaczynają wyglądać inaczej. Jeśli budujecie proces, który musi dawać identyczny wynik za rok, własny model o zamrożonej wersji jest jedynym sposobem, żeby to zagwarantować.

Ile to naprawdę kosztuje — rachunek, którego nikt nie robi

Pierwszy błąd w liczeniu polega na porównaniu ceny karty graficznej z rachunkiem za API. To porównanie zawsze wychodzi korzystnie dla serwera i zawsze jest nieprawdziwe, bo pomija wszystko, co po zakupie sprzętu dopiero się zaczyna.

Po stronie sprzętu obraz jest dziś dość prosty. Karta konsumencka z 32 GB pamięci wystarcza do modeli kilkunastomiliardowych i kosztuje kilkanaście tysięcy złotych; karta profesjonalna z 96 GB pozwala uruchomić model klasy 70B na jednej maszynie i kosztuje kilka razy więcej. Do tego reszta serwera, zasilanie, chłodzenie i miejsce, w którym to ma stać przez trzy lata. Dla małej firmy realny próg wejścia to rząd dwudziestu–pięćdziesięciu tysięcy złotych za maszynę, która sensownie obsłuży kilkanaście osób.

Po stronie kosztów, których nikt nie wpisuje do arkusza, jest reszta: ktoś musi to skonfigurować, aktualizować, monitorować i naprawiać, gdy przestanie odpowiadać w środę o dziewiątej. Ktoś musi podjąć decyzję o zmianie modelu na nowszy, przetestować ją i cofnąć, jeśli okaże się gorsza. Ktoś musi odpowiedzieć zespołowi na pytanie, dlaczego firmowy asystent radzi sobie gorzej niż to, co mają w przeglądarce. Te godziny są prawdziwym kosztem wdrożenia i to one decydują, czy projekt przeżyje rok.

Publiczne analizy porównujące własną infrastrukturę z API dają dziś zbieżny wynik: przy średnim natężeniu pracy zespołu zwrot z zakupu sprzętu wypada gdzieś w okolicach półtora–dwóch lat, a naprawdę wyraźne oszczędności zaczynają się dopiero przy wolumenach liczonych w dziesiątkach milionów tokenów dziennie. To dużo więcej, niż generuje typowa firma zatrudniająca trzydzieści osób. Jak w ogóle podejść do liczenia takich progów, rozpisaliśmy w tekście o tym, ile kosztuje wdrożenie AI.

Wniosek nie brzmi „nie róbcie tego”. Brzmi: jeśli jedynym argumentem za własnym serwerem jest cena, to prawie na pewno się nie opłaci. Jeśli argumentem jest to, że dane nie mogą wyjść z firmy — rachunek wygląda zupełnie inaczej, bo alternatywą nie jest tańsza chmura, tylko brak AI w tym procesie w ogóle.

Jakość: gdzie otwarte modele dorównały, a gdzie wciąż odstają

Przez dwa lata standardowa odpowiedź brzmiała: modele otwarte są wyraźnie słabsze. Dziś to zdanie wymaga rozbicia na kawałki, bo w części zastosowań przestało być prawdziwe.

W zadaniach zamkniętych — klasyfikacja, ekstrakcja danych ze wzoru dokumentu, przepisanie treści do struktury, tagowanie, proste streszczenie — dobre modele otwarte średniej wielkości robią dziś robotę nieodróżnialną od modeli komercyjnych. To są zadania, w których liczy się posłuszeństwo wobec instrukcji, a nie błyskotliwość, i to jest naturalne miejsce dla lokalnego modelu.

W zadaniach otwartych — złożone rozumowanie, długi kontekst, praca na kilkuset stronach dokumentacji, pisanie kodu, wieloetapowe zadania agentowe — różnica pozostaje odczuwalna i widać ją gołym okiem po kilku minutach pracy. Zespół, który dostanie do takich zadań model o połowę słabszy, przestanie go używać w ciągu miesiąca i wróci do własnych narzędzi. Mechanizm jest dokładnie ten sam, który opisaliśmy w tekście o tym, dlaczego zespół nie używa AI, a skutkiem ubocznym bywa shadow AI — czyli sytuacja, przed którą lokalny model miał chronić.

Osobno warto odnotować polski wątek. Bielik i PLLuM to modele rozwijane w Polsce, dostępne otwarcie i wyraźnie lepiej radzące sobie z niuansem polszczyzny, niż wynikałoby to z ich rozmiaru. PLLuM wchodzi do administracji i samorządów, Bielik rozwija się w stronę multimodalności. W zastosowaniach urzędowych, edukacyjnych i tam, gdzie liczy się poprawna, formalna polszczyzna, są realną opcją — i mają tę zaletę, że pytanie „czyje to jest i gdzie stoi” ma tu jednoznaczną odpowiedź.

Mniejszy model, mądrzejsze użycie: dlaczego SLM zmieniły ten rachunek

Największa zmiana ostatnich kilkunastu miesięcy nie polega na tym, że duże modele stały się większe, tylko że małe stały się użyteczne. Model o kilku miliardach parametrów, który jeszcze niedawno nadawał się głównie do demonstracji, dziś obsługuje konkretne zadanie firmowe na sprzęcie za kilkanaście tysięcy złotych — pod warunkiem że zadanie jest wąskie.

To przesuwa całą logikę wdrożenia. Zamiast pytać „jaki model postawić, żeby zastąpił ludziom ChatGPT”, warto zapytać „które trzy zadania w firmie są na tyle powtarzalne i na tyle wrażliwe, żeby warto je było wykonać u siebie”. Odpowiedź prawie zawsze wskazuje na coś nudnego: wstępna klasyfikacja poczty, wyciąganie danych z dokumentów, anonimizacja treści przed wysłaniem gdziekolwiek dalej.

Ten ostatni przypadek jest wart osobnego zdania, bo bywa najlepszym kompromisem, jaki da się zbudować. Lokalny model wykonuje jeden krok — usuwa z dokumentu dane osobowe i identyfikatory — a dopiero oczyszczona treść trafia do mocnego modelu w chmurze. Firma dostaje jakość modelu komercyjnego i zatrzymuje dane wrażliwe u siebie. Architektonicznie to ta sama logika, którą opisaliśmy przy integracji AI z systemami firmy przez MCP: decyduje nie to, jaki model jest po drugiej stronie, tylko co dokładnie do niego wysyłacie.

Co lokalny model załatwia po stronie prawa, a czego nie

Krąży przekonanie, że model na własnym serwerze zdejmuje z firmy obowiązki wynikające z RODO i AI Act. Zdejmuje część i warto wiedzieć którą, bo pozostała część potrafi zaskoczyć.

Po stronie RODO znika powierzenie przetwarzania podmiotowi trzeciemu — nie ma dostawcy, nie ma umowy powierzenia, nie ma transferu poza EOG, nie ma pytania o to, jak długo dane leżą w logach usługi. To realne uproszczenie i dla części branż decydujące. Nie znika natomiast nic więcej: nadal potrzebujecie podstawy prawnej przetwarzania, nadal obowiązuje minimalizacja danych, nadal trzeba to ująć w rejestrze czynności, a przy przetwarzaniu na dużą skalę — ocenić skutki. Serwer w piwnicy nie jest podstawą prawną.

Po stronie AI Act lokalne uruchomienie modelu nie zmienia praktycznie nic. Obowiązki podmiotu stosującego zależą od tego, do czego system służy, a nie od tego, gdzie stoi. System wspierający decyzje kadrowe jest systemem wysokiego ryzyka niezależnie od miejsca uruchomienia — rozpisaliśmy to w tekście o AI w rekrutacji po AI Act. Obowiązki informacyjne wobec klientów też obowiązują tak samo, o czym pisaliśmy przy AI Act w małej firmie.

Jest za to obowiązek, który przy on-premise przybywa: bezpieczeństwo tej infrastruktury staje się Waszą odpowiedzialnością w całości. Serwer z modelem, który ma dostęp do firmowych dokumentów, jest dokładnie tak samo wrażliwy jak serwer plików — z aktualizacjami, kontrolą dostępu, kopiami zapasowymi i logowaniem, kto o co pytał.

Jak sprawdzić to u siebie w dwa tygodnie, nie kupując niczego

Najgorszy możliwy scenariusz to zamówienie sprzętu przed sprawdzeniem, czy model w ogóle poradzi sobie z zadaniem. Odwrotna kolejność kosztuje kilkanaście godzin i rozstrzyga sprawę.

Tydzień pierwszy — nazwijcie zadanie i zbierzcie dane testowe. Jedno zadanie, wąskie, opisane jednym zdaniem: „wyciągnij z faktury numer, kontrahenta, kwotę i termin płatności”. Do tego trzydzieści–pięćdziesiąt prawdziwych przykładów z odpowiedziami, które uznajecie za poprawne. Bez tego zbioru każda dalsza dyskusja o jakości modelu jest wymianą wrażeń.

Tydzień drugi — uruchomcie model otwarty na jednym laptopie z porządną kartą albo na wynajętej maszynie z GPU, na godziny. Puśćcie te same trzydzieści przykładów przez model lokalny i przez model komercyjny. Policzcie trafienia. Jeśli lokalny wypada w granicach kilku procent od komercyjnego — macie odpowiedź i możecie liczyć sprzęt. Jeśli odstaje wyraźnie, zadanie jest za trudne albo za szeroko postawione, i lepiej to wiedzieć teraz.

Dopiero po tym teście ma sens rozmowa o zakupie. I ma ona wtedy zupełnie inny charakter, bo dotyczy konkretnego zadania, konkretnego wolumenu i konkretnej liczby, a nie ogólnego przekonania, że „u siebie będzie bezpieczniej”. Ten sam sposób pracy — najpierw pomiar, potem decyzja — opisaliśmy przy audycie AI w firmie.

Najczęstsze błędy przy wdrożeniach on-premise

Z wdrożeń, które widzieliśmy i które nie przetrwały pierwszego roku, wracają cztery te same pomyłki.

1. Zakup sprzętu przed testem jakości. Serwer stoi, model działa, tylko nikt nie sprawdził wcześniej, czy odpowiedzi są wystarczająco dobre do zadania. Bywa, że nie są, i wtedy sprzęt zostaje.
2. Postawienie lokalnego modelu jako uniwersalnego zamiennika czatu dla całej firmy. Porównanie z narzędziami, które ludzie mają prywatnie, jest natychmiastowe i bezlitosne. Lokalny model wygrywa w wąskim zadaniu, nie w konkursie ogólnym.
3. Brak właściciela po stronie firmy. Wdrożenie robi zewnętrzny wykonawca, po czym nikt wewnątrz nie odpowiada za aktualizacje i monitoring. Po pół roku system działa na modelu o dwie generacje starszym i nikt tego nie zauważył.
4. Potraktowanie serwera jako granicy bezpieczeństwa. Model lokalny nie chroni przed tym, że ktoś wklei do niego dane, do których nie ma dostępu, albo że asystent podpięty do dysku pokaże pracownikowi dokumenty spoza jego uprawnień. Kontrola dostępu musi być po stronie danych, nie modelu — pisaliśmy o tym przy asystencie AI na dokumentach firmy.

Od czego zacząć

Zacznijcie od pytania, które rozstrzyga sprawę szybciej niż jakiekolwiek porównanie modeli: czy jest w firmie zadanie, którego nie możecie dziś zrobić z pomocą AI wyłącznie dlatego, że dane nie mogą opuścić firmy? Jeśli tak — lokalny model jest właściwym kierunkiem i warto policzyć go serio. Jeśli nie, a chodzi tylko o poczucie kontroli albo o rachunek za API, prawie zawsze taniej i skuteczniej wyjdzie dobrze skonfigurowana usługa z porządną umową.

Tak z tym pracujemy: najpierw jedno wąskie zadanie i pomiar na prawdziwych danych, potem decyzja o architekturze, a sprzęt dopiero na końcu — jeśli liczby go bronią. Zakres konsultingu i wdrożeń AI opisaliśmy osobno, stawki znajdziesz w cenniku, a jeśli chcesz sprawdzić, czy w Waszym przypadku on-premise ma sens — umów bezpłatną konsultację.