A blog post about the AI bubble sent me down a weeks-long rabbit hole. The mission: stop renting AI and start owning it — a machine on my desk that keeps working even if every AI company evaporates tomorrow.

The original dream was a ₱145,000 Mac Mini running a 141-billion-parameter monster. The research killed that dream — and replaced it with something better. Along the way: what "8x22B" actually means (not what you think), why a hospital is the best metaphor for modern AI, how a response is born one token at a time, and the moment I realised I was speccing a server rack for a laptop's worth of work.

This is the research phase — everything I learned before clicking "Buy." The build comes next.

It started with a blog post that hit me like a truck: "AI Bubble Survival Plan".

The gist? We're living through an AI gold rush, and most of us are renting our picks and shovels from the same few companies. What happens when the bubble bursts, the VCs pull funding, the APIs get shut down, or the subscription prices triple overnight? What happens when the cloud AI you depend on for your daily workflow suddenly goes dark — or worse, gets acquired and dismantled?

That blog post became my manifesto. This local AI build isn't just a side project or a privacy flex — it's my first step in a survival plan. I want a setup where, even if every AI startup on Earth evaporates tomorrow, I can still code, write, research, and deliver work at full speed. No API keys. No uptime anxiety. No "service temporarily unavailable" at 11 PM the night before a deadline.

So yes, I want privacy. Yes, I want to own my data. But more than anything, I want resilience. I want to be the person who keeps shipping while everyone else is scrambling to find a new AI provider.

Of course, I'm a developer, not an AI researcher. I know how to build web apps, wrangle APIs, and debug JavaScript at 2 AM. But the world of local LLMs? That felt like walking into a hardware store where everyone speaks in tongues — quantization, MoE, VRAM, GGUF, parameter counts, context windows.

So I did what any reasonable beginner does: I went down a rabbit hole. Hard.

My first thought was simple and naive: I want the best model available.

If I'm building a local AI, why settle? I kept seeing the name Mixtral 8x22B pop up in forums and benchmark charts. It was crushing it on coding tasks, reasoning, and long-context understanding. The name alone sounded powerful — like something out of a sci-fi movie.

I started pricing it out. The Mac Mini M4 Pro with 64GB RAM and 1TB SSD sits around ₱125,000–₱145,000 (roughly $2,000–$2,300 USD). Not cheap, but I told myself it was an investment. One machine to rule them all. No more subscription fees. No more "service temporarily unavailable."

But then I started asking why I needed 8x22B. And that's when the rabbit hole got deeper.

Here's where my beginner brain got its first reality check. I thought Mixtral 8x22B meant the model had 8 times 22 billion parameters — so, 176 billion total. And I thought all 176 billion parameters woke up every time I asked it a question.

I was wrong.

When you send a prompt, the model doesn't wake up all 141 billion parameters. Instead, a tiny routing network looks at your input and says: "For this specific word/token, these 2 experts are the most qualified to handle it." It activates only those 2 experts (out of 8), processes the token, and moves to the next one.

Think of it like a hospital. You don't wake up every single doctor for every patient. The triage nurse (the router) directs each case to the right specialist. The cardiologist handles heart stuff. The neurologist handles brain stuff. They don't all crowd around a broken ankle.

This is why MoE models are so efficient — and why the naming is confusing. 8x22B doesn't mean 176B active. It means 8 experts of ~22B each, with only ~39B active at any moment.

Why This Matters for Local Hosting

If I had actually needed to load all 141 billion parameters into memory at full precision (FP32), I'd need ~564 GB of VRAM (4 bytes per parameter × 141B parameters).

That's not a Mac Mini. That's not even a high-end gaming PC. That's a server rack.

But because of the MoE architecture and quantization (compressing the model's precision from 32-bit to 16-bit, 8-bit, or even 4-bit), the actual requirements drop dramatically:

Even at aggressive quantization, 60–80 GB is still beyond what a 64GB Mac Mini can handle comfortably. The Mac Mini's unified memory is shared between CPU and GPU, and macOS itself needs a chunk. You'd be swapping to SSD constantly, which turns your AI into a very expensive paperweight.

Before I committed to hardware, I needed to understand the pipeline. Not the marketing fluff — the actual mechanics. Here's what I learned:

The Token Pipeline (How a Response Is Born)

When you type "Explain quantum computing like I'm five," here's what happens:

The whole process repeats for every single token. A 500-word response might require 700–800 forward passes through the model. That's why speed matters — and why VRAM bandwidth is just as important as capacity.

I spent days comparing setups. Here's the distilled version of what I learned:

My Decision

I'm going Option A — but the smaller one. A base Mac Mini M4 with 32GB RAM and a 512GB SSD. I'll add external storage later if needed.

Why? Because Mistral Small 24B fits comfortably in 32GB. Mixtral 8x7B (Q4) also fits with room to spare. I don't need to run 70B+ models. I value silence and desk space. And I can always upgrade or add an eGPU later.

The Setup Flow

That's it. No cloud accounts. No API keys. No usage quotas.

These are the links, threads, and tools I kept coming back to during my research:

I'm a solo developer who wants a coding assistant that knows my codebase, a writing partner that doesn't judge my drafts, a research tool that doesn't cost $20/month, and privacy — my prompts stay in my house.

I don't need to run the biggest model on earth. I need a reliable, fast, private model that I can talk to without thinking about token costs. Mistral Small 24B or Mixtral 8x7B will handle 95% of what I throw at them. The remaining 5%? I'll use cloud APIs for specialized tasks. That's not failure — that's smart resource allocation.