Former mining GPUs can sometimes become inference, rendering or batch workers. The useful question is not whether a card can execute CUDA. It is whether the complete, aged system can run an accepted workload safely, repeatedly and economically.
Ethereum completed its move away from proof-of-work in September 2022. That changed the economics of a large installed base; it did not turn every mining chassis into an AI server.
Start with an exact inventory
Record each GPU model, memory size, board vendor, firmware, hours, error history and cooling condition. Then record the motherboard, CPU, RAM, storage, PCIe slot wiring, risers, power supplies, network and enclosure.
Mixed cards may be useful as independent workers. They are harder to treat as one sharded endpoint because memory, performance and software behaviour differ.
VRAM defines the simplest model fit
Mining profitability was strongly influenced by throughput and efficiency. Inference adds a different constraint: weights, runtime overhead and active cache must fit somewhere.
Aggregate VRAM is only arithmetic. Two 24GB cards do not automatically behave like one 48GB card. A runtime may shard a suitable model across them, but that needs an explicit topology and benchmark record.
The host can become the bottleneck
Mining boards often prioritised card count over full-width PCIe links, CPU capacity and system memory. That can remain acceptable for independent long-running jobs, but it can penalise model loading, offload and communication-heavy multi-GPU work.
Replace USB risers and improvised cabling with a supportable layout before business use. Record link width and speed under load rather than assuming the slot shape proves the electrical connection.
Power and cooling need a fresh acceptance test
Do not reuse an old mining power calculation. Measure wall power, temperature, fan behaviour and stability with the intended AI workload. Inspect connectors and avoid unverified splitters or adapter chains.
An open-frame rig is not automatically appropriate for an office, customer site or shared data room. Noise, dust, physical access and fire procedures belong in the decision.
Rebuild the software trust boundary
Start with known firmware settings, a clean supported operating system and current signed drivers. Remove mining wallets, pools, remote agents and unknown startup tasks. Apply least privilege, firewall rules, patching, logging and secrets handling as you would for any production server.
The system should not receive confidential data until its provenance and configuration are understood.
Choose work that tolerates the architecture
Good candidates for evaluation include:
- independent embedding, transcription or image workers;
- rendering and frame queues;
- offline batch classification;
- a small single-GPU model per card;
- development and non-sensitive benchmarking.
Communication-heavy training, high-availability services and large sharded models may justify a purpose-built platform.
Run a go/no-go benchmark
Pin the model or application, runtime, driver and dataset. Record completed work, errors, latency or throughput, memory, wall power and temperature over a representative duration.
Compare useful work per kilowatt-hour and operator time with a current workstation, rack server and hosted option. Past hardware cost is sunk; continued operation still has an opportunity cost.
Keep the commercial conclusion honest
Repurposing is successful when the system passes the workload, safety and operating test at an acceptable cost. If it only runs after constant intervention, exposes data or blocks a more valuable service, replacement may be cheaper.
Technical context
See the physical and operating boundary
Use these views to connect the guide to the machine, its airflow and its operating environment. Captions state the limits of what each image shows.
Primary sources
Sources are checked at the review date. Platform terms, prices and public guidance can change; verify them at the point of decision.