AI hardware ROI for an edge or SBC AI fleet: depreciation and resale value

Somewhere there's a supply closet of Raspberry Pis and USB accelerators, pulled off shelves years early. Nothing broke. The vision model outgrew the accelerator's memory, the driver stack stopped updating, and boards that power on fine can't do the job anymore. That's the failure this piece exists to head off: treating depreciation as an engineering promise, not an accounting convention.

The fleet here is edge or SBC class: Raspberry Pis, mini PCs, cameras, accelerators, storage, and a management node, running always-on sensing, OCR, vision, voice, smart-home control, or automation near the data source. The alternative is cloud processing, one central server, or deterministic sensors with no model. You're paying for low per-node power, local response, less data leaving the building, and placement next to what you're sensing, the dollar side of the local-versus-cloud argument covered in local-first-cascade. The real unit is one reliable edge decision, not a token or accelerator-hour.

count every dollar the fleet actually touches

Start from one relationship and don't skip past it:

annual_capital_cost = (installed_capex - conservative_resale) / useful_years

Model early replacement and conservative resale apart from your accountant's depreciation, not the same number. Split fixed from variable: hardware, installation, and reserved capacity are fixed, electricity, tokens, transfer, and support move with usage. Human review sits on both sides, a dedicated operator is fixed, a per-exception queue is variable.

The bill of materials needs accelerator through enclosure, spares, tax, shipping, installation, minus whatever the org would buy anyway. A laptop your engineer already uses isn't an AI cost; a memory upgrade bought just to fit the model is, in full.

Measure local, rented, and API routes, logging the same fields for each:

• accepted tasks against severe failures
• input, cached input, reasoning, output volume
• retries, abstentions, human repair minutes
• queue, first token, completion, p95 latency
• active, resident-idle, sleep, unavailable hours
• energy, cooling, maintenance, and incident time

Adjust for quality first: a cheap model needing two attempts and five minutes of correction has its real cost attached to the finished result, not the first pass. Run it the other way too: a local specialist on one narrow task shouldn't be priced against a frontier API running flat out.

where the payback math quietly breaks

The bigger risk isn't the hardware, it's what a fleet costs in attention: maintenance times node count, storage failures, installation labor, accelerators stranded by a dead driver, units stuck at prototype status. Build low, base, and high demand curves with daily peaks and p95 latency baked in; a fully scheduled device can't also absorb an interactive request. Batch work fills the gaps, but only if the org has it to give.

Meter idle states: a device sleeping overnight has different economics than one holding a model resident for instant response. On shared systems, watch queueing and abandoned requests, not just throughput. On an edge fleet, multiply update, replacement, backup, and travel time by node count; operational labor dominates the bill, not electricity. The recurring mistake: a long depreciation schedule isn't proof the accelerator stays competitive. It proves nothing except how your accountant amortizes. Keep assumptions in a small table with a source and date on every number that moves.

Payback month is the first month cumulative discounted benefit passes cumulative cost, ROI over your horizon is net discounted benefit over discounted cost. Both need a conservative useful life and residual value: hardware stays functional after model growth or dropped support makes it dead weight.

Productivity gains need a realization factor. Saving ten minutes of developer time isn't ten minutes of billable revenue; it counts only if it avoids a hire, cuts outsourced spend, increases what ships, or shortens a binding queue. Run it once with productivity at zero. If it clears the bar on speculative savings alone, treat that as a warning.

Weigh renting against buying and against the API. If either still looks attractive once the worksheet's filled in, reread subscription-wrong-for-ai first. Hourly rental earns its keep while demand and hardware shape stay uncertain, but price in storage, image prep, transfer, minimum billing, and idle forgotten instances.

Base ROI on whichever is shorter, financial life or workload-relevant technical life. State the break-even boundary: tasks per month, productive GPU hours, a maximum API cost per task, a minimum useful life. That kind of number can be revisited; a narrative recommendation can't. Set a retest date and triggers: volume shifts materially, a model changes your quality gate, API prices move, electricity contracts change, or a component ages out of support. None of it lives on the GPU; it's a relationship between one workload, one alternative, and dated assumptions.

The rule I'd keep if I dropped every other line here: never let a device's useful life outlive the software's willingness to run on it.