Frost2o24/llama-3.2-1b-mini-agent-lora

Llama Mini Agent — LoRA adapter

The 90 MB LoRA adapter for Frost2o24/llama-3.2-1b-mini-agent, without the GGUF builds.

This repository holds the adapter weights alone — the same tensors, byte for byte (sha256 7b8e6efd42f8...), as the ones in the main repository. Use this one if you want to compose the LoRA yourself (PEFT, vLLM, multi-adapter serving, or merging at your own precision). Use the main repository if you want ready-to-run GGUF quants from Q3_K_M to fp16.

Full model card, evaluation methodology and limitations live in the main repository. This page carries what you need to load and prompt the adapter correctly, plus the headline numbers.

---

At a glance

Base model	unsloth/llama-3.2-1b-instruct-unsloth-bnb-4bit (NF4 quantization of meta-llama/Llama-3.2-1B-Instruct)
Method	QLoRA — rank 32, alpha 32, dropout 0, bias none, use_rslora false
Trainable params	22,544,384 across 224 tensors (16 layers x 7 projections x A/B)
Target modules	q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj
Trained on	function calling (xLAM), Bash (NL2SH-ALFA), Python (self-oss-instruct-sc2)
Training context	1024 tokens, no packing
Framework	Unsloth + TRL SFTTrainer
License	Llama 3.2 Community License

---

Results

Measured against the base model under an identical harness and identical prompts. Tool calling is scored on 500 xLAM rows held out by construction — training consumed shuffle(seed=3407)[:15000], this is [15000:15500] of the same shuffle, zero id overlap asserted at runtime. Bash and Python are executed, not string-matched.

Benchmark	n	Base Llama-3.2-1B-Instruct	This adapter	Δ	Paired test
Tool calls — exact match	500	1.8%	80.4%	+78.6 pp	—
Tool calls — correct function	500	2.6%	98.0%	+95.4 pp	—
Tool calls — well-formed output	500	8.4%	99.2%	+90.8 pp	—
Bash — InterCode-ALFA, executed	300	16.3%	31.3%	+15.0 pp	McNemar p = 1.6 × 10⁻⁷
HumanEval+ pass@1, executed	164	28.7%	25.0%	−3.7 pp	McNemar p = 0.41, n.s.

Parallel calls hold up: 276 of the 500 rows need two or more calls in one reply, scoring 77.9% exact against 83.5% for single calls. The residual error is overwhelmingly argument values, not tool choice — 17.6% of replies name the right function and get a field wrong, while only 1.2% pick the wrong function.

What the adapter buys is protocol reliability: 8.4% → 99.2% well-formed output. The base model's 1.8% is not evidence it cannot select tools — it answers in prose wrapped around a differently-shaped JSON object, so the strict parser rejects 91.6% of its replies. Both models are format-bound; this adapter is bound to the format documented below.

Out-of-format robustness

Prompted with a tool-calling convention it was not trained on, it degrades sharply. On BFCL v3 prompt mode — which asks for [func_name1(params_name1=...)] rather than JSON — it scores 2.8% macro against the base model's 15.4%, because 82.7% of its outputs echo the literal placeholder func_name1 instead of substituting the real function name.

Read that as a deployment hazard, not a capability score: drop this adapter into an agent framework that ships its own tool prompt and you get that behaviour, not the 80.4%. Full error taxonomy is in the main model card.

---

The three prompts it was trained on

Use these verbatim.

Tool calling

You are a function-calling assistant. Available tools:
{tools_as_json}
Respond with a JSON list of calls.

replies [{"name": "...", "arguments": {...}}]

Bash

You are a Bash assistant. Translate the request into a single Bash command.

replies with a bare command — no fences, no prose

Python

You are a Python coding assistant. Solve the problem with correct, working code.

replies with a fenced python block

Do not use tokenizer.apply_chat_template(..., tools=[...]). It renders Llama 3.1's stock tool prompt asking for {"name": ..., "parameters": ...}, which is not the format this adapter was trained on.

---

Usage

PEFT

import json, torch
from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import PeftModel

ADAPTER = "Frost2o24/llama-3.2-1b-mini-agent-lora"
base = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-3.2-1B-Instruct", torch_dtype=torch.bfloat16, device_map="auto")
model = PeftModel.from_pretrained(base, ADAPTER)
tok = AutoTokenizer.from_pretrained(ADAPTER)

msgs = [
    {"role": "system", "content":
     "You are a Bash assistant. Translate the request into a single Bash command."},
    {"role": "user", "content": "list open files for process 1234"},
]
enc = tok.apply_chat_template(msgs, add_generation_prompt=True,
                              return_tensors="pt").to(model.device)
out = model.generate(enc, max_new_tokens=64, do_sample=False)
print(tok.decode(out[0][enc.shape[1]:], skip_special_tokens=True))
# lsof -p 1234

Unsloth

from unsloth import FastLanguageModel
model, tok = FastLanguageModel.from_pretrained(
    "Frost2o24/llama-3.2-1b-mini-agent-lora", max_seq_length=4096, load_in_4bit=True)
FastLanguageModel.for_inference(model)

Unsloth resolves the base automatically from adapter_config.json.

Merging

merged = model.merge_and_unload()
merged.save_pretrained("llama-3.2-1b-mini-agent-merged")

The adapter was trained over an NF4 base. Merging into a bf16 base is the usual and supported path, but it is not numerically identical to training conditions; the GGUF builds in the main repository were produced this way.

---

Training recipe

Epochs	2
LR / schedule	2e-4, cosine, warmup ratio 0.03
Batch	2 x grad-accum 8 (effective 16)
Sequence	max 1024, packing=False, group_by_length=True
Regularization	NEFTune noise alpha 5
Optimizer	paged_adamw_8bit, bf16
Loss masking	train_on_responses_only — assistant turns only
Seed	3407

Data — each source capped at 15,000 rows, concatenated, shuffled, filtered to <= 1024 tokens: xLAM function calling (shuffle(seed=3407)[:15000]); self-oss-instruct-sc2 Python filtered only on ast.parse validity; NL2SH-ALFA Bash deduplicated, cleaned and frequency-capped at 250 per head utility; plus 60 hand-written bash/tool examples upsampled 5x.

---

Limitations

• Format lock-in — outside the three prompts above, tool calling is worse than the base model's.
• chat_template.jinja cannot represent this model's output. It renders a prior tool call as {"name": ..., "parameters": ...} and raises on more than one ("This model only supports single tool-calls at once!"), while the model emits a JSON list and does produce parallel calls. Normalize the shape in your own tool loop.
• Pipelines — Bash accuracy drops to 11% on long requests and 15.6% on find-rooted tasks.
• Python is weaker than the base model — measured here at 25.0% vs 28.7% HumanEval+ — though at n = 164 that gap is not statistically significant (exact McNemar p = 0.41). This is the joint-training cost identified in the 13-run ablation (see the main model card), not a data-quality defect. Treat its Python output as a draft.
• 1B model: no multi-step reasoning. Never execute generated shell commands unreviewed.

---

Citation

@misc{llama32_1b_mini_agent_lora,
  title  = {Llama Mini Agent (LoRA adapter): a 1B joint tool-calling, Bash and Python fine-tune of Llama-3.2-1B-Instruct},
  author = {Frost2o24},
  year   = {2026},
  url    = {https://huggingface.co/Frost2o24/llama-3.2-1b-mini-agent-lora}
}

License

Llama 3.2 Community License, inherited from the base model. Derivatives must carry "Built with Llama". Training data licenses are those of the upstream sources.

---

Supporting this work

The 13-run ablation this checkpoint comes from, and the evaluation sweep behind these numbers, were all produced on a single consumer laptop GPU. That is the main limit on how far the next version can go.

If your team has an NVIDIA DGX Spark or an AMD Ryzen AI Max+ ("Strix Halo") AI dev kit to spare, it would go directly into multi-turn tool data, the planned GRPO stage, and published eval numbers for the next generation of these models. Reach out via the discussions tab. No obligation either way — the weights stay freely available regardless.