3、多后端抽象层设计：统一接口、后端注册机制、能力查询与特性差异

NPU delegate 的价值在于将上层推理框架与底层不同厂商的 NPU 硬件解耦。然而，不同 NPU 的指令集、内存模型、算子实现和性能特性差异巨大。若直接在上层业务代码中为每个后端编写分支逻辑，会导致代码臃肿、难以维护，且无法适应新硬件的快速接入。多后端抽象层（Backend Abstraction Layer, BAL）正是为解决这一核心矛盾而设计的中间层。它通过定义一套稳定的统一接口，配合灵活的注册机制与能力查询协议，让上层应用能以一致的方式调度不同 NPU，同时保留对硬件特性的精细控制能力。本章将深入剖析这一抽象层的设计要点、实现路径与实战中的关键决策。

上图展示了多后端抽象层的整体架构。上层框架通过统一接口与抽象层交互，抽象层内部通过注册机制管理多个后端实例，并通过能力查询接口向上层暴露各后端的特性差异，最终由自动调度决策引擎根据模型特征与硬件状态选择最优执行路径。下面我们将从四个维度深入拆解这一设计。

3.1 核心原理：统一接口是契约，不是实现

统一接口设计的本质是定义一套稳定的语义契约，它规定了“做什么”和“返回什么”，但不规定“怎么做”。在 NPU delegate 场景中，这套契约通常包含以下核心操作：

• 生命周期管理：Initialize（初始化硬件上下文）、Finalize（释放资源）。
• 模型编译：CompileModel（将图表示编译为后端可执行格式，如 DLC、.tflite 或自定义二进制）。
• 张量绑定：AllocateTensor / BindTensor（管理输入输出缓冲，支持零拷贝）。
• 执行与同步：Execute（异步提交）、Synchronize（等待完成）、GetProfilingData（获取耗时与功耗）。

关键设计决策在于接口粒度的选择。粒度过粗（如仅提供 Run() 方法）会导致上层无法精细控制内存复用或异步流水；粒度过细（如暴露每个算子的底层指令）则会让抽象层退化为“转发层”，失去屏蔽差异的意义。实践中推荐采用分层接口：基础接口（必选）保证所有后端可用，扩展接口（可选）通过能力查询暴露高级特性。

class NpuBackend {
 public:
  virtual ~NpuBackend() = default;
  // 基础接口：所有后端必须实现
  virtual Status Initialize(const BackendConfig& config) = 0;
  virtual Status CompileModel(const GraphDef& graph, CompiledModel** model) = 0;
  virtual Status Execute(CompiledModel* model, const TensorList& inputs,
                         TensorList* outputs) = 0;
  // 扩展接口：通过 Capability 查询确认是否支持
  virtual Status AllocateZeroCopyBuffer(size_t bytes, void** ptr) {
    return Status::NotSupported("Zero-copy not available");
  }
  virtual Status GetHardwareTimestamps(uint64_t* start_ns, uint64_t* end_ns) {
    return Status::NotSupported("HW timestamps not available");
  }
};

这种设计让抽象层成为“最小可行契约”的载体。上层代码只依赖基础接口，即可保证在任何后端上正确运行；而性能敏感场景则通过能力查询动态启用扩展接口。

3.2 后端注册机制：从硬编码到插件化

注册机制解决的是“如何让抽象层知道有哪些后端可用”的问题。最原始的做法是硬编码 if-else 分支，但每增加一个后端就需要修改抽象层代码，违背了开闭原则。现代实现普遍采用工厂模式 + 注册表的组合。

操作流程：

1. 定义工厂函数类型：每个后端提供一个创建函数，返回 NpuBackend 的智能指针。
2. 注册宏或显式调用：在静态初始化阶段或显式初始化阶段，将后端名称与工厂函数绑定到全局注册表。
3. 按名称创建实例：上层通过字符串名称（如 "qcom_htp"）从注册表获取工厂并创建实例。
4. 支持优先级与别名：注册表可维护优先级列表，便于自动调度时按序尝试。

// 注册表核心实现
class BackendRegistry {
 public:
  using Factory = std::function<std::unique_ptr<NpuBackend>()>;
  static BackendRegistry& Global() {
    static BackendRegistry instance;
    return instance;
  }
  void Register(const std::string& name, Factory factory, int priority = 100) {
    factories_[name] = {std::move(factory), priority};
  }
  std::unique_ptr<NpuBackend> Create(const std::string& name) {
    auto it = factories_.find(name);
    if (it == factories_.end()) return nullptr;
    return it->second.factory();
  }
 private:
  std::unordered_map<std::string, Entry> factories_;
};

// 后端侧注册（在 .cc 文件中）
static bool reg_qcom = []() {
  BackendRegistry::Global().Register("qcom_htp", []() {
    return std::make_unique<QcomHtpBackend>();
  }, /*priority=*/10);
  return true;
}();

注册机制的另一个重要职责是处理后端依赖的第三方库。例如，Qualcomm 后端依赖 libQnnHtp.so，MediaTek 后端依赖 libmtk_dsp.so。注册时不应直接加载动态库，而应通过延迟加载（dlopen）或依赖注入的方式，避免因某个后端库缺失导致整个 delegate 初始化失败。实战中，我们通常将“注册”与“可用性探测”分离：注册表记录所有编译期已知的后端，但只有在运行时探测到对应硬件驱动或库文件时，该后端才被标记为“可用”。

3.3 能力查询与特性差异：让差异显式化

能力查询是抽象层中最具挑战性的部分。它需要回答三个问题：支持什么？支持到什么程度？代价是什么？ 一个设计良好的能力查询接口，应当返回结构化的特性集合，而非简单的布尔值。

能力查询接口的设计应遵循“默认保守，按需开放”原则。即：未明确声明支持的特性，一律视为不支持。这样可以避免因后端实现细节变化导致上层误判。同时，能力查询结果应缓存，因为查询过程可能涉及硬件探测或驱动调用，代价较高。

3.4 实战案例：构建一个支持双后端的自动调度器

下面通过一个具体案例，展示如何将上述设计落地。假设我们正在为某 Android 设备开发一个图像分割应用，设备同时具备 Qualcomm HTP 和 MediaTek APU 两个 NPU（实际设备通常只有一颗，此处为演示多后端协同）。

背景与约束：

• 模型：DeepLabV3+，输入 512x512x3，输出 512x512x21。
• 目标：在保证 mIoU 下降不超过 0.5% 的前提下，将延迟从 80ms 降至 40ms 以内。
• 约束：应用需兼容两款芯片，且不能因后端切换导致内存峰值超过 500MB。

初始现象：使用单一 Qualcomm 后端时，延迟为 45ms，满足要求，但功耗较高（平均 4.2W）。使用 MediaTek 后端时，延迟为 55ms，功耗较低（3.1W），但部分算子（如 ResizeBilinear）被回退到 CPU，导致延迟不稳定。

分析判断过程：

1. 通过能力查询发现，Qualcomm 后端支持所有算子且支持 per-channel INT8，而 MediaTek 后端不支持 ResizeBilinear 的 INT8 实现。
2. 进一步查询性能提示字段，发现 MediaTek 后端在 3x3 深度卷积上吞吐量高于 Qualcomm，但在 1x1 普通卷积上较弱。
3. 决定采用算子级混合调度：将模型拆分为两个子图，分别部署到不同后端。

实际操作步骤：

// 伪代码：基于能力查询的混合调度
auto qcom_caps = qcom_backend->QueryCapability();
auto mtk_caps = mtk_backend->QueryCapability();

// 1. 图分割：将 ResizeBilinear 及其下游算子分配给 qcom
GraphPartition partition = SplitGraph(
    model_graph,
    /*op_filter=*/[](const OpDef& op) {
      return op.type == "ResizeBilinear" ? kQcom : kAuto;
    });

// 2. 编译两个子图
CompiledModel* qcom_model = qcom_backend->CompileModel(partition.subgraph_qcom);
CompiledModel* mtk_model = mtk_backend->CompileModel(partition.subgraph_mtk);

// 3. 执行时，先执行 qcom 子图，再执行 mtk 子图，中间张量通过共享内存传递
void* shared_buffer = AllocateSharedMemory(512*512*21*sizeof(float));
qcom_backend->Execute(qcom_model, inputs, {shared_buffer});
mtk_backend->Execute(mtk_model, {shared_buffer}, outputs);

结果对比：

风险与代价：混合调度引入了额外的张量拷贝（共享内存跨后端传递），增加了约 5ms 开销。同时，两个后端并行执行时，需要处理同步问题，代码复杂度显著提升。最终我们通过异步执行 + 双线程掩盖了同步开销。

复盘经验：能力查询的价值不仅在于“能不能用”，更在于“怎么用更优”。如果仅依赖布尔型支持查询，我们只会选择单一后端；而通过性能提示字段，我们发现了混合调度的可能性。建议在能力查询结构中预留扩展字段（如 JSON 格式的附加信息），以便后端提供更细粒度的调优建议。

3.5 常见误区与总结复盘

误区一：追求“完全统一”的接口。 试图让所有后端行为完全一致是不现实的。例如，某些 NPU 要求输入张量按 16 字节对齐，而另一些则要求 64 字节对齐。抽象层应允许后端通过能力查询声明对齐要求，上层在分配内存时按最大对齐值分配，而非强制所有后端统一。

误区二：忽略“回退路径”的设计。 当 NPU 不支持某个算子时，必须回退到 CPU。但回退不应是简单的“整体回退”，而应支持算子级回退。抽象层需要维护一个“支持算子集合”，并在图分割时自动将不支持的算子标记为 CPU 执行。这要求统一接口中提供 IsOpSupported(op_type, tensor_dtypes) 的细粒度查询。

误区三：注册机制中静态初始化顺序问题。 如果多个后端的注册函数依赖全局变量，可能因初始化顺序不确定导致崩溃。解决方案是使用 Meyer's Singleton（函数内静态局部变量）或显式初始化阶段（在 main 函数早期调用 InitializeAllBackends()）。

误区四：能力查询结果不缓存。 每次调度都调用 QueryCapability() 会引入不可忽略的开销（尤其是涉及驱动 IPC 时）。应在后端创建后立即查询并缓存，仅在硬件状态变化（如低电量模式）时失效。

总结：多后端抽象层的设计核心是“稳定的契约 + 显式的差异”。统一接口保证基本可用性，注册机制保证可扩展性，能力查询则让性能优化成为可能。三者缺一不可。在实际工程中，建议先定义最小可用接口，跑通全链路，再逐步通过能力查询扩展高级特性。记住：抽象层不是用来消除差异的，而是用来管理差异的——让差异可见、可查、可决策，这才是自动调度的基础。