Apple Silicon Macs are engineering marvels. The unified memory architecture works beautifully for AI workloads, MLX provides excellent framework support, and the hardware delivers impressive performance. As we saw in our deep dive on running Qwen3-Next-80B, Macs can run large models with excellent inference speed.

But here’s the hard truth: Apple’s RAM pricing model makes their hardware prohibitively expensive for local LLM inference.

This is the second in a three-part hardware series. Part one covered why NVIDIA consumer cards fall short. Now let’s talk about why Apple’s pricing ruins what would otherwise be a very good solution.

What Apple Gets Right

Let’s start with what makes Apple Silicon genuinely impressive for LLM inference:

Unified Memory Architecture

This is where Apple’s engineering truly shines. Unlike traditional systems where CPU and GPU have separate memory pools requiring constant data copying, Apple Silicon uses one unified memory pool accessible to everything.

Here’s why this matters for LLM inference:

No data copying overhead: When you load a model, it sits in memory once. The GPU doesn’t need to copy data from CPU RAM. The Neural Engine can access it directly. There’s no PCIe bottleneck, no memory duplication, just direct access.

Memory bandwidth: This is where Apple Silicon separates itself from the competition. The memory controllers are integrated directly into the SoC, enabling extremely high bandwidth:

M4 Pro (Mac Mini M4 Pro):

• Up to 273 GB/s memory bandwidth
• 64GB max configuration
• 2 TB SSD to hold some llm models
• no option for a second SSD
• Price: 3200 Euro
• Excellent value for most LLM use cases

M4 Max:

• Up to 546 GB/s memory bandwidth
• 128GB max configuration
• 2 TB SSD
• Price: 4800 Euro
• Highest bandwidth in the consumer space

Why bandwidth matters: LLM inference is memory-bound. You’re constantly reading model weights and KV cache from memory. With 546 GB/s on the M4 Max, you can feed the GPU fast enough to maintain high token generation speeds even with massive models. This is 2-3x the bandwidth of typical DDR5 systems and far exceeds what you get with discrete GPUs (which are limited by PCIe bandwidth for system RAM access).

For comparison, a typical high-end DDR5 system might deliver 100-150 GB/s. AMD’s Ryzen AI Max+ 395, delivers M4 Pro levels around 250 GB/s. Apple’s M4 Max at 546 GB/s is in a league of its own.

This bandwidth advantage is why Macs can achieve 50+ tokens/sec on 70B-80B models despite having less raw compute than some alternatives. You’re not waiting on memory access—the bottleneck is genuinely compute, not memory bandwidth.

For LLM inference, this unified memory architecture with massive bandwidth is exactly what you want. It’s genuinely impressive engineering.

Excellent Driver Support

The MLX framework provides day-one support for novel model architectures. When Qwen3-Next-80B dropped with its new architecture, MLX had it running immediately. No waiting for driver updates, no compatibility hacks.

The Problems: Pricing and macOS

Here’s where it all falls apart: Apple’s RAM pricing is absurd. It’s like this for a long time. As Apple is a highly profitable company, I see zero chance of this changing in the near future. Actually, this is an understandable strategy to keep their high margins.

Even if you consider paying the premium to run on Apple Hardware, I am not recommending to run them as servers. Apples macOS is an operating system built for personal computers. While they advanced headless usage, it’s still an afterthought for Apple. Running a secure node is just not that easy and forces you to work against the OS. Running Linux is somehow possible, but also an edgecase for these distributions. The last thing you want in a quickly developing hardware ecosystem is to be a edgecase, as this usually leads to driver and other obscure problems.

The Takeaway

Apple Silicon is legitimately impressive hardware. The engineering is excellent, the performance is strong, and the software ecosystem is mature.

But Apple’s RAM pricing and macOS ruin what would otherwise be the perfect solution for local LLM inference.

For price-conscious builders who want maximum memory for local LLM inference, Apple simply doesn’t make financial sense.

Previously: Why you shouldn’t buy an NVIDIA GPU - the 32GB limitation problem.

Next: Why you should buy an AMD machine - the actual solution that gives you fast 128GB of RAM for half the price.

When you’re shopping for hardware to run LLMs locally, the conversation typically starts with NVIDIA GPUs. They have the best driver support, the most mature ecosystem, and work with everything. But here’s the problem: consumer NVIDIA cards are hitting a hard ceiling that makes them unsuitable for modern local LLM inference.

This is the first in a three-part series on hardware options in 2025. We’ll cover why NVIDIA consumer cards fall short, why Apple’s ecosystem pricing is prohibitive, and ultimately, what you should actually buy.

The 32GB Wall and custom builds

Let’s start with the most established path: NVIDIA GPUs.

NVIDIA has the best driver support, the most mature ecosystem, and the widest software compatibility. If you’re running vLLM, Transformers, or any PyTorch-based inference stack, NVIDIA just works.

The problem? Most consumer and prosumer NVIDIA cards top out at 32GB of VRAM. On top, there’s a reason why NVIDIA’s stock price is soaring. They demand a huge premium for their products:

• RTX 5090: 32GB, 2500+ Euro
• RTX 3090: 24GB, 1300+ Euro
• (Professional cards like the RTX 6000 Pro Blackwell: 96GB, 8,000+ Euro)

With one of these in the shoppingcart you just have the graphics card, leaving out the remaining components like CPU, RAM, SSDs, power supply and a case to house it all. There is no standard around building this, everything is possible. While this may sound cool, this is a maintenance nightmare. Do I see this special behavior on this machine because I have an Intel CPU and an ASUS motherboard? You can never rule this out, and usually you don’t have a second system to do a comparison with easily. Stability requires uniformity, there’s no way around it.

Quantization Explained

Before we talk about memory constraints, let’s understand how model size changes with quantization.

Modern LLMs store parameters as numbers. Quantization reduces the precision of these numbers to save memory. Here’s what that looks like for two common model sizes:

32B Model (like Qwen3 32B):

• FP16 (16-bit): ~64GB
• 8-bit quantization: ~32GB
• 4-bit quantization: ~16-18GB
• 3-bit quantization: ~12-14GB

70B Model (like Llama 3.1 70B):

• FP16 (16-bit): ~140GB
• 8-bit quantization: ~70GB
• 4-bit quantization: ~35-38GB
• 3-bit quantization: ~26-28GB

The rule of thumb: divide the parameter count by the bits per parameter to get approximate memory usage. A 32B model at 4-bit quantization needs roughly 32B ÷ 2 = 16GB, plus some overhead for model structure.

Lower quantization (3-bit, 4-bit) saves memory but reduces model accuracy slightly. For most local inference use cases, 4-bit quantization offers the best balance: you keep ~95% of model quality while cutting memory usage to ~25% of the original.

But here’s the catch: the model weights are only part of the story.

Why 32GB Isn’t Enough Anymore

Here’s the thing people miss: GPU memory doesn’t just hold the model weights. It also holds the KV cache: This stores the attention keys and values for your entire context window. Avid agentic coders know this as their context, and it’s always running out too fast!

Let’s do the math on a practical example:

Qwen3 32B (4-bit quantization):

• Model weights: ~18GB
• You have 14GB left for context on a 32GB card
• The KV cache size per token depends on the model’s architecture. A typical 32B model consumes around 0.5 to 1.0 MB of VRAM per token in the context window
• With 14GB remaining: 14,000 MB / 0.5 MB per token = ~28,000 tokens of context (or as low as ~14,000 tokens with FP16 KV cache)

That sounds like a lot—until you understand what actually consumes those tokens in real-world usage.

What Eats Your Context Window

Here’s what fills up those 28,000 tokens in practice:

System prompts and instructions: 500-2,000 tokens

• Base system prompt defining the agent’s behavior
• Task-specific instructions
• Safety guidelines and constraints

MCP (Model Context Protocol) plugins and tools: 2,000-5,000+ tokens

• Tool definitions for each MCP server
• Function schemas and examples
• Return value specifications
• Multiple plugins stack up quickly

Conversation history: Variable, but grows fast

• Your messages to the agent
• Agent’s responses
• Multi-turn back-and-forth
• A 20-message conversation can easily hit 10,000+ tokens

Retrieved context: 10,000-50,000+ tokens

• Document chunks pulled from vector databases
• Code files for context
• API documentation
• Knowledge base articles

Working memory for long-running tasks: The killer use case

• Agent exploring a codebase
• Multi-step research tasks
• Complex debugging sessions
• Building features across multiple files

This last point is crucial: long context = agents can work independently for longer before needing a reset. If your context fills up after 20,000 tokens, your agent might need to restart after 10-15 tool calls. With significantly more tokens available (100K+ on systems with more memory), the agent can run through dozens of tool calls, maintain full context of what it’s tried, and make better decisions.

And if you want to run a larger model—say, a 70B quantized to 4-bit (~38GB)—you can’t even fit it on a 32GB card, let alone leave room for meaningful context.

The verdict: NVIDIA GPUs are excellent for established models and production workloads where you control the infrastructure. But consumer cards hit a hard ceiling when you want both large models AND extensive context.

What About NVIDIA’s DXG Spark?

NVIDIA’s Grace Blackwell DGX Spark has an interesting spec:

• 128GB unified LPDDR5x memory
• 20 core ARM processor
• 1 petaflop AI performance
• 10 GbE, ConnectX-7 Smart NIC
• pricepoint between 3000 and 4000 Euro.
• new NVFP4 format

On paper, this is a game-changer for local LLM inference. The most interesting thing is the new NVFP4 format, allowing for more aggressive quantization. Research has shown that models can be trained to fit into this quantization with almost the same performance. As this is a hardware supported feature, it can’t be copied quickly from Apple or AMD.

But the machine is far from available: It was announced for a long time, now we have seen the first videos, but also only sold out shops so far.

Even if it becomes available, this is a subsidized offer from NVIDIA. They are expecting very high margins for their products. By the nature of the price, this cannot maintain typical nvidia margins. They want you to buy into this ecosystem and then once it works locally go the most convenient way of running it on NVIDIA hardware in the data center as well. This machine is a mechanism to lock you into their ecosystem.

Most of the things Nvidia does are closed source: CUDA is closed source, the operating system running the DGX Spark DGX OS 7 is closed source, the list goes on. We’ve seen the play before, and we’re not eager to run into the trap again.

The Memory Wall Is Real

Here’s what’s become clear: local LLM inference is increasingly memory-bound, not compute-bound.

Modern MoE architectures like Qwen3-Next demonstrate this perfectly:

• 80B total parameters, only 3B active per token
• Inference speed is excellent—if you have the memory to hold it
• Context window length matters as much as model size

The bottleneck isn’t “can my GPU compute fast enough?” It’s “can I fit the model AND enough context to do meaningful work?”

This is why 32GB cards are increasingly limiting. They work for smaller models or shorter contexts, but can’t handle the frontier of what’s possible with local inference.

This post is part of a three part series. Next week: Why you shouldn’t buy into the Apple ecosystem.

In part one, custom slash commands automated repetitive tasks but gave inconsistent results. In part two, we found the fix: separate the conversational prompt from a deterministic script.

Now, the finale. After weeks of hardening this approach, I’ve distilled it into three patterns that transform scripts into powerful self-fixing installers. Here’s what I learned building the TreeOS production setup.

The Three Patterns

1. The Self-Fixing Loop

The old way: run the script, watch it fail, open the file, find line 52, guess a fix, save, run again. High-friction context switching.

The new way: I let Claude execute the script, it fails on an edge case, and it comes back to me with what happened and multiple options how to fix it. Claude has the full context: the command, the code, and the failed output. It updates the script immediately. The script hardens with each real-world failure. This tight feedback loop is the fastest way to build robust automation. TreeOS will be open source. Users can run the install script and contribute a pull request if they encounter an edge case. Can’t wait to see this in real life.

2. Soft Front Door + Hard Engine

Every installer consists of two side-by-side files:

• Soft Front Door (.md): treeos-setup-production.md

• Hard Engine (.sh): treeos-setup-production-noconfirm.sh

The treeos prefix is to separate my custom commands from others. The markdown contains the Claude Code prompt, the conversational layer. It explains what’s about to happen, checks prerequisites, and asks for confirmation. It’s flexible and human-friendly.

The shell script is the deterministic engine. It takes inputs and executes precise commands. No ambiguity, no improvisation, 100% repeatable.

This separation is crucial. Claude can safely modify the conversation in the front door without breaking the logic in the engine. The naming convention makes the relationship obvious.

3. The Graceful Handoff

Depending on the machine and trust level of the user, sometimes Claude Code has access to sudo, sometimes not. The pattern: check if sudo is available without a password prompt.

sudo -n true 2>/dev/null && echo "SUDO_AVAILABLE" || echo "SUDO_REQUIRED"

If sudo requires a password, the front door hands off cleanly:

⚠️ This script requires sudo privileges.

Claude Code cannot provide passwords for security reasons.

I've prepared everything. Run this one command:

cd ~/repositories/ontree/treeos

sudo ./.claude/commands/treeos-setup-production-noconfirm.sh

Paste the output back here, and I'll verify success.

Claude does 95% of the work, then asks me to handle the one step it can’t. Perfect collaboration.

The Real-World Result

These three patterns and a lot of iterations produced my TreeOS production installer. It’s now 600+ lines and handles:

• OS detection (Linux/macOS) and architecture

• Downloading the correct binary from GitHub releases

• Creating system users with proper permissions

• Optional AMD ROCm installation if a fitting GPU is detected

• Service setup (systemd/launchd) and verification

When something breaks on a new platform, the self-fixing loop makes improvements trivial. I’ve hardened this across dozens of edge cases without dreading the work.

Why This Changes Everything

Traditional README files demand a lot from the user. They push the cognitive load onto users: identify your platform, map generic instructions to your setup, debug when it breaks.

This flips the script. Instead of static documentation describing a process, we have executable automation that performs it.

But this isn’t just about installers. Apply these patterns to any complex developer task:

• /setup-dev-environment clones repos, installs tools, and seeds databases

• /run-migration backs up production, runs the migration, and rolls back on failure

• /deploy-staging builds containers, pushes to registries, and updates Kubernetes

We’re moving from documentation that describes to automation that executes, with AI as the safety net and co-pilot. This is the future of developer experience: reducing friction by automating complex workflows around code.

With the explosion of AI tools, setup complexity is a real barrier. These patterns are one step towards changing that.

Just last month, Alibaba’s Qwen team released something remarkable that has gone mostly unnoticed: Qwen3-Next-80B, an 80 billion parameter model that runs as fast as a 3 billion parameter one.

This isn’t just another upgrade. It’s a paradigm shift and glimpse into the future of local AI. It’s also a perfect showcase of the current local inferencing ecosystem.

The Model That Changes the Game

The magic is in its ultra-sparse Mixture of Experts (MoE) architecture. Think of it like a massive library with 80 billion books (total parameters), but your librarian only pulls the 3 billion most relevant ones for your query (active parameters). You get the knowledge of the entire library at the speed of a small, curated collection. Interestingly, this is also similar to how actual brains work, where the prefrontal cortex directs attention to the correct brain region.

This architecture results in knowledgeable models with fast inference. According to real-world benchmarks, on a high-end Mac Studio M3 Ultra with 8-bit quantization, this translates to 50 tokens per second—fast enough for a real-time conversation with a world-class AI.

Sounds too good to be true? Unfortunately, there are a few catches, at least for now. Qwen3-Next uses a novel hybrid attention architecture combining Gated DeltaNet and Gated Attention—tricky new architectural features that most existing tools weren’t built for. The struggle to run it on affordable hardware reveals everything about the three main paths for local AI in 2025.

---

Path 1: The Apple Fast Lane

Qwen3-Next released on September 11. Full support in the popular LM Studio app? September 16. Just five days later. On a Mac, it just works. You download the model from LM Studio’s catalog, and it runs. Why is that?: Apple controls the entire stack. Their MLX framework is a specialized engine built to get the most out of their own silicon. When a new model like Qwen3-Next appears, developers can write support for it directly in MLX, bypassing the community bottlenecks that affect other platforms.

While Apple is sleepy on their product side at integrating AI, the MLX is on top of the game.

The performance is great, on this blog post there are claims for 14 tokens/sec on a Mac Mini M4 Pro with 64GB and a whopping 50 tokens/sec on a Mac Studio M3 Ultra. But this seamless experience comes at a premium. A Mac Studio equipped to run this model comfortably (128GB unified memory) starts around $7,200. You’re paying for a vertically integrated ecosystem where the hardware and software are perfectly in sync.

Path 2: The Professional Choice with NVIDIA

Support for Qwen3-Next? Day one. If you have the right hardware, running the model is as simple as a single command line or a few lines of Python. The professional AI world is built on NVIDIA and its mature software ecosystem. Frameworks like vLLM, Transformers, and SGLang are designed for production servers and work directly with a model’s native PyTorch code. There’s no need for conversion or waiting for updates. If the model’s creators release it, these tools can run it instantly.

The full, unquantized 80B model is massive and impractical for most users. Instead, the standard approach is quantization — compressing the model to use less memory with minimal quality loss.

According to deployment guides, common quantization formats include:

• FP8: ~40GB of VRAM needed

• INT8: ~42GB of VRAM needed

• INT4/AWQ: ~22GB of VRAM needed

Even with aggressive quantization, you’re looking at 22-40GB+ of VRAM. A single NVIDIA A100 80GB costs $10,000-15,000, so out of range for most. Consumer cards like the RTX 4090 (24GB) can’t fit even the most aggressive quantizations of an 80B model.

The Trade-Off: NVIDIA offers the most mature, powerful, and instantly-compatible software. But for the newest, largest models, it’s realistically a cloud or enterprise solution, not a local one for most consumers. Unless you have access to datacenter GPUs, you’re limited to smaller models or cloud inference. The just released Spark DGX could change that, but general availability is unclear.

---

Path 3: The Open Path with AMD

This is my path, and it’s the one most people are on.

The hardware is ready. My AMD Ryzen AI Max+ 395 is a beast, offering 128GB of unified LPDDR5X-7500 memory. For inference, fast memory is the limiting factor. Strix Halo matches Apple’s M4 Pro line and the DGX Spark, if it will ever be available. It’s a much more affordable system, e.g. with the Framework Desktop.

But it can’t run next generation models like Qwen3-Next-80B, at least for now. Llama.cpp is a brilliant open source community project. It’s the workhorse of local AI on AMD, making models accessible to everyone.

However, its universality is also its bottleneck. To support a radically new model like Qwen3-Next, a volunteer developer has to painstakingly implement the new architecture inside llama.cpp. As of October 2025, the pull request for Qwen3-Next is still a work in progress, with developers debugging complex issues like partial RoPE implementation. Whatever that is. Llama.cpp also powers the popular Ollama, so it has the same problems right now. The hardware is more than capable, but we’re all waiting for the community software to catch up.

Are there alternatives? Yes, there are actually two right now.

AMD users can use vLLM like NVIDIA users do. But despite ROCm 6.4.1 and 7.0 supporting the Ryzen AI Max+ 395 chipset (gfx1151), vLLM compatibility remains problematic. Users encounter “invalid device function” errors during model initialization, and official support for gfx1151 is still an open feature request.

With SGLang it’s the same story. It’s a framework that comes from the bigger cloud center hardware and is slow at adopting consumer hardware like the AMD AI Max+. There’s a PR open, but little activity.

What This All Means

This one model neatly illustrates the trade-offs in local AI today:

1. Apple & NVIDIA: The “it just works” experience. It’s fast and polished, but you pay a premium for admission to the walled garden. You might go faster now, but beware of locking yourself in.

2. AMD & Llama.cpp: The universal path. It brings AI to the most hardware at the best value, but for brand-new, architecturally complex models, there can be a delay as the open-source ecosystem catches up.

The good news is that the community path is rapidly improving:

In LLama.cpp there’s a lot of activity. I find it hard to follow all the details, even as a hardware enthusiast. Ollama’s new inference engine with direct GGML access shows they’re building toward faster support for novel architectures, though the transition is ongoing.

Ultra-efficient MoE models like Qwen3-Next prove that frontier-level intelligence can run on our local machines. The infrastructure is racing to keep up, and this competition means a better future for everyone, no matter which path you’re on.

I love how new terms are being coined at the moment. Simon Willison’s post about getting from Vibe coding to Vibe engineering is a perfect example. Unfortunately, it’s missing one key property of codebases: The differing viscosities of your files and often lines.

The blog post is a superb summary of things to look out for efficiently coding with agents. I found myself nodding at every bullet point. As an engineering leader who pitched a lot of these for implementation, it often feels like we can ultimately prove now that good software engineering practices have a business impact, instead of being misunderstood as a goodie for the engineers…

One aspect was lacking, and in the spirit of coining terms, I’d like to name it viscosity of software. Every codebase has fast, easy-to-change parts and almost impossible-to-change parts. If you draft to change them, you’ll spend the whole week convincing other engineers. These crucial files or lines have many implications to the whole project. It’s often unclear which lines are written in stone and which are written in sand.

Another way to frame this is tribal knowledge: Engineers accustomed to this codebase know these corners from their own experience or because of the stories around it. So far, I didn’t find a way to onboard my agents with this knowledge. Every agent comes in like a new developer, not knowing anything about the code. It’s amazing how fast they navigate the codebase. The AGENTS.md and code comments help a bit, but it’s a main frustration point when relying more on agents. They’re unaware of this tribal knowledge and I don’t know how to teach them.

How do we teach a machine to be afraid of the right lines of code? I’d love to hear your thoughts.