做容器平台底层运维的人，大概率都有过这种经历：节点上明明插着好几块加速卡，驱动也装好了，但创建容器时一声明要多少资源就报错，或者容器起来了，应用却根本访问不到设备。问题多半不是驱动，而是异构计算资源治理没做扎实。这里的"治理"不是调度器怎么排队，而是 runtime 这种容器运行时架构，如何把物理设备从宿主机资源池里"发现"出来，再通过一套生命周期管理协议，安全地交给容器使用，最后还能干净地收回去。这套机制直接决定你的多卡集群到底能用起来几成。这篇文章就从 runtime 架构切入，把设备发现链路和生命周期管理协议逐层拆开，适合基础设施开发、平台运维和做任务调度的同行参考。
1. 异构计算资源为什么要"治理"，治理的边界到底划在哪
1.1 异构设备不是"大号网卡"
很多人习惯把异构设备当成普通 I/O 设备处理，插上驱动，在容器里挂个 /dev 节点就算了。真实情况远比这复杂。
GPU、NPU、FPGA、RDMA 网卡，每种设备的访问方式都不一样。有些设备需要设备节点配合厂商的用户态运行库，应用才能算起来；有些设备要额外挂载固件目录或者虚拟化层提供的控制文件；还有的设备对设备内存、显存、算力规格有硬性要求。如果只是简单地把设备文件映射进容器，应用很可能因为缺少依赖库、环境变量或者设备的某种隐藏属性而启动失败。
异构这个词的另一层意思，是管理语义不统一。有的设备支持 MIG 切分，可以把一块大卡切成多份；有的设备只支持独占；有的设备支持共享但需要特殊的隔离机制。如果平台侧不抽象出一层统一的"资源单位"，调度器和运行时根本没办法在一个频道上对话。
1.2 治理边界：调度器管"宏观"，runtime 管"微观"
在典型的容器平台架构里，资源治理天然分两层。
调度器这一层，只关心哪个节点有多少可用资源，任务调度过来时按数量扣账。它不关心具体是哪块设备，也不关心设备此刻是否被某个进程占用。runtime 这一层，恰恰相反，它知道节点上设备的细节，比如设备编号、健康状态、设备节点路径、依赖库位置，但它没有全局的任务视图。
如果两层混在一起，要么调度器对设备状态做过多的假设，要么runtime越权处理全局决策。异构计算资源治理要做的事情，就是在两层之间画一条清晰的边界：调度器按"数量+资源类型"做决策，runtime 按"设备实例列表+设备属性"做实现，中间用一套协议串起来。
1.3 为什么协议必须固化在 runtime 架构里
没有协议的时候，每个厂商各写各的脚本，初始化设备、配置容器、回收资源，逻辑全散落在 Supporter 脚本和自定义命令里。短期看起来能用，一旦升级驱动、节点重启、设备热插拔，各种奇怪问题就冒出来了。真正的问题是缺少统一的交互契约。
所以现代运行时架构中会专门定义设备管理和生命周期管理的协议。协议规定了设备插件如何注册、如何上报设备、如何响应分配请求、如何释放资源、如何传递健康状态。有了协议，设备驱动厂商和上层平台就能解耦，平台不需要知道某个设备怎么初始化，只需要按照协议调用接口；厂商也不需要理解平台的全部调度逻辑，只要实现协议就好。
2. 设备发现链路：从物理设备到 runtime "看见"设备的全流程
2.1 底层硬件探测：从内核接口到设备列表
设备发现的第一步，是把宿主机上所有符合条件的物理设备找出来。这一步一般在设备插件里完成，插件作为一个特权守护进程跑在节点上。
底层探测的通道有三类：第一类是内核暴露的文件系统接口，比如 PCI 总线的设备目录，可以枚举总线上的厂商号、设备号、类别号；第二类是对应驱动注册的设备节点，比如 /dev 下的字符设备；第三类是厂商 SDK 自带的枚举接口，有的能查到设备名、设备内存、固件版本，甚至设备实时温度。实际编程时，通常先遍历系统接口，再用驱动层接口补充细节。
比如在 Linux 环境里，可以先读取 /sys/bus/pci/devices 下的目录，找出和计算设备类别相关的设备，再通过设备节点和驱动接口确认设备状态。要注意的是，不能在探测时直接对设备做初始化操作，否则会影响正在运行的任务。设备发现应该是只读的，除非明确知道设备处于空闲状态。
这一步在实践中最常见的错误是权限不足。插件如果用一个低权限用户跑，读不到设备节点，或者调驱动库失败，最后呈现出来的就是节点资源为 0。我见过很多次这种问题，排查到最后发现是 systemd 服务里的 User 字段配错了。
2.2 插件注册：设备信息如何变成可调度的资源
发现设备还不够，要让上层调度器知道"这个节点上有 4 块某某类型的设备"，需要插件主动注册。
注册过程本质上是插件和 runtime 控制面建立一条连接，然后上报两类信息：一类是资源名称，也就是给这批设备起的统一名称；另一类是可用数量，也就是当前健康且空闲的设备数。控制面收到后，把节点容量更新到调度器的全局账本里。
在容器平台里，扩展资源通常用整数表示，不支持百分比请求，所以在设计资源语义时要尽量贴合实际：是独占设备、共享设备还是可切分设备，应该通过不同资源名称区分，而不是把切分比例塞进同一个名称里。
有一点容易被忽略：注册动作不是一次性的。插件启动后要周期性重新上报，尤其当设备状态变化时，必须主动推送更新。如果控制面只信任启动时的一次注册，设备故障后资源数量就不会扣减，调度器会继续把任务发到坏设备上。
2.3 健康状态上报：设备"存在"不等于"可用"
设备发现里最关键也最容易做错的一环，是健康状态判断。
硬件的健康状态不是简单的 0 和 1。设备驱动可能加载失败，设备可能因为过热被系统禁用，设备可能进入错误的功耗状态，这些都导致设备物理存在但不可用。所以插件必须周期性地检测设备健康度，不能只在启动时扫一遍。
检测方式依赖具体设备，一般是通过厂商提供的运行时库查询设备状态，或者读取内核日志里的错误事件。健康检查的频率需要平衡。太频繁会占用设备上下文切换资源，尤其对计算设备来说，每次查询可能打断正在跑的 kernel；太慢又导致故障发现滞后。我的建议是默认 5 到 10 秒一轮，如果发现连续失败，可以缩短到 1 到 2 秒快速确认，避免误报。
当插件确认某块设备故障，要做两件事：一是把它从可用列表中移除，并上报控制面；二是尝试触发告警，让运维介入。之后设备恢复后，再把它加回列表并上报。整个发现链路才算闭环。
3. 生命周期管理协议：从请求分配到资源回收的四个环节
3.1 资源分配：决定"谁用哪块设备"的策略
调度器决定把任务放到哪个节点，但它不会告诉你具体用哪块物理设备。这一步是协议最精彩的地方。
常见的分配模式有两种。一种是控制面分配：控制面根据全局状态，在收到调度请求后查询插件维护的空闲设备列表，选择一块或多块设备，再下发给 runtime。另一种是运行时分配：控制面只转发"需要两块设备"的请求，runtime 或插件在本地选择一个具体的设备实例。
两种模式各有取舍。控制面分配的好处是全局视角，可以做到设备负载均衡，但代价是状态同步复杂，节点和插件的任何变化都要及时通知控制面。运行时分配更简单，插件的空闲列表天然是最新的，但容易出现局部碎片化，比如某多卡节点上前面几块设备总被抢，后面几块一直闲置。
我在实际项目里比较倾向混合模式：控制面做粗粒度分配（指定节点），runtime 按本地策略选择具体设备。本地策略要支持可配置，比如优先选择待分配次数少的设备，或者优先选空闲显存大的设备。分配结果需要记录在案，方便后面对账。
3.2 设备挂载细节：不止是映射一个设备文件
分配完成后，runtime 要为容器准备设备环境。这一步远没有想象的简单。
首先要把设备节点挂载进容器。以常见设备为例，/dev 下的字符设备文件具备主设备号和次设备号，运行时创建容器时需要按这些信息创建设备节点，而不是简单复制文件。
其次要挂载依赖目录。设备厂商的驱动库、配置文件、固件目录，往往需要挂载到容器指定的路径。如果漏掉某个目录，应用可能在运行到某个函数时才报找不到某个文件，非常难排查。更稳妥的做法是让插件在分配时返回一个完整的"设备环境清单"，包含所有需要挂载的路径、环境变量和额外设备。
最后是环境变量。某些设备通过环境变量控制应用能看到的设备范围，比如把设备索引或者内存大小限制传进去。这类变量必须由插件生成，而不是由上层应用自己设定，否则会出现应用绕过隔离直接访问一块没分配给它的设备。
挂载阶段还要注意设备节点的读写权限。容器应以非 root 身份运行，设备节点不能默认给 0666 权限，否则任何容器都能访问，安全上就失控了。
3.3 健康检查、故障恢复与设备回收
容器运行期间，设备可能出故障。生命周期协议必须覆盖这个阶段。
插件在检测到设备故障后，要立即上报，并且根据业务策略决定处理方式。如果容器里跑的是一个可迁移的短任务，可以考虑杀掉容器让调度器重新调度；如果是一个有状态长任务，不建议直接杀，最好标记异常并人工介入。协议里要预留这种区分。
真正会出问题的是设备回收阶段。容器退出后，runtime 负责卸载挂载、删除容器内的设备节点。但插件侧的"设备空闲计数"什么时候扣减，需要和容器退出事件对齐。如果插件在容器退出事件到手之前就提前标记资源空闲，可能出现新容器把资源占走，旧容器却还在跑的冲突；如果一直不标记，设备又被浪费。
一个比较好的做法是：插件监听两个信号，一个是容器运行时的退出回调，一个是自己的主动探活任务。两个信号都确认设备上没有任何活跃进程了，才真正置为空闲。整个过程要有超时控制，防止进程僵死后设备永远被扣住。
3.4 协议状态机与消息语义：一个可落地的样子
把上面的流程整理成状态机，大致是这样几类状态：
| 状态 | 含义 | 触发动作 | 可能去向 |
|---|---|---|---|
| 空闲 | 设备健康且未被使用 | 分配请求成功 | 分配中 |
| 分配中 | 已确定分配给某容器，但未完成挂载 | 挂载完成 | 使用中 |
| 使用中 | 容器正在使用设备 | 容器退出/故障 | 回收中 |
| 故障 | 设备健康检查失败 | 运维处理 | 空闲或下线 |
| 回收中 | 正在清理残留进程和设备状态 | 清理完成 | 空闲 |
协议的消息语义至少要包含：注册请求、注册响应、设备列表上报、设备列表更新、分配请求、分配响应、释放请求、健康事件上报。所有请求都必须带请求 ID，用于去重。分配请求和释放请求必须是幂等的，同一请求重复发送不能导致资源被扣两次或者释放两次。
协议里还必须处理超时。比如分配请求发出后，插件可能在本地挂载时卡住，如果不做超时控制，资源就一直挂在"分配中"。实际场景里可以设置 30 秒的分配超时，超时后运行时主动回收本地挂载，并返回失败。
4. 生产环境里的真实排障与优化经验
4.1 节点重启后，设备容量迟迟不恢复
有段时间我负责的多卡节点只要重启，任务就全部卡在调度队列里，节点状态显示资源为 0。最先怀疑是插件没起来，上去一看插件进程活着，日志也在正常打印设备列表。于是开始怀疑控制面缓存，重启控制面也没用。
后面跟踪发现，控制面保存的节点设备容量，在节点重启后没有清空。插件重新注册时，控制面认为节点容量已经存在，直接把新上报的数量当作"增量"处理，结果变成 0 加 4，还是 0。也就是说旧容量把新容量盖掉了。
解决办法很简单：控制面把"注册"接口设计成"覆盖式"语义，即每次插件上报都直接替换该节点的设备容量快照，而不是做累加。同时插件启动时先主动上报一个空列表，清空旧状态，再上报完整列表，这样即使控制面状态陈旧也能被纠正。
经验之谈：设备发现协议的注册和上报，方向一定不能反，必须是"从节点主动拉取"或"节点主动上报"，不能让控制面去推断节点状态。
4.2 容器退出后，设备句柄泄漏导致可用设备数越来越少
另一个经典问题是物理设备明明 4 块，跑了几轮短任务后只剩 2 块可用。排查时先看插件的空闲列表，发现已经标记了 3 块空闲，但实际设备文件上有残留进程占用。
这台设备被上一个容器用过，容器退出时 runtime 卸挂载失败，或者因为某些僵死进程没有释放文件描述符，设备一直被内核占用。插件只看容器退出回调，就会把这块设备提前标记为空闲，但实际上下一个容器根本起不来。
最后的根治方案是在插件里做"孤儿设备扫描"：周期性地检查设备文件上是否有活跃的进程句柄，如果发现一个设备被标记为空闲但还有进程引用，就强制清理该进程（当然要结合平台侧的确认），再真正标注空闲。这个扫描动作相当于给协议补了一个补偿机制。
4.3 同一设备被两个容器同时使用，是谁的锅
共享模式还好，某些独占型设备如果同时被两个容器使用，轻则任务输出错乱，重则设备固件崩溃。这类问题往往是最难查的，因为现象通常不在同一个节点上，而是在不同的任务之间反复出现。
排查后发现，根因是控制面和插件之间出现了"分配不一致"。控制面持有一份设备分配记录，插件持有一份空闲列表，两者不同步。两个并发请求分别通过了控制面的数量检查和插件的本地锁检查，但用的却是同一块物理设备。
要解决这个问题，必须把分配决策收敛到单一权威节点。我后来把策略改成：控制面只下发"需要 N 块"的请求，实际选设备完全交给插件处理，插件内部加锁并返回具体设备 ID。这样即使控制面记录出问题，插件侧也不会重复分配。与此同时，协议里要加入对账机制：插件定期上报已分配设备列表，控制面以此校准自己的账本，发现冲突及时告警。
4.4 设计生命周期协议时，我会先盯着这几个点
把前面踩过的坑总结一下，如果要自己设计一套 runtime 架构下的设备管理协议，这几个点优先盯住。
第一，幂等。分配、释放、上报这三个动作，没有任何一个可以假设只执行一次。所有消息都带唯一请求 ID，接收方必须能识别重复请求。这条能规避大部分诡异的"资源凭空消失"问题。
第二，超时。所有同步调用都要有超时，并且超时后的行为要明确定义。比如分配超时后，插件返回一个错误码，同时执行本地清理，不能把设备留在"分配中"悬挂着。
第三，版本。设备列表上报必须带版本号，控制面只信任比当前版本更新的上报。否则节点上的设备变化顺序乱掉，旧状态覆盖新状态，容量必然出错。
第四，可观测。协议层最好把每一步操作的时间和结果都打到日志里，尤其是设备分配和回收。实际排障时，没有分配历史记录几乎等于盲查。后来我在自己的实现里给每块设备加了一个环形日志，记录它最近二十次状态变化，任何问题都能很快定位。
5. 最后分享一个小技巧
在做设备发现模块之前，别急着接真硬件。可以先在测试机上创建一个虚拟设备文件，用脚本模拟设备状态变化，把设备发现和生命周期协议的逻辑跑通。我就是靠这个方法，在完全没有真卡的环境里验证了分配、挂载、释放、故障上报的完整链路，后来接入真设备时只花了半天就调通了。
另外，协议设计时一定要留版本字段，而且要把版本信息随每次上报一起发送。设备驱动升级、插件升级、控制面升级都可能造成协议不兼容，版本号能让你在升级后第一时间定位到是哪一层的契约变了。这个小地方，救过我太多次了。
