A second-hand Tesla P40 can still run useful AI. In this home-server experiment, the biggest energy cost came while it was waiting.
By Sevan Safarian
Most writing about AI and energy is about hyperscale data centres. This is about the other end of the scale: one second-hand datacenter card from 2016, in a home server, running the AI of a small free app. I wanted to know what it really costs in electricity, and whether reusing old hardware for AI is the greener option or just feels like it.
These are the results of my own experiment on my own machine, not an independently replicated benchmark.
The setup
I build Fring, a free wardrobe app: you photograph a garment, a vision model fills in its details, and the app suggests outfits from what you already own. All of its AI runs on an NVIDIA Tesla P40, a Pascal card released in 2016 with 24 GB of memory, which I bought second-hand. No cloud AI API is involved.
Two models live on it permanently:
- A vision-language model (Qwen3-VL-8B-Instruct, 4-bit quantised, served by llama.cpp’s llama-server) that recognises garments, about 6.4 GB of video memory.
- A virtual try-on model (Leffa, a diffusion model) plus a background-removal model, about 8.8 GB.
The server is a home machine with a Ryzen 7 2700X. It is not dedicated to the app: it also runs my code hosting, CI and other self-hosted services, and holds a second, small GPU (a Quadro M2000). Its whole electricity bill is therefore not an AI cost.
How I measured
| Component | Method | Measured or estimated? |
|---|---|---|
| CPU package | Linux powercap interface (/sys/class/powercap/intel-rapl:0/energy_uj, which the kernel also exposes for AMD Ryzen); difference between two readings one second apart | Measured |
| GPUs | nvidia-smi --query-gpu=power.draw, sampled every second | Measured |
| Six disks (~14 W) | Manufacturer datasheets, ~2–2.5 W per 2.5-inch hard disk, less for SSDs | Estimated |
| Motherboard, memory, fans, regulators (25–45 W) | No sensor; deliberately wide range | Estimated |
| Power-supply losses | Corsair RM850x (2024, Cybenetics Gold). Independent testing by Hardware Busters reports 85.4% efficiency at 10% load, 89.5% at 20%, and about 91% at 30–50%. I use 85–90% at idle (~17% load) and 89–91% under load. The independent efficiency figures were measured at 115 V, rather than France’s approximately 230 V mains supply, so the resulting wall-power estimates should be treated as approximate. | Estimated |
| At the wall | One spot check using an inexpensive Mecheer plug-in meter, at idle with models loaded and light web containers running. The reading fell within the range below, but I did not write down the exact number. | Spot check, not a recorded measurement |
The wall figures below are therefore ranges, not single readings, and the GPU figures are GPU only.
Idle: the number that matters most
With both models loaded and nothing to do:
| Component | Power | Basis |
|---|---|---|
| CPU package | 30.8 W | Measured |
| Tesla P40, card only | 48.3 W | Measured |
| Quadro M2000, card only | 12.7 W | Measured |
| Disks, board, memory and fans | ~49 W | Estimated |
| Whole server, at the wall | 156–166 W | Estimated range |
For the whole machine running around the clock, that is 1,370–1,450 kWh a year, roughly €275–€295 at my tariff (€0.20/kWh), shared with everything else it runs. The P40 alone, idling with its models resident, draws about 48 W: some 420 kWh and about €85 a year, card only, before power-supply losses.
Under load
Recognising garments. I sent 30 consecutive recognition requests to the vision model. Each took 2.4 seconds end to end in this run (with a generous answer length; in the app’s own benchmark of 26 real photos, 1.3 seconds). During the run the P40 averaged 158 W and the CPU 47 W, which puts the whole server at roughly 290–300 W at the wall. Per request, that is about 0.2 Wh in total, of which about 0.09 Wh is the extra cost above idle.
Rendering a virtual try-on. One 20-step Leffa render took 86.7 seconds. The P40 averaged 207 W (peaking at 236 W, close to its 250 W limit) and the CPU 48 W: about 350–355 W at the wall. That is roughly 8.5 Wh per render in total, about 4.5 Wh above idle.
The trap that nearly made it pointless
For a month, every try-on took about 21 minutes, not 87 seconds. The model had been loaded in fp16, half precision, because “use fp16 to save memory” is the default advice everywhere. It is good advice on recent cards. On this one it is not: on paper, a Pascal card of this generation (compute capability 6.1) executes 2 fp16 operations per clock cycle and per multiprocessor, against 128 in fp32, so 1/64 of the throughput (NVIDIA CUDA C Programming Guide, arithmetic instruction throughput).
What I observed on a full render is a different number from that theoretical ratio. With the same inputs and the same seed, a render took 1,241 seconds in fp16 and 85 seconds in fp32, about 14.6 times faster in fp32, with practically identical images (a mean difference of 0.77/255 per pixel). The memory saving fp16 bought was worthless: the card was nowhere near full. I did not measure power during the fp16 runs, so this is a runtime ratio, not an energy ratio.
The lesson is not specific to this card. On old hardware, measure before applying the usual advice.
What the old hardware forces you to give up
The P40 is being pushed out by software, not by wear. Working hardware also depends on the software it can continue to run, part of the wider right-to-repair discussion.
- NVIDIA’s R580 driver branch is the last to support Pascal, and CUDA 12.x is the last toolkit generation that does (NVIDIA architecture matrix). CUDA 13 removes offline compilation for these older architectures, although already-built applications can keep working (NVIDIA CUDA 13 announcement).
- From PyTorch 2.8, the official builds for CUDA 12.8 and 12.9 no longer include Pascal kernels (PyTorch announcement). Other builds still do; my try-on service stays pinned to an older PyTorch.
- Some modern serving engines are out of reach: vLLM, for example, currently requires compute capability 7.5 or higher.
- Current Ollama releases need driver 570 or newer for Pascal cards, above the 550 driver my distribution ships (Ollama GPU guidance). I moved to llama.cpp, which still supports these cards, and in my benchmark it turned out faster (1.3 instead of 2.9 seconds per photo) and lighter (6.4 instead of 7.6 GB).
In practice, that means a frozen software target: no driver past R580, PyTorch pinned to builds that still carry Pascal kernels, no bf16, and any new model has to fit those constraints. It works, but each year fewer things will.
Is it actually greener?
I can’t give a verdict, and I’d rather say why.
Over the last 30 days the app ran 148 garment recognitions and no try-on renders in production. At about 0.09 Wh each above idle, that is roughly 13 Wh of actual AI work in a month. Over the same month, the P40 idling with its models loaded drew about 35 kWh, card only. For a small app, idle power dominates the AI work by three orders of magnitude. The card’s efficiency per task barely matters; the fact that it is switched on all the time does.
What I can say:
- I bought a used card instead of a new one. That alone doesn’t prove one fewer card was manufactured, and I have no lifecycle figure for a P40’s embodied emissions, so I won’t put a number on what was avoided. This is a key consideration when assessing refurbished electronics and e-waste.
- It keeps users’ photos off a cloud API, which is a privacy argument more than an environmental one.
What I cannot say:
- That it uses less electricity than a newer card. A recent, more efficient GPU would likely idle lower and finish each task faster. I have not measured one.
- That it beats a cloud API per request. Large providers batch requests across many users and run newer hardware; my card serves one small app and spends nearly all its time waiting.
Without a matched alternative and lifecycle data, “greener” would be a guess. If I wanted to reduce the footprint for real, the lever would not be the model or the precision. It would be idle: unloading the models when nobody is using the app, or sharing the card with more work. Both have costs (a cold start of a minute or more for the try-on model), and for now I have chosen responsiveness over idle savings. That is a trade-off, and it should be described as one.
What I’d tell someone considering the same thing
Measure the whole server at the wall, not just the GPU. Count idle time, because for a small service it is most of the bill. Check the software support horizon of the card before you build on it. And don’t apply the usual advice without testing it on your hardware: on mine, the standard memory-saving setting made every render about fourteen times slower.
Sevan Safarian is an independent developer in France who builds Fring, a free wardrobe app that helps people wear what they already own. All of its AI runs on second-hand hardware in a home server. His longer technical write-up includes the fp16/fp32 measurements. This article was drafted with the help of an AI assistant from his own measurements and notes, and reviewed before submission.
Featured photograph: electronic circuit board, illustrative rather than the author’s Tesla P40. Photo by Umberto / Unsplash.