# Host RAM ECC and EDAC: separate from GPU memory errors

Host-RAM ECC errors and GPU-memory errors belong to different devices and counters.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/host-ram-ecc-edac/
Language: en

Host-RAM ECC errors and GPU-memory errors belong to different devices and counters. A Linux EDAC message cannot automatically be called a VRAM fault. Preserve its source, memory-controller or GPU identity, and event type before correlating chronology. This prevents replacing a healthy graphics card because of another component's report while retaining evidence of a genuine host-memory problem affecting the LLM server.

## Identify the EDAC domain

The [Linux EDAC documentation](https://docs.kernel.org/next/driver-api/edac.html) defines controllers, channels, DIMMs, and error-report fields. These coordinates do not automatically identify a physical slot label without checking platform mapping. Retain the original label and complete message before simplifying a dashboard. Missing or ambiguous labels limit localization and should remain visible. Describing a server as high-RAM establishes neither ECC availability nor the reporting mechanism of its particular memory controller. Capacity and error telemetry are separate properties requiring separate inventory evidence.

## Keep GPU counters separate

[NVML device queries](https://docs.nvidia.com/deploy/nvml-api/latest/api/group__nvmlDeviceQueries.html) expose ECC information for supported GPUs. Its scope is the identified device and counter type, not a host DIMM. Unsupported API results must not become zero-error observations. With several GPUs, preserve a stable identity so a changed index after restart cannot attach an event to another device. Host and GPU memory need separate series and labels even when both use the term ECC and reside in the same physical server. Do not merge their totals into an undifferentiated memory-health number.

## Record an event explicitly

Use separate rows for distinct observations:

| Source | Object | Evidence to retain |
| --- | --- | --- |
| EDAC | Host controller/DIMM | Label, type, timestamp |
| NVML | GPU | Identity, counter scope, timestamp |
| Application | LLM request | Error, stage, request ID |

This is a recording template, not proof of causality. Similar timestamps motivate investigation but do not justify adding unrelated counters or declaring that one report caused another without further evidence and clock alignment.

## Follow the diagnostic branch

If an EDAC count increases, inspect the host-memory path and server documentation. If GPU ECC telemetry changes, investigate that GPU through supported diagnostic procedures. An application allocation failure is not automatically an ECC event; resource exhaustion is another category. Preserve pre-restart evidence where observation permits it without intervening in production. Lifecycle changes can affect counter visibility, so interpret deltas with observation boundaries and restart history. An apparent reset must not be reported as repaired hardware merely because the displayed count is lower.

## Produce a scoped conclusion

Keep complete messages, kernel and driver versions, label mapping, and counter intervals. State what is reliably localized and what needs platform-specific confirmation. Do not invent one acceptable error threshold for every system. Maintenance decisions need the relevant manufacturer's guidance and observed history. Recheck label mapping after module or placement changes: an old dashboard label does not prove the next event identifies the same physical slot. The artifact should preserve host-RAM and VRAM identity rather than conflating reliability across unrelated components.

## Related reading

[RAM and VRAM: which memory matters for an AI server?](/journal/ram-vs-vram/); [A 128 GB RAM server for LLMs: useful roles beyond VRAM](/journal/server-128gb-ram-llm/).