Inspiration

Every AI optimization demo I'd seen made the same trade-off: fake the numbers to make the pitch look good. I wanted to build the opposite — a real tool that tells you the truth about what "optimized for Arm" actually means, with genuine data wherever genuine data was available, and an honest "this is simulated" label everywhere it wasn't. Arm64 is quietly becoming the default for cloud inference (Graviton, Cobalt, mobile SoCs), and developers deploying there deserve a tool that doesn't lie to them about performance.

What it does

ArmTurbo is a model optimization and benchmarking platform for Arm64 targets. You search for a real model on Hugging Face, pull its actual metadata (file sizes, parameter count, format), run it through an optimization pipeline (quantization, ONNX/graph optimization, Arm-specific NEON/SVE2 tuning), and get a before/after benchmark comparison — tokens/sec, latency, memory, model size — with a shareable report at the end.

The honesty architecture is the core design decision: a BenchmarkProvider interface has three implementations — a local deterministic simulator (clearly labeled "Simulated" everywhere it appears), and real interfaces for Arm64 hardware and Arm Performix that honestly report "not connected" rather than faking a connection. Nothing in this app claims to be a real hardware measurement unless it actually is one.

How we built it

• Frontend: React + TypeScript + Vite + Tailwind, with a design system built entirely on CSS custom properties so the whole visual identity (a black/platinum/steel

Challenges we ran into

The trickiest bug was in the Hugging Face search flow: typing a fuzzy term like a model's short name and hitting "Analyze" was sending that raw text straight to the exact-id lookup endpoint, which returned a misleading "gated or private" error instead of a sensible "not found." The fix was making Analyze smarter about intent — try an exact id directly if it looks like one (org/model), otherwise run a real search first and only fall through to an honest "no matches" message, never a guess dressed up as a real result.

Getting the honesty architecture right was harder than getting the UI right. It's easy to build a benchmark dashboard; it's harder to build one that resists the temptation to make simulated numbers look real, at every single layer — copy, badges, and the underlying data model itself.

Accomplishments that we're proud of

A tool that never once lies about what's real. Every "Simulated" badge, every "Not connected" status, and every "formula-based estimate, not a measurement" disclaimer is load-bearing, not decoration.

What we learned

That honesty is a design constraint, not an afterthought — it has to be enforced in the data layer (the BenchmarkProvider interface) so it can't accidentally leak past the UI layer later.

What's next

Wiring up a real Arm64 device provider and Arm Performix integration to replace "not connected" with genuine hardware benchmarks, and adding real quantization/ONNX execution instead of the current simulation layer.

Built With

• arm64
• aws-graviton4
• bcrypt
• express.js
• huggingface-api
• jwt
• node.js
• react
• react-router
• recharts
• tailwindcss
• typescript
• vite