README.md

---
license: apache-2.0
language:
- en
tags:
- blueprint
- hardware
- cad
- iot
- prototyping
- agents
- robotics
- electrical
- mechanical
- 3D
pipeline_tag: text-generation
base_model: Qwen/Qwen2.5-3B-Instruct
library_name: transformers
---

# Parti Base

**Parti turns natural language prompts into hardware designs and plans.**

Tell it what you want to build — *"a compact desk clock with an e-ink display and a remote"* —
and it gives back a structured blueprint: the parts list, how the parts connect, step-by-step
build instructions, rough costs, and a quick design check. Everything comes out as clean,
organized data that an app can read and build on.

This is the **all-in-one model** — it runs on its own, no add-ons needed. (There's also a small
adapter-only version at
[**parti-base-lora**](https://huggingface.co/caid-technologies/parti-base-lora).)

📌 **Note:** Great for drafting and exploring ideas — not a replacement for real engineering, CAD software, or safety review.

## Questions

Contact us:  
[Caid Technologies](mailto:team@caid-technologies.com)

---

## What it can do

Give it a hardware idea and it can produce any of:

- 📋 a **parts list** (components)
- 🔌 a **wiring/connection map** between the parts
- 🛠️ ordered **build steps** — now with detailed, step-by-step assembly instructions
- 💲 rough **sourcing and cost** info
- ✅ a basic **design check**
- 📦 or the **whole project plan** at once

You can ask for the complete plan, or just one piece (like only the parts list).

## What it's good for — and not

✅ **Good for:** brainstorming hardware projects, drafting parts lists and build steps, and
turning a rough idea into an organized starting plan.

🚫 **Not for:** final engineering decisions, production CAD models, electrical safety, or anything
safety-critical. Treat the output as a helpful **first draft to review**, not a finished design.

## Try it

```python
from transformers import AutoModelForCausalLM, AutoTokenizer

REPO = "caid-technologies/parti-base"
model = AutoModelForCausalLM.from_pretrained(REPO, device_map="auto", torch_dtype="bfloat16")
tok = AutoTokenizer.from_pretrained(REPO)

msgs = [
    {"role": "system", "content":
        "You design hobbyist electronics projects. Given a request, reply with a single "
        "JSON object describing the full project. Output only the JSON."},
    {"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, 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))
```

💡 **Tip:** keep `max_new_tokens` high (≥ 6000) so long plans aren't cut off, and keep
`repetition_penalty=1.1` so wiring lists don't get stuck repeating. For Ollama/local apps,
convert this model to GGUF with llama.cpp.

## What it learned from

It was trained on about **170 real-world hardware projects** — things like weather stations,
small robots, drones, smart-home gadgets, lab tools, and audio gear — expanded into several
thousand practice examples. Everything is **DIY, maker-friendly** electronics-plus-hardware,
and **every project ships complete, detailed assembly instructions** (a quality gate drops any
project whose build steps are missing or bare titles).

**Most common project types in the training data:**

| Project type | Share | Examples |
|---|---|---|
| Test & lab instruments | ~20% | function generator, Geiger counter |
| Smart-home / IoT gadgets | ~15% | pet feeder, smart mailbox, pill dispenser |
| Radio, comms & networking | ~9% | LoRa base station, APRS tracker, NAS |
| Wearables & health | ~8% | sleep ring, heart-rate strap |
| Audio & music | ~8% | synth module, guitar pedal, speaker |
| Robotics & motion | ~7% | quadruped robot, robotic arm |
| Environmental sensing | ~7% | air-quality monitor, weather station |
| Clocks & e-ink displays | ~6% | word clock, e-ink calendar |
| Maker / fabrication tools | ~5% | vinyl cutter, pen plotter |
| Drones & aerial | ~5% | FPV drone, VTOL aircraft |
| Everything else | ~10% | lighting, games, automotive, power |

## Good to know (limitations)

- It's a **small model**, so complex, many-part projects are harder for it.
- It **proposes** designs; it doesn't verify them. Always sanity-check before building.
- It's strongest on common project types (lab tools, smart-home) and weaker on rarer ones
  (games, automotive).
- **Wiring maps need `repetition_penalty≈1.1`** — with plain greedy decoding the model can fall
  into repetition loops on that task (see the numbers below).

## How well it works

Evaluated on projects it **never saw during training** (held-out test split, grouped by project
so nothing leaks; 40 sampled rows per task). **"Valid"** means the output parses as JSON and
passes schema + cross-reference checks (every part a step or wire mentions actually exists, build
steps are correctly ordered, vocabularies respected).

| Task | Result (held-out) |
|---|---|
| 🛠️ Build steps | **95%** valid |
| ✅ Design check | **95%** valid (matches the reference exactly 73% of the time, structural F1 0.92) |
| 📋 Parts list | **82%** valid |
| 📦 Full project plan | **89%** next-token accuracy, perplexity **1.4** * |
| 🔌 Wiring map | **50%** valid with plain greedy decoding — this is the task the `repetition_penalty=1.1` tip exists for |

\* Full plans run ~9k tokens, so they're scored teacher-forced — how well the model predicts a
correct complete plan token-by-token — rather than by free generation.

Two honest notes:

- On the generative tasks the model **proposes its own valid design** rather than reciting the
  reference answer (exact-match ≈ 0% on parts/steps/wiring). That's expected and desirable for
  open-ended design — many valid answers exist per prompt — so "valid" is the metric that matters.
- The wiring-map number is measured at **worst-case decoding** (pure greedy, no penalty). The
  failure mode is repetition loops, which the recommended `repetition_penalty=1.1` targets.

*Evaluation: July 2026, current weights.*

---

<details>
<summary> <b>Technical details</b> </summary>

- **Base model:** `Qwen/Qwen2.5-3B-Instruct`; this repo is the **fine-tune merged to 16-bit**
  (standalone, no adapter needed).
- **Method:** QLoRA with Unsloth (LoRA r=32, alpha=32, all attention+MLP projections), then merged.
- **Training:** 1 epoch (222 steps), max_seq_len 8192, effective batch 8, lr 2e-4 (linear, 3%
  warmup), adamw_8bit, NEFTune α=5, loss masked to assistant turns; best-eval checkpoint kept
  (eval_loss 0.227 at step 100) rather than the final overfit step.
- **Hardware:** single RTX 4070 (12 GB).
- **Data:** 172 base projects (42 hand-authored + 130 synthetic) with complete, detailed assembly
  instructions enforced by a completeness gate; projected into 6 task "modes" (full plan, parts,
  wiring, instructions, validation) → 6,869 rows; split **grouped by project** so none leak
  between train/val/test; 1,772 train rows after the ≤8192-token fit filter and a 350/mode
  rebalancing cap so the model doesn't coast on the easy modes.
- **Evaluation:** held-out test split, 40 rows/task; short-output tasks scored by free generation
  + schema/reference validation; long-output tasks (full plans, ~9k tokens) scored teacher-forced
  (next-token accuracy + perplexity on the gold answer).
- **Inference:** `do_sample=False`, `repetition_penalty≈1.1`, `max_new_tokens≥6000`, pass the
  attention mask.

```bibtex
@misc{parti_base,
  title  = {Parti Base: Qwen2.5-3B for structured hardware generation},
  author = {Caid Technologies},
  year   = {2026},
  howpublished = {\url{https://huggingface.co/caid-technologies}}
}
```

Built with [Unsloth](https://github.com/unslothai/unsloth) and 🤗 Transformers / PEFT / TRL.

</details>