1. ECC功能概述
2. ECC记录的内容
3. ECC记录存储的位置
3.1. 实时计数（易失性 & 聚合性）
3.2. 系统级持久化日志
3.3. 硬件层面（有限且不直接面向用户）
4. 并不是所有NVIDIA GPU均支持ECC
4.1. 产品线严格区分
4.2. 成本与定价考量
5. ECC查询、清零与开关
5.1. 查询ECC记录
5.2. ECC计数清零
5.3. ECC模式开启与关闭
6. 典型场景与处理建议
7. ECC注意事项
8. 实践：检测到无法纠正的ECC错误——GPU需要重置
8.1. 概述
8.2. 症状
8.3. 解决方法
1. ECC功能概述
H100、H200等GPU模组的ECC（Error Correction Code，错误纠正码）记录是指GPU在运行过程中检测、记录和纠正内存错误的相关数据。ECC的作用与重要性如下：
作用：ECC是HBM（高带宽内存）中的纠错机制，用于检测和纠正单比特错误（Single-Bit Errors），并检测多比特错误（Multi-Bit Errors），确保计算精度和数据完整性；重要性：在HPC、AI训练等场景中，ECC可防止因内存错误导致的计算错误或系统崩溃。
在进行GPU卡与模组的维修、检验时，ECC记录可以作为重要的评估参考信息。
2. ECC记录的内容
1）单比特错误纠正：
GPU自动纠正HBM中的单比特错误，并记录错误计数。可通过NVML（NVIDIA管理库）或nvidia-smi命令查询。
2）多比特错误检测：
ECC无法纠正多比特错误，但会记录事件并可能触发系统警报。
3）错误类型分类：
Volatile ECC错误：易失性错误，GPU重启后计数清零。Aggregate ECC错误：GPU生命周期内累积的聚合性错误（需手动重置计数）。
3. ECC记录存储的位置
H100、H200 GPU（以及整个NVIDIA现代数据中心GPU系列）的ECC记录存储在多个地方，可以分为实时计数和持久化日志两大类。
3.1. 实时计数（易失性 & 聚合性）
这部分是GPU硬件和驱动直接维护的计数器，可以通过nvidia-smi或NVML API实时查询。
1）存储位置：这些计数直接存储在GPU芯片内部的内存控制器和寄存器中。
2）两种类型：
易失性计数：记录自上次GPU驱动加载/重新初始化以来的错误数量。GPU完全断电重启或驱动重新加载后，此计数会清零。聚合计数：记录自上一次手动重置以来，在GPU整个运行生命周期内累积的错误数量。它不会因系统重启而清零，必须通过管理命令（如 nvidia-smi --reset-ecc-errors）或有权限的API调用来清除。
3）访问方式：
nvidia-smi -q -d ECC# 或更具体的查询nvidia-smi --query-gpu=ecc.errors.corrected.aggregate.device_memory --format=csv
可以使用nvidia-smi -i -n查看指定GPU卡的信息（n表示GPU卡在设备中的编号，如0、1、2等）。
nvidia-smi -i0-q-d ecc==============NVSMI LOG==============Timestamp : Mon May 2713:55:22 2024Driver Version :535.104.05CUDA Version :12.2Attached GPUs :2GPU 00000000:3B:00.0 ECC Mode Current : Enabled Pending : Enabled ECC Errors Volatile SRAM Correctable :0 SRAM Uncorrectable :0 DRAM Correctable :0 DRAM Uncorrectable :0 Aggregate SRAM Correctable :0 SRAM Uncorrectable :0 DRAM Correctable :0 DRAM Uncorrectable :0
3.2. 系统级持久化日志
为了进行长期健康分析、预警和故障排查，必须将这些实时计数与其他系统事件一起记录下来。
1）操作系统系统日志：
Linux：通常通过NVIDIA GPU驱动的内核模块写入到 /var/log/syslog 或 journalctl 中。当发生严重的、不可纠正的ECC错误或其他GPU故障时，驱动会生成带有 NVRM 或 kernel 标签的日志条目。
2）NVIDIA驱动日志：
位置通常在 /var/log/nvidia-* 目录下（例如 nvidia-installer.log, nvidia-bug-report.log）。nvidia-bug-report.log 是在生成诊断报告时创建的，会包含某一时刻完整的ECC状态快照。
3）服务器管理控制器日志：
对于像H200这样的模组，它通常是安装在DGX系统、HGX平台或品牌服务器（如戴尔、惠普、联想） 中的。这些服务器的BMC（基板管理控制器） 或 iDRAC/iLO/XCC会通过IPMI或其他协议监控PCIe设备健康状态。关键点：某些严重的GPU错误（如导致GPU卡重置或宕机的致命ECC错误）会被主机的事件日志记录，并传递给BMC，写入到BMC的 持久化系统事件日志中。即使主机操作系统崩溃，这个日志仍然保留。这是进行远程诊断和硬件保修索赔的重要依据。
4）第三方监控和集群管理工具：
DCGM（NVIDIA Data Center GPU Manager）：这是NVIDIA官方推荐的监控工具。DCGM代理会定期（可配置）轮询所有GPU的ECC计数、性能指标和健康状态，并将其发送到DCGM Exporter或直接存储到时间序列数据库（如 Prometheus、 InfluxDB、 Grafana）中。DCGM可以配置为在ECC错误率超过阈值时触发警报。这是生产环境中集中化、持久化存储和可视化ECC历史记录最常用的方法。
5）特定系统和云平台工具：
NVIDIA DGX系统：有专门的DGX OS和Base Command Manager，它们集成了更完善的日志和监控系统。云服务商（如AWS、Azure、GCP）：如果使用搭载H100、H200等的云实例，云平台的控制台通常会提供自己的GPU健康监控视图和日志，底层可能也基于DCGM。
3.3. 硬件层面（有限且不直接面向用户）
GPU内部可能有少量的非易失性存储（如寄存器或Flash的某个小分区）用于记录最严重的错误事件，但这些信息通常不直接开放给用户读取。
当GPU被返厂进行失效分析时，NVIDIA工程师可以使用内部工具和接口，从芯片和固件中提取更详细、更低层的错误诊断信息，这比用户可访问的计数要详细得多。
4. 并不是所有NVIDIA GPU均支持ECC
核心原因：市场定位与成本控制
4.1. 产品线严格区分
GeForce RTX：定位为消费级市场，主要面向游戏玩家、创作者和发烧友。其设计核心是极致性价比和峰值性能，所有功能都为此服务。
NVIDIA RTX / Data Center GPU（如H200, A100, L40S）：定位为专业计算和数据中心市场。其核心是极致可靠性、数据完整性和稳定性，为此不惜成本和功耗。ECC是这类产品的强制性、基础性功能。
NVIDIA RTX 6000 Ada Generation是与RTX 4090同代（Ada Lovelace架构）的专业可视化显卡。它使用带ECC的GDDR6显存，驱动经过ISV认证，完全支持ECC功能和管理。这是追求稳定性的正确选择，但价格是RTX 4090的数倍。2025年12月19日刚刚发布的RTX Pro 5000，同时在规格说明中，明确说明支持ECC：
4.2. 成本与定价考量
1）支持ECC需要：
显存颗粒本身支持ECC（通常更贵）。
额外的内存控制器和芯片逻辑来实现检错和纠错，这会增加晶体管数量和芯片复杂度。
功耗和性能的微小代价（ECC会引入少量延迟和功耗）。
2）对于消费级市场，每增加一美元成本都会影响其巨大的销量和竞争地位。NVIDIA会严格砍掉所有对游戏/创作“非必要”的功能来控制成本。
5. ECC查询、清零与开关
5.1. 查询ECC记录
1）使用 nvidia-smi 命令：
nvidia-smi --query-gpu=ecc.errors.corrected.volatile.device_memory, ecc.errors.uncorrected.volatile.device_memory, ecc.errors.corrected.aggregate.device_memory, ecc.errors.uncorrected.aggregate.device_memory --format=csv
2）使用NVML API：通过编程方式获取ECC计数（适用于监控系统）。
5.2. ECC计数清零
ECC计数不会因系统重启而清零，可以使用nvidia-smi --reset-ecc-errors进行清零：
重置目标 GPU 的 ECC 错误计数器。可选参数为0|VOLATILE（易失性计数）或1|AGGREGATE（聚合性计数）。此操作需要root权限。除非使用 -i 参数指定单个 GPU，否则将影响所有 GPU。该操作的效果是即时生效的。5.3. ECC模式开启与关闭
开启或关闭ECC功能的命令为nvidia-smi -i -n -e 0|1，开启（1）或关闭（0）第n号GPU卡的ECC模式，重启后配置生效。
6. 典型场景与处理建议
1）典型场景建议：
偶发单比特错误：通常由宇宙射线、电路噪声等环境因素引起，GPU会自动纠正，无需立即处理。
频繁单比特错误：可能预示硬件故障（如HBM或显存模块问题），建议监控错误率并联系技术支持。
多比特错误：需立即检查硬件稳定性，可能导致数据损坏或任务失败。
2）核心建议：
日常监控：使用 nvidia-smi 或集成到你的监控栈中的 DCGM。
故障排查：发生问题时，同时检查操作系统日志和服务器BMC/IPMI事件日志。
长期健康管理：部署像DCGM + Prometheus + Grafana这样的监控组合，这是管理H200等数据中心GPU健康状态（包括ECC记录）的行业最佳实践。
7. ECC注意事项
性能影响：启用ECC会略微增加内存访问延迟（通常<5%），但对可靠性要求高的场景必选。
禁用ECC：默认启用，不建议禁用（除非特定测试场景）。
厂商工具：戴尔、惠普等OEM厂商可能提供额外的ECC监控工具（如集成在服务器管理界面中）。
8. 实践：检测到无法纠正的ECC错误——GPU需要重置
8.1. 概述
ECC错误指的是GPU内存遇到其自身无法自动纠正的问题。这类错误通常不会导致设备完全失效，但会干扰GPU的正常运行。其成因多样，可能包括硬件故障、固件问题或内存瞬时错误等。在严重情况下，不可纠正的ECC错误可能预示着更严重的硬件故障。
可能观察到的症状包括：
未知错误：nvidia-smi 命令可能显示 GPU 链路信息和 ECC 模式为“未知错误”，这表明 GPU 遇到了无法正常上报或管理的问题。
不可纠正的 ECC 错误：dmesg 日志中可能会出现关于不可纠正的 ECC 错误的提示信息，这可能意味着需要关注的潜在问题。
服务故障：NVIDIA Fabric Manager 服务可能无法启动，从而影响依赖于 NVIDIA GPU 基础设施的系统运行。
8.2. 症状
1）nvidia-smi输出中为一个或多个GPU显示ERR! ERR! ERR!错误信息。
2）查询nvidia-smi时，当前的GPU Link Info显示为Unkown Error，ECC Mode显示为GPU requires reset，且ECC Errors计数器显示为N/A：
3）Dmesg显示An uncorrectable ECC error detected：
4）NVIDIA Fabric Manager 服务nvidia-fabricmanager.service无法启动：
8.3. 解决方法
通常来说，DRAM的可纠正及不可纠正ECC错误对NVIDIA GPU而言并非致命性故障，可能通过执行nvidia-smi重置操作和/或重启操作系统得以解决。
步骤1）nvidia-smi reset：此命令会触发对一个或多个GPU的重置。它可用于在通常需要重启机器的情况下，清除GPU的硬件和软件状态。当发生双位ECC错误时，此命令通常特别有效。
步骤2）重启系统
请注意： 务必同时提供 nvidia-smi -q 命令的输出以及 dmesg 的日志内容。
若依然未能解决问题，那么，可能中招了:(，抓紧时间及时联系售后。
希望进一步了解GPU参数与GPU模组的同学，可以参考如下内容：
白话GPU-58 GPU显卡技术参数详细解读
白话GPU-13 GPU服务器H100或H200机头、模组是啥？以及其构成
NVIDIA HGX B200 GPU模组UBB
