Do you need ECC for a home LLM server?

Get ECC when a job on that machine would hurt to lose halfway through. Skip it when the job is cheap to rerun. That's the whole rule: it hinges on whether an interrupted or silently wrong run costs more in wasted hours than the memory premium costs, not on how important the workload feels.

the same box, two different risk profiles

My reference point: a workstation serving local inference to a small team, nothing exotic, no lab conditions, not representative of every machine you'd build. ECC guards against one specific failure: a bit flip in memory mid-run. On interactive chat or code completion, a flip usually shows up as a crash or a wrong token, and the fix is hitting enter again. On an overnight fine-tune, a document-extraction batch, or a persistent vector store nothing re-validates, the same flip can quietly corrupt state that gets trusted for weeks. ECC being good isn't in dispute; what decides the purchase is whether your workload has stretches where nobody's watching and the state is expensive to rebuild.

Write the job down first: interactive chat, code completion, document extraction, or an overnight batch. Decide what a good result looks like before touching a setting. That answer tells you whether you need ECC before you've spent a cent.

how I'd actually test that, not guess it

Once the workload is separated from the vibes, testing any change (ECC, offload setting, driver update) uses the same discipline. Same inputs every run, launch command saved with the result. Include a cold start when a human will hit one, repeat long enough to expose heat or queueing, and log output quality next to the numbers, not just whether it loaded. One warm sample tells you nothing your gut didn't already assume.

Record only the numbers that could flip the decision: time to first token, prompt-processing speed, generation speed, peak memory, wall power when it matters, and whether the task succeeded. Medians describe the normal case; a slow percentile, p95 not the average, describes the pauses that make people quietly stop trusting the setup.

workload:      one named, repeatable task
inputs:        fixed and versioned
quality gate:  pass / fail / abstain
latency:       cold, warm, and p95
resources:     memory, power, disk
decision:      keep, revert, or retest

where this turns into superstition

The specific trap with ECC is treating it as a purity test instead of pricing the alternative: retries and corrupted state against a memory upcharge. "It loaded" is not a performance result. "The answer looked fine" is not an evaluation of anything. Check runtime logs and operating-system metrics instead of trusting a flag you set once. When two configurations disagree, change one variable and say why you expect the difference. Otherwise you're just collecting anecdotes with a spreadsheet attached.

There's a maintenance cost too. A fragile five-percent win, ECC-related or not, evaporates the next time a model, driver, or runtime updates, so keep the test cheap: a small script, a handful of representative prompts, a plain-text result file. That's enough to retest after every upgrade without standing up an observability stack, and it holds for setups like homelab-llm-server.

My rule stays simple. Pay for ECC on the box running long or unattended jobs, where a silent error has time to compound before anyone notices, the kind of run in h100-overnight-batch. Skip it on the interactive box you're happy to restart. Test the smallest plausible change first, keep headroom for the next model you'll want to try, and stop tuning once the workflow hits its latency and quality target.

If you're not sure which category your machine falls into, that's the next step: count how many of this month's runs sat unattended for more than a few minutes, then price out what it would have cost you not to notice if one of them went wrong.