One machine can be run on attention. You know its price, its quirks, its power draw, and you glance at the dashboard while your coffee brews. Somewhere between machine three and machine five, that stops working, and the habits that made your first rig profitable start quietly costing you money. Here is what breaks at fleet scale, and the playbook that replaces attention with process.
What breaks between one machine and five
Scaling problems in GPU hosting are rarely dramatic. They are multiplication problems:
- Per-machine babysitting stops scaling. If checking one machine's price and status takes five minutes three times a day, five machines take over an hour daily. The usual response is not more discipline, it is silently checking less, which means problems live longer.
- Settings drift apart. Machine two got a different price floor because electricity felt more expensive that month. Machine four still has the region filter you were experimenting with in March. Nobody decided the fleet should be inconsistent; it happened one reasonable tweak at a time, and now no two machines behave alike or can be compared.
- Nothing tells you when something breaks. With one machine you notice an outage because you look often. With five, a rig can sit offline or mispriced for a day before your rotation reaches it. Silent downtime is the most expensive kind, because every idle hour is revenue that expires on the spot.
The pattern behind all three: at fleet scale, anything that depends on you remembering to look is already failing. The playbook below removes the looking.
Step 1: uniform base settings, deliberate exceptions
Pick one baseline configuration and apply it to every machine: strategy, bid offset, region filter, interruptible discount, notification preferences. Write it down, even if only in a text file. The point is not that every machine must be identical forever. The point is that every difference from the baseline should be a decision you can name, not sediment.
Uniformity also makes results legible. When five machines run the same strategy, the one that underperforms is telling you something about its hardware or its market, not about a forgotten setting. Fleet-wide controls help here: in GPU Autopilot you can select multiple machines and apply a setting such as Max Price to the whole selection at once, instead of editing rigs one at a time and hoping you typed the same number five times.
Step 2: per-machine floors from per-machine power costs
The one setting that legitimately differs per machine is the price floor, because it should be derived from that machine's real costs, and those differ. A 4-GPU server with a datacenter overhead multiplier does not break even at the same hourly rate as a repurposed desktop with one card. Compute each floor:
- 1Get each machine's true power draw: GPU TDPs plus system overhead. Capping power helps here; most cards lose little rental performance at 80% power. See the NVIDIA power limit guide in our open source Linux tools collection.
- 2Multiply by your electricity rate to get an hourly cost per machine. The Power Cost Calculator does this arithmetic for you: rate in $/kWh, system-type overhead, per-GPU TDP presets, and it outputs hourly, daily, and monthly cost.
- 3Set each machine's floor at or above its hourly cost. The floor is the number automation never crosses, so it is the one place where per-machine precision pays.
The full break-even method, including hardware payback, is in how to set your price floor.
Step 3: notifications instead of dashboard-watching
Dashboard-watching is polling, and you are a slow, expensive poller. Invert the model: configure alerts so events come to you, and treat an empty notification feed as evidence things are fine. Route rentals starting and ending, price changes, errors, and scheduler events to Discord or Telegram, and tune the per-event preferences so the feed stays meaningful. An error alert should interrupt your day; a routine price change should not.
Setup details for both channels are in the Discord and Telegram alerts guide.
Step 4: a weekly review of the activity log
Automation without review becomes a black box you stop understanding. Replace daily babysitting with one scheduled weekly pass over the activity log, where every pricing decision is recorded with its market context. Twenty minutes covers a five-machine fleet if you look for patterns rather than reading every line:
- A machine logging Held at its floor for days means the market for that GPU type is clearing below your costs. That is a hardware or power problem, not a pricing one.
- Repeated Failed entries point at API or machine issues worth fixing before the weekend.
- Compare Rented frequency across machines with identical settings. The laggard has a story: worse reliability score, worse network, wrong region filter.
Put it on the calendar
Scale the machines, not the hours
The goal of this playbook is that machine six costs you a floor calculation and a baseline application, not another daily chore. Uniform settings make the fleet comparable, per-machine floors keep every rig above water, notifications replace polling, and the weekly review keeps you in command of what the automation does in your name. Growth then becomes a hardware and capital question, which is the question you actually wanted.
Two good next reads: more machines on the public internet means more attack surface, covered in SSH security for GPU hosts, and choosing how hard each part of the fleet competes is covered in strategy modes. The Vast.ai side of multi-machine operation is documented at docs.vast.ai.