Mac mini fleets

Shelving and racking

A Mac mini is small and light, so most fleets sit on open wire shelving or in rack shelves rather than in purpose built enclosures. What matters is air: a Mac mini draws air in at its base and exhausts it at the back (check the vents on your model). Keep the base off solid, closed surfaces (a wire shelf or small risers work), leave the back clear, and do not stack Macs directly on top of each other.

Put each Mac where you can reach its power button and its Ethernet port, label each one with the device name it shows on the Nodes page, and run cables so one Mac can come out without unplugging its neighbors.

Power on by itself

A node that stays down after a power cut earns nothing until someone visits it. In System Settings, Energy, turn on starting up automatically after a power failure, and stop the Mac from sleeping. The same from a terminal:

# start up again after a power failure, and never sleep the systemsudo pmset -a autorestart 1sudo pmset -a sleep 0 # check what is setpmset -g

Then make the engine start at login with a launch agent (label com.silicon.engine), and turn on automatic login for the user that runs it, so the engine comes back without a keyboard.

Power and cooling

Apple publishes the idle and maximum power draw and the heat output of each Mac mini model (search support.apple.com for Mac mini power consumption and thermal output). Plan circuits and cooling on the maximum. While serving, the engine reads the live draw and GPU temperature from the system (macmon) and shows them on the node UI's Network page as the availability readings.

Heat

Every watt a Mac draws ends up as heat in the room. To size cooling, convert watts to BTU per hour:

heat (BTU/h) = watts x 3.412 Example (assumed: 10 Macs at a 140 W planning figure each)  1,400 W x 3.412 = 4,777 BTU/h

Add the switch, the router and anything else in the room. A closet with a door and no air exchange heats up fast; give it an exhaust fan or put the fleet where the building's cooling reaches.

Thermal limits the engine enforces

A node can stop taking network work when it runs hot, and resume when it has cooled. Both live in the node's settings (limits):

A limit without its reading is not enforced, and the Network page says so in a note. While paused, requests already running finish and the node is routed nothing new.

How many Macs per circuit

A circuit should not carry more than 80% of its rating as a continuous load (the US electrical code's rule; many electricians keep the same margin elsewhere). A fleet that serves around the clock is a continuous load.

Macs per circuit = (circuit amps x volts x 0.8) / watts per Mac                   rounded down, after subtracting the switch and anything else on the circuit Example (assumed: 140 W per Mac as the planning figure)  US 15 A, 120 V:  15 x 120 x 0.8 = 1,440 W   1,440 / 140 = 10.3  ->  10 Macs  US 20 A, 120 V:  20 x 120 x 0.8 = 1,920 W   1,920 / 140 = 13.7  ->  13 Macs  EU 16 A, 230 V:  16 x 230 x 0.8 = 2,944 W   2,944 / 140 = 21.0  ->  21 Macs

Network

Use wired Ethernet for every Mac. Wi-Fi adds latency and jitter to every streamed token, and a fleet of Macs on one access point competes for the same air.

Nothing is opened inbound. With the relay on (the default), each node holds one outbound WebSocket to the relay over port 443, and the gateway reaches the node through it. That works behind NAT, behind a home router and behind carrier grade NAT, with no port forwarding. Turn the relay off only for a node with a public HTTPS address of its own.

Upload carries the answers

Prompts arrive on your download side and answers leave on your upload side. A streamed chat answer is small: one server sent event per token. Images, speech and embeddings answers are much larger per request. Upload is usually the scarcer direction on home and small office lines, so check it before you add Macs.

Download carries the models

Each Mac downloads its own copy of the weights it serves, so ten Macs loading the same model download it ten times. Cap the rate per Mac with the downloads settings: max_mbps (1 to 10000 megabits per second) and first_only, which holds the cap only until the Mac's first complete model is on disk.

upload per Mac (bit/s) = concurrent streams x tokens per second x bytes per event x 8download time (s)      = model size in GB x 8,000 / line speed in Mbit/s Example (assumed: 4 streams per Mac, 40 tokens per second each, 250 bytes per event)  4 x 40 x 250 x 8 = 320,000 bit/s = 0.32 Mbit/s per Mac  10 Macs: 3.2 Mbit/s of upload for chat streams alone Example (assumed: a 4.5 GB model on a 100 Mbit/s line)  4.5 x 8,000 / 100 = 360 s per Mac; 10 Macs one after another: 1 hour

Cost per token

Power is the running cost a fleet controls. Work it out per 1M tokens, so it compares directly with what 1M tokens earns.

hours per 1M tokens       = 1,000,000 / (tokens per second x 3600)power cost per 1M tokens  = watts / 1000 x hours per 1M tokens x price per kWhearnings per 1M output    = output price per 1M x operator share Example (assumed: 60 W while serving, 40 tokens per second, $0.20 per kWh,         a model billed at the default $1.50 per 1M completion tokens)  hours per 1M tokens      = 1,000,000 / (40 x 3600) = 6.94 h  power cost per 1M tokens = 60 / 1000 x 6.94 x 0.20 = $0.083  earnings per 1M output   = 1.50 x 0.70 = $1.05

The operator share is 70% of what the customer's balance covered for the work your Macs served (a marketplace listing can set its own share). A model without a price row bills at $0.50 per 1M prompt tokens and $1.50 per 1M completion tokens; most models have their own rates on /pricing, so use those. Prompt tokens earn too; the example leaves them out.

Payback

A Mac pays for itself only from the hours it serves paid work, and that depends on demand, not on how fast the Mac is. The network's paid tokens of the last 7 days are what the operator guide's estimator uses for its demand range; when there was no paid traffic, it says so and shows zero. The estimator on the download page runs these formulas for one Mac, with the busy share as your input.

monthly earnings   = paid output tokens per month / 1,000,000 x earnings per 1M outputmonthly power cost = average watts / 1000 x hours in the month x price per kWhpayback (months)   = hardware cost / (monthly earnings - monthly power cost) Example (assumed: $1,400 per Mac, paid work 6 hours a day at 40 tokens per second,         60 W serving and 5 W idle, $0.20 per kWh, 30 days, earnings $1.05 per 1M output)  paid output tokens   = 40 x 3600 x 6 x 30 = 25.92M  monthly earnings     = 25.92 x 1.05 = $27.22  monthly power cost   = (60 x 6 + 5 x 18) / 1000 x 30 x 0.20 = $2.70  payback              = 1,400 / (27.22 - 2.70) = 57 months

When monthly earnings do not exceed monthly power cost, the Mac never pays back. Double the paid hours and the same Mac pays back in about half the time; demand moves the answer more than any hardware choice.

Running the engine on each Mac

Every Mac runs its own engine and joins as its own node, with its own credential. (Several Macs can instead form a cluster that shards a large model and joins as one node: see Clusters.)

Install

The engine runs from its source release on each Mac. You need uv, Rust and Xcode's Metal toolchain. Give each Mac its own long SILICON_API_KEY, kept in ~/.silicon/engine.env (mode 600) for the launch agent rather than on the command line.

# the newest engine release, checked against its SHA256SUMSV=$(curl -fsS https://www.siliconnetwork.io/releases/latest/version)curl -fsSLO https://www.siliconnetwork.io/releases/v$V/silicon-engine-$V-source.tar.gzcurl -fsSLO https://www.siliconnetwork.io/releases/v$V/SHA256SUMSgrep " silicon-engine-$V-source.tar.gz$" SHA256SUMS | shasum -a 256 -ctar -xzf silicon-engine-$V-source.tar.gz && cd silicon-engine-$V # once, on macOSxcodebuild -downloadComponent MetalToolchain # run it; --extra mlx is required on a Mac (the dashboard comes built)SILICON_API_KEY=choose-a-long-secret uv run --extra mlx silicon

Join with device sign-in

On each Mac, open http://localhost:52415/network (or the menu bar app) and choose Sign in and join. Approve the code on the dashboard, checking that it matches the one on that Mac. For Macs without a screen, use Screen Sharing, or mint a node credential on the Nodes page for each Mac (it starts with snop_ and is shown once) and set it as SILICON_OPERATOR_CREDENTIAL. One credential per Mac means you can revoke one Mac without touching the rest.

Settings on each Mac

The node settings live in node_settings.json in the engine's config directory and are kept when the node leaves. The node UI's Network and Downloads pages edit them, and so does the engine API:

PUT http://localhost:52415/v1/network/settingsAuthorization: Bearer $SILICON_API_KEY {  "schedule":  {"mode": "always", "on_power_only": false},  "limits":    {"max_gpu_temp_c": 95, "max_power_w": null, "pause_on_thermal_pressure": true},  "downloads": {"max_mbps": 200, "first_only": false}}

A dedicated serving Mac usually wants mode: always. The availability readings on the same page say why a node is paused: outside_hours, in_use, cpu_busy, too_hot, over_power, on_battery, battery_low or thermal_pressure.

Fleet tools

The fleet view on the dashboard, Nodes, Fleet, lists every node of your organization with its device, chip, memory, region, status, engine version, models, group and whether it is paused. Every member sees it; owners and admins can change it.

A bulk change names up to 500 nodes, or every node of a group, and applies to all of them or to none. Owners and admins of the organization receive a notification when a node has sent no heartbeat for 10 minutes, and another when it is back online.

The node UI's Network page on each Mac shows when pushed settings apply, and its Health page shows requests served, failed and refused, recent errors and verification results.

Checklist