Basal to modele, które czytają tekst i odpowiadają na pytania o niego, na przykład do którego działu skierować zgłoszenie. Tworzy je Remek Kinas. My, zespół IT SOL, rozwijamy basal-rs: otwarty silnik w Rust, czyli program, który uruchamia te modele na kartach NVIDIA i na Macach z Apple Silicon. Daje te same decyzje co obliczenia referencyjne autora modeli. Jest darmowy, na licencji Apache 2.0.
brew install itsoltech/tap/basal-rs Zgłoszenie: klient prosi o zwrot pieniędzy za uszkodzony telefon.
dept choice Do którego działu skierować zgłoszenie?urgent noul Czy sprawa jest pilna?Komentarz pod artykułem: „Autor nie ma pojęcia, o czym pisze. Typowy dyletant.”
tone score Jak ostry jest ton komentarza?remove noul Czy komentarz narusza regulamin?E-mail: „W załączniku przesyłam fakturę nr 14/10/2026 za serwis klimatyzacji. Termin płatności: 14 dni.”
doc choice Jaki to dokument?approve noul Czy wymaga akceptacji płatności?Ilustracja formatu odpowiedzi API. Wartości są przykładowe.
Wybierz system, uruchom serwer i wyślij pierwsze pytanie. Na Macu i na Linuksie wystarczą dwa albo trzy polecenia.
brew install itsoltech/tap/basal-rsbasal doctor # pokazuje, co jest na komputerze i czego brakujebasal serve # http://127.0.0.1:8000Wymaga Maca z Apple Silicon (sprawdzone na M1 Pro i M2 Max). Przy pierwszym starcie serwer pobiera model basal-1.5-4.5B. Aktualizacja: brew upgrade basal-rs.
curl --fail-with-body localhost:8000/v1/systemone \
-H 'content-type: application/json' -d '{
"model": "basal-1.5-4.5B",
"state": "Zgłoszenie: klient prosi o zwrot pieniędzy za uszkodzony telefon.",
"questions": {
"dept": {"type": "choice", "instructions": "Do którego działu skierować zgłoszenie?",
"criteria": {"returns": "Zwroty", "tech": "Wsparcie techniczne", "sales": "Sprzedaż"}},
"urgent": {"type": "noul", "instructions": "Czy sprawa jest pilna?"}
}
}'{
"model": "basal-1.5-4.5B",
"answers": {
"dept": {
"type": "choice",
"choice": "returns",
"probabilities": {"returns": 0.94, "tech": 0.05, "sales": 0.01},
"confidence": 0.91
},
"urgent": {"type": "noul", "noul": 0.31}
}
}basal client to program wiersza poleceń. Czyta dane ze standardowego wejścia (stdin) albo z pliku i zwraca decyzje modelu Basal. Wynik można zapisać w zmiennej Bash, przekazać do jq albo do kolejnego pliku JSONL. Z opcją --local model działa w samym kliencie: dane nie opuszczają komputera i nie trzeba uruchamiać serwera.
cat zgloszenie.txt | basal client --local \
--ask 'Czy zgłoszenie opisuje awarię blokującą pracę?' --value0.9937360260087164Treść zgloszenie.txt: „Po aktualizacji system nie uruchamia się i cały zespół nie może pracować.” Samo --ask zadaje pytanie tak/nie. --value wypisuje tylko prawdopodobieństwo odpowiedzi „tak”, które można od razu zapisać w zmiennej Bash albo użyć w warunku.
department=$(basal client --local --state reklamacja.txt \
--ask 'Do którego działu skierować zgłoszenie?' \
--choice 'returns=Zwroty i reklamacje' \
--choice 'support=Pomoc techniczna' \
--choice 'sales=Pytania przed zakupem' \
--choice 'other=Inna sprawa lub brak informacji' --value)
echo "$department"returnsTreść reklamacja.txt: „Telefon przyszedł uszkodzony. Chcę zwrotu pieniędzy.” W każdym --choice klucz przed znakiem = jest wynikiem dla skryptu, a opis po nim objaśnia opcję modelowi. Pytanie typu choice zawsze kończy się jedną z podanych opcji.
basal client --local --template routing.json \
--state tickets.jsonl --input jsonl --state-pointer /text |
jq -c '{id: .input.id, department: .response.answers.department.choice,
urgent: (.response.answers.urgent.noul * 100 | round / 100)}'{"id":101,"department":"returns","urgent":0.03}
{"id":102,"department":"support","urgent":0.02}
{"id":103,"department":"other","urgent":0.06}
{"id":104,"department":"other","urgent":0.98}W pliku JSONL każda linia to osobny rekord JSON. Szablon routing.json zadaje o każdy rekord dwa pytania: o dział i o pilność. Pole .input zawiera cały rekord, więc ID nie ginie. Zgłoszenia 103 (pytanie o monitor przed zakupem) i 104 trafiły do other, bo szablon każe wybrać other, gdy brakuje informacji. Pełna odpowiedź podaje prawdopodobieństwo każdej opcji, więc takie przypadki wyłapie próg albo dokładniejszy opis kryteriów.
cat app.log | basal client --local --input lines \
--ask 'Czy wpis wskazuje utratę danych lub niedostępność usługi?' |
jq -c '{p: (.response.answers.result.noul * 100 | round / 100), line: .input}'{"p":0.01,"line":"10:02:11 INFO api: GET /v1/orders 200 in 41 ms"}
{"p":0.03,"line":"10:02:13 WARN cache: hit ratio dropped to 71%"}
{"p":0.87,"line":"10:02:19 ERROR db: primary unreachable, failing over to replica"}
{"p":0.86,"line":"10:02:24 ERROR storage: disk full, 312 uploads not saved"}
{"p":0.01,"line":"10:02:31 WARN auth: 3 failed logins for one user"}
{"p":0.01,"line":"10:02:40 INFO worker: job 8812 finished in 2.4 s"}
{"p":0.92,"line":"10:02:44 ERROR api: 503 for all /v1/payments requests"}--input lines ocenia osobno każdą niepustą linię. Model ładuje się raz na cały strumień danych. Do alertów wystarczy dodać w jq select(.p >= próg). Próg ustala się według własnych zasad i sam nie gwarantuje trafności. Przy ciągłym strumieniu logów zamiast cat można użyć tail -F.
basal client --local --template all-types.json \
--state reklamacja.json --input json |
jq -c 'def r: . * 100 | round / 100; .answers | {department: .department.choice,
urgent: (.urgent.noul | r), severity: (.severity.score | r),
tags: .tags.selected, action: .refund_action.action}'{"department":"returns","urgent":0.02,"severity":2.11,"tags":["damage","refund","delivery"],"action":"approve"}Jeden szablon zadaje pięć pytań o ten sam stan: choice (wybór jednej opcji), noul (tak/nie), score (średnia ważona poziomów od 0 do 3), multi (kilka opcji naraz) i act (wybór działania). Stan to obiekt z warunkami zwrotu i treścią reklamacji. act wybiera działanie o najmniejszym oczekiwanym koszcie według kosztów podanych w szablonie. Klient zwraca decyzję, ale jej nie wykonuje.
Wyniki pochodzą z uruchomienia na Macu z Apple Silicon (M1 Pro), z opcją --local i modelem basal-1.5-4.5B. Pliki wejściowe są w repozytorium basal-rs, w katalogu examples/client.
Używamy modeli Basal we własnych projektach. Potrzebowaliśmy silnika, który na zwykłej stacji roboczej odpowiada w kilkadziesiąt milisekund i daje te same decyzje co obliczenia referencyjne autora modeli. Napisaliśmy go w Rust.
Ten sam silnik udostępniamy za darmo, razem z kodem i wynikami pomiarów. Chcemy, żeby każdy, kto ma Maca z Apple Silicon albo kartę NVIDIA, mógł jak najlepiej wykorzystać swój sprzęt. Tak wspieramy rozwój polskiego AI i ułatwiamy korzystanie z polskich modeli.
Licencja Apache 2.0 pozwala używać silnika także w celach komercyjnych, zmieniać go i wbudowywać we własne produkty.
Kod, raporty z pomiarów i dane pomiarowe są w publicznym repozytorium na GitHubie.
Serwer działa na twoim komputerze i domyślnie przyjmuje połączenia tylko z niego (adres 127.0.0.1). Z internetu pobiera wagi modeli z Hugging Face.
Remka Kinasa jako autora modeli podajemy w README, w pliku NOTICE i na tej stronie.
Silnik zmienia sposób wykonania obliczeń. Sam model zostaje bez zmian. Każdą obietnicę poniżej sprawdzamy pomiarem, a raporty z danymi są w publicznym repozytorium.
Jeden plik programu, bez Pythona i środowisk wirtualnych. basal doctor sprawdza
komputer i podpowiada, czego brakuje i jak to naprawić. Na Linuksie cała instalacja z
bibliotekami CUDA zajmuje 1,07 GB. Środowisko Pythona dla basal-serve, referencyjny serwer autora modeli napisany w Pythonie (PyTorch, na Macach MLX). zajmuje od 7,08 GB.
$ brew install itsoltech/tap/basal-rs $ basal servePorównanie rozmiaru
900/900
Autor oceniał modele w obliczeniach Liczby zapisane w 32 bitach, czyli pełna precyzja obliczeń.. basal-rs domyślnie liczy w Liczby zapisane w 16 bitach, o połowę mniej niż w FP32. i sumuje w f32. Na 900 pytaniach z dziewięciu zbiorów daje te same decyzje co obliczenia FP32 (basal-1.5-max, A100).
Raport zgodności0
To samo żądanie daje co do bitu tę samą odpowiedź, gdy przychodzi samo, w partii z innymi i przy 32 klientach naraz. Wynik decyzji nie zależy od tego, co serwer liczy w tej samej chwili.
Jak to działa1,5–2,8×
Porównanie z serwerem upstream w trybie fast: ta sama karta i ta sama klasa precyzji, czyli 16 bitów (f16 i BF16). Na jedną decyzję basal-rs zużywa przy tym 1,3–2,8 raza mniej energii.
BenchmarkiDziała na Macach z Apple Silicon i na kartach NVIDIA: A100, RTX 30xx i nowszych. Model ma trzy rozmiary. Pytania mogą być po polsku i po angielsku.
Serwer obsługuje API TypeSafe System One i konwencje serwera upstream. Aplikacje napisane pod jedno z nich działają bez zmian. Jeden proces serwera może obsługiwać kilka modeli.
POST /v1/systemonekontrakt TypeSafe System OnePOST /v1/basalkonwencje serwera upstreamGET /v1/modelslista dostępnych modeliGET /metricsmetryki dla Prometheusa, opcjonalnieSzybkość basal-rs porównujemy z basal-serve v1.5.0, referencyjny serwer autora modeli napisany w Pythonie (PyTorch, na Macach MLX). Na kartach NVIDIA w trybie fast: BF16, torch.compile i CUDA graphs. w jego trybie fast. Oba silniki działają na tej samej karcie i liczą w 16 bitach. Decyzje obu porównujemy z jednym punktem odniesienia: obliczeniami w pełnej precyzji FP32, w których autor oceniał modele. Wyniki opisują silnik. Nie są oceną trafności modeli.
wagi i wyniki pośrednie w f16, sumy w mnożeniu macierzy w f32
PyTorch z torch.compile i CUDA graphs, na Macach MLX w bf16
Pełna precyzja, w której autor oceniał modele. Służy do porównania decyzji. Szybkości z nią nie porównujemy. Kto potrzebuje dokładnie FP32, ustawia w basal-rs dtype: f32 i dostaje 900 / 900.
Wybrane pomiary basal-rs i serwera upstream na tych samych kartach graficznych i komputerach Mac. Wszystkie modele, karty i pomiary są na stronie z benchmarkami.
| Pomiar | upstream v1.5.0, BF16 (fast) | basal-rs, f16 | Jednostka |
|---|---|---|---|
| Pojedyncza decyzja, mediana | 90,7 | 63,4–64,0 | ms (mniej = lepiej) |
| Jedno pytanie przez HTTP, mediana (p50) | 118 | 72 | ms (mniej = lepiej) |
| 32 klientów naraz | 6,8 | 21,8 | żądań/s (więcej = lepiej) |
| Ruch mieszany, 32 klientów | 17 | 119 | żądań/min (więcej = lepiej) |
| Dokument 16 tys. tokenów, 5 pytań | 112,2 | 5,3 | s (mniej = lepiej) |
Upstream działał na tej samej karcie w swoim najszybszym trybie (fast). Limit mocy karty: 250 W, a przy dokumencie 16 tys. tokenów 300 W. Token to fragment tekstu: model czyta dane wejściowe jako ciąg tokenów.
basal-rs przyjmuje żądanie HTTP, buduje prompty według protokołu Basala, liczy je na karcie graficznej albo na Macu i zwraca rozkład prawdopodobieństwa dla opcji. Kolor numeru pokazuje, czyj kod za nim stoi.
Tak. Silnik jest na licencji Apache 2.0, która pozwala też na zastosowania komercyjne. Autor modeli Basal również wydał je na licencji Apache 2.0. Nie trzeba zakładać konta ani mieć klucza API. Nie ma limitów.
Modele Basal i ich autor, Remek Kinas. basal-rs odtwarza jego protokół decyzji: ten sam prompt, te same tokeny (token IDs), obie kolejności opcji i tę samą kalibrację. Nasze pomiary opisują szybkość silnika i zgodność z obliczeniami referencyjnymi upstream. Nie są oceną trafności samych modeli.
f16 to zapis liczb w 16 bitach, a FP32 w 32 bitach, czyli w pełnej precyzji. Punktem odniesienia są obliczenia FP32, w których autor oceniał modele. basal-rs domyślnie liczy w f16, z sumowaniem w f32, i daje te same decyzje co FP32 w 899–900 z 900 pytań. Jedyne różnice dotyczą pytań, w których FP32 daje niemal remis, np. 0,503 wobec 0,497. Serwer upstream w trybie fast liczy w BF16, innym formacie 16-bitowym, i ma 890–896 z 900. Szybkość porównujemy właśnie z tym trybem, czyli 16 bitów z 16 bitami. Kto potrzebuje dokładnie FP32, ustawia dtype: f32.
Maca z Apple Silicon albo komputera z Linuksem x86_64 i kartą NVIDIA z compute capability 8.0 lub wyższym (A100, RTX 30xx i nowsze). Potrzebna pamięć karty graficznej (GPU) to wagi modeli plus aktywacje, czyli wyniki pośrednie obliczeń: basal-1.5-mini ~3,2 GB, 4.5B ~9,5 GB, max ~23 GB.
Tak. POST /v1/systemone działa według kontraktu TypeSafe System One, łącznie z jego statusami błędów. POST /v1/basal działa według konwencji serwera upstream v1.5.0. Aplikacja nie musi wiedzieć, że po drugiej stronie działa basal-rs.
Protokół decyzji jest ten sam. Różni się sposób wykonania obliczeń. basal-rs układa prompty w drzewo wspólnych początków (prefiksów), więc wspólny stan liczy tylko raz. Ma własny kod GPU dla CUDA i Metal oraz harmonogram, który przepuszcza krótkie żądania przed długimi. Do działania nie potrzebuje Pythona.
Serwer nie sprawdza, kto wysyła żądania, bo nie ma uwierzytelniania. Domyślnie przyjmuje połączenia tylko z tego samego komputera (127.0.0.1). Adres 0.0.0.0 przyjmuje połączenia z sieci i jest używany także w obrazie Docker. Jest przeznaczony dla zaufanej sieci albo do pracy za proxy, które uwierzytelnia żądania.
Wersja 1.0.0 ma dopracować pojedynczy serwer: obsługiwane systemy, karty, wydajność i integracje. Później silnik ma obsługiwać wiele kart i maszyn naraz. Wydania i listy zmian publikujemy na GitHubie. Do pracy nad każdym z punktów zapraszamy przez zgłoszenia i pull requesty.
basal-rs uruchamia modele, ale ich nie tworzy. Decyzje podejmują modele Basal, a za ich jakość odpowiada autor modeli, Remek Kinas. Silnik basal-rs odpowiada za szybkość i sposób wykonania obliczeń.
Wysyła przez HTTP stan, czyli tekst lub dane do oceny, i pytania o niego. Dostaje decyzje z prawdopodobieństwami.
Silnik i serwer w Rust, które uruchamiają modele. Odpowiadamy za to, jak szybko i jak przewidywalnie liczą się decyzje.
Modele decyzyjne. To one podejmują decyzje i od nich zależy jakość odpowiedzi.
Polskie modele bazowe (1.5B, 4.5B, 11B Instruct). Modele Basal powstały przez ich dostrojenie.
basal-rs jest otwartym projektem i zapraszamy do jego rozwoju. Czekamy na uwagi, pomysły, zgłoszenia problemów i pull requesty, po polsku albo po angielsku.
Różnice wobec upstream, problemy z wydajnością, obsługa nowych kart. Zgłoszenia przez formularz na GitHubie, także po polsku.
Otwórz zgłoszeniePoprawki kodu i dokumentacji, nowe karty, wydajność. Przy większej zmianie najpierw zgłoszenie, żeby uzgodnić podejście i sposób pomiaru.
Jak pomóc w rozwojuJak dobrać model, kartę albo konfigurację serwera.
GitHub DiscussionsProsimy nie zgłaszać ich publicznie. Zgłoszenie prywatne: przez GitHub Security Advisories albo na dev@itsol.tech.
Zgłoś prywatnie