前两天在一个算力集群运维群里，有人扔出来一个问题：**Nvidia 的 L2 cache 里如果存在被标记为 poisoned 的行，它在被换出的时候会不会把这份数据写回 GPU memory？**底下很快吵成两派，一派认为缓存脏行必须回写，poison 只是挂在旁边的一个标记位；另一派认为既然已经知道数据坏了，任何形式的回写都等于主动往显存里投毒。我平时的工作有一大半时间在处理 GPU 的 ECC 报错和长跑训练任务的稳定性，这个问题对应的现象我在机房里确实撞见过，所以想把它完整拆一遍。
先说结论的方向：这不是一个能用"会"或"不会"回答的问题。答案取决于这条 L2 行被毒化的那一刻是干净的还是脏的、错误是在哪一级校验中被发现的、以及换出路径上有没有把 poison 属性一起带下去。把这几条捋清楚之后，你会发现硬件厂商在这件事上的取舍非常克制，甚至可以说"保守到让你意外"。这篇文章适合三类人看：正在维护 GPU 集群、被 Xid 报错折磨过的运维；写 CUDA 内核、关心数据完整性边界的开发者；以及做长时间训练、想知道"这块卡还能不能继续用"的人。如果你只是搜显卡驱动安装的，这篇确实帮不上忙——顺便说一句，现在搜任何 Nvidia 相关的技术问题，前面几页基本都被驱动安装、nvidia-smi报错、控制面板找不到之类的帖子淹没了，真正涉及内存层级的讨论很少，这也是我想写这篇的原因之一。
1. poison 在硬件世界里到底指什么
1.1 一个类比：贴了"已污染"封条的箱子
把 GPU 的内存层级想象成一个物流仓库。数据是从仓库（GPU memory，比如 HBM 或 GDDR）搬到分拣台（L2 cache）再送到工位（SM 里的计算单元）的。正常情况下，每个箱子上都贴着校验码，搬运过程中如果发现箱子破了但还能修补，就修好继续送，这叫可纠正错误（CE，Correctable Error）；如果破得连修补都做不到，继续送就等于把一份错误的数据喂给计算逻辑，这时候仓库管理员不会把箱子扔掉装作没事，而是给它贴一张"已污染"的封条，同时记一笔账——这张封条就是poison。
关键点在于：poison 不是一种数据，而是一种状态标记。它表达的意思不是"这份数据是错的"，而是"这份数据已经不是可信的值了，谁读谁负责报错"。这个区别非常重要，因为它决定了系统后续能做什么：如果只是"数据错了"，那还有机会重试、重算、从副本恢复；如果是"数据不可信且没有其他副本"，那唯一的正确做法就是让读到它的人立刻知道，而不是拿到一个看起来很正常的错误值。
硬件为什么要费劲搞这么一套东西？因为**静默数据损坏（SDC，Silent Data Corruption）**是整个计算领域最讨厌的一类故障。它不会让程序崩，不会让进程挂，只会让结果悄悄偏移一点点，然后你在三天后拿到一个 loss 曲线看起来正常、但模型精度就是差 2 个点的训练产物，根本无从溯源。所以从 CPU 到 GPU，从内存控制器到缓存，只要涉及 ECC，就一定会配套一套"读不到就报错"的机制，poison 是这套机制里最末端、也是最刚性的那一环。
1.2 从 CE 到 DUE：错误分级决定了 poison 会不会出现
理解 poison 出现的时机，得先把错误分级看明白。ECC 编码（常见的是 SECDED，单纠错双检错）能纠正 1 个比特的错误，能检测 2 个比特的错误。于是就有了下面这个分层：
| 错误类型 | 现象 | 硬件典型动作 | 对上层的影响 |
|---|---|---|---|
| CE（单比特） | 1 bit 翻转，编码可纠 | 硬件直接纠回，计数 +1 | 完全无感，除非速率异常 |
| DUE（不可纠正） | 2 bit 及以上翻转，或整块失效 | 无法恢复，标记 poison | 读取方必须收到错误信号 |
| SDC（静默损坏） | 错误未被检测到 | 无动作 | 最危险，只能靠结果比对发现 |
| 行失效 / 颗粒失效 | 整行、整 bank 不可用 | 行重映射或页退役 | 容量下降，但可用性保持 |
这张表里有个隐含信息：poison 是 DUE 的伴生产物，不是独立事件。硬件不会无缘无故把一份好数据标记成 poison，它一定是在某次校验中发现"这个位置的数据已经不可恢复"之后才贴封条。所以在讨论"会不会写回显存"之前，第一步永远是先确认 poison 是在哪一级产生的——是在显存颗粒的读取路径上，还是在 L2 这片片上 SRAM 自己的校验逻辑里。这两者后续的处理路径完全不同。
另外还有一点常被忽略：CE 如果密集出现，也会间接导致 poison。因为绝大多数 GPU 的错误管理策略里都有阈值机制，比如"某个内存页在 24 小时内出现超过 N 次 CE，就主动把这个页退役掉"。这不是因为 CE 本身危险，而是因为 CE 密集说明这个物理位置在退化，下一次很可能就是 DUE。
1.3 为什么硬件宁可直接报错，也不肯返回"大概是这个值"
我见过不少人吐槽：既然 L2 里那份数据已经知道坏了，为什么不干脆丢掉这一行，重新从显存读一遍？听起来合理，但硬件层面的约束比这复杂得多。第一，重新读一遍大概率还是错的，因为错误源可能就在显存颗粒或者传输链路上，重复读取只会重复触发同一个 DUE，白折腾一圈还多消耗带宽。第二，如果这一行是脏行（被 SM 写过但还没落盘），那它本身就是"最新版本"，显存里那份才是过期的，重新读反而会读到旧数据，制造一个更难查的数据不一致。第三，错误处理路径必须足够简单且确定，任何"先尝试恢复、失败再报错"的乐观策略都会显著拉长关键路径，而缓存的读写路径是要拿面积和延迟去换的。
所以硬件设计者选了最保守的方案：一旦确认不可恢复，就地贴毒，快速上报，把决策权交给软件。软件层拿到 poison 之后，可以根据场景决定是杀进程、退页、重启设备还是直接告警。这套"硬件保守、软件灵活"的分工，是整个 ECC 体系能跑通的基础。
2. Nvidia GPU 的 L2 与 GPU memory 之间的真实关系
2.1 L2 是 GPU 的一致点，不是一块可选缓存
在 Nvidia 的 GPU 架构里，L2 的地位跟 CPU 侧不太一样。从 Fermi 开始，L2 就是全局内存访问的唯一一致点：SM 发出的读写请求，最终都要经过 L2 才能到显存；显存返回的数据，也一定先落到 L2 再分发给 SM。这意味着 L2 不是一个"命中率优化开关"，而是必经通道。这个设计带来两个直接后果：一是所有显存流量都能在 L2 侧被观察到、被计数、被干预，这也是为什么显存侧的 ECC 统计最终会汇总到 L2 相关的计数器上；二是 L2 的物理实现是**切片式（slice）**的，地址经过哈希散列到不同切片，切片与显存控制器之间存在固定的绑定关系。
为什么要把切片和显存控制器绑在一起？因为这样能让流量本地化，减少片上的跨区路由，同时让每个切片只服务自己那一小段地址空间，便于实现并行和错误隔离。代价是：错误的影响范围会被切片结构放大或限制。如果毒化发生在某个切片的某条 cache line 上，理论上受影响的地址范围是可控的——这正是"contained error"这个概念能存在的物理基础。
还要提一句容量。数据中心卡上的 L2 是几十 MB 量级（A100 是 40MB，H100 是 50MB），而新一代产品的 L2 继续往上放大。这块片上 SRAM 本身也是有 ECC 保护的，也就是说L2 自己也会中毒，不只是"搬运工"，它也是"保管员"。这一点在排查时非常关键：如果你看到的是 SRAM 相关的 ECC 计数在涨，那问题出在片上，跟显存颗粒没关系。
2.2 写回、脏行与 eviction：一次换出都经历了什么
要回答"会不会写回显存"，必须先把一次正常的换出流程拆开。GPU 的 L2 对全局内存来说是**写回（write-back）**的，这意味着：
- 当 SM 写一份数据时，数据先落在 L2，标记为脏（dirty），此时显存里还是旧值；
- 当 L2 容量压力上来，需要腾位置时，会挑一条牺牲行（victim）换出；
- 如果牺牲行是干净的（clean），直接把状态置为无效，不产生任何显存写操作；
- 如果牺牲行是脏的，就把整行数据发回对应的显存控制器，落盘之后再置为无效。
这个流程里有几个细节值得抠。第一，干净行的换出是不写显存的，这是后面回答 poison 问题的最关键前提之一。第二，L2 的 cache line 不是原子粒度，现代 GPU 普遍采用分 sector的组织方式，一条 line 被切成若干 sector（典型是 32 字节一个 sector），每个 sector 有独立的有效位和校验。第三，sector 化直接决定了 poison 的粒度——如果毒化是按 sector 标记的，那么同一条 line 里其他 sector 的数据仍然是可用的，硬件没必要把整条 line 一起报废。
这三点合起来就说明一件事：**"L2 里的 poison 会不会写回显存"这个问题，必须先问清楚毒化发生在哪条 line 的哪个 sector 上、这条 line 是干净还是脏的。**不先问这两句，任何回答都是在猜。
2.3 L2 的物理切分与 sector 语义对 poison 粒度的影响
上面提到的 sector 化，值得单独展开，因为它直接决定了工程上你看到的错误范围有多大。公开资料对具体实现细节讲得很克制，但从设计惯例反推：一条 128 字节的 line 通常拆成 4 个 32 字节 sector，ECC 是按 sector 计算和校验的，所以一次 DUE 通常只会让一到两个 sector 不可用，而不是整条 line。反映到软件层，就是同一个内存页里可能只有一小段地址受影响。
这个粒度信息在实操中很有价值。比如你在做数据校验或者错误注入测试的时候，如果只按页（4KB 或更大）去判断"这块内存是不是坏的"，颗粒度会太粗，把大量本来可用的数据一起判死；反过来如果按字节去判断，又抓不到问题。比较合理的做法是按 sector 对齐去定位可疑范围，再往上归并成页，交给页退役或行重映射机制处理。
还有一个容易踩的坑：不同架构对 SRAM ECC 的覆盖范围不一样。有的架构只保护 L2，有的连寄存器文件和共享内存一起保护。所以同样是"A100 报了 SRAM 不可纠正错误"，在不同型号上对应的物理范围和后续处置方式可能完全不同。查计数的时候一定要看清nvidia-smi -q -d ECC里报的是 SRAM 还是 DRAM，这两个字段的含义和处置路径不能混着看。
3. 被毒化的行在换出时会发生什么：三种设计路径
3.1 路径一：干净行直接丢弃，根本不产生写回
这是最简单也最常见的情况。如果这条被毒化的 L2 行是干净的——意思是它只是被读取过、没有被修改过，显存里那份才是权威版本——那么它的换出路径跟普通干净行完全一样：置无效、丢弃，不产生任何写回显存的流量。
这种情况下"会不会把 poisoned 数据写到 GPU memory"的答案是明确的：不会，而且是根本不会尝试。因为换出逻辑判断的是脏位，不是毒位，clean 的行走的是纯丢弃路径，连数据通路都不打开。显存里那份数据还是原来的样子——如果错误源本来就在显存侧，那么再次读取这个地址会再次触发同样的 DUE，形成一个稳定的、可复现的错误点；如果错误源在片上链路或 L2 自身，那么显存里的数据其实是好的，这个地址后续重新读进来可能是正常的。
这里有个反直觉的点值得强调：poison 不一定代表数据真的全坏。它代表的是"这次读取路径上校验失败了，我无法证明这份数据是对的"。错误源可能在传输、可能在缓存 SRAM 自身、也可能确实在颗粒。所以遇到 poison 之后，正确的动作是定位错误源，而不是无脑认定显存坏了。这两者在处置上的差别很大——前者可能只需要重启设备清掉片上状态，后者才需要退页。
3.2 路径二：脏行绝不允许"以有效数据身份"写回
真正麻烦的是脏行被毒化的情况。这条 line 上有 SM 写进去的新数据，还没落盘，而它又被判定为不可恢复。这时候硬件不可能走"丢弃"路径，因为丢弃等于把上层已经写入的数据悄悄抹掉，属于数据丢失；也不可能走"当作正常数据写回"路径，因为那等于把已知的坏数据写成显存的权威版本，彻底破坏了 poison 机制存在的意义。
所以设计上只剩下两种可能：要么把 poison 属性一起带到写回事务里，让显存控制器知道"这份数据带着毒，不要在后续读取时把它当成好数据"；要么放弃这次写回，同时把错误升级上报，由软件层通过退页、重置等方式收拾残局。无论走哪条路，有一点是确定的：**硬件不会把一份已知不可信的数据，以"有效"的身份写进显存，然后让后续读取毫无察觉地拿到它。**这是整个机制的红线，跨过这条线，ECC 就白做了。
从设计惯例推断，带毒写回在实现上难度很高，因为它要求下游的存储介质或者内存控制器有能力记录"这个地址目前是毒的"这一状态。而普通的 DRAM 颗粒并没有这么一个位置放 poison 标记，除非上层专门维护一张毒化地址表。这就是为什么现实中更常见的处置方式是上报 + 退役：不纠结这份数据能不能写回去，直接把承载它的物理页标记为不可用，从分配器的可用池里摘出去，后续任何程序都不会再从这个页上分配内存。
3.3 路径三：把毒带到目标地址，让后续读取继续报错
即使假设硬件真的实现了带毒写回，它的目的也不是"保存数据"，而是保证毒不会消失。这个逻辑用一句话概括：毒可以被转移，但绝不能被清除。因为一旦毒在某个环节被悄悄清掉，这个地址就会在后续读取时返回一份看起来正常、实际错误的数据，退化成了 SDC——而 SDC 恰恰是这套机制最想消灭的东西。
所以从系统设计角度，poison 的生命周期只有三种合法归宿：
- 被上报：错误计数器加一，产生一条 Xid 事件，运维侧的告警被触发；
- 被隔离：对应的物理页退役，或者行被重映射，从此不再参与分配；
- 被传递：如果这一行必须流动，poison 属性跟着一起流动，读到它的地方继续报错。
注意这里面没有"被写回显存然后当没事发生"这一项。这也是我在群里那场争论里最后的落点：讨论"会不会写回"其实跑偏了，真正该问的是"毒会不会在写回过程中丢失"。前者是通路问题，后者是正确性问题。
3.4 给出结论：公开文档能支撑到什么程度
这里必须诚实一点。Nvidia 的公开文档里，你能查到 ECC 的开关方式、错误计数器的含义、Xid 事件的定义、页退役和行重映射的使用方法，但查不到 L2 换出路径在遇到 poison 时的逐拍行为。这属于微架构实现细节，厂商没有义务公开，也不适合拿来公开。
能确定的、有文档或者有可观测行为支撑的部分：
- poison 机制存在，且 DUE 会通过 Xid 事件在上层可见；
- 页退役和行重映射会把出问题的物理位置从可用资源里摘出去；
- 干净行的换出不产生显存写流量，这是 write-back 缓存的基本语义；
- 系统绝不会静默地把已知坏数据当成有效数据传下去，否则整套 ECC 就没有意义。
属于合理推断、需要标注为推断的部分：脏行带毒写回的具体实现方式、sector 级的毒标记粒度、以及 L2 slice 与内存控制器之间的毒传递协议。
我的建议是：在工程上按"最坏情况按脏行处理，处置按退页做"这个原则来操作。因为即使某次 poison 实际发生在干净行上、显存其实没坏，退页带来的代价也只是损失一点点容量；而如果反过来误判成"没事"，代价可能是几天的训练结果报废。
4. 从可观测行为反推：页退役、行重映射与 Xid
4.1 nvidia-smi 里那几个计数器分别是干什么的
与其纠结微架构细节，不如把精力放在能直接观测的指标上。下面这些命令我在现场排查时基本是条件反射式地敲。
# 看 ECC 的整体状态与错误计数 nvidia-smi -q -d ECC # 看页退役情况（数据中心卡支持） nvidia-smi -q -d PAGE_RETIREMENT # 看行重映射情况（Ampere 及以后的数据中心卡支持） nvidia-smi -q -d ROW_REMAPPER # 只取不可纠正错误的总数，适合脚本采集 nvidia-smi --query-gpu=ecc.errors.uncorrected.volatile.total --format=csv,noheader几个字段的含义需要掰开讲。ECC 计数分Volatile和Aggregate两组：Volatile 是自上次驱动加载或者上次显式清零以来的计数，Aggregate 是设备生命周期内的累计值。现场排查要先看 Volatile，因为你要判断的是"这次事故是什么时候开始、涨得快不快"；判断硬件是否已经退化，才去看 Aggregate。
再往下还分SRAM和DRAM两类。SRAM 对应片上缓存（L2 等）的校验失败，DRAM 对应显存侧的校验失败。这个区分极其重要，因为 SRAM 错误往往是设备局部状态问题，一次彻底的重置可能就恢复正常；而 DRAM 错误更倾向于物理退化，通常意味着这块位置需要退役。
行重映射那几个字段（Correctable / Uncorrectable / Pending / Failure）也值得说明。Pending 表示有行被标记为需要重映射但还没生效，通常需要一次设备级重置才能落地；Failure 表示重映射尝试失败，这基本等于宣判这个物理位置救不回来了。看到 Failure，就该考虑把这张卡从生产池里拿出来了。
4.2 Xid 48/63/64/92/94/95 对应的是哪一类事件
ECC 计数器告诉你"有多少错"，Xid 告诉你"发生了什么事件、什么类型、影响范围多大"。这两个信息是互补的。我整理了一张常用的对照表：
| Xid | 含义 | 现场含义 |
|---|---|---|
| 48 | 双比特 ECC 错误（DBE） | 出现了不可纠正错误，是 poison 的典型前驱事件 |
| 63 | 页退役或行重映射事件 | 硬件已经动手隔离了，属于"处置动作已发生" |
| 64 | 页退役或行重映射记录失败 | 隔离动作没能写进记录，需要人工介入 |
| 92 | 单比特错误速率过高 | CE 在密集出现，物理位置在退化 |
| 94 | 可隔离的 ECC 错误（Contained） | 影响范围能限制在某个上下文内 |
| 95 | 不可隔离的 ECC 错误（Uncontained） | 影响整个设备，需要整体重置 |
Contained 和 Uncontained 这一对概念是整个错误管理里最有工程价值的设计。Contained 意味着这个错误可以被限制在一个进程或者一个计算实例内，把这个进程杀掉，设备其他部分继续可用；Uncontained 意味着错误已经扩散到设备级共享资源，这时候任何还在跑的进程都不该信任自己的结果。在 MIG（多实例）场景下，这个区分尤其重要，因为一个实例上的 contained 错误理论上不应该影响同卡上的其他实例。
# 抓内核侧的 Xid 事件，带时间戳 dmesg -T | grep -i xid # 需要完整现场时，生成一份包含驱动状态、ECC 计数、拓扑信息的报告 nvidia-bug-report.shdmesg -T | grep -i xid这条命令我几乎是每次都敲，因为它能把"报错时间"和"任务日志里异常发生的时间"对上，这是判断影响范围的第一手证据。
4.3 页退役与行重映射的区别，以及为什么必须重启才生效
这两个机制经常被混为一谈，但它们的层级完全不同。**页退役（Page Retirement）**是驱动/固件层面的机制：把出问题的物理内存页记录下来，写进设备的持久化信息区，下次驱动加载时把这一页从可用内存池里摘掉。它的粒度是页，操作对象是"逻辑上的可用内存"。**行重映射（Row Remapping）**是更底层的机制，直接作用于 HBM 内部的物理行，把坏行映射到预留的备用行上，对上层基本透明。
为什么强调"必须重启或重置才生效"？因为这两个机制都需要在设备初始化阶段才能安全地改动内存布局。运行中的设备上有活跃的上下文、有正在进行的 DMA，不可能中途把一块内存从别人脚底下抽走。所以现场处置的标准动作是：先取证、再停任务、再做设备重置或重启节点、最后验证计数是否停止增长。跳过重置这一步，Pending 状态会一直挂着，实际可用性并没有恢复。
还有一个常被忽略的点：消费级显卡对这些机制的支持非常有限。很多 GeForce 型号在nvidia-smi里根本没有 ECC 这一栏，行重映射更是数据中心卡才有的能力。所以在工作站上遇到类似的错误现象，你能做的往往只是换卡，而不是像数据中心卡那样通过退页和重映射把卡救回来。
5. 一套可复现的排查与处置流程
5.1 现场取证：在重启之前必须抓的东西
我踩过的最大一个坑，就是发现问题之后急着重启，结果所有易失性的现场信息全没了，只剩一个"重启后恢复正常"的结论，根本无法判断根因，也没法给上级或者客户一个交代。后来我把取证动作固定成了下面这几步，顺序不能乱。
# 第一步：记录当前 ECC 计数与行重映射状态 nvidia-smi -q -d ECC,PAGE_RETIREMENT,ROW_REMAPPER > /tmp/gpu-$(date +%s).log # 第二步：抓 Xid 与驱动侧日志 dmesg -T | grep -iE "xid|nvidia" > /tmp/dmesg-gpu.log # 第三步：记录在跑的任务和显存占用，便于判断影响面 nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv # 第四步：确认设备拓扑，判断是不是同一张卡反复出问题 nvidia-smi topo -m这几步的核心目的是把"错误的绝对数量、错误发生的时间点、当时谁在用卡、卡在机器里的位置"这四件事固定下来。尤其是 Aggregate 计数，它是唯一能证明"这是偶发还是持续退化"的证据，一旦重启就再也拿不到原始值了。我个人的习惯是同时把输出落到一个带时间戳的文件里，并且在工单里贴原始文本而不是截图，方便后续用脚本做批量比对。
如果条件允许，再用 DCGM 做一次健康检查，能拿到比nvidia-smi更细的字段：
dcgmi health -g 0 -c dcgmi diag -r 2不同版本的 DCGM 字段编号会变，脚本里引用具体字段 ID 之前，务必先查一下当前版本对应的官方字段表，否则你的监控看板会在某次升级之后默默开始报错，而且很难发现。
5.2 判断"能不能继续跑"的三条硬标准
取证之后就是决策。我一般用三条硬标准来判，任何一条不满足就不建议继续跑生产任务：
| 判断项 | 可以继续 | 建议停机 |
|---|---|---|
| 错误类型 | 只有 CE，且速率平稳 | 出现 DUE，或 CE 在短时间密集出现 |
| 隔离范围 | Contained，且能定位到具体进程 | Uncontained，或无法定位到单进程 |
| 隔离动作 | 页退役、行重映射已成功记录 | 出现重映射 Failure，或 Xid 63/64 反复出现 |
这三条的逻辑是：CE 且平稳 = 硬件在工作，只是有点磨损；DUE = 已经有数据不可信了；Contained = 影响面可控；Uncontained = 全设备结果不可信；退役成功 = 问题位置已经被摘掉；重映射失败 = 问题位置摘不掉。前两组回答"要不要停"，第三组回答"停了之后能不能复用"。
特别要强调的是重映射 Failure 这一项。很多人看到 ECC 计数不再增长就以为没事了，但如果 Failure 计数非零，说明硬件试图隔离坏行但失败了，那块物理位置仍然可能被使用，错误会以更隐蔽的方式继续出现。这种情况我的处理方式是直接把卡标记为待更换，不再投入生产。
5.3 长跑任务的监控配置与告警阈值
长期跑训练任务的机器，靠人肉nvidia-smi是不现实的。我的做法是把关键指标打进监控系统，并且设置分级告警。经验阈值大致是这样：CE 每分钟增长超过个位数就该看一眼，不可纠正错误只要出现一次就该告警，Xid 94/95 出现即告警，Xid 48 出现即告警并自动标记当前任务结果不可信。
自动标记这一点特别重要。因为一旦发生了不可纠正错误，那个时间点之后的训练结果在严格意义上就不应该被信任了。我见过团队为了赶进度，把出错的 checkpoint 接着往下训，最后发现loss 正常但验证集指标诡异，返工的成本远超重新跑一遍。训练任务的正确性，比训练任务的速度值钱得多。
另外一个实用配置是把 ECC 计数和任务的启动时间对齐。因为 Volatile 计数在驱动重载后会清零，如果你的任务跨越了驱动升级或者节点重启，前后两段的数据就不能直接比较。我在做归因分析的时候，习惯把任务的 PID、启动时间、结束时间跟 Xid 时间戳放在同一张表里对齐，这样一眼就能看出来"这个任务是不是在报错的时间窗口内"。
5.4 几个容易被误判的场景
最后说几个我在实际排查中反复遇到的误判，都是走了弯路换来的。
第一种是把显存不足的报错当成 ECC 问题。如果开启了 ECC，可用显存会有一部分被拿去做校验位，容量会有几个百分点的下降；如果这个下降刚好卡在某个大批量任务的临界点上，表现出来就是 OOM，而不是 ECC 报错。这种情况不要往硬件故障方向查，先算一下 ECC 开启前后的可用容量差。
第二种是把驱动层的通信失败当成硬件故障。nvidia-smi连不上驱动、查询返回异常，很多时候只是驱动状态异常或者某个进程占着设备没放，跟 ECC 和 poison 一点关系都没有。判断方法是看内核日志里有没有 Xid，没有 Xid 的情况下，优先怀疑软件层。
第三种是把单次 CE 当成"卡要坏了"。单比特错误在超大容量显存上是可以接受的统计现象，只要速率平稳、不密集、不伴随 DUE，就不构成更换理由。真正要警惕的是"速率突然抬升"，而不是"存在某个绝对值"。
第四种，也是跟这篇文章主题最相关的一种：把 poison 当成"显存里那格数据坏了"。前面反复说过，poison 只是当次读取路径上校验失败的状态标记，错误源可能在片上、可能在链路、也可能在颗粒。所以正确的处置顺序永远是先定位错误源（看 SRAM 还是 DRAM 计数、看 Xid 类型），再决定是重置、退页还是换卡，而不是一上来就宣布显存坏了。
我在实际维护集群的过程中体会最深的一点是：GPU 的错误管理机制本身是相当完备的，真正容易出问题的是人。急着重启导致现场丢失、误判错误类型导致返工、把不该继续的任务继续下去导致结果作废——这几种情况造成的损失，远比硬件故障本身大。至于最开始那个"poison 会不会从 L2 写到显存"的问题，我的答案一直是同一句：毒可以被传递、被上报、被隔离，但绝不会被当成好数据悄悄落盘，因为一旦允许这件事发生，整套 ECC 体系就失去了它存在的全部意义。
