B4-9B Nachrechnen (LoRA)

An ORPO LoRA for B4-9B that makes it better at doing math through its tools, with thinking off. Behind egirl's OpenAI-compatible API, B4 has calculate and a sandboxed Python run_code. B4 already reached for a tool on arithmetic, but it set problems up wrong, sent whole programs to the calculator, and sometimes ignored the number the tool returned. Nachrechnen is German for "re-checking the sums".

Ship it as an adapter, not merged into a quantized model. See Baking and quantization: merged and then quantized to Q8_0, most of the MATH gain disappears.

Files

file	use
`adapter_model.safetensors`, `adapter_config.json`	PEFT adapter (r 16, alpha 32, all attention + MLP projections)
`B4-9B-Nachrechnen-LoRA-f16.gguf`	the same adapter for llama.cpp: `llama-server -m B4-9B-Q8_0.gguf --lora B4-9B-Nachrechnen-LoRA-f16.gguf`

All numbers below were measured the second way: a B4-9B Q8_0 GGUF with this f16 LoRA loaded at runtime.

Training

All on-policy and self-distilled, with no teacher model. B4-9B answered GSM8K-train and MATH-train problems (disjoint from the test sets) four times each, thinking off, inside the same egirl harness and persona it is served with. Every answer was checked against the key. Pairs cut at the first assistant turn where the two runs differ, so the model learns the decision, not a new voice.

B4-9B
 + ORPO  563 pairs, 2 epochs, lr 2e-5, beta 0.1, max length 4096
         280  best-of-N      a right setup over a wrong one, same problem, both its own samples
          90  code routing   run_code over a program sent to calculate
          40  ignored tool   a reply that reports the tool's number over one that doesn't
          18  rescued        a right 5th/6th sample over a wrong one
          70  controls       35 direct answers over a pointless search, 35 searches over a stale answer
          81  scratchpad     a direct answer over run_code used as a print() scratchpad (ARC-train questions)

The chosen sides passed filters that came from reading the pairs. Figure problems ([asy]) were dropped, along with replies containing false arithmetic in the prose and replies where the key was only incidentally in the text. A lenient "key appears in the reply" check had let 0 + 1 + ... + 7 = 28 count as a right answer to "0".

The 81 scratchpad controls are what separate this release (internally "B") from the first try ("A"). A learned to reach for run_code and began using it as a scratchpad on multiple-choice knowledge questions, in 9 of 52 runs. That cost a turn and gained nothing. B removed the habit.

The pairs are not released.

Numbers

Same harness, persona and settings for every column (thinking off). The test sets are GSM8K test (1319) and the numeric-answer subset of MATH-500 (318). Where a cell has two numbers, they are two passes.

	B4-9B	first try (A)	this adapter
GSM8K test	83.7 / 84.0	86.5 / 86.2	86.8 / 86.7
MATH-500 numeric	78.6 / 78.6	81.4 / 82.4	84.0 / 84.3
runs that sent code to `calculate`	86 / 100	16 / 19	not counted
tool used on static knowledge questions (52)	12	11 (9 scratchpad)	0
needs-a-program questions right (30)	29	28	26
current-info questions searched (20)	19	20	20
Python program tasks right / first program ran (44)	35 / 39	36 / 43	37 / 43
tool-decision sets (41 + 37)	41, 35	40, 36	41, 35
ARC / ARC-Easy / TruthfulQA	61.2 / 84.4 / 36.6	60.9 / 83.9 / 36.7	60.2 / 84.4 / 37.1

The guardrail sets check that B4's earlier training still holds: search when facts may be stale, answer directly when not, run a program when one is needed. They are flat. The two "needs-a-program" misses are one item failed in both passes. Its program for amicable numbers added only the smaller number of each pair, and it reported that output. It ran the code and trusted a buggy result; it did not make the answer up. Trusting buggy output was already a B4 weakness, and this adapter does not fix it.

Baking and quantization

The merge itself is exact. Kessel linear with the adapter applied to B4-9B gives bf16 weights where every tensor is either identical to B4-9B or equals base + (alpha/r)·B·A, with no error, including the vision and MTP tensors, which are untouched. One rcbench pass on that merge, converted to Q8_0:

	B4-9B	B4-9B Q8_0 + f16 LoRA	merged, then Q8_0
GSM8K test	83.7	86.8	86.4
MATH-500 numeric	78.6	84.0	79.2
GSM8K runs using `run_code`	5	212	93

The quantized merge behaves about halfway between the base and the adapter. Our reading is that the LoRA deltas from a short, low-lr run are small compared with a Q8_0 block's step, so quantizing the merged weights rounds much of them away. A runtime adapter in f16 keeps them. We haven't yet checked the merge in bf16. B4 itself, a bigger change, survived the same merge-then-quantize path.

If you need a single file, keep the changed projections at f16/bf16 rather than Q8_0. Measure before trusting it.

Limits

It was trained and measured only inside egirl's harness with the Familiar persona and its tool schemas. Other prompts and tool formats weren't tested.
Math only: GSM8K-style word problems and numeric MATH problems. Proofs and symbolic answers weren't trained or measured.
It still trusts its own program output when the program is wrong.