E-Waste GPUs Benchmarked: What Actually Runs in 2026

The viral post “Benchmarking 15 ‘E-Waste’ GPUs with Modern Workloads” just hit the front page of Hacker News, and the comment section is a mess of homelabbers arguing about whether a $60 Tesla K80 can still pull its weight in 2026. Short answer: sometimes yes, sometimes catastrophically no. The interesting part is figuring out which is which – and that’s what this guide is for.

If you’ve been eyeing an e-waste GPU on eBay to run local LLMs, Whisper transcription, or Stable Diffusion at home, this walks you through reading the benchmark results honestly and picking a card that matches your actual workload.

Who this is for (and who should skip it)

You have a spare PC, a rough budget of $50-$300, and you want to run AI models locally without renting cloud time. You’re okay with a used datacenter card that arrived with dust in it. You’re fine editing a config file or two.

Skip this if you want plug-and-play, low-latency chat with a 70B model. That’s not what these cards do. Dense Llama 3.1 70B at Q4_0 spread across four P40s runs at 0.033 tokens per second – one token every thirty seconds, according to tinycomputers.io’s P40 home lab measurements. “What is 2+2?” would take over six minutes to answer. The 96GB of combined VRAM is a headline that hides a completely unusable configuration.

What the benchmark actually showed

15 cards, three workload categories (LLM, Whisper, Vision Transformer), Docker containers, then re-run as GPUs were added. Three findings from the esologic post stood out – none of them are the ones the tutorial blogs keep repeating. Prices as of the July 2026 post: decommissioned NVIDIA enterprise GPUs are one of the last remaining sources of idle VRAM. K80 with 24GB of GDDR5 sells for $60, P100-16GB for around $75, V100-16GB for under $200.

• The M60 quietly wins at Whisper. Turns out it had exceptional transcription throughput and goes for only $50 on the used market. If audio transcription is your workload, that’s the cheapest good answer available right now.
• Mixing generations backfires for LLMs. “The V100 in the mix is held back significantly by the P100s in the LLM use case,” the author noted directly. The fastest card runs at the slowest card’s speed.
• Multi-GPU LLM scaling was flat. Docs say sharding works; esologic found throughput stayed the same as more GPUs were added. The author flagged it as a probable llama.cpp configuration issue, not a hardware ceiling. More on this below.

That last point deserves one more sentence of explanation. LLM inference in llama.cpp by default uses tensor-split across GPUs, but the communication overhead on PCIe (not NVLink) can eat the gain – especially on Pascal-era cards without high-bandwidth interconnects. It’s not that multi-GPU is broken; it’s that the defaults aren’t tuned for this hardware generation.

Pick a card by workload, not by spec sheet

Numbers below are from the llama.cpp CUDA benchmark discussion on GitHub (Llama 2 7B Q4_0; pp512 = prompt processing, tg128 = token generation), cross-referenced with community reports. Prices reflect mid-2026 eBay ranges and will drift.

* P100 Llama2-7B figure: 49.66 tok/s – that’s from DatabaseMart’s Ollama 0.5.11 benchmark run, not the llama.cpp thread.

The P40 is the default recommendation for a reason. Same 24GB as a 3090 for roughly a tenth of the cost. But look at prompt processing: 1,007 vs 5,174 tokens/sec. That gap is what you experience as staring at a blank screen for three seconds before the model starts responding – on a long system prompt, that wait compounds.

Setup that actually works

Assume Ubuntu 22.04 or 24.04. Skip Windows unless you have a specific reason. Install the current NVIDIA server driver for your Ubuntu release (check the NVIDIA driver download page for the latest version – package names change between Ubuntu releases), reboot, then verify with nvidia-smi.

# After driver install and reboot, verify
nvidia-smi

# Install Ollama (wraps llama.cpp, handles multi-GPU sharding automatically)
curl -fsSL https://ollama.com/install.sh | sh

# Pull a quantized model that fits your VRAM
ollama pull llama3.1:8b-instruct-q4_K_M # ~5 GB, fits any card here
ollama run llama3.1:8b-instruct-q4_K_M

Use GGUF quants (Q4_K_M, Q5_K_M, Q8_0) even if you have headroom. The weights are stored in 4-bit or 8-bit integer format and dequantized to FP32 at runtime – this is what sidesteps Pascal’s missing BF16 hardware entirely. You don’t need native BF16 when the inference stack handles it in software.

If Ollama’s auto-sharding gives you worse-than-expected performance across multiple cards, drop to raw llama.cpp. Ollama trades control for convenience – and on multi-GPU Pascal rigs, that tradeoff sometimes hurts.

The cooling problem nobody wants to talk about

Blower card. Server chassis airflow assumed. In a 1U or 2U rack with front-to-back forced airflow, it’s fine. In a desktop tower or micro-ATX case, it’s not – the P40 has no onboard fan and depends on chassis airflow to stay within temperature limits. Same story for M40, P100, V100.

None of this is unique to e-waste cards specifically – any blower-style GPU needs chassis airflow. The difference is that consumer GPUs usually come with their own fans anyway. These don’t. So you solve it: add a case fan aimed at the card’s intake, use a server chassis, or buy an aftermarket cooler. What you don’t do is run a sustained inference job and hope ambient airflow is enough. It won’t be.

What the docs still don’t answer

Two questions the benchmarks left open. First: how much of the flat multi-GPU LLM scaling is llama.cpp misconfiguration versus PCIe bandwidth contention? The author couldn’t say – “this points to a llama.cpp configuration issue on my part. PRs always appreciated if you know what is going on here.” As of July 2026, nobody in the thread has posted a working fix.

Second: the “context tax.” The P40 decision comes down to whether you need “fits in VRAM” or “feels fast” – these old GPUs look fine on tokens/sec for short prompts, then get crushed as context and KV cache grow. There’s no clean public benchmark showing exactly where a P40 hits the cliff on a 32K prompt versus an 8K one. If you’re planning long-context work, budget an afternoon to measure your own setup before committing to the hardware.

A cheap starter build people are actually running

From the HN thread, one commenter’s rig is worth borrowing outright: 6x Tesla P4s, a Xeon E5 2696v3, 48GB DDR4, all in a micro-ATX case on a 650W PSU. Effective 48GB of GPU VRAM via llama.cpp, hitting 7-12 tokens/sec on 20-30B Q4KM dense models with 32K-64K context. Total hardware cost roughly $500 – cheaper than one used 3090, and it gets you into 30B model territory with long context.

Is it the best rig? No. Is it usable inference on your desk for pocket change? Yes.

FAQ

Is a Tesla K80 still worth $60 in 2026?

For Stable Diffusion or basic learning, maybe. For modern LLM inference, skip it – the architecture is too old for most current inference stacks, and driver support is narrowing. As of mid-2026, better options exist at similar prices.

Can I mix a modern RTX card with an old Tesla?

You can, but expect the fast card to run at the slow card’s speed for LLM inference – esologic confirmed this directly with a V100 dragged down to P100 speeds in a mixed rig. The exception: if each card handles a completely different workload (Whisper on the M60, a small LLM on a 3060), mixing is fine because they’re not synchronized on the same model. Same workload, same generation.

What’s the single best e-waste card in 2026?

LLMs solo: P40 at $150-200. Whisper: M60 at $50. Dense multi-GPU on a tight power budget: six P4s. No universal winner – which is exactly why the 15-GPU benchmark exists.

Next step: pick one card and one workload. Pull a GGUF model that fits its VRAM, run ollama run, and time your first 500 tokens. Everything else in this guide only matters after you have a real measurement from your own hardware.