I Bought an AI Computer
Contents
I’ve wanted to run my own AI for a while now, but never quite pulled the trigger on the hardware. On paper, the pitch is irresistible: an always-on machine that does your AI bidding without a token bill or a subscription. In practice, I had my doubts that I could get anything close to frontier quality out of a few-thousand-dollar box. Eventually, a dangerous mix of curiosity and optimism (fueled by many YouTube testimonials) won out, and I bought one.
Picking the Hardware
For something to be considered proper “AI” hardware, it needs a chip optimized for AI workloads and crap tons of RAM (GPU or unified memory). In the world of consumer-grade AI hardware, there are basically three camps:
- NVIDIA Blackwell — showcased very nicely by their own DGX Spark line
- Apple’s M-series chips — with the wildly spec’d/priced Mac Studio M5 Ultra as its most recent contender
- AMD Strix Halo — of which Ryzen AI Max+ 395 is the implementation du jour.
After lots of research and soul searching, I settled on Strix Halo. It turns out that there are quite a few vendors selling various flavors of this machine (including AMD themselves). It took me some doing to find the right combination of quality and value, but I landed on the GEEKOM A9 Mega:
- AMD Ryzen AI Max+ 395 chip
- 128 GB unified memory (256 GB/s on paper, ~200 GB/s in practice)
- 2 TB storage
- 120 W sustainable power
Since the box came preinstalled with Windows 11 Pro, I had to install Fedora 44 Server on it to make it usable for AI stuff.
Plan A: Two Models Side by Side
I wanted to run my software factory for both development and validation (which works best with models from different families, so one can check the other’s work), along with an always-on agent. So, I set up the box with Qwen3.8-27B and gpt-oss-120b, plus Hermes (the agent) and Open WebUI, which resulted in the following configuration:
How Close Do They Get to Sonnet?
My main use case for this machine is coding, so naturally I wanted to understand how good these models are when compared to what I consider to be the gold standard for everyday dev work — Sonnet (5.5 as of this writing). There are obviously many benchmarks available on the internets comparing these models (alongside many, many others), but I wanted to set up my own test.
And so, I created a test with 20 Python tasks, gave each model 2 attempts at each task, ran every solution against hidden tests, and had Opus 5.5 blind-review the code for quality:
The results were roughly as expected, with Qwen being the better coder, but very, very slow, while gpt-oss was the opposite — worse coder, but way faster. I should also note that I tested Qwen with both Q8 and Q5 quantizations and the higher quantization made no meaningful difference in quality, but ran about 30% slower.
Plan B: One Model to Rule Them All
Although the results I got from these models were fine, I wanted to see if I could do better. So I started looking for an alternative, which led me to Qwen3.8-Flash-Next. Notably, given its hefty size, I could not run anything else alongside it:
Revisiting the Sonnet Comparison
I reran the same Sonnet comparison as before and it turns out that Flash-Next is both a better coder and faster than its non-Flash sibling (though still slower than gpt-oss):
And here is how each model did, task by task:
By the way, it’s worth taking a moment to explain why this happens. Flash-Next is obviously a much larger model than Qwen 27B (125B parameters vs 27B), yet somehow runs materially faster. This is possible because it’s based on a Mixture of Experts (MoE) architecture that uses only a small fraction of itself (about 6B parameters) for each token. gpt-oss uses the same trick, which is why it’s the fastest of the three.
But What About Agent Work?
While my code testing made it clear that Flash-Next is the model to use, I wanted to make sure that it is also good enough as the main model for Hermes. To that end, I ran a bunch of agentic task tests (16 tool-use and instruction-following tasks, three runs each) on Flash-Next and gpt-oss:
Both models aced the tool-use tasks (30/30) with zero malformed tool calls. Notably, Flash-Next got there in about half the steps, but gpt-oss followed formatting instructions more strictly (18/18 vs 15/18).
The bottom line to all this is that Flash-Next is going to be just fine for Hermes.
What It Costs to Run
Finally, you can’t talk about local AI without talking about the cost of actually running the machine. I measured the power as reported by the chip’s built-in sensor, sampled four times a second while each model worked through the same four dev tasks (three runs each). Since this power usage only covers the CPU, GPU, and memory controller, the calculator below adds an estimated 25 W for everything else:
Once again, Flash-Next is the standout: it draws the least power (~93 W), slightly less than gpt-oss and well under the dense Qwen 27B, which pins the chip at its 120 W limit.
Final Thoughts
Though by no means a perfect replacement, I genuinely think that local AI has a lot of promise. While I don’t see it fully replacing frontier models for all work, it can definitely play an important role. For instance, I plan to run the workers in my software factory locally, while using opus/gpt-sol to plan and check the work.
