本文详细介绍了地平线计算平台在多模型推理场景下，为解决任务抢占问题而设计的模型优先级控制策略。文章指出，BPU硬件本身不具备任务抢占能力，为实现此功能，工具链采用了软件层面的抢占机制。通过将模型编译时的Function Call（FC）粒度拆分，以及在推理API中设置不同的任务优先级，可以有效控制模型间的抢占行为。例如，通过设置`max_time_per_fc`参数，可以将长执行时间的FC拆分为多个短时间FC，从而允许高优先级任务在模型执行过程中进行抢占。文章还阐述了直连模式和中继模式两种工作模式，并提供了抢占示例的Trace图分析，清晰展示了优先级策略的实际运行效果。

🎯 **软件实现BPU资源抢占**：地平线征程6计算平台BPU硬件本身不直接支持任务抢占。为解决一个大型模型独占BPU资源影响其他高优先级任务的问题，工具链通过软件方式实现了BPU资源抢占功能。抢占的粒度被设计为Function Call（FC），即BPU在执行完一个FC后，可以暂时挂起当前模型，切换执行另一个模型，待新模型完成后再恢复原模型状态。

🛠️ **Function Call（FC）拆分是关键**：原始编译的hbm模型FC可能合并成一个长执行时间的FC，无法实现抢占。为解决此问题，可以通过在模型编译阶段（QAT方案）或模型转换阶段（PTQ方案）设置`max_time_per_fc`参数，将一个长FC拆分成多个短FC。例如，将一个10ms的FC拆分成10个1ms的FC，从而为抢占提供更细粒度的时机。

⬆️ **灵活的任务优先级设定**：UCP推理API允许通过`hbUCPSchedParam.priority`参数设置任务优先级。优先级共分为三类：普通任务（<254，不可抢占），高优抢占任务（=254，可抢占普通任务），以及Urgent抢占任务（=255，可抢占普通任务及254优先级任务）。抢占行为是系统级别的，不受进程限制，且不区分中继或直连模式。

🔄 **直连与中继模式选择**：UCP框架支持直连模式（系统默认）和中继模式。中继模式需启动`ucp_service`并设置环境变量`HB_UCP_ENABLE_RELAY_MODE=true`来启用，它支持多进程任务的统一调度。两种模式下UCP接口调用方式一致，用户可根据需求灵活选择，以优化性能和灵活性。

一、引言

多模型推理场景中，可能会存在谁先谁后，甚至 A 模型任务正在运行，但需要被 B 模型任务抢占的情况。针对这种情况，地平线提供了模型优先级控制策略。

二、优先级与抢占介绍

此功能仅支持在开发板端实现，x86 模拟器不支持此功能。

2.1 理论简介

征程 6 计算平台 BPU 硬件本身没有任务抢占功能，对于每一个推理任务，一旦它进到 BPU 计算后，在该任务执行完之前，会一直占用 BPU，其他任务只能排队等待。

此时容易出现 BPU 计算资源被一个大模型任务独占，进而影响其他高优先级模型任务的执行。针对这种问题，工具链开发了基于软件的方式 实现的 BPU 资源抢占功能。

需要关注：

hbm 模型在 BPU 上推理时，它表现为 1 个或者多个 function-call 的调用，其中 function-call 是 BPU 的执行粒度，多个 function-call 调用任务 在 BPU 硬件队列上按序进行调度，当一个模型所有的 function-call 都执行完成，那么一个模型推理任务也就执行完成了。BPU 模型任务抢占粒度设计为 function-call，即 BPU 执行完一个 function-call 之后，暂时挂起当前模型，然后切入执行另外一个模型，当新模型执行完成之后，再恢复原来模型的状态继续运行。 但是这里存在两个问题，第一是编译出来的 hbm 模型 function-call 都是 merge 在一起的，此时模型只有一个大（长）的 function-call，它无法被抢占；第二是每个 function-call 的执行时间比较长或者不固定，会造成抢占时机不确定，影响抢占效果。

为了解决上述两个问题，地平线进行了一些处理，下面介绍其操作方法：

如果您使用 QAT 方案：在 模型编译 阶段，需要在 compile 接口中添加 max_time_per_fc 选项，用于设置每个 function call 的执行时间（以微秒为单位），默认取值为 0 （即不做限制）。您可以自行设置这个选项，控制 hbm 上板运行时每个 function-call 的执行时间。假设某 hbm 总执行时间为 10ms，当模型编译时 将 max_time_per_fc 设置为 1000，则这个 hbm 将会从默认的 1 个 10ms function-call 被拆分成 10 个 1ms function-call。如果您使用 PTQ 方案，在 模型转换 阶段，需要在 YAML 文件 编译器相关参数（ compiler_parameters ）中，添加 max_time_per_fc 参数。

2.2 UCP 推理 API

板端推理 C++代码：需要在任务提交时设置 hbUCPSchedParam.priority 参数。

优先级按照是否支持抢占，可以分为：高优抢占优先级任务、普通优先级任务。

配置 infer 任务优先级小于 254，则为普通任务，不可抢占其他任务。配置 infer 任务优先级等于 254，则为高优抢占任务，可支持抢占普通任务。配置 infer 任务优先级等于 255，则为 urgent 抢占任务，可抢占普通任务和 254 抢占任务。

注意：

抢占（254/255）是系统级别的，即当前进程提交的抢占任务不仅能对进程内的普通任务，也可对其他进程的普通任务实施抢占行为。抢占不需要考虑 中继 relay 或 直连 direct 模式。优先级（0～253）在进程内可以按照优先级排序，跨进程优先级排序，需要启动中继模式。

2.3 工作模式

UCP 框架支持两种主要工作模式：直连模式和中继模式。系统默认运行在直连模式下。QNX 操作系统和 x86 仿真不支持中继模式。

中继模式下，支持多进程任务的统一调度，使用中继模式前，首先启动 ucp_service，service 文件位于 deps_aarch64/ucp/bin/service/ 路径下，并通过设置环境变量 HB_UCP_ENABLE_RELAY_MODE=true 来启用 Relay 模式，使得用户进程可以通过中继服务进行通信。

无论是直连模式还是中继模式，UCP 接口的调用方式保持一致，不会对编程逻辑产生影响。您可以根据实际需求灵活选择这两种模式，以满足系统在性能和灵活性方面的要求。

三、抢占示例介绍

示例 UCP trace 图如下：

上面的抢占模型 A，单独运行是 1.9ms下面的被抢占的模型 B，单独运行 17.1ms，且模型 B 设置的 Function call 是 1000us=1ms

分析如下：

模型 B 开启 Function call=1000 编译，在未发生被抢占情况时，latency 与不开启 fc 一致。抢占模型 A，在任务提交抢占时，会等待 1～2ms，再开始执行模型 A（因此模型 A wait 大约 3～4ms），在等待的 1～2ms 中，模型 B 继续执行，因此模型 B 相比于单独运行，wait 只会多～6ms≈1.9*3（3 次模型 A 执行时间）。模型 B 运行最后一个 function call 期间，不能被抢占，所以上面 最后那个 抢占模型 A 多等了一会，变成～2.1ms。

在 BPU Trace 中，可以看到更具体的 BPU 抢占与优先级详情，示例如下

图中：三个模型设置了三个优先级，其中 petr 最低优，且是分段可抢占的，googlenet 的 task_priority=255，resnet50 的 task_priority=254。