Instructions to use EzioDevio/ArduinoLLM-7B with libraries, inference providers, notebooks, and local apps. Follow these links to get started.

Libraries

How to use EzioDevio/ArduinoLLM-7B with Transformers:

# Use a pipeline as a high-level helper
from transformers import pipeline

pipe = pipeline("text-generation", model="EzioDevio/ArduinoLLM-7B")
messages = [
    {"role": "user", "content": "Who are you?"},
]
pipe(messages)

# Load model directly
from transformers import AutoTokenizer, AutoModelForCausalLM

tokenizer = AutoTokenizer.from_pretrained("EzioDevio/ArduinoLLM-7B")
model = AutoModelForCausalLM.from_pretrained("EzioDevio/ArduinoLLM-7B", device_map="auto")
messages = [
    {"role": "user", "content": "Who are you?"},
]
inputs = tokenizer.apply_chat_template(
	messages,
	add_generation_prompt=True,
	tokenize=True,
	return_dict=True,
	return_tensors="pt",
).to(model.device)

outputs = model.generate(**inputs, max_new_tokens=40)
print(tokenizer.decode(outputs[0][inputs["input_ids"].shape[-1]:]))

Notebooks
Google Colab
Kaggle
Local Apps Settings

vLLM

How to use EzioDevio/ArduinoLLM-7B with vLLM:

Install from pip and serve model

# Install vLLM from pip:
pip install vllm
# Start the vLLM server:
vllm serve "EzioDevio/ArduinoLLM-7B"
# Call the server using curl (OpenAI-compatible API):
curl -X POST "http://localhost:8000/v1/chat/completions" \
	-H "Content-Type: application/json" \
	--data '{
		"model": "EzioDevio/ArduinoLLM-7B",
		"messages": [
			{
				"role": "user",
				"content": "What is the capital of France?"
			}
		]
	}'

Use Docker

docker model run hf.co/EzioDevio/ArduinoLLM-7B

SGLang

How to use EzioDevio/ArduinoLLM-7B with SGLang:

Install from pip and serve model

# Install SGLang from pip:
pip install sglang
# Start the SGLang server:
python3 -m sglang.launch_server \
    --model-path "EzioDevio/ArduinoLLM-7B" \
    --host 0.0.0.0 \
    --port 30000
# Call the server using curl (OpenAI-compatible API):
curl -X POST "http://localhost:30000/v1/chat/completions" \
	-H "Content-Type: application/json" \
	--data '{
		"model": "EzioDevio/ArduinoLLM-7B",
		"messages": [
			{
				"role": "user",
				"content": "What is the capital of France?"
			}
		]
	}'

Use Docker images

docker run --gpus all \
    --shm-size 32g \
    -p 30000:30000 \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=<secret>" \
    --ipc=host \
    lmsysorg/sglang:latest \
    python3 -m sglang.launch_server \
        --model-path "EzioDevio/ArduinoLLM-7B" \
        --host 0.0.0.0 \
        --port 30000
# Call the server using curl (OpenAI-compatible API):
curl -X POST "http://localhost:30000/v1/chat/completions" \
	-H "Content-Type: application/json" \
	--data '{
		"model": "EzioDevio/ArduinoLLM-7B",
		"messages": [
			{
				"role": "user",
				"content": "What is the capital of France?"
			}
		]
	}'

Docker Model Runner
How to use EzioDevio/ArduinoLLM-7B with Docker Model Runner:
```
docker model run hf.co/EzioDevio/ArduinoLLM-7B
```

ArduinoLLM-7B / README.md

EzioDevio

Upload folder using huggingface_hub

4802bdc verified 5 days ago

preview code

Raw

History Blame Contribute Delete

4.47 kB

	---
	license: apache-2.0
	base_model: Qwen/Qwen2.5-Coder-7B-Instruct
	tags:
	- arduino
	- esp32
	- raspberry-pi
	- micropython
	- circuitpython
	- embedded-systems
	- code-generation
	- lora
	- continued-pretraining
	language:
	- en
	library_name: transformers
	---

	# ArduinoLLM-7B (v2)

	A Qwen2.5-Coder-7B specialist for embedded systems wiring and code generation, covering Arduino C++, Raspberry Pi Python, MicroPython, and CircuitPython across 9 boards.

	Given a component and a board, it generates a wiring table, an ASCII wiring diagram, working code, and a short explanation of the key design decision — in one consistent format.

	## What's new in v2

	v1 was trained entirely on LLM-generated synthetic examples. v2 adds a genuine second training stage: continued pretraining on real library source code (~500M tokens from 240,634 real files across the Arduino core libraries, `micropython-lib`, and the Adafruit CircuitPython Bundle), followed by re-running instruction fine-tuning on top.

	Result: format compliance improved from 83% to 100% on a 12-question held-out benchmark, and three specific, previously-documented failure modes (an internally-inconsistent wiring diagram, a fabricated I2C conflict-resolution procedure, and an invented sensor capability) no longer reproduce.

	\| Metric \| v1 \| v2 \|
	\|---\|---\|---\|
	\| Format compliance \| 83% \| 100% \|
	\| Contamination-free \| 100% \| 100% \|
	\| Correct runtime API \| 92% \| 92% \|
	\| Syntax valid \| ~100% \| 100% \|
	\| Speed (RTX 5090) \| 73.2 tok/s \| 37.5 tok/s \|

	v2 currently runs slower than v1 — a known tradeoff from the local re-merge process, not a quality issue. A faster-quantized export may follow.

	## Post-release findings (ongoing)

	After initial v2 publication, targeted fixes were applied for two mechanically-verified issues, now enforced by automated checks in `validate_dataset.py` rather than prompt instructions alone:
	- ESP32/ESP8266-specific macros (e.g. `IRAM_ATTR`) appearing in AVR (Arduino Uno) code
	- Resistive sensors (LDR, FSR, thermistor) wired without a required voltage-divider resistor

	Further spot-testing has surfaced two additional, not-yet-fixed patterns worth knowing about before you rely on generated wiring:
	- Occasional swapped SPI pin assignments on ESP8266, where hardware SPI pins are fixed in silicon but the generated wiring table sometimes assigns them incorrectly
	- Character LCD displays (HD44780-style, in any interface variant — parallel, I2C backpack, or claimed SPI) are currently unreliable: wiring diagrams have shown fabricated pins and internal inconsistency with the accompanying code across multiple tests

	These are documented here rather than left for users to discover. As with all outputs, verify pin assignments against your specific hardware's actual datasheet — especially for character LCDs until this is resolved.

	## Usage

	```python
	from unsloth import FastLanguageModel

	model, tokenizer = FastLanguageModel.from_pretrained(
	model_name="EzioDevio/ArduinoLLM-7B",
	max_seq_length=2048,
	load_in_4bit=True,
	)
	FastLanguageModel.for_inference(model)

	prompt = "How do I wire a BME280 sensor to an ESP32 over I2C, with Arduino code?"
	inputs = tokenizer(prompt, return_tensors="pt").to("cuda")
	outputs = model.generate(**inputs, max_new_tokens=1300)
	print(tokenizer.decode(outputs[0], skip_special_tokens=True))
	```

	## Training data

	- Synthetic: 1,634 unique wiring/code examples, generated via the Anthropic API, Google's Gemini API, and a locally-hosted Qwen2.5-Coder-32B, validated for format compliance, runtime contamination, AVR/ESP macro correctness, and resistive-sensor voltage-divider presence.
	- Real corpus: ~500M tokens (of a 2.59B-token total) from real Arduino/MicroPython/CircuitPython library source code.

	OpenAI and DeepSeek were not used, since both explicitly prohibit using their API output to train competing models.

	## Limitations

	- Most reliable on well-represented single-component combinations.
	- v2 used only ~19% of the available real-code corpus.
	- Character LCD displays are currently unreliable (see Post-release findings above).
	- Occasional SPI pin-assignment errors on ESP8266 have been observed.
	- Always verify wiring against the component's actual datasheet before connecting power.

	## Full pipeline and dataset

	See [github.com/EzioDEVio/ArduinoLLM-7B](https://github.com/EzioDEVio/ArduinoLLM-7B) for the complete training pipeline, dataset, and evaluation scripts.