Can a Local Qwen 27B Design Hardware? ESP32 GPS Build Test

Can a local Qwen 3.8 27B model handle a physical hardware design project?

Early results say yes, with caveats. In a hands-on test, a 4-bit Qwen 3.8 27B running locally on an Olares One (a 24 GB GPU) drove OpenCode through an ESP32, GPS and OLED speedometer project. It asked sensible questions, wrote firmware, generated OpenSCAD enclosure files and exported STLs. The first enclosure was workable but plain. Whether it fully matches frontier models from 11 months ago depends on the later fit checks, which the available material does not show.

What was actually built in this test?

The project is a GPS speedometer. Three cheap, common parts make it up:

The creator picked these because he had them on hand, had used them before, and they are widely documented online. That matters for a local model. Popular hobby parts appear in tutorials and examples, so a smaller model has a decent chance of knowing them.

The goal was a 3D-printable case and working firmware. The speed unit was fixed at miles per hour, with the idea that it could be changed in software and reflashed later.

How was the local setup configured?

The model ran on an Olares One, a local AI server the creator first covered about 11.5 months earlier during its Kickstarter. He accessed it from a Windows laptop through a web browser. Its desktop includes apps such as OpenCode, Hermes Agent, Blender and ComfyUI. Olares sponsored the video, which is worth knowing when reading the enthusiasm around the hardware.

The workflow used OpenCode as the coding agent, with the local model behind it. The toolchain was set up beforehand so the test could focus on design rather than installation:

• OpenSCAD for parametric 3D models
• Arduino CLI for building and flashing ESP32 firmware
• Blender for viewing the exported meshes

The prompt was deliberately loose. It gave the overall goal and the parts on hand, then let the model decide how to organize the work and what to ask.

How much VRAM does a 4-bit 27B model need here?

The dashboard on the Olares One showed about 20.5 GB of video memory in use out of a little over 24 GB while the model was working. CPU cores were barely touched, and the GPU did the heavy lifting. System memory use was also high, but the creator attributed that to other services running, with 96 GB available.

Two practical points follow. A 27B model at 4-bit fits on a 24 GB card with some headroom, but not a lot. And the multimodal capability means you can hand it a photo of a PCB when text measurements are not enough.

What did the model get right?

It asked before it built. The agent checked that OpenSCAD and Arduino CLI were available, then produced a checklist of what it needed. It wanted the exact ESP32 board and the dimensions of each component. The creator measured parts with calipers and supplied the numbers.

It knew the parts. The creator pointed out that the model could tell common GPS modules apart and reasoned about the SSD1306's pin count and power needs. All of that knowledge lives inside a model small enough to run on one consumer-class card.

It flagged a fit problem unprompted. The OLED's active screen area is much narrower than the full PCB. The model realized its first bezel would sit in the wrong place and leave a visible gap, then asked for the actual screen dimensions. Older models were not reliable at this kind of reasoning about physical parts.

It noticed software compatibility issues. While writing firmware, it spotted a problem with one of the GPS library APIs and worked around it.

Where was it merely okay?

The first output was OpenSCAD source, not print-ready geometry. The creator asked for STL exports and rendered previews. The results included a lid, an OLED cutout and a USB-C cutout for power. His verdict was that the design is workable but function-oriented, with no flair.

He also lowered the bar on one known weak spot. For the first attempt he told the model not to try placing the mounting holes perfectly, because older models had historically made a mess of mounting point positions. That means the first pass was not a test of the hardest part of the job.

Does it match frontier models from 11 months ago?

The creator framed the test against his January 1st, 2026 experiment, where Claude Opus 4.5 and ChatGPT 5.2-Codex tried to build a physical vibe-coded product. The question was whether a local model could match or beat that result.

The material available here covers the planning, firmware drafting, first CAD pass and exports. It stops before the printed parts are checked for fit. So there is no honest final scoreboard to report. What can be said is that the process looked competent: good questions, correct part knowledge, and self-correction on the OLED bezel. The real judgment depends on whether the printed case holds the boards, the display lines up, and the firmware reads GPS speed correctly.

Is this a good way to vibe code hardware?

For hobby builds, the approach looks sound, with a few habits worth copying:

1. Use parts with plenty of public documentation.
2. Pre-install the toolchain so the agent does not burn time on setup.
3. Measure components yourself with calipers and give the model real numbers.
4. Let the agent ask questions first, and answer them precisely.
5. Stage the work. Get the first enclosure to fit loosely, then refine mounting points in later passes.
6. Export STLs and inspect them in a viewer such as Blender before printing.

The limits are also clear. Local models of this size may struggle with very large codebases. Physical fit still depends on accurate measurements from a human, and a model cannot see your PCB unless you show it.