# Deterministic LoRA training directly through quantized GGUF serving weights

> Source: <https://discuss.huggingface.co/t/deterministic-lora-training-directly-through-quantized-gguf-serving-weights/179118#post_1>
> Published: 2026-08-22 09:30:41+00:00

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:
