Wdrożenie modelu Bielik na VPS a błąd wyczerpania przestrzeni dyskowej

Utrata kontroli nad ścieżką zapisu lokalnych modeli LLM prowadzi do krytycznego przepełnienia dysku systemowego na serwerach VPS. Implementacja modelu Bielik poprzez środowisko Ollama wymaga precyzyjnej rekonfiguracji architektury przechowywania danych, aby zagwarantować stabilność systemu operacyjnego i obniżyć koszty infrastruktury z zachowaniem pełnej izolacji danych.

Architektura lokalnego LLM: motywacja prawna i kosztowa

Wdrożenie lokalnego modelu językowego upraszcza zgodność z RODO, ponieważ eliminuje transfer danych osobowych do chmur publicznych i redukuje liczbę podmiotów przetwarzających, które trzeba objąć umowami powierzenia. Modele klasy Bielik operują w architekturze zamkniętej, w której logi zapytań ani kontekst przetwarzania nie opuszczają infrastruktury sprzętowej administratora danych.

Komercyjne interfejsy API dostawców takich jak OpenAI czy Anthropic wymuszają przesyłanie informacji na zewnętrzne serwery, co rozszerza powierzchnię ryzyka. Nie jest to jednak automatyczne naruszenie przepisów — transfer do państw trzecich bywa legalizowany decyzją o adekwatności (Data Privacy Framework), standardowymi klauzulami umownymi (SCC) i umową powierzenia, a więksi dostawcy oferują tryby zero-retention oraz przetwarzanie w regionie UE. Self-hosting nie tyle „ratuje przed nielegalnością", ile znosi konieczność utrzymywania i audytowania całej tej warstwy formalnej, a przy tym daje niezależność od przerw w dostępie do sieci i chroni przed vendor lock-in.

Rachunek kosztowy zależy wyłącznie od wybranego modelu i długości kontekstu, więc porównanie ma sens tylko z jawnymi założeniami. Przykładowo: 500 zapytań dziennie po ~2 000 tokenów wejścia i ~500 tokenów wyjścia to ok. 30 mln tokenów wejścia i 7,5 mln wyjścia miesięcznie — przy modelach z najwyższej półki daje to kwoty rzędu setek dolarów, przy tanich modelach klasy „mini/flash" zaledwie kilka–kilkanaście dolarów. Punktem odniesienia dla wariantu lokalnego jest stały koszt VPS-a (kilkanaście–kilkadziesiąt EUR miesięcznie) niezależny od wolumenu. Zanim podejmiesz decyzję, policz to na aktualnym cenniku swojego dostawcy i własnym rozkładzie zapytań.

Warto też urealnić oczekiwania wobec opóźnień: model 11B uruchamiany na CPU generuje kilka tokenów na sekundę, więc pełna odpowiedź powstaje w dziesiątkach sekund. Wartości rzędu 100–500 ms dotyczą czasu do pierwszego tokena (TTFT) na akceleratorze GPU, a nie scenariusza CPU-only opisywanego w tym artykule. Zyskiem lokalnego wdrożenia jest przewidywalność opóźnień i brak zależności od obciążenia cudzej infrastruktury, a nie surowa szybkość.

Instalacja środowiska Ollama i polskiego modelu Bielik

Ollama stanowi wiodący silnik do serwowania skwantyzowanych modeli językowych w lokalnych środowiskach produkcyjnych, domyślnie nasłuchując żądań na lokalnym porcie sieciowym. Polskojęzyczny model Bielik, dysponujący miliardami parametrów, wymaga integracji przez interfejsy API, gdzie mechanizmy kwantyzacji obniżają zapotrzebowanie na pamięć — vRAM przy uruchomieniach na GPU, a RAM systemowy przy inferencji procesorowej.

Bielik w wariancie 11b-v2.3-instruct to model o 11,2 miliarda parametrów. Same wagi w precyzji 16-bitowej zajmują ok. 22 GB, a doliczając cache KV i narzut runtime realne zapotrzebowanie karty graficznej sięga 24–32 GB vRAM. W środowiskach bez specjalistycznych akceleratorów GPU instalacja sprowadza się do wykorzystania zoptymalizowanych plików typu GGUF, które aplikują kwantyzację do formatów takich jak Q4_K_M, Q5_K_M czy Q8_0. Dla VPS-a rozsądnym punktem startu jest Q4_K_M (~6,7 GB); Q8_0 zajmuje ~12 GB i według samego SpeakLeash jest praktycznie nieodróżnialny od float16, ale zasobożerny i wolny, przez co nie jest rekomendowany dla większości zastosowań. Pobranie i uruchomienie instancji realizowane jest poprzez interfejs CLI za pomocą jednej komendy:

ollama run SpeakLeash/bielik-11b-v2.3-instruct:Q4_K_M

Po aktywacji demon Ollama serwuje żądania z wykorzystaniem REST API na porcie 11434 (http://localhost:11434), co umożliwia płynną integrację z innymi językami programowania, w tym z wykorzystaniem biblioteki OpenAI. Procesy nie są taryfikowane za „zużyty token”, co umożliwia wielowątkową, darmową analizę obszernych korpusów tekstu.

Eliminacja podatności: przeniesienie katalogu OLLAMA_MODELS

Domyślna instalacja silnika Ollama wymusza bezwarunkowy zapis wielogigabajtowych plików wag modeli bezpośrednio na partycji systemowej. W środowiskach wirtualnych prowadzi to do natychmiastowego wyczerpania krytycznej przestrzeni dyskowej. Prawidłowa architektura wdrożenia wymaga permanentnej relokacji bazy danych modeli na wyizolowany wolumen dyskowy poprzez modyfikację systemd.

W systemach z rodziny Linux domyślną lokalizacją docelową jest /usr/share/ollama/.ollama/models. W systemach Windows oprogramowanie zapisuje dane na dysku systemowym w lokalizacji C:\Users\<username>\.ollama\models. Relokacja na dodatkowy wolumen wymaga zmiany systemowej zmiennej środowiskowej o nazwie OLLAMA_MODELS. Wykorzystanie popularnego dowiązania symbolicznego (symlink) bywa niezalecane; udokumentowanym standardem architektonicznym jest nadpisanie parametrów usługi.

W systemie Linux migrację przeprowadza się w następujących krokach:

1. Zatrzymanie usługi poleceniem sudo systemctl stop ollama.service.
2. Synchronizacja i transfer danych rsync-em na nowy zasób, np. sudo rsync -av /usr/share/ollama/.ollama/models/ /srv/ollama-models/.
3. Nadanie właściciela katalogowi docelowemu: sudo chown -R ollama:ollama /srv/ollama-models. Bez tego kroku usługa nie wystartuje — demon działa na koncie ollama i nie zapisze do katalogu należącego do roota.
4. Modyfikacja pliku systemd przez sudo systemctl edit ollama.service i dodanie bloku z parametrem Environment="OLLAMA_MODELS=/srv/ollama-models" w sekcji [Service].
5. Przeładowanie konfiguracji przez sudo systemctl daemon-reload i uruchomienie silnika komendą sudo systemctl start ollama.service.
6. Weryfikacja: systemctl show ollama.service | grep OLLAMA_MODELS powinno zwrócić nową ścieżkę, a ollama list — komplet wcześniej pobranych modeli.
7. Usunięcie starych danych z katalogu bazowego w /usr dopiero po potwierdzeniu funkcjonalności.

Jeśli unit korzysta z mechanizmów sandboxingu systemd (ProtectSystem=, ProtectHome=, ReadWritePaths=), katalog spoza dozwolonych ścieżek zostanie zablokowany mimo poprawnych uprawnień plikowych — objawia się to błędem zapisu przy starcie. W takim przypadku w tym samym pliku override należy dopisać ReadWritePaths=/srv/ollama-models.

W izolowanych środowiskach Docker ustawienie odpowiedniej zmiennej polega na zamontowaniu zasobów pamięci trwałej (volume) w kontenerze w domyślnym katalogu /root/.ollama.

Parametryzacja i koszty infrastruktury VPS

Hosting modeli średniej wielkości (kilka–kilkanaście miliardów parametrów) na budżetowych serwerach VPS wymaga priorytetyzacji wysokiej przepustowości podsystemu pamięci oraz surowej wydajności jednowątkowej procesora. Optymalizacja kosztowa infrastruktury sprzętowej bazuje na doborze instancji wirtualnych z dedykowanymi zasobami vCPU, co eliminuje opóźnienia i redukuje miesięczny koszt utrzymania LLM.

Do lokalnego przetwarzania logiki i walidacji RODO sprzęt stacjonarny pracownika obsługującego procesy w modelu bazowym musi dysponować 16 GB RAM oraz 4-rdzeniowym procesorem — przy założeniu kwantyzacji Q4_K_M (~6,7 GB wag), która zostawia zapas na system operacyjny i pozostałe usługi. Uruchamianie wariantu Q8_0 (~12 GB) na maszynie z 16 GB RAM współdzielonej z Dockerem, bazą danych czy n8n kończy się reakcją OOM killera. Podczas testowania instrukcji dla wielu jednoczesnych zdarzeń (transkrypcja i generacja LLM na CPU), obciążenie potrafi wynosić bez przerwy od 90 do 100% użycia procesora. Należy unikać standardowych, budżetowych współdzielonych serwerów VPS na korzyść maszyn z gwarantowanym rdzeniem obliczeniowym.

Transkrypcja i inferencja języka oparta na procesorze jest silnie jednowątkowa, co czyni czystą moc i stabilność per pojedynczy rdzeń cenniejszą niż sumaryczną wielowątkowość. Kryterium to najlepiej spełnia Netcup z linii Root Server — RS 2000 G12 (8 dedykowanych rdzeni EPYC, 16 GB RAM, 512 GB NVMe) mieści się w cenie poniżej 30 EUR miesięcznie z wyraźnym zapasem. U Hetznera trzeba uważać na nazewnictwo: linia CX (CX22/32/42/52) oraz ARM-owa CAX (np. CAX41 — 16 vCPU, 32 GB, ~31 EUR) to instancje ze współdzielonym vCPU, więc formalnie przeczą powyższej rekomendacji, choć w praktyce bywają używane jako tańszy kompromis. Dedykowane rdzenie oferuje dopiero linia CCX, ale jej wyższe warianty wychodzą poza budżet tego wdrożenia (CCX53 to 32 vCPU i 128 GB RAM za ok. 192 EUR miesięcznie). Osobną, darmową opcją testową pozostaje ARM-owy free tier Oracle Cloud, który udostępnia do 24 GB pamięci RAM i 4 rdzenie Ampere — wystarczająco, by uruchomić skwantyzowanego Bielika, choć bez gwarancji dostępności zasobów.

Wnioski praktyczne i rekomendacje

• Zmierz obecne zużycie zasobów dyskowych przed pracami administracyjnymi, wykonując polecenie du -sh /usr/share/ollama/.ollama/models.
• Skonfiguruj osobną partycję pod montowanie dużych zestawów plików LLM i przekaż jej uprawnienia komendą sudo chown -R ollama:ollama — jeszcze przed startem usługi, nie po nim.
• Zdefiniuj systemową zmienną OLLAMA_MODELS w ustawieniach systemd lub środowisku zmiennych Windows, zamiast ryzykować niestabilnością systemowych powiązań symbolicznych (symlink).
• Zweryfikuj wdrożenie przez systemctl show ollama.service | grep OLLAMA_MODELS oraz ollama list, zanim usuniesz stary katalog modeli.
• Dobierz kwantyzację do dostępnej pamięci: Q4_K_M dla maszyn z 16 GB RAM, Q5_K_M przy 24 GB, Q8_0 dopiero gdy pamięć nie jest ograniczeniem.
• Wdróż środowisko chmurowe w oparciu o instancje VPS oferujące dedykowane (nie współdzielone) rdzenie vCPU dla zagwarantowania stałej przewidywalnej przepustowości jednowątkowej procesora.

---

Źródła

1. Paweł Rosół, AI w pracy Inspektora Ochrony Danych – Jak wykorzystać sztuczną inteligencję bez naruszenia RODO? — https://pawel.rosol.pl/posts/ai-w-pracy-iod/
2. Bielik-how-to-start/Bielik_2_Ollama_integration.ipynb, GitHub (SpeakLeash) — https://github.com/speakleash/Bielik-how-to-start/blob/main/Bielik_2_Ollama_integration.ipynb
3. Bielik-11B-v2.3-Instruct-GGUF (karta modelu, tabela kwantyzacji), Hugging Face (SpeakLeash) — https://huggingface.co/speakleash/Bielik-11B-v2.3-Instruct-GGUF
4. Does anyone know how to change where your models are saved on linux?, r/ollama — https://www.reddit.com/r/ollama/comments/1c4zg15/does_anyone_know_how_to_change_where_your_models/
5. Keep Ollama From Eating Your Linux Disk: Move Model Storage and Prune Safely, DEV Community — https://dev.to/lyraalishaikh/keep-ollama-from-eating-your-linux-disk-move-model-storage-and-prune-safely-498f
6. Ollama Model Storage Path Guide: Windows, macOS, Linux, and Moving Models — https://knightli.com/en/2026/04/06/ollama-model-storage-path-and-migration/
7. Set Ollama model directory in docker compose, GitHub Issue #832 (open-webui) — https://github.com/open-webui/open-webui/issues/832
8. Sugestie dotyczące VPS do hostowania LLM, r/VPS — https://www.reddit.com/r/VPS/comments/1q6eif4/vps_suggestions_for_llm_hosting/
9. Ollama, dokumentacja oficjalna — Windows — https://docs.ollama.com/windows
10. Netcup, cennik Root Server (RS 2000 G12) — https://www.netcup.com/en/server/root-server
11. Hetzner Cloud, cennik i specyfikacja linii CX / CAX / CCX — https://www.hetzner.com/cloud/

Uwaga metodologiczna: ceny VPS oraz koszty API zmieniają się i były aktualne w momencie publikacji — przed decyzją zakupową zweryfikuj je w cenniku dostawcy.