Mac Studio Cluster

When a Mac Studio cluster makes sense

• Serving models to many users. One machine handles a limited number of requests at once. More nodes means more throughput.
• Several large models online together. A chat model, a coding model and an embedding model, each on its own node.
• Models too large for one machine. Splitting a model across nodes is possible, with caveats below.
• Render farms. Distributing frames across Max-class GPUs to finish a sequence sooner.

Prices in USD per month for each machine's starting configuration. More memory, storage or several machines? Ask us.

Two ways to serve models

Replicate: one model copy per node

Run the same model on every node with Ollama, llama.cpp's server or MLX, and put a load balancer in front. This is simple, robust and scales almost linearly with node count. If a node is busy or restarting, the others keep answering. For most teams this is the right default.

Shard: one model across nodes

When a model is larger than one machine's usable memory, you can split its layers across nodes. llama.cpp's RPC backend and MLX's distributed features are options that exist for this. They work, but they are still maturing, every token crosses the network, and performance depends on the link between nodes. Pooling memory this way extends what you can load; it does not make each request faster. Test with your own model before you commit.

Sharding needs the nodes to talk to each other. Tell us what you need and we will discuss how the machines can be connected.

Planning node count by model size

Start with memory. A 4-bit quantised model needs roughly 0.5–0.7GB per billion parameters plus room for context. macOS lets the GPU use roughly two-thirds to three-quarters of unified memory by default. That gives about 24–27GB usable on a 36GB M5 Max and about 64–72GB on a 96GB M5 Ultra.

Model (4-bit)	Approx. memory	Minimum nodes	Notes
14B	8–12GB	1 × M5 Max	Add nodes only for throughput
30–34B	18–26GB	1 × M5 Max (tight) or 1 × M5 Ultra	Ultra leaves room for long context
70B class	40–55GB	1 × M5 Ultra	Replicate for more users
100B+ class	60GB and up	2 × M5 Ultra or more	Sharding; test first

Then plan for load. A rough method:

1. Pick the smallest node that holds your model with room for context.
2. Measure tokens per second and concurrent requests on that one node.
3. Divide your peak demand by what one node handles, and round up.
4. Add one spare node if you cannot accept a slower service during restarts.

All figures are rough and depend on context length, quantisation and runtime. Our post on local LLM memory on Apple silicon goes deeper.

Render farms

For 3D work, split the frame range across nodes. Each Mac Studio renders its own frames with a Metal-capable renderer such as Blender Cycles, and writes to shared storage or uploads results when done. Frame-level splitting needs no special networking between nodes, only a way to collect output. Use M5 Max nodes for most scenes and an Ultra for scenes that need a lot of memory.

Terms and quotes

Mac Studio nodes are on 6- or 12-month terms: the M5 Max is $529/mo and the M5 Ultra $999/mo on 12 months. For several nodes, extra memory or a specific network design, ask for a quote on the contact page. For single machines, see Mac Studio M5 Ultra rental.

FAQ

Can a Mac Studio cluster pool memory for one large model?

It can, using tools such as llama.cpp's RPC backend or MLX distributed. These are still maturing and depend on the network between nodes, so test with your model first.

How many nodes do I need?

Start with the smallest node that holds your model, measure its throughput, then add nodes to meet peak demand. The table on this page gives rough starting points.

Can I mix M5 Max and M5 Ultra nodes?

Yes. A common pattern is Ultra nodes for the largest model and M5 Max nodes for smaller models or rendering.

Are Mac Studio nodes available month to month?

No. Mac Studio M5 Max and M5 Ultra are on 6- and 12-month terms.