At CES 2026, Lisa Su walked on stage with a lunchbox-sized mini PC and ran a 235-billion-parameter model on it — locally, no cloud. The chip is AMD's Ryzen AI Max+ 395, and it's quietly one of the more interesting things to happen to AI infrastructure this year.
What AMD actually shipped
- •Ryzen AI Max+ 395 — CPU and GPU sharing a single pool of up to 128GB unified memory, which is what lets it hold a 235B model.
- •Runs large open models (DeepSeek R1, Qwen3-235B-class) locally on x86 — AMD says it beats an Nvidia RTX 5080 by roughly 3x on DeepSeek R1 inference.
- •Sold as a "lunchbox" mini PC: third-party boxes on the same chip from around $1,500–$2,400 for 128GB configs; AMD's own first-party desktop around $3,999.
The headline is simple: frontier-class open models now run on a device that fits on your desk, with your data never leaving the room, and effectively zero marginal cost per token after you buy the hardware.
The catch: one box isn't a strategy
A local inference box is fantastic — until you hit its edges. You'll still want a true frontier model (Claude Opus, Gemini) for the hard 10% of requests the box can't match. The box saturates under load. It goes offline for an OS update. And you do not want to maintain two codepaths — one for 'local' and one for 'cloud.' That's a routing problem, and routing is exactly what Antbase does.
Antbase makes the lunchbox just another node
The lunchbox serves an OpenAI-compatible endpoint (via vLLM, llama.cpp, or Ollama). Antbase already treats self-hosted vLLM as a first-class provider — it's how on-prem and hybrid deployments work today. You point the vLLM connector at the box's URL and it joins the routing pool alongside every cloud provider. Your apps don't change: they keep calling ant:auto.
# The lunchbox exposes an OpenAI-compatible endpoint on your network:
# http://lunchbox.local:8000/v1 (vLLM serving qwen3-235b / deepseek-r1)
# Antbase's vLLM provider is just a base URL — point it at the box:
provider: vllm
baseUrl: http://lunchbox.local:8000/v1
models: [qwen3-235b, deepseek-r1]
# Apps keep calling the same API — now there's a local node to route to:
# model: "ant:auto" -> Antbase picks local vs cloud per requestHybrid routing: private + cheap local, frontier + overflow cloud
Once the box is a routing target, Antbase decides per request where each prompt should go:
- •Sensitive data -> stays on the local box, never touches a third-party API.
- •High-volume, cost-sensitive work -> local, where marginal cost is ~zero.
- •The hard 10% that needs a frontier model -> cloud (Claude Opus, Gemini, GPT-class).
- •Box saturated or offline -> automatic failover to the cloud pool, no dropped requests.
- •One OpenAI-compatible API across all of it — no local-vs-cloud branching in your code.
That's the real unlock. The lunchbox isn't a replacement for the cloud and the cloud isn't a replacement for the lunchbox — you want both, with something deciding intelligently between them. Buy the hardware once, route the long tail of cheap/private traffic to it, and burst to frontier models only when a request actually needs it.
You can start today, hardware optional
The models the lunchbox runs — DeepSeek R1, Qwen3-235B — are already in Antbase's cloud pool, including the free tier. So you can build the hybrid app now against the cloud versions, then drop in an AMD box later and Antbase blends it in with zero code changes. Try the cloud versions side by side first:
Local inference just got cheap and good enough to matter. The teams that win with it won't be the ones who go all-local or all-cloud — they'll be the ones who route intelligently across both. That's what Antbase is for.
