AI hardware ROI for an edge or SBC AI fleet: comparing the complete purchase price
Before you spec a single board or accelerator, write down the number that settles the purchase: incremental installed cost per accepted task, against the cheapest workable alternative, with a break-even stated in operational terms you recheck monthly. Everything below argues for why that number has to include the stuff you'd rather leave off the invoice.
Every node you don't buy twice
An edge or SBC fleet means unglamorous parts: a Raspberry Pi or Orange Pi, a mini PC, cameras, an accelerator card, storage, an enclosure, a power supply, a management node. The job is always-on and local: sensing, OCR, vision, voice, smart-home glue, narrow automation that has to happen at the data, since shipping it to a cloud endpoint or running a central server defeats the point of a local-first cascade. So does swapping in deterministic sensors and rules, the real competitor here. The payoff, if there is one: low per-node power, a local response, less data leaving the building, hardware next to whatever it watches. Price it as one reliable edge decision, not a token or an accelerator-hour. Installed cost is compute, host, memory, storage, power, cooling, network, tax, and setup, the same cost architecture as any inference budget, minus whatever you'd buy anyway: a shared laptop stays off the ledger, a memory stick bought only to fit the model doesn't. Split the rest into fixed cost (hardware, install, reserved capacity) and variable cost (electricity, tokens, transfer, human review), fixed if dedicated, variable if per-exception. Track acceptance and failure rates, repair minutes, tail latency, and active, idle, asleep, or down hours per node. A model needing two attempts and a five-minute human fix isn't cheap: its cost belongs to the finished result.
The unit that never left prototype status
The failure mode that eats budgets isn't the chips. Maintenance is. It scales with node count: storage that fails quietly, installation labor, an accelerator fragmented across SKUs, a board meant to ship that instead sits on a desk as a permanent prototype. Build a low, base, and high demand case, and watch the daily peak and tail latency: a box running flat out has no headroom for an interactive request. Batch work can fill quiet hours, but only if it would genuinely happen anyway. Idle states matter: a workstation asleep overnight and a server holding models resident for instant response are different animals, and confusing them is how a spreadsheet lies. On shared systems, watch queueing and abandoned requests; on a fleet, multiply update, replacement, backup, and travel time by node count, since labor scales and electricity doesn't. The comparison that quietly poisons these numbers: a bare used GPU against a finished computer or a turnkey cloud endpoint. Keep assumptions in a small table with a source and a date, and resist hiding uncertainty behind false decimal precision.
Numbers you can recheck beat a recommendation you have to defend forever.
Where the break-even line actually sits (hardwareroi)
Payback is the month cumulative discounted benefit clears cumulative cost; ROI over the horizon is net discounted benefit over discounted cost, both only as honest as your useful-life and residual-value assumptions. Hardware can run fine and still go economically obsolete once a model or support cycle ends. Productivity gains need a realization factor: ten minutes saved isn't automatically ten minutes of revenue, only if it avoids a hire, cuts outsourced spend, raises output, or shortens a binding queue. Run the model once with that term at zero: a purchase surviving only on speculative time savings is a warning sign. Weigh rental against buying and API calls: hourly GPU rental earns its keep while the workload's shape is unsure, provided you count persistent storage, image prep, transfer, minimum billing, and the instance somebody forgot to shut down. A short rental trial often beats an expensive wrong purchase. Set a retest date: volume moving materially, a model swap shifting the quality gate, API prices changing, an electricity contract renewing, a component reaching end of support.
The rule I'd keep, stated flat: price the incremental installed cost of the workload against its real alternative, and write the break-even as an operational number, accepted tasks per month, GPU hours, or cost per API task, never as a story you tell once and stop revisiting.