CoolFace
Modelpublic

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

sourceHugging Facellama3.2updated 15d agoView on Hugging Face
0likes31downloads
Model Card

Llama Mini Agent — LoRA adapter

The 90 MB LoRA adapter for [`Frost2o24/llama-3.2-1b-mini-agent`](https://huggingface.co/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 Q3KM 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 modelunsloth/llama-3.2-1b-instruct-unsloth-bnb-4bit (NF4 quantization of meta-llama/Llama-3.2-1B-Instruct)
MethodQLoRA — rank 32, alpha 32, dropout 0, bias none, use_rslora false
Trainable params22,544,384 across 224 tensors (16 layers x 7 projections x A/B)
Target modulesq_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj
Trained onfunction calling (xLAM), Bash (NL2SH-ALFA), Python (self-oss-instruct-sc2)
Training context1024 tokens, no packing
FrameworkUnsloth + TRL SFTTrainer
LicenseLlama 3.2 Community License

Results

<img src="benchmarks.png" alt="Grouped bar chart comparing Llama-3.2-1B-Instruct against the Llama Mini Agent adapter. Tool-call exact match 1.8% base vs 80.4% adapter; tool calls well-formed 8.4% vs 99.2%; Bash executed 16.3% vs 31.3%; HumanEval+ 28.7% vs 25.0%. Off-format BFCL v3 probe: 15.4% base vs 2.8% adapter." width="100%"/>

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.

BenchmarknBase `Llama-3.2-1B-Instruct`**This adapter**ΔPaired test
Tool calls — exact match5001.8%80.4%+78.6 pp
Tool calls — correct function5002.6%98.0%+95.4 pp
Tool calls — well-formed output5008.4%99.2%+90.8 pp
Bash — InterCode-ALFA, executed30016.3%31.3%+15.0 ppMcNemar p = 1.6 × 10⁻⁷
HumanEval+ pass@1, executed16428.7%25.0%−3.7 ppMcNemar 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

python
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

python
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

python
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

Epochs2
LR / schedule2e-4, cosine, warmup ratio 0.03
Batch2 x grad-accum 8 (effective 16)
Sequencemax 1024, packing=False, group_by_length=True
RegularizationNEFTune noise alpha 5
Optimizerpaged_adamw_8bit, bf16
Loss maskingtrain_on_responses_only — assistant turns only
Seed3407

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

bibtex
@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.