netcfg-8b-GGUF

netcfg-8b-GGUF

Quantized GGUF build of Qwen3-8B fine-tuned to convert network device configuration text into normalized JSON, across 17 vendor platforms.

Runs in LM Studio, Ollama, llama.cpp, or anything else that reads GGUF. Fully local — no config text leaves the machine.

Türkçe özet: Ağ cihazı konfigürasyonlarını normalize JSON'a çeviren Qwen3-8B modelinin GGUF sürümü. LM Studio, Ollama ve llama.cpp ile çalışır. Tamamen yerel, konfigürasyon metni makineden çıkmaz.

Files

Results

Held-out set: 236 configurations from topologies never seen during training. The split is by topology seed, not by sample, so no configuration from a training topology appears in evaluation.

Both rows use the same prompt, the same Q4_K_M quantization, the same serving stack (LM Studio), and temperature=0. The only variable is the model.

Precision 0.8975, recall 0.9610.

Without the schema in the prompt, the base model scores F1 0.0227 — it cannot guess the target shape. The 0.5752 baseline above is the fair one: the base model is handed the full schema as a system prompt, the same schema the fine-tune was trained against.

The MMLU difference is 2 questions out of 200 (z = 0.21). Read it as "general ability preserved", not as an improvement. 35% of the training mix was general instruction data specifically to protect against catastrophic forgetting.

Full methodology, training details, and pre-registered thresholds: huseyinturkdogan/netcfg-8b-lora

Usage

Load the model, give it a system prompt describing your target JSON schema, set temperature to 0, and append /no_think to the user message to disable Qwen3's reasoning mode. Every number above was measured that way.

Known limitations

It fills in plausible defaults that are not in the source. The clearest case: an SR Linux configuration with no MTU statement produced "mtu": 1500 on every interface. 1500 is the correct Ethernet default — it is simply not in the input. This is the main source of the remaining precision gap.

It occasionally drops a module. On one EOS config the expected module list was ["bfd", "bgp", "mpls"] and the model produced ["bfd", "bgp"], missing MPLS, while getting every BGP neighbor, AS number, and community list exactly right.

Training data is synthetic, generated with netlab. Vendor-valid syntax, but not production text. Expect degradation on real configurations carrying comments, dead blocks, and site conventions.

Dataset and evaluation code

huseyinturkdogan/netcfg-config-json

Hardware

Trained on a single ASUS ProArt PX13 laptop — AMD Ryzen AI Max+ 395 (Strix Halo, gfx1151), Radeon 8060S, 128 GB unified memory — under WSL2 / Ubuntu 24.04 with ROCm 7.2.1, librocdxg 1.2.0, and torch 2.9.1+rocm7.2.1. About 72 s per optimizer step, 7.5 hours total. No cloud compute.

A note for anyone attempting this on the same hardware: AMD's own ROCm documentation states "No ML training support" for Ryzen APUs under native Windows, and native-Windows training on gfx1151 did in fact fail here — every GPU-to-CPU scalar read returned a stale host buffer, producing a silently frozen loss and a zero-valued saved adapter. Under WSL2 it works. Verify the data path before trusting any training run on this chip.