AI · Local AI · Experiment

Two local models built my server rack in 3D.

Before buying a cabinet for my home lab, I wanted to see it. Two AI models on my own hardware wrote every 3D part. Here is what broke and what held.

14 October 2026 · 4 min read

3D render: a 1.5 metre desk with two monitors on an arm, a printer, and a white locked rack cabinet underneath holding a PC, two AI servers and a NAS — The whole setup: locked 12U cabinet under the desk, kid-proof, ducted to a wall vent.

The lesson: the model never decides a measurement. Plain code sets every size and position. The model only draws inside the box it is given.

PC slid out of the rack with the lid off, built by the 125B model

Built by the 125B modelFast mixture-of-experts Open in 3D →

The same PC view, built by the 27B model

Built by the 27B modelSlower, more careful Open in 3D →

563D parts written by local AI

2models, same instructions

6failures caught

0parts drawn in the cloud

The race

Same 28 parts, same machine. Press the button.

125B MoE5B active

0 / 28

0:00

27B denseall weights, every word

0 / 28

0:00

	125B MoE	27B dense
Time	11 min 45 s	28 min 51 s
Broken parts	1	2
Kept to real sizes	often too big	close

Speed went to the sparse model. Accuracy went to the dense one. Neither was clean alone.

How it worked

Hybrid: a cloud assistant conducted, the local models did the bulk. Tap a step.

Tap a step to see what happens there.

cloud: plan + reviewlocal: 56 partscode: checks

Every part, drawn by a model

No photos here: every shape and face below came out of a model's code. Flip between the two to compare.

AI server, drawn in 3D by the model — AI server

Mac Studio (future), drawn in 3D by the model — Mac Studio (future)

Rack PC case, drawn in 3D by the model — Rack PC case

10G switch, drawn in 3D by the model — 10G switch

Apple TV, drawn in 3D by the model — Apple TV

Wi-Fi router, drawn in 3D by the model — Wi-Fi router

Front of the open cabinet in 3D: switch, patch panel, rack PC, two AI servers, NAS

Inside the cabinet, top to bottom: switch, patch panel, PC, AI servers, NAS.

Six things that broke

Tap a card to see the guard that now stops it.

Before: grey sheets and black spikes across the PC view

BeforeAfter

Drag: the silent bug, before and after the guard.

Next: fully local

Swap the cloud conductor for a relay of local models. They hand off through a job file, not chat. Run one part through it.

Press a button to send a GPU part through the relay.

Two limits shape it. My GX10 holds one big model at a time, so the drafter runs the batch, then swaps to the repairer. And a model grading itself is weak: the code checks and a screenshot caught every real failure.

Exact models and settings

Both ran on one ASUS Ascent GX10 (NVIDIA GB10, 128 GB unified memory). Same prompts, same layout, same checks.

Model A: the fast drafter
Model	Qwen3.8-Flash-Next 125B-A5B (mixture of experts, about 5B active per token)
Weights	INT4 AutoRound quantisation
Engine	TensorFold, OpenAI-compatible API
Server	context 131,072 · 2 parallel slots · KV cache fp8 · vision on
Per request	temperature 0.4 · top_p 0.95 · top_k 20 · max tokens 16,000 · thinking off
Concurrency	up to 4 requests queued on 2 slots

Model B: the careful repairer
Model	Qwen3.8 27B (dense, 27.3B parameters)
Weights	Q4_K_M quantisation, with multi-token prediction
Engine	Ollama 0.40.2, native chat API
Server	context 131,072 · kept loaded in memory
Per request	temperature 0.4 · top_p 0.95 · top_k 20 · max tokens 16,000 · thinking off
Concurrency	2 requests at a time

The conductor (cloud)
Model	Claude Opus 5.5 in Claude Code
Role	checked specs, wrote layout and checks, read screenshots, fixed and published. Wrote none of the 56 parts.

Temperature 0.4 trades creativity for steadier code. Thinking off because, with a precise spec, reasoning burned the whole budget before writing anything.

Swap in a better model next year. The fence still holds.