跳到主要内容

自动复位机制

本章介绍TCIM的自动复位机制。当推理过程中底层硬件因超时进入卡死状态时，TCIM可自动触发后摩设备复位，并在复位完成后返回状态码。如果自动复位成功，用户无需重新加载模型或重建 Stream，仅需重新准备模型输入，并再次推理模型即可；如果自动复位失败或返回异常状态码，则需按状态码处理建议执行等待、重试或手动恢复。

在模型推理过程中，算子异常、输入异常或运行时状态异常等问题可能导致底层硬件超时卡死。若采用传统恢复方式，用户通常需要手动复位后摩设备、重新初始化运行环境并重新加载模型。该过程恢复链路较长，业务中断时间通常较久，并且可能影响同一后摩设备上的其他并发推理任务。自动复位机制用于简化上述恢复流程，降低用户对硬件异常的处理复杂度。该机制默认开启，适用于在线推理、长时间稳定性测试、并发推理服务等对恢复时间和业务连续性要求较高的场景。

自动复位以后摩逻辑设备为单位执行。每颗后摩M50芯片在系统中都会被识别为一个独立的逻辑设备，对于包含多个逻辑设备的后摩设备，自动复位仅作用于有异常的后摩逻辑设备，不会复位设备内的全部逻辑设备。若多颗后摩逻辑设备发生异常，TCIM 会分别触发对应逻辑设备的自动复位流程。

4.1.10.1. 特性说明​

自动复位机制具备以下特点：

  • 免模型重载 ：复位过程由TCIM自动完成。复位成功后，用户无需重新创建 Module、重新加载模型，以及重新创建 Stream。

  • 秒级恢复 ：后摩设备自动复位通常可在3 ~ 4秒内完成。

  • 默认开启，可配置关闭 ：该机制默认开启，如需关闭，可将环境变量 TCIM_XH2_AUTO_RESET 设置为 0。

4.1.10.2. 自动复位流程与状态码处理​

当模型推理阶段发生超时卡死时，TCIM会自动触发底层后摩设备复位。复位完成后，TCIM会通过状态码告知复位结果；如果复位仍在进行中，其他访问同一后摩设备的推理线程也可能返回后摩设备暂不可用状态。

在并发推理场景下，即使只有某一个线程的推理任务触发超时卡死，复位过程也会影响同一后摩逻辑设备上运行的其他推理线程。因此，需要在所有推理线程中统一处理相关状态码，而不是只处理触发超时的线程。

注意

以下状态码仅说明其在自动复位机制中的含义与处理方式，不代表该状态码的全部触发原因或唯一处理方式。

表 4.3 自动复位相关状态码处理建议 状态码含义应用层处理建议
Status::TIMEOUT （C++）当前推理任务发生超时卡死，TCIM已完成自动复位。
  • 在单线程场景下，所有推理相关错误（包括超时、卡死等）均统一归集并返回该错误码。

| 重新准备模型输入后，再次推理模型。无需重新创建 Module、重新加载模型，以及重新创建 Stream。
Status::UNAVAILABLE （C++） | 后摩设备正在自动复位过程中，当前线程暂时无法访问后摩设备。常见场景包括：

  • 并发推理场景中未直接触发卡死的其他线程访问该设备。
  • 自动复位过程中，应用进程被 Ctrl+C 等外部信号强制中断后，其他线程或重新启动的进程访问该设备。

| 处理建议：

  • 复位正常进行的情况：等待短暂时间后重试。复位完成后，可继续使用原有 Module 和 Stream 进行模型推理。
  • 若因 Ctrl+C 等外部信号中断导致复位流程被破坏，则需要执行后摩设备手动复位，并结合日志进一步定位问题。

Status::ERR_FATAL （C++） | 自动复位失败，后摩设备无法通过自动复位恢复。 | 停止当前推理流程，手动执行后摩设备复位，再重新启动推理程序。手动复位需重新创建 Module、重新加载模型，以及重新创建 Stream。
Status::ERR_KERNEL （C++） | 与自动复位过程异常相关。常见于以下场景：

  • 后摩设备在自动复位过程中，应用进程或其他线程继续调用TCIM API。
  • 后摩逻辑设备间通信异常。
  • 在多线程场景下，当某个超时线程触发自动复位时，已在队列中排队等待执行的其他线程任务会被强行中断，并返回该错误码。

| 处理建议：

  • 多线程场景：设置主机端休眠一小段时间，再重新启动推理程序。
  • 其他：手动执行后摩设备复位。若问题持续出现，请结合日志进一步定位问题。

Status::RESOURCE_EXHAUSTED （C++） | 与自动复位过程异常相关。常见于以下场景：

  • 在多线程场景下，后摩设备在自动复位过程中，其他并发执行的推理任务或API调用因资源未完全释放而触发该错误。

| 建议主机端进行短时间的休眠，再重新启动推理程序。
RuntimeError （Python） | 无法明确具体的底层错误原因。 | 建议主机端进行短时间的休眠，再重新启动推理程序。
FatalError （Python） | 自动复位失败，后摩设备无法通过自动复位恢复。 | 停止当前推理流程，手动执行后摩设备复位，再重新启动推理程序。手动复位需重新创建 Module、重新加载模型，以及重新创建 Stream。

4.1.10.3. 环境变量配置​

自动复位机制默认开启。若在特定运维、调试或自动化测试场景下需要关闭该机制，并回退到手动硬复位流程，可通过环境变量 TCIM_XH2_AUTO_RESET 进行控制。

表 4.4 自动复位环境变量配置 环境变量名默认值取值说明
TCIM_XH2_AUTO_RESET1
  • 1：推理发生超时卡死时，TCIM自动接管并触发底层后摩设备复位。
  • 0：关闭自动复位机制。推理发生超时卡死后，需要用户手动执行硬复位。

4.1.10.4. 并发推理场景​

在并发推理场景下，多个线程可能共享同一后摩逻辑设备资源。当任一线程因推理卡死触发自动复位时，该后摩逻辑设备会进入短暂的复位窗口期。在此期间，同一后摩逻辑设备上的其他线程也可能受到影响。

典型行为如下：

  • 触发卡死的线程可能返回 Status::TIMEOUT。

  • 复位窗口期内，其他正在访问该后摩逻辑设备的线程可能返回 Status::UNAVAILABLE。

  • 复位成功后，各线程无需重新加载模型，也无需重新创建 Stream，可再次推理模型。

建议采用如下处理方式：

  • 返回 Status::TIMEOUT 后，重新准备输入并重新发起当前推理任务。

  • 返回 Status::UNAVAILABLE 后，等待一段时间再重试。

  • 返回 Status::ERR_FATAL 或 Status::ERR_KERNEL 后，停止当前推理流程，手动执行该后摩逻辑设备复位，再重新启动推理程序。

4.1.10.5. 芯片间互联部署场景​

在多设备或多芯片联合部署的大模型推理场景中，当其中一个后摩逻辑设备或一个计算阶段触发卡死时，多卡进程内部可能会连续或交替触发多次自动复位流程。

在该过程中，应用层可能会观察到以下现象：

  • 不同线程返回的状态码可能在 Status::TIMEOUT 和 Status::UNAVAILABLE 之间短暂交替。

  • 多个后摩逻辑设备可能不会在同一时刻完成复位。

  • 部分线程可能先进入可重试状态，部分线程仍处于后摩逻辑设备不可用状态。

上述现象属于芯片间互联恢复过程中的正常行为。用户可按照状态码处理建议进行处理。

4.1.10.6. 回调函数说明​

自动复位机制不会触发用户通过TCIM接口注册的 pre_reset 和 post_reset 回调函数。

4.1.10.7. 不适用场景​

自动复位机制主要用于处理推理阶段发生的轻量级硬件超时卡死问题。以下场景通常超出自动复位机制的覆盖范围：

  • 物理掉卡 ：后摩设备从系统中掉线或无法枚举。此类问题可能在日志中表现为模型初始化失败、后摩设备打开失败或后摩设备资源不可用。

  • 片间互联失败 ：芯片间互联场景下，片间通信链路异常。此类问题可能在日志中出现 Status::UNAVAILABLE 或连续出现 Status::TIMEOUT 状态码。

  • 复位流程被强制中断 ：后摩设备正在自动复位时，用户通过终端输入 Ctrl+C 强制终止，可能导致底层状态无法正常恢复。

发生上述问题时，应结合日志进行定位，并执行手动复位。

4.1.10.8. 注意事项​

自动复位期间请勿强制中断当前推理进程。例如，在后摩设备正在执行自动复位时，不建议通过终端输入 Ctrl+C 强制终止程序。如果自动复位控制流被外部信号中断，底层硬件或驱动状态可能停留在异常状态，后续重新启动推理程序时可能持续返回 Status::ERR_KERNEL，或出现初始化失败。

若发生该问题，需手动复位后摩设备。

4.1.10.9. 手动复位​

当自动复位失败或系统进入不可恢复状态时，需要执行手动复位以恢复运行环境。可通过后摩SMI工具 hm_smi -r <device_id> 完成复位，其中 <device_id> 表示后摩设备逻辑ID。

后摩SMI工具详情，参看 《SMI工具使用指南》。