1. 课程导入与全景认知

当我们谈论“云原生AI算力”时，很多人的第一反应是“把GPU放进Kubernetes里跑训练任务”。这个理解不算错，但远远不够。云原生AI算力真正要解决的，是让异构加速器（GPU、NPU、RDMA网卡等）像CPU和内存一样，成为可被调度、可被隔离、可被观测、可被治理的标准资源。它包含三个层次：资源层把物理GPU抽象为可分配的设备；调度层决定哪个任务在什么时刻占用哪些卡；治理层保证这些卡在长时间高负载下依然稳定、可解释、可恢复。三者缺一不可，而生产环境中最容易被低估的恰恰是第三层。

先看一个具体的资源抽象过程。在Kubernetes中，GPU通过Device Plugin机制注册为扩展资源，节点上会暴露类似 nvidia.com/gpu: 8 的可分配数量。一个训练Pod申请 nvidia.com/gpu: 2，调度器只会检查节点剩余数量是否足够，并不会关心这两张卡是否在同一NUMA节点、是否共享同一条PCIe Switch、是否其中一张已经被ECC错误标记为降级。这就是“数量调度”与“拓扑调度”的差别。生产实践中，我们通常需要引入拓扑感知调度，把GPU、NVLink、PCIe、NUMA、RDMA网卡的位置关系纳入决策，否则一个8卡分布式训练任务可能被拆到跨NUMA甚至跨机架的卡上，通信带宽直接下降一个数量级。

GPU生产实践的核心挑战可以归纳为四类。第一类是资源碎片与拓扑错配：集群里明明有几十张空闲卡，但没有任何一个节点能凑出满足拓扑约束的8卡组合，任务长期Pending。第二类是故障的隐蔽性与扩散性：单张GPU的ECC错误、XID错误、NVLink降速往往不会让任务立刻崩溃，而是表现为训练速度缓慢、loss曲线异常，等到发现时已经浪费了数天算力。第三类是多租户干扰：显存带宽、L2缓存、PCIe带宽都是共享资源，一个推理任务可能因为邻居的显存密集型任务而延迟抖动。第四类是可观测性割裂：DCGM指标、Kubernetes事件、训练框架日志、NCCL通信日志分散在不同系统，排障时需要在多个界面之间反复切换。

可靠性治理的目标，就是把这三种状态区分开，并让系统在每一种状态下都能做出正确决策。具体来说，治理目标包括：可发现——通过DCGM、XID、ECC、NVLink状态等指标持续采集GPU健康信号；可判定——定义明确的健康分级，例如Healthy、Degraded、Unhealthy，并给出每级的判定阈值；可隔离——对Degraded卡打上污点，阻止新任务调度，但不粗暴驱逐正在运行的任务；可恢复——通过重置、重启、换卡等操作让节点回到可用状态；可追溯——保留故障时间线，回答“这张卡在过去7天里发生过什么”。

下面这张图展示了从GPU物理设备到上层训练任务的完整信号链与治理路径。它把资源抽象、健康信号、调度决策和治理动作放在同一条链路上，帮助建立全景认知。

理解了这张全景图，课程的整体学习路径也就清晰了。我们会沿着“资源抽象 → 调度与拓扑 → 健康信号 → 故障判定 → 隔离与恢复 → 可观测与复盘”这条主线展开，但不会平均用力。前半部分重点讲清楚GPU在Kubernetes中如何被表示、如何被分配、拓扑约束如何影响性能；中段进入生产实践的核心，包括DCGM指标解读、XID错误分类、ECC与NVLink降速的判定阈值、节点污点与Pod驱逐策略；后段聚焦可靠性治理的工程化落地，包括健康检查控制器、自动隔离与恢复流程、故障时间线记录、以及多租户场景下的干扰检测与配额治理。

需要特别强调的是，本课程不会把“可靠性”讲成一句口号。每一类故障都会落到具体的信号、阈值和动作上。例如，当DCGM报告某张卡的ECC Double Bit Errors在1小时内从0增长到3，我们应该做什么？当XID 48（DBE）出现时，是否立即隔离？当NVLink状态从active变为inactive但任务仍在运行，是等待还是主动迁移？这些判断需要结合业务SLA、任务类型和集群冗余度来综合决策，而课程会给出可参考的决策框架和参数示例。

最后，关于课程中出现的所有参数、阈值和配置示例，需要明确：它们是为了说明原理和操作过程而设计的教学示例或合理假设，并非来自某个特定生产集群的实测数据。实际落地时，必须根据自身硬件型号、驱动版本、业务负载特征和SLA要求进行校准。可靠性治理没有万能参数，只有持续观测、判定、隔离、恢复、复盘的闭环。