Ollama Modelfile: własny asystent linijka po linijce

Czym jest Modelfile w Ollama

Modelfile w Ollama to zwykły plik tekstowy, który opisuje własny model: na jakim modelu bazowym stoi, jaki ma prompt systemowy, jakie przykłady rozmowy zna i z jakimi parametrami działa. Budujesz go jednym poleceniem ollama create, a potem uruchamiasz pod własną nazwą, jak każdy inny model. Dokumentacja Ollama nazywa go „planem” (ang. blueprint) do tworzenia i udostępniania własnych modeli.

Jeśli znasz Dockera, myśl o nim jak o Dockerfile. To nasze porównanie, nie oficjalne, ale dobrze oddaje sens: model bazowy w FROM, nad nim kilka warstw ustawień, a wynik ma własną nazwę i da się go odtworzyć z pliku. Dzięki temu przestajesz przy każdej rozmowie wklejać ten sam polski prompt systemowy i ręcznie ustawiać temperaturę. Wszystko siedzi w jednym pliku, który trzymasz w git.

Ten poradnik zakłada, że Ollama już działa na Twoim VPS. Jeśli nie, zacznij od instalacji Ollama na VPS i uruchomienia własnego LLM. Przykłady opieramy na Bieliku, polskim modelu od SpeakLeash, bo to on najczęściej odpowiada po polsku na naszych serwerach.

Na jakiej wersji Ollama to sprawdzano

Listę instrukcji bierzemy z dokumentacji na docs.ollama.com/modelfile, czytanej 23 października 2026 r. Tego dnia najnowszym stabilnym wydaniem na stronie wydań Ollama na GitHubie było v0.40.9. Kopia dokumentacji w tagu v0.40.9 wymienia te same instrukcje co strona główna.

Nie musisz przypinać tej wersji na stałe. Aktualizuj Ollama tak jak dotąd. Gdy coś w tym poradniku nie zgadza się z Twoim serwerem, najpierw sprawdź, na czym stoisz:

ollama --version

Zacznij od ollama show --modelfile

Każdy model w Ollama ma już swój Modelfile. Najlepiej przeczytać go, zanim napiszesz własny. Pobierz Bielika i wyświetl jego plik:

ollama pull SpeakLeash/bielik-11b-v3.0-instruct:Q4_K_M
ollama show --modelfile SpeakLeash/bielik-11b-v3.0-instruct:Q4_K_M

Zwróć uwagę na nazwę. W bibliotece Ollama nie ma modelu o samej nazwie bielik, a strona ollama.com/library/bielik zwraca błąd 404. Modele SpeakLeash mają przestrzeń nazw SpeakLeash/, na przykład SpeakLeash/bielik-11b-v3.0-instruct albo mniejszy SpeakLeash/bielik-4.5b-v3.0-instruct. Wiele innych wyników wyszukiwania to modele wgrane przez społeczność, a nie oficjalne modele SpeakLeash.

Strona modelu SpeakLeash/bielik-11b-v3.0-instruct pokazuje pięć tagów: Q4_K_M (6,7 GB), Q5_K_M (7,9 GB), Q6_K (9,2 GB), Q8_0 (12 GB) i bf16 (22 GB). Który wybrać na Twój VPS, wyjaśnia porównanie kwantyzacji Q4, Q8 i FP16.

Modelfile pokazany na tej stronie ma kilka cech, które warto znać. Nie ma w nim instrukcji SYSTEM. Jest za to TEMPLATE, który warunkowo odwołuje się do .System, czyli ma miejsce na prompt systemowy. Są też trzy linie PARAMETER stop i linia PARAMETER temperature 0.1. Zapisz do pliku to, co widzisz u siebie. Przyda się później do porównania:

ollama show --modelfile SpeakLeash/bielik-11b-v3.0-instruct:Q4_K_M > bielik-baza.txt

Osiem instrukcji Modelfile w obecnej dokumentacji

Każda linia ma postać INSTRUKCJA argumenty. Znak # zaczyna komentarz. Dokumentacja mówi wprost, że Modelfile nie rozróżnia wielkości liter, a instrukcje mogą stać w dowolnej kolejności. Wielkie litery to tylko konwencja, która ułatwia czytanie.

Obecna dokumentacja wymienia osiem instrukcji:

• FROM (wymagana): model bazowy.
• PARAMETER: parametry, z którymi Ollama uruchamia model.
• TEMPLATE: pełny szablon promptu wysyłany do modelu, w składni szablonów języka Go.
• SYSTEM: wiadomość systemowa, którą szablon wstawia do promptu.
• LICENSE: licencja, na której udostępniasz model.
• MESSAGE: historia wiadomości, czyli przykładowa rozmowa.
• REQUIRES: minimalna wersja Ollama, której model potrzebuje.
• CAPABILITY: dodatkowa zdolność modelu.

Starsza dokumentacja, na przykład w tagu v0.13.0, opisywała też ADAPTER do adapterów LoRA (dostrojonych nakładek na model bazowy). Obecna strona i kopia w tagu v0.40.9 już go nie wymieniają. Nie testowaliśmy, czy silnik nadal go przyjmuje, więc w tym poradniku go pomijamy.

Budujemy polskiego asystenta na Bieliku

Cel jest prosty: model polski-asystent, który odpowiada po polsku, krótko i technicznie, jak dyżurny administrator. Oto cały plik:

# polski-asystent: asystent techniczny na bazie Bielika
FROM SpeakLeash/bielik-11b-v3.0-instruct:Q4_K_M

SYSTEM """Jesteś asystentem technicznym zespołu, który utrzymuje serwery VPS z Linuksem. Odpowiadasz zawsze po polsku. Piszesz krótko i konkretnie. Polecenia powłoki podajesz w blokach kodu. Gdy czegoś nie wiesz, mówisz to wprost i nie zgadujesz."""

MESSAGE user Jak sprawdzić, ile miejsca zostało na dysku?
MESSAGE assistant Uruchom df -h. Kolumna Avail pokazuje wolne miejsce na każdym systemie plików.
MESSAGE user Usługa nie wstaje po restarcie. Od czego zacząć?
MESSAGE assistant Sprawdź status poleceniem systemctl status nazwa-uslugi, a potem przeczytaj logi przez journalctl -u nazwa-uslugi -n 50.

PARAMETER temperature 0.3
PARAMETER num_ctx 8192

Poniżej omawiamy każdą część po kolei.

FROM: na czym stoi Twój model

FROM to jedyna wymagana instrukcja. Według dokumentacji może wskazywać istniejący model (nazwa:tag), katalog z wagami w formacie Safetensors albo plik GGUF podany ścieżką. Dla plików GGUF podzielonych na części dokumentacja pokazuje ścieżkę z gwiazdką, na przykład ./model-*.gguf.

Tu budujemy własny model na modelu z biblioteki, więc wystarczy jego pełna nazwa z tagiem. Podawaj tag jawnie. Bez tagu z samego pliku nie wynika, którą kwantyzację zbudował kolega na drugim serwerze. Jeśli zamiast tego masz plik GGUF z Hugging Face, sam import, razem z naprawą szablonu czatu, opisuje osobny poradnik o imporcie modelu GGUF do Ollama. Karta GGUF Bielika 11B v2.3 na Hugging Face też podaje gotowy Modelfile do takiego importu.

SYSTEM: polski prompt systemowy

SYSTEM ustawia wiadomość systemową. Dokumentacja dodaje ważne zastrzeżenie: wiadomość trafia do szablonu „jeśli to ma zastosowanie”. W praktyce znaczy to tyle, że TEMPLATE musi mieć miejsce na .System. Przykładowy szablon w dokumentacji zaczyna się od {{ if .System }}, czyli wstawia prompt systemowy tylko wtedy, gdy jakiś istnieje.

Prompt piszemy po polsku, bo model ma odpowiadać po polsku. Potrójny cudzysłów """ pozwala zmieścić dłuższy tekst. Pisz konkretne zasady, które da się sprawdzić w odpowiedzi: „odpowiadasz po polsku”, „polecenia w blokach kodu”. Ogólniki w stylu „bądź pomocny” niczego nie zmieniają w zachowaniu i trudno je przetestować.

MESSAGE: przykładowe pary pytanie i odpowiedź

MESSAGE przyjmuje role user, assistant i system. Rola user to przykład pytania użytkownika, a assistant to przykład odpowiedzi modelu. Rola system to według dokumentacji inny sposób podania wiadomości systemowej. Składnia to MESSAGE <rola> <wiadomość>, a pary user i assistant układasz na przemian, tak jak w przykładzie z dokumentacji.

Takie pary pokazują modelowi ton i długość odpowiedzi lepiej niż sam opis. Na początek zwykle wystarczą dwie pary. Celowo nie ma w nich cudzysłowów ani znaków odwrotnego apostrofu. Wiadomość to zwykły tekst do końca linii, więc prosty tekst daje najmniejsze ryzyko, że coś zostanie źle odczytane. Dobieraj przykłady inne niż pytania, które naprawdę padną. Powód wyjaśniamy w części o błędach.

PARAMETER: jedna linia na opcję

Składnia to PARAMETER <nazwa> <wartość>. Każda opcja to osobny temat, więc tu tylko po jednym zdaniu i odsyłacze:

• temperature: losowość odpowiedzi. Dokumentacja podaje domyślnie 0.8, a Modelfile Bielika na stronie modelu ustawia 0.1. Szczegóły w poradniku o temperaturze i próbkowaniu w Ollama.
• num_ctx: rozmiar okna kontekstu. Dokumentacja podaje domyślnie 2048, a strona Bielika 11B v3.0 mówi o oknie 32K. Ile ustawić i ile to kosztuje pamięci, wyjaśnia poradnik o długości kontekstu i num_ctx.
• num_predict: maksymalna liczba generowanych tokenów, domyślnie -1, czyli bez limitu. Więcej w tekście num_predict w Ollama wyjaśnione.
• stop: sekwencja, na której model przerywa generowanie. Tę linię można powtórzyć kilka razy.
• top_k, top_p, min_p, repeat_penalty, seed: dalsze ustawienia próbkowania. Ich domyślne wartości są w tabeli w dokumentacji.

Pamiętaj, że domyślne wartości z dokumentacji to wartości silnika. Model bazowy może mieć w swoim Modelfile inne, tak jak Bielik ma temperature 0.1. Dlatego wpisuj jawnie te opcje, na których Ci zależy, a po zbudowaniu sprawdź, czy są w wyniku ollama show --modelfile.

ollama create i ollama run: zbuduj i sprawdź

Zapisz plik jako Modelfile i zbuduj model. Flaga -f wskazuje ścieżkę do pliku:

ollama create polski-asystent -f ./Modelfile
ollama list
ollama run polski-asystent "Jak sprawdzić, które porty nasłuchują na serwerze?"

ollama list powinno pokazać polski-asystent obok modelu bazowego. Odpowiedź na pytanie testowe powinna być po polsku, krótka i z poleceniem w bloku kodu. Jeśli model odpowiada długo i ogólnie, zasady z SYSTEM mogły do niego nie dotrzeć. Sprawdź to według listy na końcu poradnika.

Modelfile w git obok reszty konfiguracji

Modelfile to konfiguracja, tak samo jak plik nginx czy docker-compose.yml. Trzymaj go w tym samym repozytorium. Plik nie musi nazywać się Modelfile, bo i tak podajesz ścieżkę w -f. Przykład zakłada, że repozytorium z konfiguracją serwera leży w ~/infra:

mkdir -p ~/infra/ollama
mv ./Modelfile ~/infra/ollama/polski-asystent.Modelfile
cd ~/infra
git add ollama/polski-asystent.Modelfile
git commit -m "ollama: Modelfile dla polski-asystent"
ollama create polski-asystent -f ~/infra/ollama/polski-asystent.Modelfile

Zmiana promptu to teraz commit i ponowne ollama create pod tą samą nazwą. Historia git pokaże, kto i kiedy zmienił prompt systemowy. To ważne, gdy model nagle zaczyna odpowiadać inaczej i trzeba znaleźć przyczynę. Gdzie Ollama fizycznie trzyma pobrane modele, opisuje tekst o ollama pull, ollama run i przechowywaniu modeli.

Co model pochodny dziedziczy po bazie? Sprawdź to sam

Dokumentacja Modelfile nie mówi, co dokładnie model pochodny przejmuje od modelu z FROM. Słowo „odziedziczone” pada tylko przy CAPABILITY. Dlatego nie podajemy tu odpowiedzi z pamięci. Są trzy pytania, które warto rozstrzygnąć na własnym serwerze i własnej wersji Ollama:

1. Czy polski-asystent ma TEMPLATE i linie stop z Bielika, chociaż ich nie wpisałeś?
2. Co ollama show --modelfile drukuje dla modelu pochodnego: tylko Twoje linie czy pełny, scalony plik?
3. Czy ponowne ollama pull modelu bazowego zmienia już zbudowany model pochodny?

Pierwsze dwa pytania sprawdzisz jednym porównaniem:

ollama show --modelfile polski-asystent > asystent-przed.txt
diff bielik-baza.txt asystent-przed.txt

Szukaj w obu plikach linii TEMPLATE, PARAMETER stop i SYSTEM. Wynik diff pokaże, które fragmenty są wspólne, a które pochodzą z Twojego pliku. Przykładowy wynik w dokumentacji zawiera też komentarz z podpowiedzią, jak zbudować nowy Modelfile na jego podstawie przez podmianę linii FROM.

Trzecie pytanie sprawdzisz po aktualizacji bazy:

ollama pull SpeakLeash/bielik-11b-v3.0-instruct:Q4_K_M
ollama show --modelfile polski-asystent > asystent-po.txt
diff asystent-przed.txt asystent-po.txt

Pusty wynik ostatniego diff oznacza, że to, co Ollama pokazuje dla modelu pochodnego, się nie zmieniło. Zapisz oba wyniki w repozytorium obok Modelfile. Po kolejnej aktualizacji Ollama powtórzysz test i od razu zobaczysz różnicę.

REQUIRES, CAPABILITY i LICENSE: kiedy ich użyć

REQUIRES ustala minimalną wersję Ollama dla modelu. Dokumentacja podaje przykładową wartość 0.14.0. Ma to sens, gdy udostępniasz model innym i wiesz, że starsza Ollama go nie obsłuży. Nie sprawdzaliśmy, jaki komunikat wypisuje zbyt stara wersja, więc go tu nie cytujemy.

CAPABILITY dodaje zdolność modelowi GGUF lub MLX i nie usuwa zdolności odziedziczonych ani wykrytych. Dokumentacja opisuje ją tylko dla tych formatów. Nie zakładaj, że działa z FROM wskazującym model z biblioteki, dopóki tego nie sprawdzisz.

LICENSE podaje licencję, na której udostępniasz model, w potrójnym cudzysłowie. Strona Bielika 11B v3.0 podaje licencję Apache 2.0 oraz warunki użytkowania na bielik.ai/terms. Jeśli publikujesz własny model na bazie Bielika, przeczytaj je przed publikacją.

Dlaczego własny model nie słucha promptu systemowego?

Przy pierwszym własnym modelu najczęściej wychodzą trzy problemy. Każdy da się sprawdzić w kilka minut.

Prompt systemowy nie trafia do modelu. SYSTEM działa tylko wtedy, gdy szablon go wstawia. Uruchom ollama show --modelfile polski-asystent i znajdź w bloku TEMPLATE odwołanie do .System. Jeśli go tam nie ma, Twój prompt nie ma gdzie trafić. Prosty test: tymczasowo dopisz do SYSTEM zasadę łatwą do zauważenia, na przykład „Każdą odpowiedź zacznij od słowa OK”. Zbuduj model ponownie i zadaj dwa pytania. Jeśli żadna odpowiedź nie zaczyna się od „OK”, problem leży raczej w szablonie niż w treści promptu. Naprawa szablonu to temat poradnika o imporcie GGUF.

Przykłady z MESSAGE wyciekają do odpowiedzi. Dokumentacja nie opisuje takiego zjawiska, ale warto je wykluczyć. Objaw: model powtarza słowo w słowo odpowiedź z przykładu albo odpowiada na pytanie z przykładu zamiast na Twoje. Zadaj pytanie bardzo podobne do jednego z przykładów, a potem zupełnie inne. Jeśli przy podobnym pytaniu dostajesz kopię przykładu, zmniejsz liczbę par i zrób je mniej podobne do prawdziwych pytań.

Model w ogóle się nie ładuje. Najpierw sprawdź nazwę w FROM. Brak prefiksu SpeakLeash/ albo literówka w tagu sprawia, że Ollama nie znajdzie modelu bazowego. Potem sprawdź pamięć. Większy num_ctx w Modelfile podnosi zapotrzebowanie na pamięć, więc model, który działał bez Twojego pliku, może się z nim nie zmieścić. Zmniejsz num_ctx albo wybierz mniejszy tag. Jeśli Ollama działa jako usługa systemd o nazwie ollama, przyczynę zobaczysz w logach:

journalctl -u ollama -n 50

Jeśli model się ładuje, ale długie odpowiedzi przerywa limit czasu, to inny problem. Opisuje go poradnik o błędzie context deadline exceeded w Ollama.

FAQ

Czy instrukcje w Modelfile trzeba pisać wielkimi literami?

Nie. Dokumentacja Ollama mówi, że Modelfile nie rozróżnia wielkości liter, a instrukcje mogą stać w dowolnej kolejności. Wielkie litery w przykładach to tylko konwencja, dzięki której łatwiej odróżnić instrukcję od jej argumentu. Jedyna wymagana instrukcja to FROM.

Jak zobaczyć Modelfile modelu, który już mam w Ollama?

Uruchom ollama show --modelfile nazwa:tag, na przykład ollama show --modelfile SpeakLeash/bielik-11b-v3.0-instruct:Q4_K_M. Zobaczysz szablon, parametry i pozostałe instrukcje modelu. Przekieruj wynik do pliku, jeśli chcesz go porównać z wersją po zmianach albo użyć jako punktu wyjścia dla własnego Modelfile.

Dlaczego ollama pull bielik nie działa?

W bibliotece Ollama nie ma modelu o samej nazwie bielik. Oficjalne modele SpeakLeash mają przestrzeń nazw, na przykład SpeakLeash/bielik-11b-v3.0-instruct lub SpeakLeash/bielik-4.5b-v3.0-instruct. Używaj pełnej nazwy z tagiem, na przykład :Q4_K_M, także w linii FROM swojego Modelfile.

Mój prompt w SYSTEM nie działa. Co sprawdzić?

Dokumentacja mówi, że SYSTEM trafia do szablonu tylko wtedy, gdy ma to zastosowanie. Uruchom ollama show --modelfile dla swojego modelu i sprawdź, czy blok TEMPLATE zawiera .System. Jeśli nie zawiera, prompt nie ma gdzie trafić. Dopisz do promptu łatwą do zauważenia zasadę, zbuduj model ponownie i sprawdź, czy odpowiedzi jej przestrzegają.

Czy Modelfile nadal obsługuje ADAPTER dla LoRA?

Dokumentacja Ollama w wersji v0.13.0 opisywała ADAPTER do adapterów LoRA. Obecna strona dokumentacji i jej kopia w tagu v0.40.9 już tej instrukcji nie wymieniają. Sam brak w dokumentacji nie dowodzi, że silnik jej nie przyjmuje. Jeśli jej potrzebujesz, sprawdź to na swojej wersji Ollama przed wdrożeniem.