Lokalny LLM: Ollama czy LM Studio. Kiedy to ma sens

Model językowy na własnym laptopie brzmi jak zabawka dla entuzjastów, dopóki nie policzysz, ile razy w miesiącu wysyłasz dokumenty klienta do cudzego API. Postawiłem u siebie Ollamę i LM Studio, przepuściłem przez nie ten sam materiał, którym normalnie karmię Claude'a, i wyszła proporcja, której się nie spodziewałem. Lokalny model rozwiązuje mniej problemów, niż obiecuje marketing, ale te, które rozwiązuje, są dokładnie tymi, na których firmy z branży finansowej zacinają się przy wdrożeniu AI.

Rozbieram temat od strony liczb: ile pamięci karty zjada który model, gdzie kończy się jakość odpowiedzi i kiedy sprzęt wychodzi taniej niż faktura za tokeny.

Czytanie: ~10 min

Dlaczego akurat teraz warto to policzyć

Dwa lata temu lokalny model był ciekawostką. Odpowiadał wolno, gubił składnię przy dłuższym tekście i nie umiał wywołać narzędzia. Dziś model 8-miliardowy w kwantyzacji 4-bitowej mieści się w pamięci karty za dwa tysiące złotych, obsługuje function calling i utrzymuje sensowny polski przez kilkanaście akapitów.

Zmieniła się też druga strona równania. Rachunki za API rosną nie dlatego, że ceny idą w górę, tylko dlatego, że zaczynamy używać modeli w pętli. Jeden agent, który przetwarza folder z pięciuset dokumentami, generuje więcej tokenów niż miesiąc rozmów w czacie. Kiedy zadanie jest powtarzalne i głupie, płacenie za najlepszy model na rynku przestaje mieć uzasadnienie.

Argument o RODO jest w połowie nieprawdziwy

Najczęstsze uzasadnienie dla lokalnego modelu brzmi „nie możemy wysyłać danych do chmury, bo RODO". W większości przypadków to nieprawda i szkoda, że tak często kończy dyskusję.

OpenAI, Anthropic i Microsoft mają wzory umów powierzenia przetwarzania, serwery w regionie UE i tryb, w którym dane nie idą na trening. Prawnie da się to ułożyć. Zrobiłem to u siebie i przy zleceniach dla klientów z sektora finansowego, i nie było to trudne.

Prawdziwe blokady wyglądają inaczej i są bardziej prozaiczne:

• klauzula w umowie z klientem końcowym, która zabrania przekazywania jego danych podmiotom trzecim, bez wyjątków dla podprzetwarzających
• wymóg audytowy lub sektorowy, w którym trzeba wskazać fizyczną lokalizację przetwarzania
• decyzja właściciela firmy, który po prostu nie chce, żeby jego dokumentacja wychodziła poza serwerownię, i nie musi tego uzasadniać

Jeśli któryś z tych punktów dotyczy twojego projektu, lokalny model przestaje być fanaberią i staje się jedyną drogą. Jeśli żaden nie dotyczy, przeczytaj resztę tekstu jako rachunek ekonomiczny, nie jako argument o bezpieczeństwie.

Matematyka pamięci, której nie da się oszukać

To jedyna rzecz, którą musisz zrozumieć przed pierwszą instalacją. Wszystko inne można doczytać później.

Model w pełnej precyzji (16 bitów na parametr) zajmuje około 2 GB pamięci na każdy miliard parametrów. Model 8B to 16 GB, model 70B to 140 GB. Żadna konsumencka karta tego nie udźwignie, dlatego w praktyce używa się modeli skwantyzowanych, czyli takich, w których wagi zapisano na mniejszej liczbie bitów.

Standardem jest kwantyzacja 4-bitowa, w plikach GGUF opisana jako Q4_K_M. Zjada około 0,5-0,6 GB na miliard parametrów. Do tego trzeba doliczyć bufor na kontekst, który przy 8 tysiącach tokenów zabiera niecały gigabajt, a przy 32 tysiącach potrafi zjeść cztery.

Przelicznik, którym się posługuję przy szacowaniu:

| Rozmiar modelu | Q4_K_M | Minimalna karta | Realny komfort | |---|---|---|---| | 3B | ~2 GB | 6 GB VRAM | laptop bez dedykowanej karty da radę na CPU | | 8B | ~5 GB | 8 GB VRAM | 12 GB, jeśli chcesz duży kontekst | | 14B | ~9 GB | 12 GB VRAM | 16 GB | | 32B | ~20 GB | 24 GB VRAM | 24 GB, ale bez zapasu | | 70B | ~42 GB | dwie karty 24 GB | stacja robocza albo Mac ze 64 GB |

Granica jest ostra i to jest ważniejsze niż wygląda. Model, który wchodzi w pamięć karty, odpowiada z prędkością 30-60 tokenów na sekundę, więc szybciej, niż czytasz. Model, który przekracza pamięć o dwa gigabajty, ląduje częściowo w RAM-ie i spada do 2-4 tokenów na sekundę. Różnica między „działa świetnie" i „nie da się tego używać" to często jedna warstwa modelu.

Osobny przypadek to Apple Silicon. Pamięć jest tam wspólna dla procesora i układu graficznego, więc MacBook Pro z 36 GB uruchomi model 32B bez kombinowania. Na Windowsie z kartą 12 GB o tym samym modelu można zapomnieć.

Ollama i LM Studio nie są konkurentami

Oba narzędzia uruchamiają te same pliki GGUF na tym samym sprzęcie i oba wystawiają API zgodne z formatem OpenAI. Różni je pomysł na to, kto ma z nich korzystać.

Ollama, czyli Docker dla modeli

Ollama to demon, który siedzi w tle i słucha na porcie 11434. Instalujesz, wpisujesz jedno polecenie i masz model gotowy do zapytań.

ollama pull llama3.1:8b
ollama run llama3.1:8b

Modele bierze z własnego rejestru, wersjonowane tagami jak obrazy kontenerów. To wygodne przy powtarzalnych wdrożeniach, bo llama3.1:8b na moim laptopie i na serwerze klienta oznacza dokładnie ten sam plik z tą samą kwantyzacją. Konfigurację systemowego promptu i parametrów trzymasz w pliku Modelfile, który idzie do repozytorium razem z kodem.

Wady wychodzą, gdy chcesz odejść od rejestru. Import własnego GGUF z Hugging Face jest możliwy, ale wymaga ręcznego pliku konfiguracyjnego. Domyślne ustawienia kontekstu są zachowawcze i pierwsze zderzenie z tym kosztowało mnie godzinę zdziwienia, dlaczego model „zapomina" początek dokumentu, choć okno miało być duże.

Ollama jest wyborem, kiedy model ma być elementem systemu: backend, kontener, skrypt w CI.

LM Studio, czyli warsztat z suwakami

LM Studio to aplikacja okienkowa. Przeglądasz Hugging Face bez wychodzenia z programu, widzisz przy każdym pliku, czy zmieści się w twojej pamięci, i ładujesz go jednym kliknięciem. Suwaki dla temperatury, długości kontekstu i liczby warstw przenoszonych na kartę masz na wierzchu.

Ta widoczność jest realną zaletą przy szukaniu granic sprzętu. Zamiast czytać dokumentację, przesuwasz suwak liczby warstw, patrzysz na zużycie pamięci i po pięciu minutach wiesz, gdzie leży twój limit. Na Macu dodatkowo dostajesz modele w formacie MLX, które na Apple Silicon są wyraźnie szybsze niż te same modele w GGUF.

Serwer lokalny włączasz jedną zakładką i słucha na porcie 1234, też w formacie OpenAI. Do produkcji bym tego nie stawiał, bo to aplikacja z interfejsem, a nie usługa systemowa.

Mój podział wygląda tak: LM Studio do testowania i wybierania modelu, Ollama do wpuszczania go w kod. Instalowanie obu naraz nie jest marnotrawstwem, tylko normalną kolejnością pracy.

Czego lokalny model nie zrobi, choćbyś bardzo chciał

Tu kończy się część optymistyczna. Model 8B skwantyzowany do czterech bitów nie zbliża się do najlepszych modeli w chmurze i żadne ustawienie tego nie zmieni.

Zadania, w których lokalne modele wypadają u mnie słabo:

• Kod w większym projekcie. Zaproponuje sensowną funkcję, ale zgubi się w architekturze i wymyśli metodę, której nie ma w bibliotece. Do refaktoru w .NET dalej używam Claude'a i nie widzę powodu, żeby to zmieniać.
• Wielostopniowe rozumowanie. Zadanie z trzema warunkami i wyjątkiem od jednego z nich rozjeżdża się w połowie.
• Długi kontekst. Nominalnie modele obsługują 128 tysięcy tokenów. Praktycznie przy 20 tysiącach jakość odpowiedzi zaczyna siadać, a wcześniej siada twoja pamięć karty.
• Polski w tekstach na zewnątrz. Modele 8B piszą po polsku poprawnie, ale sztywno. Do posta na LinkedIn się nie nadaje.

Za to jest zestaw zadań, w których lokalny model wygrywa nie „prawie tak dobrze", a wprost lepiej niż chmura, bo liczy się przepustowość i brak limitów:

• klasyfikacja i tagowanie dużych zbiorów, na przykład przypisanie kategorii kosztowej do dziesięciu tysięcy opisów z wyciągu bankowego
• wyciąganie pól z dokumentów po wcześniejszym OCR, gdzie liczy się schemat wyjściowy, nie elokwencja
• generowanie embeddingów pod RAG, które przy dużej bazie w chmurze robi się absurdalnie drogie
• anonimizacja przed wysłaniem czegokolwiek dalej, czyli lokalny model jako filtr przed modelem w chmurze

Ostatni punkt jest moim ulubionym rozwiązaniem tego całego dylematu. Lokalny model wycina nazwiska, numery kont i identyfikatory, a do chmury leci już tekst pozbawiony danych osobowych. Masz jakość dużego modelu i argument dla prawnika w jednym.

Kiedy sprzęt zwraca się szybciej niż API

Policzmy uczciwie, bo to zwykle rozstrzyga dyskusję szybciej niż argumenty o prywatności.

Używana karta z 24 GB pamięci to w Polsce wydatek około 3000-3500 zł. Pobiera pod obciążeniem jakieś 350 W, więc przy stawce 1 zł za kilowatogodzinę godzina pracy kosztuje 0,35 zł. Osiem godzin dziennie przez miesiąc to niecałe 60 zł prądu.

Po drugiej stronie: dobry model w chmurze to rząd kilku dolarów za milion tokenów wejściowych i kilkunastu za wyjściowe. Przy rozmowach w czacie nie przekroczysz w miesiącu równowartości kilkudziesięciu złotych i kupowanie karty jest wtedy czystą stratą pieniędzy.

Sytuacja odwraca się, gdy wchodzi przetwarzanie wsadowe. Pipeline, który co noc przepuszcza kilka tysięcy dokumentów, robi dziesiątki milionów tokenów miesięcznie. Przy rachunku 800 zł na miesiąc karta zwraca się w cztery miesiące i od piątego pracuje za prąd. Przy rachunku 100 zł nie zwróci się nigdy, bo wcześniej się zestarzeje.

Do tego dochodzi koszt, którego nikt nie wpisuje w arkusz: twój czas. Pierwsze uruchomienie zajmie ci pół godziny, ale utrzymanie sterowników, aktualizacje i debugowanie sytuacji „dlaczego dziś wolniej" to kilka godzin w roku. Przy jednym projekcie to nie ma znaczenia. Przy trzech naraz zaczyna boleć.

Podłączenie do .NET bez przepisywania kodu

Techniczny szczegół, który przesądza o tym, że warto spróbować: oba narzędzia udają API OpenAI. Jeśli twoja aplikacja gada już z jakimkolwiek modelem przez oficjalny klient, zmieniasz adres bazowy i klucz na dowolny łańcuch znaków.

// klucz jest ignorowany lokalnie, ale klient wymaga niepustej wartości
var client = new OpenAIClient(
    new ApiKeyCredential("nieistotne"),
    new OpenAIClientOptions { Endpoint = new Uri("http://localhost:11434/v1") });

var chat = client.GetChatClient("llama3.1:8b");
var odpowiedz = await chat.CompleteChatAsync("Sklasyfikuj koszt: paliwo, faktura 340 zł");

Ten sam mechanizm działa w Semantic Kernel, w LangChain i w n8n, gdzie wystarczy dodać własny endpoint w konfiguracji poświadczeń OpenAI. Dzięki temu decyzja „lokalnie czy w chmurze" schodzi do poziomu zmiennej środowiskowej i możesz ją podejmować per zadanie, a nie per projekt.

Jedna pułapka z praktyki: pierwsze zapytanie po dłuższej przerwie trwa kilka sekund, bo model musi wejść do pamięci. Ollama wyrzuca go po pięciu minutach bezczynności. Jeśli twój endpoint ma odpowiadać szybko, ustaw OLLAMA_KEEP_ALIVE na dłuższy czas albo pogódź się z zimnym startem.

Co bym wybrał na twoim miejscu

Jeśli chcesz tylko sprawdzić, o co ten hałas, zainstaluj LM Studio i pobierz model 8B w kwantyzacji Q4. Kwadrans pracy, zero konfiguracji, od razu widzisz, co ten sprzęt potrafi.

Jeśli masz konkretne zadanie wsadowe i rachunek za API, który rośnie z miesiąca na miesiąc, policz break-even zanim cokolwiek kupisz. Poniżej dwustu złotych miesięcznie nie ma o czym rozmawiać.

Jeśli twoja blokada jest umowna albo audytowa, lokalny model nie jest oszczędnością, tylko warunkiem wejścia w projekt. Wtedy patrz na to jak na koszt licencji, którego nie da się ominąć, i zaplanuj sprzęt z zapasem, bo model 32B potrafi zdziałać znacznie więcej niż 8B.

A jeśli chodzi ci głównie o spokój z danymi osobowymi, zanim wydasz trzy tysiące na kartę, zbuduj filtr anonimizujący na modelu 3B. Dwa dni pracy i problem znika w większości scenariuszy.

Jeśli zastanawiasz się, czy w twoim procesie lokalny model ma sens, i wolisz to sprawdzić na własnych danych niż na cudzej prezentacji, napisz do mnie przez mwozniczka.net/kontakt. Robię prototypy, które da się przetestować w codziennej pracy, zanim zapadnie decyzja o większym wdrożeniu.