类别: 运行时:核心意外停止
此错误表示 TPU 核心过早停止执行指令。这是一种严重错误状态,硬件会因无法恢复的故障、违反硬件限制或由编译器生成的运行时断言触发的有意中断而强制停止。
示例出错提示:
INTERNAL: Accelerator device halted prematurely, perhaps due to an on-device check-failure. Node 0 halted unexpectedly at tag:pc TensorCoreSequencer:1:0x1d9 ...
XLA 后端: TPU
概览
XLA 会将 JAX 程序编译为一系列低级汇编指令。 在运行时,TPU 设备会按顺序执行这些指令。当 TPU 硬件遇到无法恢复的情况(阻止进一步执行)时,就会发生“Core Halted Unexpectedly”(核心意外停止)错误,从而强制核心进入致命的“HALTED”(已停止)状态。
由于此错误可能源于物理硬件故障、编译器 bug 或用户代码问题(尤其是在自定义内核中),因此您必须仔细分析日志消息以确定具体原因。
调试
如需解决此错误,您必须先确定是哪种特定场景导致了意外停止。请检查日志中是否有下述特定文本签名。
- "observed errors are: [Hardware/Network/Power]":这表示 物理基础架构故障。→ 跳转到 场景 1:基础架构故障(硬件/网络/电源)
- " observed errors are: [User]":这表示违反了硬件限制 。→ 跳转到 场景 2:违反硬件限制
错误消息包含具体详细信息,例如以下关键字:
BoundsCheck、scheckne、scheckeq、schecklt、scheckge、scheckbetween这表示已编译程序中由编译器生成的断言在执行期间失败。→ 跳转到 场景 3:XLA 编译器生成的断言失败
场景 1:基础架构故障(硬件/网络/电源)
签名: 日志明确指出 observed errors are: [Hardware] 或 observed errors are: [Network] 或 observed errors are: [Power]。
这表示与您的软件或模型逻辑无关的物理基础架构故障。TPU 芯片、连接芯片的网络结构或电源已发生故障。
- 重试作业: 如果问题是瞬时电压下降或网络波动,简单的重试可能有效。
- 识别并移除不良节点: 如果同一特定任务或主机上持续出现错误,则硬件可能存在缺陷。使用集群管理工具“排空”/“隔离”受影响的节点,并在正常节点上重启作业。
场景 2:违反硬件限制
签名: 日志指出 observed errors are: [User]。
这表示 XLA 编译器生成了一条违反不可侵犯的硬件限制的指令(例如,一条尝试访问 HBM 或 Scratchpad 内存上超出范围的内存地址的指令)。虽然标记为“User”,但这种情况很少是由高级用户代码引起的。
- 提交 XLA bug: 这很可能是编译器 bug,编译器绝不应发出违反硬件规范的指令。 请提交错误报告。
场景 3:XLA 编译器生成的断言失败
签名: 错误消息包含有关失败的编译器生成的断言的具体详细信息。查找以下关键字:
BoundsCheck、scheckne、scheckeq、schecklt、scheckge、scheckbetween
这表示已编译程序中由编译器生成的断言在执行期间失败。分析具体错误消息以确定子类型。
场景 3.A:启动组不匹配
示例出错提示:
Core halted unexpectedly: INTERNAL: Accelerator device halted prematurely, perhaps due to an on-device check-failure. Node 0 halted unexpectedly at tag:pc TensorCoreSequencer:1:0x1d9 (from TensorCoreSequencer:1:0x309): scheckne: An unexpected leader shows up in the launch group with a different launch id than the current group leader.
原因: 此错误通常发生在多主机 TPU 环境中。它表示应以同步方式执行同一程序(作为“启动组”的一部分)的 TPU 核心已失去同步。 具体而言,TPU 核心加入了一个同步组,该组的程序标识符与当前组领导者不同,这表明主机之间的程序不一致。
- 验证 XLA 标志: 确保所有主机都使用完全相同的
XLA_FLAGS。 - 检查 JAX 程序是否一致: 检查所有主机是否都在执行相同的 JAX 程序。验证 Docker 映像、libtpu 版本等。
场景 3.B:边界检查失败
示例出错提示:
Core halted unexpectedly: INTERNAL: Accelerator device halted prematurely, perhaps due to an on-device check-failure. Node 0 halted unexpectedly at tag:pc TensorCoreSequencer:23:0x292 (from TensorCoreSequencer:23:0xd74a): BoundsCheck 92 [deref of %s931] for %937 = dma.hbm_to_vmem [thread:$0] /*hbm=*/%s931, /*size_in_granules=*/16384, /*vmem=*/%s935, /*dst_syncflagno=*/%s860, /*src_stride=*/512, /*dst_stride=*/128, /*steps_per_stride=*/8
原因: 程序尝试访问分配边界之外的内存。错误消息通常包含有关内存访问类型(例如 dma.hbm_to_vmem)和地址计算的详细信息。
- 调试自定义内核: 如果使用 Pallas,请检查索引计算。
使用
pl.debug_print或checkify验证张量索引。 - 检查分片: 确保分片注释与张量形状一致。
场景 3.C:Mosaic/Pallas 同步
示例出错提示:
Core halted unexpectedly: INTERNAL: Accelerator device halted prematurely, perhaps due to an on-device check-failure. Node 0 halted unexpectedly at tag:pc TensorCoreSequencer:21:0xae5 (from TensorCoreSequencer:21:0x54c5): Semaphore (scratch argument 1) has a nonzero value upon exit from a Mosaic kernel. Make sure every DMA is awaited, and every semaphore signal is paired with a wait.
原因: 此错误特定于 Mosaic 编译器(由 Pallas JAX 使用)生成的代码。它表示自定义内核中存在同步问题。TPU 使用信号量来管理依赖项(例如,确保 DMA 在使用前完成)。此错误表明信号量上的信号未得到正确等待。
- 审核同步: 确保每个
dma_start都有对应的dma_wait。 - 检查信号量: 验证信号量信号和等待是否严格配对。
未分类的问题
如果您的错误日志与场景 1、2 或 3 不匹配(即没有“observed errors”、没有“scheck”标记,也没有特定的边界/信号量消息):
- 操作: 这很可能是内部 XLA bug。 请提交错误报告。