The Homelab Redesign: One Spark Cluster, Two Agentic Workstations, and a PAIR

Last post ended on a tease, so here is the plan it was teasing. I am redesigning this homelab around a cluster instead of a box. Two DGX Sparks bonded into one server, PAIR running across everything, and the RTX 5090 and my wife’s Mac mini demoted from inference engines to agentic workstations. Demoted is the wrong word. Promoted, actually, since neither one will be waiting on a GPU queue anymore.

Two Sparks, bonded into one server

The Sparks are not going in as two separate PAIR nodes. NVIDIA’s own clustering path bonds a pair of Sparks over a single cable using MPI and NCCL, and the combined 256GB of unified memory is the whole reason this plan exists. I want to run something in DeepSeek V4 Flash’s weight class losslessly, and a single 128GB Spark cannot hold that build with any room left for context. Bonded, the pair presents as one inference target, not two independent ones I would need to keep in sync with the same model on both.

That decision closes off the other path I was weighing after the last post, running two independent Spark nodes each holding a smaller model so concurrent subagent requests spread across both on their own. That version is real and PAIR would handle it well. It is just not this version. I am building for one large lossless model first, not for maximum concurrency across small ones.

Why PAIR still matters on a one node cluster

A bonded pair of Sparks looks like a single node to PAIR, so a reasonable question is why PAIR is in this plan at all if there is nothing yet to route between. The answer is the Mac Studio I have not bought yet. Once that machine joins, whether as its own model or as a second independent target for a smaller workload, I do not want to touch a single line of configuration on either agentic workstation to make that happen. PAIR’s whole design point is that the address an application uses never changes, no matter which paired machine ends up serving the request. I would rather pay the setup cost once, now, while the cluster is simple, than retrofit routing later while something is already depending on it.

AI-NT-No-Problem and the Mac Mini become clients, not compute

Here is the role split. AI-NT-No-Problem, the RTX 5090 box, and my wife’s M4 Mac mini both run PAIR, but neither one runs an inference engine of its own once this is live. They are cluster members with no GPU work assigned to them. Hermes, OpenClaw, whatever agent harness is running on either machine, keeps calling its own local address exactly like it does today. PAIR on that machine forwards the request across the network to the Spark pair, waits for the response, and streams it back. The agent never learns anything changed.

That is the actual payoff of this redesign. The 5090 stops queueing behind its own inference workload and stays free for whatever else it is doing, gaming, content creation, agent orchestration overhead. The Sparks, headless machines with no desktop session to speak of, run PAIR’s terminal interface instead of the desktop app and do nothing but serve models all day.

The open question we cannot research our way out of

PAIR proxies Ollama and LM Studio. It does not proxy vLLM. NVIDIA’s own guidance for serving a model across a bonded Spark pair points at vLLM, and one independent benchmark I found put vLLM roughly 30 percent faster than Ollama on the same model on a single Spark, before clustering even enters the picture.

That gap has not gone unnoticed by the people actually building PAIR. NVIDIA’s own repository already carries an open pull request adding vLLM as a third engine, fully tested, still waiting on maintainer review, with a follow-on PR stacked on top of it to add SGLang as a fourth. Three separate contributors have independently opened pull requests adding some flavor of llama.cpp support: adopt-only against a proxy, a second adopt-only attempt, and a PAIR-installed engine via llama-server’s router mode. None of the four has merged. The demand to run something other than Ollama is visible in the repository itself. The answer just is not in main yet.

I still do not know whether Ollama can serve a model distributed across an NCCL bonded pair the way vLLM does, and none of those open pull requests touch that specific combination either. That is not a question I can answer by reading more pull requests. It needs the actual hardware, the actual bonded pair, Ollama attempted first because it is what merged and shipped, then vLLM measured against it to see what the real throughput cost of choosing PAIR compatibility turns out to be today. That test is the next post, once the Sparks are actually racked.

Is a router worth building around before I know whether the engine it requires can even do the job I am buying the hardware for?

By the Numbers

• 2 DGX Sparks, bonded over NCCL into one 256GB unified memory target
• 1 cluster node PAIR sees where the bonded pair sits, not two
• 2 machines demoted from inference engines to pure agentic workstations, the RTX 5090 box and the M4 Mac mini
• 1 Mac Studio not yet purchased, the reason PAIR is in this plan before it is strictly needed
• 2 inference engines PAIR supports today, Ollama and LM Studio, neither of which is the vLLM stack NVIDIA recommends for the bonded pair
• 4 open pull requests adding a third or fourth engine to PAIR, none merged
• ~30% — one independent benchmark’s throughput gap, vLLM over Ollama, on a single Spark before clustering
• 0 lines of client configuration I want to touch when the Mac Studio eventually joins