basal-omni-1.0-max-GGUF (experimental)
GGUF files (Q8_0 and Q6_K) of basal-omni-1.0-max (12B, base Gemma 4 12B) for llama.cpp and Ollama, on NVIDIA GPUs, Apple Silicon (Metal) or the CPU. Same model and the same typed-decision API through basal-serve. Text only: the image and audio encoders are not in the GGUF files; for images and audio use the bf16 model.
Q8_0 and Q6_K pass every bar of the basal port gate against bf16 (agreement, agreement where bf16 is sure, accuracy, ECE). Q5_K_M and Q4_K_M did not, so they are not shipped.
Measured against bf16
Agreement is the share of decisions where the file picks the same option as the bf16 release model, served as released (--mode eager, bf16), on the development set dev v2 (10,606 decisions), one RTX PRO 6000 96 GB (CUDA), the engine's --mode gguf (llama.cpp b11312 through llama-cpp-python 0.3.36). Bars (the basal port gate for this tier): agreement on 2-10 options >= 0.9552, agreement where bf16's margin >= 0.2 >= 0.9893, accuracy within 1 point, ECE at most +0.01.
| file | size | agreement (2-10 options) | at margin >= 0.2 | accuracy | ECE | decisions/s (16 in flight) | gate |
|---|---|---|---|---|---|---|---|
basal-omni-1.0-max-Q8_0.gguf (recommended) |
12.7 GB | 0.9868 | 0.9983 | -0.07 pt | -0.0006 | 8.9 | PASS |
basal-omni-1.0-max-Q6_K.gguf (smaller) |
9.8 GB | 0.9761 | 0.9947 | -0.11 pt | -0.0046 | 7.5 | PASS |
- For reference, an F16 conversion (23.8 GB, not shipped) agrees in 0.9930 (0.9995 at margin >= 0.2): Gemma 4 is implemented faithfully by llama.cpp, and llama.cpp tokenizes the basal prompts exactly as the Hugging Face tokenizer (2,000 of 2,000).
- Q8_0 on Metal (Apple M4 Pro, 600 decisions, 8,192-token context): agreement 0.9950, 1.0000 at margin >= 0.2, accuracy unchanged; its ECE on these 400 two-to-ten-option items was +0.013, while the CUDA run of the same file on the same items is +0.001 (binned ECE moves by about 0.01 at this size). 0.4 decisions/s in process.
- Automation with this folder's
CALIBRATION.gguf.json(fitted on Q8_0 readouts with--mode gguf, calibration test of 8,560 decisions, accuracy 0.904): at 1% target error 47.9% of decisions are decided automatically (observed error 0.5%); at 5%, 82.5% (4.0%). - The files are a decision-layer port of the same model, not a new model; its benchmark results (Werdykt v1 0.823, the Polish and English sets) are on basal-omni-1.0-max. These files are not scored separately on them.
Use
The basal server renders basal's own prompt and reads the probabilities of the option codes; it runs the GGUF file in process, or in front of Ollama or llama.cpp. Install the basal engine 2.2.0 or newer with the gguf extra (llama-cpp-python 0.3.36 or newer: Gemma 4 support):
uv pip install "basal[gguf] @ https://github.com/rkinas/basal/archive/refs/tags/v2.5.3.tar.gz"
hf download Remek/basal-omni-1.0-max-GGUF --local-dir basal-omni-1.0-max-GGUF
basal-serve --model ./basal-omni-1.0-max-GGUF --mode gguf --gguf basal-omni-1.0-max-GGUF/basal-omni-1.0-max-Q8_0.gguf --port 8000
On NVIDIA, build llama-cpp-python with CUDA (see the engine's docs/GGUF.md); on a Mac it uses Metal. Then ask questions exactly as with basal-omni-1.0-max (choice, noul, score, multi, act, tool, and the task types; up to 255 options).
Ollama (0.35 or newer; checked on the mini files; not yet measured on max):
cd basal-omni-1.0-max-GGUF && ollama create basal-omni-1.0-max:q8_0 -f Modelfile.Q8_0 && cd ..
basal-serve --model ./basal-omni-1.0-max-GGUF --mode ollama --ollama-model basal-omni-1.0-max:q8_0 --port 8000
A plain ollama run gives free text only: the typed answers come from basal-serve in front of it. Ollama mode reads at most 20 options per question (Ollama returns at most 20 log-probabilities) and 4,096 tokens per prompt; for long documents and up to 255 options use --mode gguf.
- Calibration:
--mode ggufloadsCALIBRATION.gguf.json, fitted on this port.CALIBRATION.jsonis the bf16 model's calibration, the default for--mode ollamaand--mode llamacppuntil they have fits of their own. You can refit any of them on your own labelled data withbasal-calibrate. - Memory on Apple Silicon: max Q8_0 with the engine's 16,384-token context does not fit a 24 GB Mac (it ran with 8,192 tokens); use a 32 GB Mac or Q6_K.
- One option order. The shipped calibration is fitted for one option order (the default).
How it was made
convert_hf_to_gguf.pyof llama.cpp b11312 on the bf16 release model (the text decoder; the image and audio encoders are left out) to F16 and Q8_0;llama-quantizefrom F16 to Q6_K without an importance matrix. Converting on Linux (CUDA) and macOS gives byte-identical files.CALIBRATION.gguf.json: the bf16 model's method and splits on this port's Q8_0 readouts (--mode gguf, one option order): per-type and per-bucket temperatures and certified thresholds for 1% and 5% error. Q6_K is served with the same file.
Files
basal-omni-1.0-max-Q8_0.gguf,basal-omni-1.0-max-Q6_K.gguf: the GGUF files.Modelfile.Q8_0,Modelfile.Q6_K: forollama create.- Tokenizer,
chat_template.jinja: as in the bf16 model (the basal server renders the prompt with them). CALIBRATION.gguf.json,CALIBRATION.json: the calibration fitted on this port, and the bf16 model's.basal.json: prompt format 2 and the readout protocol.- LM Studio:
basal-omni-1.0-max-Q8_0-decision.ggufandbasal-omni-1.0-max-Q6_K-decision.ggufare the files above with basal's decision metadata added (weights unchanged). LM Studio 0.4.26 or newer (beta channel at the time of writing; llama.cpp engine 2.65.1+, not the MLX engine) serves them as decision models on/v1/systemoneand/v1/decisions: choice, yes/no and score, up to 26 options, temperatures fromCALIBRATION.gguf.json. LM Studio ends a request after 30 s, so split very long documents.- With basal 2.5.0 you can add the same metadata to a GGUF file yourself (a file of this repository, downloaded, or your own quantisation; the tensors are not touched):
basal-export-gguf Remek/basal-omni-1.0-max-GGUF lmstudio/basal-omni-1.0-max-Q8_0.gguf --gguf basal-omni-1.0-max-Q8_0.gguf --systemone.
- With basal 2.5.0 you can add the same metadata to a GGUF file yourself (a file of this repository, downloaded, or your own quantisation; the tensors are not touched):
Limitations
- Experimental, as the bf16 model: validate it on your own documents before relying on it.
- Text only (see above).
- Quantisation changes some decisions where the model is unsure (see the table); decisions it is sure about are almost unchanged.
- Exact arithmetic and thresholds are a weak spot of one-pass decisions: compute them in code.
- Decisions with serious consequences for people should be reviewed by a person.
Citation
@software{kinas2026basal20,
title = {basal-2.0: typed-decision models and inference engine for Polish and English},
author = {Kinas, Remigiusz},
year = {2026},
version = {2.0.0},
url = {https://github.com/rkinas/basal}
}
License and attribution
Apache-2.0. Converted from basal-omni-1.0-max, fine-tuned from google/gemma-4-12B-it (Apache-2.0).