Deterministic LoRA training directly through quantized GGUF serving weights

Xyntetik Runner now trains LoRA adapters directly through quantized GGUF serving weights, eliminating the separate FP16 training copy. In a reproducible experiment, a tool-use LoRA trained on a frozen Qwen3-4B Q4_K_M GGUF improved exact tool-call accuracy from 0.69 to 1.00 and right-tool selection from 0.72 to 1.00 on a held-out eval. Two independent runs produced byte-identical adapter GGUFs with the same SHA256, while BF16 and Q8-trained adapters showed cosine similarity 0.9998, and Q4-trained adapters differed with cosine 0.9926, yet all reached 1.00 on the task.

I’ve been working on making Xyntetik Runner train LoRA adapters directly through the same quantized GGUF weights it serves. The important part is that there is no separate FP16 training copy and no second training runtime. The forward pass used for training is the forward pass used for inference. The first reproducible artifact is now live on Hugging Face: For this release I trained a tool-use LoRA directly against a frozen Qwen3-4B Q4 K M GGUF. On the small held-out eval, exact tool-call accuracy went from 0.69 to 1.00 and right-tool selection from 0.72 to 1.00. More interesting to me is the reproducibility result: same base GGUF same dataset same seed same training config = byte-identical adapter GGUF Two independent runs at 4B scale produced the same SHA256. I also repeated the same training task through BF16, Q8 0 and Q4 K M copies of the same base model. The BF16 and Q8-trained adapters ended up extremely close in weight space, cosine 0.9998. The Q4-trained adapter followed a measurably different optimization path, cosine 0.9926 against the others, while all three adapters still reached 1.00 on this particular held-out task. So at least in this experiment, training through the deployed quantization and training through the high-precision parent are not numerically the same operation, even though they ended up capability-equivalent on the measured task. The repo contains the adapters, dataset, raw eval JSONs, provenance records, hashes and commands needed to reproduce the runs. A few important limits: This is a narrow synthetic tool-use task with 29 held-out prompts. The training set is small enough that the run is clearly in memorization territory. I’m treating this as a demonstration of the training mechanism and reproducibility properties, not as evidence of general tool-use improvement. I’d be especially interested in people trying the reproducibility claim on hardware I don’t have access to, or rerunning the BF16/Q8/Q4 comparison on a harder task where the optimization-path difference may become behaviorally visible. Runner itself is here: