想象你入住一家全球连锁酒店，推开房门却发现床头面板上嵌着七八种插座：有圆孔的、方孔的、Type-C 的，还有贴着“大功率专用”标签的独立回路。你只想给手机充电，难道要拖着一包转接头出门？于是这家酒店在每间客房装了一台“万能适配面板”——不管你用什么插脚，面板会自动识别电器规格、选择最匹配的回路，让电流在瞬间送到正确的地方。 在以手机为代表的边缘 AI 设备上，我们正面对同样的“插孔混乱”：高通芯片擅长跑卷积，苹果神经引擎擅长矩阵运算，有的 DSP 只认 int8 数据，老款 CPU 又只支持 float32。若开发者针对每种芯片各写一套推理代码，相当于为每个插座单独配一个充电器。Android NNAPI 和 iOS Core ML，正是两大移动平台各自打造的那台“万能适配面板”。本文会用这台面板做主线，带你理解统一加速接口、驱动适配、模型转换、能力查询与回退机制，并最终搭起跨平台移动 AI 推理的完整图景。

岗位关联

学透移动端统一加速接口，你就能在边缘设备上把模型调度得又快又稳，这是 AI 从云端走向千家万户的关键工程能力。

目录
  1. 可视化演示
  2. 统一加速接口
  3. NNAPI驱动适配
  4. Core ML转换
  5. 设备能力查询
  6. 推理回退机制
  7. 跨平台抽象层
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示Android NNAPI的分层架构、推理执行流程与设备能力查询回退机制。切换模式查看不同维度，拖动滑块调节推理负载。

本节配有交互动效（进入视口后自动加载，约 3KB）。

NNAPI分层架构设计 应用层：TensorFlow Lite/Caffe2等框架通过NNAPI C API调用 运行时：NNAPI RTL负责模型编译、内存管理与算子调度 latency = t_compile + t_execute + t_memcpy 推理延迟由编译、执行与内存拷贝时间组成

统一加速接口

你拖着行李箱走进那家连锁酒店，想赶紧给手机充电。可面前的面板嵌着圆孔、方孔、Type-C、大功率专用孔，你的充电器根本插不进去。酒店的万能适配面板解决了这个难题——它不关心你的插脚长什么样，只负责把电安全送到设备里。移动端 AI 的处境完全相同：高通 SoC 里的 Hexagon DSP、苹果的 Neural Engine、Adreno GPU、Mali GPU……每种芯片都有自己的“方言”，而 NNAPI 与 Core ML 就是官方准备的万能面板。

NNAPI（Android Neural Networks API）从 Android 8.1 起向开发者提供统一的神经网络推理接口。无论底层是 NPU、GPU 还是 DSP，上层模型只需走同一套 API 调用。iOS 的 Core ML 同理，把模型封装为 .mlmodel 格式后，由系统决定如何在 ANE（Apple Neural Engine）、GPU、CPU 之间分配。两层都遵循同一个理念：把硬件差异挡在接口之后，让应用开发者只面对“插孔”——也就是一个稳定的推理入口。

不过，万能面板虽然省掉了转接头，但它自己也有开销。一次推理的总耗时可以分解成三部分：

理解这三段时间，你就明白为什么小模型有时反而感受不到 NPU 加速——当 T_compute 很短，T_dispatch 和 T_collect 就成了主导。这也是接下来驱动适配要重点优化的对象：让面板“识别插脚”更快更准。

Ttotal=Tdispatch+Tcompute+Tcollect\displaystyle T_{total} = T_{dispatch} + T_{compute} + T_{collect}
总推理耗时 = 调度时间 + 硬件计算时间 + 结果回收时间。T_dispatch 是面板识别电器规格的“握手”过程，T_compute 是真正跑算子的时间，T_collect 是把计算结果取回应用内存的过程。
  1. 调度时间 $T_{dispatch}$请求从应用层传入接口，到硬件正式开工前的所有准备工作，包括张量格式转换、内存分配、驱动唤醒等。好比面板识别插脚规格并完成回路切换。
    Tdispatch=tconvert+tallocate+twakeT_{dispatch} = t_{convert} + t_{allocate} + t_{wake}
  2. 计算时间 $T_{compute}$硬件真正执行算子前向传播的耗时，由模型总运算量除以设备峰值算力得到。算力越强的芯片，这条回路送电越快。
    Tcompute=MopsPdeviceT_{compute} = \frac{M_{ops}}{P_{device}}
  3. 结果回收时间 $T_{collect}$计算完成后把输出张量从硬件内存复制回应用内存的时间，等价于面板确认充电完成并断开回路的收尾动作。
    Tcollect=Nparams×KbytesBbusT_{collect} = \frac{N_{params} \times K_{bytes}}{B_{bus}}

NNAPI驱动适配

万能面板不是酒店自己装的，而是由各国插座厂商派电工来接线。为了保证所有房间的面板长得一样，酒店集团下发了一本《排线手册》：火线什么颜色、零线怎么走、地线接哪里，全部标准化。在 NNAPI 的世界里，这本手册叫 HAL（Hardware Abstraction Layer，硬件抽象层）。高通、联发科、华为这些芯片厂商，都必须按 HAL 规范编写自己的驱动，才能让芯片被系统识别、调度。

驱动适配要回答三个问题：支持哪些算子？每个算子支持什么精度？性能基准如何？厂商把这些信息写进驱动，NNAPI 运行时再汇总成一张“能力表”。当应用发起推理时，运行时把模型算子与能力表做匹配，生成一份执行计划。比如 NPU 不认某个自定义激活函数，运行时就把这段算子“切割”出来，扔给 CPU 去算，其余部分继续走 NPU。

多个硬件的能力叠加起来，就构成了整机可用的算子范围：

这一节解释了为什么驱动适配是移动 AI 里最容易被低估的脏活：面板背后站着无数个电工，只要有一个厂商没按手册接线，应用层的体验就会出现“识别慢、跳闸多”。选择成熟的 SoC 平台，本质就是在选择一本排线更规范的手册。

Odriver=⋃i=1nOi\displaystyle O_{driver} = \bigcup_{i=1}^{n} O_i
O_i 表示第 i 个硬件支持的操作算子集合。整个驱动能执行的算子范围，是所有加速器算子集的并集；其中各硬件都支持的交集部分，才是可以自由加速的区域。
  1. 硬件算子集 $O_i$每个加速器对算子的支持范围天差地别。NPU 可能覆盖绝大多数标准卷积，却缺少某个自定义激活函数；GPU 刚好相反。这就像不同电工接的插座，有的支持大功率电吹风，有的只够充手机。
    Oi={op∣硬件i支持执行算子op}O_i = \{op \mid 硬件 i 支持执行算子 op\}
  2. 整机算子并集所有硬件算子范围取并集，代表整机能执行的算子全集。集合越大，模型在端上跑通的可能性越高。
    Odriver=⋃i=1nOiO_{driver} = \bigcup_{i=1}^{n} O_i
  3. 算子切割判定当模型中的算子不属于任何硬件的支持集，运行时将该算子分配到 CPU 执行，其余算子仍留在加速器上——这就是常常听到的“算子切割”。
    op∉⋃i=1nOi⇒op 分配给 CPU 执行op \notin \bigcup_{i=1}^{n} O_i \quad \Rightarrow \quad op \text{ 分配给 CPU 执行}

Core ML转换

走到苹果酒店分店，你会发现面板干净很多：只有 Type-C 和 Lightning 两种孔。苹果把插座标准统一了，但前提是你的充电器得配得上——如果你带来的是欧标插头，就必须先套一个转接头。Core ML 的“转接头”就是 coremltools 转换工具。TensorFlow、PyTorch 训练出的模型，必须转换成 .mlmodel 格式，才能在 iPhone 上跑推理。

转换过程并不是改个后缀那么简单。coremltools 会做算子映射、权重重排、常量折叠，还会按你的配置做模型压缩。移动端内存和带宽有限，通常会把 float32 权重降到 float16 甚至 int8。绝大多数模型在 fp16 下精度损失微乎其微，但 int8 量化就需要更谨慎：敏感结构（如检测头的回归分支）可能产生明显的边界偏移。

因此，每次转换后都要回头验证精度变化。这个验证有一个简单直观的量化指标：

转接头图便宜，插上就滋滋响；转换策略图省事，模型输出就会漂。核心教训是：Core ML 的转换管道不是“一键无损搬家”，而是一次需要验收评测的工程交付。

Lconvert=∣Accfp32−Accconverted∣\displaystyle L_{convert} = | Acc_{fp32} - Acc_{converted} |
转换损失 = 原模型准确率与转换后模型准确率的绝对差。差值越大，说明当前量化策略或算子映射对该模型越不友好。
  1. 原模型精度 $Acc_{fp32}$转换前 fp32 模型在固定验证集上的准确率，是精度的“出厂基准线”。
    Accfp32=NcorrectNtotalAcc_{fp32} = \frac{N_{correct}}{N_{total}}
  2. 转换后精度 $Acc_{converted}$同一验证集上加载 .mlmodel 后的准确率。如果转换算子映射不当或量化过狠，这个数字会明显下滑。
    Accconverted=Ncorrect′NtotalAcc_{converted} = \frac{N'_{correct}}{N_{total}}
  3. 损失计算 $L_{convert}$绝对差越小，转换保真度越高。业界习惯设定阈值（如 0.5%）来判断是否接受当前转换配置。
    Lconvert=∣Accfp32−Accconverted∣L_{convert} = | Acc_{fp32} - Acc_{converted} |

设备能力查询

万能面板上那块小屏幕很有用：显示“本回路支持 20W 快充，需 USB-PD 协议”。你不需要拆开墙板试错，看一眼就知道行不行。NNAPI 从 1.2 版本提供 getCapabilities()，Core ML 通过 mlComputeUnits 和 deviceHasANE() 等接口暴露硬件能力。这些 API 就是面板上的小屏幕——让开发者在推理之前就知道“这台机器能插什么电器”。

能力查询不只是拿一张“支持/不支持”的清单，更要回答“多个可用设备选谁”。NNAPI 的 Device 对象会携带性能特征（如 FLOPS、内存带宽），Core ML 的计算单元偏好则允许开发者声明“优先 ANE、其次 GPU、最后 CPU”。我们可以在启动时把各设备的能力打成矩阵，然后按业务需求做加权评分。

假设每个设备有 n 项可量化指标，综合评分如下：

有了小屏幕，你不再盲目试插孔；有了能力查询，应用就能在服务启动时和运行中持续评估“哪条回路最稳”，并根据设备温度、负载变化动态调整，而不是等崩溃了再补救。

S=∑i=1nwi×qi\displaystyle S = \sum_{i=1}^{n} w_i \times q_i
S 是设备综合能力分。q_i 是第 i 项指标的归一化得分（范围 0~1），w_i 是业务侧对该指标的重视程度，所有权重之和为 1。
  1. 指标得分 $q_i$对算力、功耗、延迟等指标的归一化处理。比如算力 11 TOPS 映射为 1.0，0.3 TOPS 映射为 0.2，消解不同量纲的可比性问题。
    qi∈[0,1]，表示第 i 项指标的归一化得分q_i \in [0, 1] \text{，表示第 } i \text{ 项指标的归一化得分}
  2. 权重 $w_i$不同的业务场景权重不同——实时视频检测更看重延迟，待机常驻的语音助手更看重功耗，因此权重是业务侧配置而非硬件固定值。
    ∑i=1nwi=1\sum_{i=1}^{n} w_i = 1
  3. 加权求和把分数与权重逐项相乘后求和，得分最高的设备就是本请求的候选执行端。这相当于面板屏幕上对多个回路同时做“适配度排名”。
    S=∑i=1nwi×qiS = \sum_{i=1}^{n} w_i \times q_i

推理回退机制

深夜电压不稳，万能面板在主回路跳电时会自动切换到应急照明回路，并闪一下指示灯。你也许不会留意电流走了哪条回路，但你在意手机是不是在充电。回退机制就是 AI 应用的应急照明——当 NPU 驱动崩溃、GPU 负载过高、某个算子不匹配时，推理任务自动降级，而不是直接让用户看到“应用无响应”。

优秀的回退链不是简单粗暴的“失败就换一个”，而是需要设计优先级和降级策略。典型链路是：优选 NPU → 次选 GPU → 再选 DSP → 最终 CPU。同时还要考虑精度模式切换：fp16 跑不动，就转成 int8 再试一次；再不行，业务层可以降级（比如从“精确检测”降级为“粗略判断”）。每条回退路径都应记录日志，以便后续统计和优化。

回退机制的可靠性可以用概率模型来评估。设第 i 个加速器独立执行成功的概率为 p_i，那么整个回退链最终成功的概率为：

应急回路不需要每次都启用，但一旦主回路跳电你还在充电，这就是可靠性的价值。工程上，我们甚至可以在回退触发时顺带上传一条匿名日志——把“跳闸”记录变成下一次面板优化的依据。

Pall=1−∏i=1n(1−pi)\displaystyle P_{all} = 1 - \prod_{i=1}^{n} (1 - p_i)
整条回退链完全失败的概率等于各级失败概率的连乘。硬件越可靠、回退层次越多，P_all 就越接近 1，用户无感降级的概率就越高。
  1. 单设备成功概率 $p_i$通过真实负载统计得到，比如 NPU 在十万次推理中成功九万八千次，p=0.98。
    pi=NsuccessNattemptsp_i = \frac{N_{success}}{N_{attempts}}
  2. 单设备失败概率与成功概率互补，代表由该设备引起的回退触发率。
    1−pi1 - p_i
  3. 全链路失败概率各层回退都失败的概率，等于各失败概率连乘。回退层级越多，这个值越小。
    ∏i=1n(1−pi)\prod_{i=1}^{n} (1 - p_i)
  4. 最终成功概率用 1 减去全链路失败概率，得到至少有一级成功执行的总体可靠性，是回退链设计的核心指标。
    Pall=1−∏i=1n(1−pi)P_{all} = 1 - \prod_{i=1}^{n} (1 - p_i)

跨平台抽象层

连锁酒店发展成了全球集团，巴黎、东京、上海的分店越开越多。于是集团推出“全球统一客房标准”：面板外观、插孔排布、指示灯颜色全部一致。旅客在纽约学会怎么充电，到了东京依然会。跨平台统一抽象层就是移动 AI 应用里的这份“全球客房标准”——业务团队只需要学会一套接口，就能同时指挥 Android 的 NNAPI 和 iOS 的 Core ML。

抽象层通常对上层暴露三个方法：createSession、runInference、queryDevice。内部实现则按平台分流：Android 端走 NNAPI，iOS 端走 Core ML。模型也要双格式发布——同时导出 .tflite 和 .mlmodel，并在构建脚本中统一校验两者输出一致性。

但抽象层最忌讳的是“把差异强行磨平”。NNAPI 允许按设备名指定 NPU 或 GPU，Core ML 允许偏好 ANE 或 CPU——这些平台特色能力必须透传给上层。为此，需要一个可量化的基线来做两平台的性能对比：

当每间客房的面板长得一样，旅客才会获得确定性的体验；当 NNAPI 和 Core ML 被同一抽象层收编，团队才能实现“模型训练一次、两端部署、统一度量”。这就是边缘 AI 从造轮子走向工程化的关键一步。

Snorm=SdeviceSreference×100%\displaystyle S_{norm} = \frac{S_{device}}{S_{reference}} \times 100\%
归一化性能分 = 被测设备某项性能原始分 ÷ 参考设备同项分数 × 100%。它把不同平台、不同量纲的帧率或延迟统一成相对百分比，便于横评比对。
  1. 绝对性能分 $S_{device}$用同一套基准测试脚本（如固定输入尺寸的 MobileNet）分别测量 Android 和 iOS 设备上的推理帧率。
    Sdevice=FPS 原始值（同模型同输入）S_{device} = \text{FPS 原始值（同模型同输入）}
  2. 参考分母 $S_{reference}$选定一台机器作为“黄金基准”，比如项目组指定的某款中端手机，所有平台都以它为标尺。
    Sreference=参考设备的 FPS 原始值S_{reference} = \text{参考设备的 FPS 原始值}
  3. 归一化百分比 $S_{norm}$将原始分转为相对百分比后，Android 与 iOS 的能力就放在同一坐标轴上比较，方便在做技术选型和复盘时直接对话。
    Snorm=SdeviceSreference×100%S_{norm} = \frac{S_{device}}{S_{reference}} \times 100\%

AI 应用场景

手机本地相册智能分类

阶段：边缘推理部署与硬件调度

解决的问题：传统做法把用户照片上传云端做主体分类，既消耗流量又有隐私泄漏风险。利用 NNAPI/Core ML 将模型加载到本地，通过能力查询自动选择 NPU/GPU 执行；遇到无 NPU 的低端机时回退到 GPU/CPU，功能丝毫无损。整个推理链条像房间里的万能面板——照片不出手机，分类照常完成。

具体案例：某手机厂商在相册 App 中部署 MobileNet 分类模型，通过 NNAPI 查询设备能力后，将 fp16 推理派发给 NPU，单张平均耗时 12ms，比纯 CPU 快约 8 倍；在无 NPU 的低端机上自动回退 GPU，仍保持相册滑动不卡顿。

跨平台工业质检一体机

阶段：跨平台推理抽象与回退保障

解决的问题：工业产线同时部署 Android 控制台和 iOS 管理端，若分别适配两套推理 API，重复开发量巨大。借助统一抽象层，业务只看 createSession / runInference / queryDevice 三个方法，由抽象层在 Android 端调用 NNAPI、在 iOS 端调用 Core ML。

具体案例：某家电厂用同一份 ONNX 模型分别导出 .tflite 与 .mlmodel。Android 一体机通过 NNAPI 将划痕检测任务派给 GPU，iOS 管理端用 Core ML 做图片复核；两端准确率差小于 0.5%，联合开发周期缩短 40%。当 GPU 过热降频时，回退机制自动切换到 CPU 保证质检告警不中断。

Python 演示

python50 行
# 统一推理抽象层演示：模拟 NNAPI Core ML 能力查询与回退class EdgeDevice:    def __init__(self, name, fp16, int8, peak_tops):        self.name = name        self.supports_fp16 = fp16        self.supports_int8 = int8        self.peak_tops = peak_tops     def can_run(self, precision):        return self.supports_fp16 if precision == 'fp16' else self.supports_int8     def run(self, task):        print('  [' + self.name + '] 执行 ' + task + ' 峰值算力 ' + str(self.peak_tops) + ' TOPS')        return True  class UnifiedInference:    def __init__(self):        self.devices = [            EdgeDevice('NPU', False, True, 11.0),            EdgeDevice('GPU', True, True, 1.2),            EdgeDevice('DSP', False, True, 0.8),            EdgeDevice('CPU', True, True, 0.3)        ]     def query_capabilities(self):        print('=== 设备能力查询 ===')        for d in self.devices:            fp = 'Y' if d.supports_fp16 else 'N'            i8 = 'Y' if d.supports_int8 else 'N'            print('  ' + d.name + '  fp16=' + fp + '  int8=' + i8 + '  peak=' + str(d.peak_tops) + ' TOPS')     def dispatch(self, task, precision):        print('=== 推理请求 ' + task + ' 精度=' + precision + ' ===')        for d in self.devices:            if d.can_run(precision):                d.run(task)                return d.name            print('  [!] ' + d.name + ' 不支持 ' + precision + ' 回退...')        print('  [兜底] 所有设备不支持 改用 CPU 低精度执行')        return 'CPU'  if __name__ == '__main__':    engine = UnifiedInference()    engine.query_capabilities()    print()    engine.dispatch('图像分类', 'fp16')    print()    engine.dispatch('目标检测', 'int8')
目的：演示一个简化的统一推理抽象层，模拟设备能力查询以及推理请求在 NPU/GPU/DSP/CPU 之间按能力回退的完整流程。
  1. def can_run(self, precision):能力查询的核心：判断设备是否支持某精度，对应正文中的能力查询 API。
  2. if d.can_run(precision):运行时检查，只有通过才把推理请求派发给该设备，等价于万能面板先看回路支不支持再送电。
  3. print(' [!] ' + d.name + ' 不支持 ' + precision + ' 回退...')回退日志，帮助开发者监控调度质量并持续优化回退链。
  4. engine.dispatch('图像分类', 'fp16')演示一个会发生回退的请求：NPU 不支持 fp16，自动落到 GPU 执行。
  5. engine.query_capabilities()启动时查询设备能力，作为后续推理调度的重要依据，对应 NNAPI 的 getCapabilities。

常见误区

误区我以为只要调用了 NNAPI 接口，系统就会自动选中最高效的 NPU，不需要自己操心调度逻辑。

正解NNAPI 提供的是能力协商框架，不是“一键最优”的黑魔法。驱动会暴露支持范围和性能特征，但最终调度依赖应用层合理查询、编译和回退。系统保证接口合规，不保证绝对最优，就像万能面板只保证回路能通电，不保证每次都是你最喜欢的那条线路。

为何常见：Android 官方示例大多只演示“调用成功”，很少展示“如何挑选设备”，容易让人误以为加速完全自动。

误区模型转成 .mlmodel 就是无损转换，和原来一模一样，不需要再验证。

正解转换过程若使用 fp16/int8 量化，会丢失部分数值精度，尤其目标检测的回归头等敏感结构。需要用验证集重新计算 L_convert，和转换前对比，确认损失在可接受范围内。苹果工具只是尽力优化，不是“无损压缩”。

为何常见：转换工具提示“转换成功”时，开发者很自然地把“成功”理解为“无损”，忽略了数值精度差异。

误区启动时拿到能力表，之后一直沿用就行，不用在运行时反复查询。

正解设备能力会动态变化：NPU 可能因发热降频、GPU 可能被其他进程抢占、iOS 进程可能被系统降权。最佳实践是启动时查询一次基线，运行中结合温度和负载做热感知调度，并在超时后触发回退。

为何常见：PC 时代的“静态能力检测”思维惯性，让开发者低估了移动设备资源的高度动态性。

误区Android 用 NNAPI、iOS 用 Core ML，两边接口都“统一”了，直接各写各的不就好了吗？

正解两个平台的 API 完全不同：NNAPI 以设备列表为中心，Core ML 以计算单元偏好为中心；模型格式也不同（.tflite vs .mlmodel）。跨平台抽象层要解决的是模型双格式管理、接口收敛、基准测试统一等问题，而不是把两个 SDK 换名覆盖。

为何常见：“跨平台”这个词太响亮，让团队误以为抽象等于消灭差异，而事实上好的抽象恰恰是保留并隔离差异。

面试题

Q1. NNAPI 从哪个 Android 版本开始正式引入？

单选题 · easy

  • A.Android 7.0 Nougat
  • B.Android 8.1 Oreo← 正确答案
  • C.Android 9.0 Pie
  • D.Android 10 Q

答案：B。NNAPI 在 Android 8.1（API 27）正式推出，相当于酒店统一安装万能面板的起点版本。Android 7.0 时代相关能力还在早期预览，9.0 和 10 则是在 8.1 基础上的增强，所以正式引入版本选 B。

Q2. Core ML 模型转换后的标准文件格式是什么？

单选题 · easy

  • A.轻量级模型格式 .tflite
  • B.开放交换模型格式 .onnx
  • C.苹果模型格式 .mlmodel← 正确答案
  • D.历史遗留格式 .caffemodel

答案：C。Core ML 使用 .mlmodel（或新版 .mlpackage）作为统一载体，相当于苹果客房规定的插脚标准。.tflite 是 TensorFlow Lite、.onnx 是开放式交换格式、.caffemodel 是 Caffe 格式，它们都需要通过 coremltools 转换后才能被 Core ML 使用。

Q3. 在 NNAPI 驱动适配过程中，芯片厂商的驱动需要向系统上报哪些信息？

多选题 · mid

  • A.支持的算子列表← 正确答案
  • B.支持的数据精度类型← 正确答案
  • C.设备性能基准参数← 正确答案
  • D.用户的应用安装列表

答案：ABC。驱动适配的本质是“向面板上报自己能接什么电器”。算子列表、精度类型、性能参数（如 FLOPS、内存带宽）决定调度器能否正确指派推理任务。用户应用安装列表属于隐私数据，与硬件能力无关，驱动绝不会也不应上报。

Q4. 设备能力评分公式 S=Σw_i×q_i 的主要作用是什么？

单选题 · mid

  • A.将设备指标转化为综合评分← 正确答案
  • B.直接控制硬件时钟频率
  • C.替代训练过程的损失函数
  • D.将模型参数压缩到 int8

答案：A。这个公式相当于万能面板上的“综合适配分”。w_i 由业务偏好决定，q_i 是单指标归一化得分，加权求和后得到可比较的总分。它不直接调硬件频率、不参与训练，更不是量化压缩，而是辅助路由决策。

Q5. 下列哪些属于推理回退机制的合理设计？

多选题 · mid

  • A.优选 NPU 失败后依次切换 GPU与CPU← 正确答案
  • B.失败时直接将错误抛出给用户
  • C.回退同时记录日志与耗时指标← 正确答案
  • D.精度从 fp16 降级到 int8 重试← 正确答案

答案：ACD。回退机制类似酒店应急照明，核心是让服务不中断。A 是逐级降级，D 是精度降级重试，C 是回退过程的可观测性，都合理。B 把异常直接抛给用户属于失败处理而非回退设计，会严重伤害体验。

Q6. Core ML 在 iOS 上执行推理时，关于隐私性的说法正确的是？

单选题 · mid

  • A.模型必须上传苹果服务器才能推理
  • B.推理可以在设备本地完成，数据不出手机← 正确答案
  • C.Core ML 无法在离线环境工作
  • D.推理结果必须经过 iCloud 同步

答案：B。Core ML 的核心卖点就是本地推理，相当于在房间里直接用面板充电，不用把电器送到总电站。它完全支持离线运行。A、D 误以为苹果强制联网，C 与事实相反，只有 B 正确描述其隐私特性。

Q7. 某手机 NPU 支持 int8 但不支持 fp16，GPU 同时支持两者，CPU 也支持两者。模型是 fp16，哪个调度顺序最优？

单选题 · hard

  • A.GPU 优先，NPU 次之，CPU 兜底← 正确答案
  • B.NPU 优先，GPU 次之，DSP 再后
  • C.CPU 优先，DSP 次之，GPU 再后
  • D.DSP 优先，CPU 次之，NPU 再后

答案：A。最优调度应在不浪费尝试的前提下，尽快命中支持该精度且算力最强的硬件。模型为 fp16，GPU 支持且算力高于 CPU，因此优先试 GPU；NPU 虽然算力高但不支持 fp16，先试它只会白等一次。A 把 GPU 放最前、NPU 作次选备胎，兼顾效率与可用性。

Q8. 构建跨平台抽象层时，应保留哪些平台特有的扩展点？

多选题 · hard

  • A.NNAPI 的指定设备选择能力← 正确答案
  • B.Core ML 的计算单元偏好设置← 正确答案
  • C.平台私有模型格式内部内存布局
  • D.各平台能力查询的指标字段解析← 正确答案

答案：ABD。抽象层要“统一相似、保留差异”。A、B 是各平台独有且对性能有重大影响的配置，暴露给上层可让开发者做精细优化；D 的指标字段需透出，才能在两平台统一日志和监控。C 私有格式的内存布局属于内部实现细节，若暴露给上层，抽象层就失去了封装意义。

Q9. 以下哪项属于 Core ML 转换过程中的常见量化手段？

单选题 · hard

  • A.使用 fp16 降低权重存储体积← 正确答案
  • B.使用 dropout 增加泛化能力
  • C.使用 batch norm 加速训练
  • D.使用数据增强扩充训练集

答案：A。转换时的量化是为了让模型更小、更快，fp16/int8 是常见手段，好比把充电器的铜线换成轻量化材质。dropout、batch norm、数据增强都是训练阶段的课题，与模型转换环节无关，因此选 A。

Q10. 若四项能力得分为 [0.9, 0.7, 0.5, 0.3]，权重为 [0.4, 0.3, 0.2, 0.1]，加权评分 S 是多少？

单选题 · mid

  • A.0.65
  • B.0.70← 正确答案
  • C.0.80
  • D.0.75

答案：B。把权重与得分逐项相乘再求和：0.9×0.4 + 0.7×0.3 + 0.5×0.2 + 0.3×0.1 = 0.36 + 0.21 + 0.10 + 0.03 = 0.70。这就像给面板上每个指标按重要程度加权，最后得到一台设备的综合适配分，答案是 B。