A standalone 8B model merging the Tapask/telecom-oss-8b LoRA adapter into its base AliMaatouk/LLama-3-8B-Tele. Specialised for TMF Frameworx (eTOM, SID, Open APIs) and OSS/BSS telecom operations. No PEFT runtime required — load and use like any Llama-3 model.
Two flavours of the same fine-tune:
Standalone (this repo) — single load, simpler for inference
Adapter-only — 670 MB, needs the base model at load time (smaller download)
OSS/BSS architecture decisions (ODA components, build-vs-buy, MANO choices)
Fault-to-inventory correlation (service impact from topology traversal)
TMF spec Q&A (technical knowledge retrieval)
Integration code (TMF-compliant Python clients)
How to use
python
1from transformers import AutoModelForCausalLM, AutoTokenizer
23model_id ="Tapask/telecom-oss-8b-merged"4tokenizer = AutoTokenizer.from_pretrained(model_id)5model = AutoModelForCausalLM.from_pretrained(model_id, torch_dtype="auto", device_map="auto")6model.eval()78prompt ="""Below is an instruction that describes a task related to telecom OSS/BSS systems, TMF Frameworx, or network operations. Write a response that appropriately completes the request.
910### Instruction:
11Generate a TMF641 service order payload for a 5G network slice with URLLC characteristics targeting an enterprise IoT customer.
1213### Response:
14"""1516inputs = tokenizer(prompt, return_tensors="pt").to(model.device)17output = model.generate(**inputs, max_new_tokens=1024, temperature=0.3, do_sample=True)18print(tokenizer.decode(output[0][inputs.input_ids.shape[1]:], skip_special_tokens=True))
Uses the Alpaca prompt template the model was trained with. Keep the ### Instruction: / ### Response: markers exactly.
Deploying with Ollama / llama.cpp
This repo is fp16 safetensors. For Ollama/llama.cpp, convert to GGUF:
Then create an Ollama Modelfile with the Llama-3 chat template and FROM ./telecom-oss-8b.Q4_K_M.gguf.
Training data
18,779 instruction–response pairs generated programmatically via Claude API, Kimi K2.5 on Ollama Cloud, and GLM-5 on Ollama Cloud, prompted with 8 category-specific TMF expert personas (system prompts + 4–5 batch variants each). Distribution:
Category-aware soft validators (TMF API reference presence, SID entity coverage, eTOM term coverage, JSON validity for payload categories)
Refusal-pattern scrubbing (I cannot, As an AI, etc. removed)
Type coercion for 297 pairs where source models emitted output as nested JSON objects instead of JSON strings
Evaluation loss trajectory
Epoch
Eval loss
2.27
0.8545
2.37
0.8440
2.46
0.8447
2.56
0.8438 ← best, used for merge
2.65
0.8479
2.75
0.8478
Loss plateaued and began ticking up after epoch 2.56 — classic mild overfitting signal. load_best_model_at_end=True ensured the merged model corresponds to the epoch 2.56 region.
Limitations
Synthetic data provenance — training pairs were generated by LLMs (Claude, Kimi K2.5, GLM-5) prompted with TMF expert personas. Content is stylistically consistent with TMF specs but not validated line-by-line against official TMF Open API documents. Treat outputs as starting points, not canonical.
Inner-JSON flaws — ~15% of category-1 pairs had minor inner-JSON issues (unescaped quotes inside payload strings). Not filtered out for training.
Category 8 undertrained — TMF Code Generation category ended at 74% of its 3,000-pair target due to narrow topic space and dedup loss. Code-generation quality is the weakest axis.
Domain scope — the model is narrow. General-purpose conversation, math, or code outside TMF integration will be no better (and often worse) than the base.
Standards currency — trained against TMF Open API versions current as of the prompt design (~v4/v5 dominant). May cite outdated endpoint paths for newer TMF releases.