What this checkpoint does
Given a hobbyist-hardware prompt, the model emits a structured project record. It was trained on
six staged "modes," so it can produce either a complete record or any single section:
Table with columns: Mode, Task, Output| Mode | Task | Output |
|---|
| A | Normalize | free-text description → full canonical record |
| B | Prompt → Project | design request → full canonical record |
| C | Prompt → Components | prompt → {"components": [...]} |
| D | Components → Relationships | components table → {"relationships": [...]} |
| E | Project → Instructions | project + parts + graph → {"instructions": [...]} |
| F | Project → Validation | record with validation blanked → the validation block |
Canonical schema (full record)
project, requirements, components[], relationships[],
fabrication, instructions[], sourcing, validation
Component ids are snake_case; relationships form a graph whose endpoints must reference real
components; instructions are ordered with dependencies; sourcing carries normalized USD costs.
Intended use
- Parsing natural-language hardware requirements into structured specs
- Drafting component lists, wiring/relationship graphs, and ordered build instructions
- Producing manufacturability/validation reasoning over a candidate design
- Acting as the structured-generation layer in a larger hardware-agent pipeline
Not for: replacing deterministic CAD kernels, simulation, electrical validation, or
safety-critical engineering review. Treat outputs as assistive proposals, not authoritative
engineering.
How to use
from transformers import AutoModelForCausalLM, AutoTokenizer
REPO = "caid-technologies/blueprint-qwen3b-v2"
model = AutoModelForCausalLM.from_pretrained(REPO, device_map="auto", torch_dtype="bfloat16")
tok = AutoTokenizer.from_pretrained(REPO)
msgs = [
{"role": "system", "content":
"Mode B — Prompt→Project. You design hobbyist electronics and manufacturing "
"projects. Respond with a single JSON object describing the complete project. "
"Output only the JSON object."},
{"role": "user", "content": "A compact desk clock with an e-ink display and an IR remote."},
]
inputs = tok.apply_chat_template(
msgs, add_generation_prompt=True, return_tensors="pt", return_dict=True).to(model.device)
out = model.generate(
**inputs,
max_new_tokens=6144,
do_sample=False,
repetition_penalty=1.1,
pad_token_id=tok.eos_token_id,
)
print(tok.decode(out[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True))
Inference notes (learned from eval):
- Use a high
max_new_tokens (≥ 6000) for full-record modes (A/B) — short caps truncate the JSON.
- Set
repetition_penalty ≈ 1.1 — greedy decoding can otherwise loop on relationship lists (Mode D) and never close the array.
- Always pass the
attention_mask (the pad token equals EOS otherwise).
For Ollama / llama.cpp, convert this model to GGUF with llama.cpp's convert_hf_to_gguf.py,
then quantize (e.g. q4_k_m).
Training
Table | |
|---|
| Base model | Qwen/Qwen2.5-3B-Instruct (trained 4-bit via unsloth/Qwen2.5-3B-Instruct-bnb-4bit, merged to 16-bit) |
| Method | QLoRA (4-bit) with Unsloth, then merged to fp16 |
| LoRA | r=32, alpha=32, dropout=0, target = q,k,v,o,gate,up,down |
| Max sequence length | 6144 |
| Epochs | 1 (early stopping on eval_loss, best checkpoint restored) |
| Effective batch | 8 (batch 1 × grad-accum 8) |
| Optimizer / LR | adamw_8bit, 2e-4, linear schedule, 3% warmup, weight decay 0.01 |
Data. Synthetic dataset of normalized hobbyist hardware projects expanded into the six staged
modes above. The train/val/test split is grouped by base project so no project (or any of its
variants/mode-rows) leaks across splits — held-out scores measure generalization to unseen
projects. The training set is rebalanced per mode (cap 350/mode) to stop the model coasting on
the easy, near-constant validation (Mode F) and instruction (Mode E) rows.
Dataset distribution
Built from 130 base hardware projects (~110–115 unique after near-duplicates), expanded
into 978 records and projected into 3,242 task-mode rows. All projects are
hobbyist/maker-scale electromechanical builds (microcontroller + sensors/actuators + enclosure).
By application domain (what each prototype does):
Table with columns: Domain, Share, Examples| Domain | Share | Examples |
|---|
| Test, measurement & lab instruments | ~20% | function generator, Geiger counter, curve tracer |
| Smart-home / IoT appliances | ~15% | pet feeder, smart mailbox, pill dispenser, PIN safe |
| Radio, comms & networking | ~9% | LoRa base station, SDR, APRS tracker, NAS, KVM |
| Wearables & health | ~8% | sleep ring, heart-rate strap, fall pendant, UV wristband |
| Audio & music | ~8% | EuroRack VCO, reverb pedal, BT speaker, sampler |
| Robotics & motion |
By composition:
Table with columns: Dimension, Breakdown| Dimension | Breakdown |
|---|
| Variant type | positive_variant 35% · evaluation_negative 29% · prompt_rewrite 22% · seed 13% |
| Project category | electromechanical 95% · electronics 2.7% · mechanical 2.7% |
| Component category | electrical 77% · mechanical 23% |
| Component type | electronic 66% · misc 24% · mechanical 5% · 3d_printed 4% · other 2% |
| Task mode | E 30% · F 30% · A/B/C 11% each · D 8% |
| Split (grouped, no leakage) | train 2,573 · val 317 · test 352 |
| Token length | p50 3,624 · p90 4,840 · p99 6,147 · max 9,605 |
Evaluation
Evaluation uses a held-out test split of unseen projects, scoring each mode for JSON validity
(parse + schema + reference integrity), exact match, and structural F1 vs the gold answer.
⚠️ Metrics for this exact (v2) checkpoint are being finalized. The figures below are from the
prior checkpoint under the same harness and are indicative, not final for v2. Mode F's targets
are near-constant, so its high score reflects an easy task rather than strong auditing ability.
Table with columns: Mode, valid%, F1, Notes| Mode | valid% | F1 | Notes |
|---|
| A | ~84% | low* | full record; *F1 understated by single-reference scoring |
| B | ~97% | low* | full record |
| C | ~95% | — | components |
| D | ~67% | — | relationship graph; sensitive to decode settings (use ) |
*Open-ended modes (A/B/C) produce valid but different records than the single gold reference,
so exact-match/F1 understate quality; valid% is the more meaningful metric there.
Limitations & biases
- Small base model (3B): capacity-limited; complex multi-subsystem projects are harder.
- Synthetic training data: the model reflects the dataset's conventions and may not match any
specific vendor catalog, real pricing, or standard.
- No physical validation: dimensions, electrical wiring, and manufacturability are proposals,
not verified engineering. Do not build safety-critical hardware from raw outputs.
- Mode F shortcut: validation outputs skew toward "all valid"; the model is not yet a reliable
defect auditor.
- Decoding-sensitive: without
repetition_penalty, relationship generation can loop.
Citation
@misc{blueprint_qwen3b_v2,
title = {Blueprint: Qwen2.5-3B for structured hardware project generation},
author = {Caid Technologies},
year = {2026},
howpublished = {\url{https://huggingface.co/caid-technologies}}
}
Built with Unsloth and 🤗 Transformers / PEFT / TRL.