Bielik on-premise: od czego zacząć
Alan Balcerowiak ·
Lokalny model językowy przestał być eksperymentem dla entuzjastów. Polski Bielik ma otwartą licencję, gotowe wersje skwantyzowane i da się go postawić na własnym serwerze w jeden dzień. Trudniejsze jest wszystko, co dzieje się wokół modelu. Poniżej opisuję, od czego zaczynam i na czym najczęściej tracę czas.
Dlaczego lokalnie
Powód jest jeden i nie jest techniczny: dane firmy nie powinny opuszczać jej infrastruktury. Umowy, korespondencja z klientami, dokumentacja wewnętrzna, konfiguracje systemów – to wszystko trafia do kontekstu modelu, gdy budujemy asystenta na dokumentach. Przy usłudze w chmurze trzeba zaufać dostawcy, jego podwykonawcom i ich zasadom przechowywania danych. Przy modelu on-premise pytanie „gdzie są nasze dane” ma prostą odpowiedź: w serwerowni, w tym samym miejscu co wczoraj.
Ma to też znaczenie przy regulacjach, które obejmują firmę – RODO, NIS2, w sektorze finansowym wymagania nadzoru. Lokalne wdrożenie nie załatwia zgodności samo z siebie, ale usuwa z analizy całą kategorię pytań o transfer danych do zewnętrznego przetwarzającego.
Drugim argumentem jest język. Bielik-11B-v2.3-Instruct to model o 11 mld parametrów, rozwijany przez SpeakLeash razem z ACK Cyfronet AGH, udostępniony na licencji Apache 2.0. Polszczyzna jest dla niego językiem pierwszym, a nie jednym z wielu.
Cztery klocki
Minimalny stos, od którego zaczynam, ma cztery elementy. Każdy z nich jest otwartoźródłowy i każdy da się wymienić bez przepisywania reszty.
Serwowanie modelu: vLLM
vLLM uruchamia model jako serwer z API zgodnym z formatem OpenAI. To praktyczna zaleta: biblioteki klienckie, narzędzia do testów i kod aplikacji nie muszą wiedzieć, że pod spodem działa lokalny Bielik. Karta modelu na Hugging Face zawiera gotowe polecenia uruchomienia przez vLLM, a autorzy publikują też wersje skwantyzowane (m.in. GPTQ i FP8), które zmniejszają wymagania pamięciowe.
Embeddingi: BGE-M3
Model embeddingów zamienia pytania i fragmenty dokumentów na wektory. Używam BGE-M3: obsługuje ponad 100 języków, przyjmuje wejście do 8192 tokenów i oferuje trzy tryby wyszukiwania – gęsty, rzadki i wielowektorowy. Licencja MIT. Ważne: embeddingi liczą się lokalnie tak samo jak odpowiedzi modelu. Jeśli wektory liczy zewnętrzne API, to tekst dokumentów i tak wychodzi poza firmę.
Baza wektorowa: ChromaDB
ChromaDB wystarcza na start: prosta instalacja, metadane przy dokumentach, filtrowanie. Przy większych wolumenach albo wymaganiach wysokiej dostępności można przejść na inną bazę – dlatego dostęp do niej zamykam w jednej warstwie aplikacji, a nie rozsiewam po kodzie.
Aplikacja: FastAPI
Na wierzchu stoi usługa w FastAPI, która składa całość: przyjmuje pytanie, wyszukuje fragmenty, decyduje, czy odpowiadać, wywołuje model i zwraca odpowiedź z cytatami. To tu żyje logika, o której piszę w notatce o RAG, który odmawia – filtr trafności i warstwa decyzyjna. Całość pakuję w kontenery Dockera, żeby środowisko testowe i produkcyjne różniły się tylko sprzętem.
GPU: jak myśleć o rozmiarze
Nie podam jednej liczby, bo jej nie ma. Pamięć karty zjadają trzy rzeczy i każdą trzeba policzyć osobno:
- wagi modelu – zależą od liczby parametrów i precyzji. Ten sam model w pełnej precyzji i po kwantyzacji 4-bitowej to zupełnie różne wymagania. Kwantyzacja zawsze kosztuje coś w jakości, więc sprawdzam ją na własnym zestawie pytań, a nie na ogólnych benchmarkach;
- pamięć na kontekst (KV cache) – rośnie z długością kontekstu i liczbą równoczesnych zapytań. RAG wkłada do promptu kilka fragmentów dokumentów, więc konteksty są dłuższe niż w zwykłym czacie;
- pozostałe modele – embeddingi, ewentualny reranker, rozpoznawanie mowy. Można je trzymać na tej samej karcie albo osobno, ale trzeba je uwzględnić.
Praktyczna kolejność: najpierw ustalam, ilu użytkowników będzie pytać jednocześnie i jak długie są typowe dokumenty, potem wybieram wariant modelu, a dopiero na końcu sprzęt. Odwrotna kolejność – „mamy taką kartę, co na niej zmieścimy” – kończy się zwykle albo zbyt agresywną kwantyzacją, albo kolejką zapytań w godzinach szczytu.
Gdzie traci się najwięcej czasu
Postawienie modelu to zwykle najkrótszy etap. Czas pochłaniają inne rzeczy.
Przygotowanie dokumentów. Skany bez warstwy tekstowej, tabele rozjechane przy konwersji PDF, nagłówki i stopki powtarzane na każdej stronie, kilka wersji tego samego regulaminu. Jakość odpowiedzi rzadko przekracza jakość danych wejściowych. Na tym etapie spędzam więcej czasu niż na doborze modelu.
Cięcie na fragmenty. Za krótkie fragmenty gubią kontekst, za długie rozmywają wyszukiwanie. Dobrze jest ciąć wzdłuż struktury dokumentu – rozdziałów, paragrafów, punktów – zamiast co określoną liczbę znaków, i zostawić w metadanych tytuł dokumentu oraz numer sekcji, żeby dało się cytować źródło.
Uprawnienia. Jeśli użytkownik nie ma dostępu do dokumentu w systemie źródłowym, nie może dostać odpowiedzi z tego dokumentu przez asystenta. Filtr uprawnień musi działać na etapie wyszukiwania, a nie dopiero przy wyświetlaniu.
Brak zestawu testowego. Bez kilkudziesięciu pytań z oczekiwanymi odpowiedziami każda zmiana – nowy model, inne cięcie, nowa wersja vLLM – jest zgadywaniem. Zestaw buduję w pierwszym tygodniu, nie w ostatnim.
„Lokalnie” tylko z nazwy. Telemetria bibliotek, pobieranie modeli przy starcie kontenera, zewnętrzne czcionki w interfejsie. Przed wdrożeniem warto uruchomić całość z odciętym ruchem wychodzącym i sprawdzić, co przestało działać. To najtańszy test tego, czy dane naprawdę zostają w środku.
Monitoring od pierwszego dnia
Lokalny model nie ma panelu dostawcy, który pokaże zużycie i błędy. Trzeba to zbudować samemu, i warto od razu. Mierzę czas do pierwszego tokenu i całkowity czas odpowiedzi, długość kolejki w vLLM, zajętość pamięci karty, liczbę odmów i liczbę odpowiedzi bez cytatu. Ta ostatnia jest dla mnie sygnałem ostrzegawczym: odpowiedź bez źródła w systemie RAG oznacza zwykle, że coś poszło inaczej, niż zaplanowano. Logi pytań przechowuję na tych samych zasadach co dokumenty, z których korzysta asystent – bo pytania użytkowników same bywają poufne.
Od czego zacząć w praktyce
- Wybierz jeden zbiór dokumentów i jedną grupę użytkowników. Nie całą firmę.
- Zbierz od nich 30–50 prawdziwych pytań, w tym takie, na które w dokumentach nie ma odpowiedzi.
- Postaw model w vLLM, embeddingi i bazę wektorową na jednej maszynie, bez optymalizacji.
- Zmierz, jak system odpowiada i jak odmawia. Dopiero wtedy decyduj o sprzęcie docelowym, kwantyzacji i skalowaniu.
Model to jeden z czterech klocków i zwykle nie ten, który sprawia problemy. Gdy asystent ma też sięgać do systemów firmy, a nie tylko do dokumentów, przeczytaj, jak ograniczam go do odczytu konstrukcyjnie.