Chapter 13: NPU and Specialized Compute Units

本章讨论手机 SoC 中的 NPU、DSP、ISP、secure processor 和 sensor hub 如何进入移动操作系统的能力链路。读完后，读者应能定位一个本地 AI 功能经过哪些硬件单元，判断它适合 CPU、GPU 还是 NPU，追踪 Android 与 Apple 平台把专用硬件封装给 App 的边界，并解释本地推理对延迟、隐私、功耗和系统智能功能的影响。

贯穿本章的材料是一类常见 App 可见行为：相机或相册 App 在本地对一张人像执行实时增强。用户看到的是“预览更清晰、背景虚化更稳定、人物分割更准确、相册能搜索猫和文字”。系统内部要把 camera sensor 的原始数据送入 ISP，把神经网络模型送入 NPU 或 GPU，把持续传感器事件交给低功耗单元，把用户身份或密钥相关判断留在安全处理环境中。这个例子能覆盖本章的核心问题：专用硬件提供算力，移动 OS 决定算力以什么能力形式开放。

公开资料给出了两个重要边界。Android 的 Neural Networks API 曾作为高层机器学习框架访问硬件加速推理的系统接口；官方文档同时标注 NNAPI 在 Android 15 起 deprecated，性能关键工作负载建议迁移到替代方案，例如 TensorFlow Lite GPU runtime。AOSP 的 Neural Networks API drivers 文档仍说明 Neural Networks HAL 继续支持，用来抽象 GPU、DSP 等设备并让 framework 查询 driver 能力。Apple 公开材料主要落在 Core ML 和 Machine Learning & AI 页面：Core ML 面向端侧模型执行，Metal 面向 GPU 图形与计算，具体调度到 Apple Neural Engine 的内部策略属于平台实现细节。本章采用公开 API、公开 HAL 描述和可观察平台行为来建立系统模型。

13.1 NPU 与专用计算单元的系统位置

NPU 是神经网络处理单元（Neural Processing Unit）的常用名称，主要执行矩阵乘法、卷积、归一化、激活函数、量化张量计算等模型推理操作。它在 SoC 中的位置接近 GPU、ISP、内存控制器和电源管理域，因为推理任务需要持续读写 tensor buffer，也需要在功耗和温度预算内完成短时高吞吐计算。

专用计算单元的共同特征是“任务形态固定，硬件路径短，系统调度条件明确”。CPU 适合控制逻辑和通用分支；GPU 适合大规模并行图形与通用并行计算；NPU 适合被编译后的神经网络图；DSP 适合音频、语音、传感器信号和低延迟流式处理；ISP 适合 camera raw data 到可显示图像的流水线处理；secure processor 适合密钥、身份认证、可信执行和数据保护；sensor hub 适合低功耗常驻采样、步数、姿态和上下文事件。

以本章的人像增强为例，相机 sensor 先输出 raw frame，ISP 处理曝光、降噪、色彩和 HDR；NPU 或 GPU 运行人物分割、深度估计、超分辨率或语义识别模型；DSP 可能处理语音命令、降噪或音频事件；sensor hub 持续提供设备姿态、运动状态和低功耗唤醒；secure processor 参与 Face ID、指纹、密钥释放或受保护数据访问。这些单元没有直接暴露给普通 App。App 看到的是 Camera、Photo、Vision、Core ML、Media、Speech 或平台智能能力。

下面的图把一次本地人像增强放进跨层路径。图中“能力代理”代表系统服务、daemon、runtime 或 vendor service；不同平台名称不同，但职责相似：接收 framework 请求，检查调用者身份和策略状态，选择后端，提交 buffer，返回结果。

这条路径说明专用硬件在移动 OS 中通常处于 App 与硬件之间的中后段。App 发出的请求先被 API、权限、生命周期、电源状态和模型能力约束处理，再进入 runtime 或服务层。硬件只执行已经被系统包装、调度和授权过的任务。这个边界使系统能同时管理稳定性、隐私、功耗、兼容性和多 App 并发。

13.2 AI Inference、Image Processing、Signal Processing 的硬件分工

AI inference 指用已经训练好的模型对输入数据做推断。输入可以是图像、音频、文本、传感器序列或多模态特征，输出可以是分类、检测框、分割掩码、嵌入向量、生成结果或置信度。移动 OS 关心的核心问题是模型图、输入输出 buffer、数据类型、延迟目标和后端能力是否匹配。

Image processing 指图像采集和显示前的传统图像流水线。Camera raw data 通常先经过 ISP 的去马赛克、降噪、镜头校正、白平衡、HDR 合成、tone mapping、锐化和颜色转换。ISP 处理的是高带宽连续帧，路径靠近 camera interface、memory controller 和 display pipeline。它的任务通常由 camera HAL、camera service、vendor imaging stack 和系统相机框架共同组织。

Signal processing 指音频、语音、无线信号、传感器读数和低延迟事件流的处理。DSP 的优势在于固定采样率、固定窗口、低延迟、低功耗和持续运行。例如语音唤醒、音频降噪、回声消除、步态检测和设备姿态估计都更适合 DSP 或 sensor hub 处理。它们的结果常常以事件、特征或低频状态进入系统服务。

三类任务在本地人像增强中同时出现。ISP 先把 raw frame 转成稳定的 YUV 或 RGB buffer；NPU 对 buffer 运行人像分割或图像增强模型；DSP 处理用户语音指令或环境音；sensor hub 提供设备姿态，帮助相机决定防抖和方向；CPU 负责调度、状态机、错误处理和 UI 更新。系统的价值在于把这些单元串成可控流水线，使 App 获得一个稳定结果，而无需直接管理每个硬件队列。

任务类型	典型硬件	输入	输出	系统封装重点
AI inference	NPU、GPU、CPU	tensor、图像、音频、文本特征	分类、掩码、embedding、生成结果	模型兼容性、后端选择、buffer 交换、功耗预算
Image processing	ISP、GPU、NPU	raw frame、camera metadata	preview、capture、HDR、降噪结果	camera pipeline、stream 配置、帧同步、画质策略
Signal processing	DSP、sensor hub、CPU	音频采样、传感器序列、事件流	语音特征、活动状态、唤醒事件	低功耗常驻、批处理、延迟上限、后台策略
Secure processing	secure processor、TEE、secure element	密钥、认证挑战、受保护数据	验证结果、解密许可、签名结果	权限边界、数据保护、用户存在性、可信状态

这张表的判断顺序是：先看输入是什么，再看输出是否需要连续实时返回，再看任务对内存带宽和功耗的敏感程度，最后看平台公开接口能否稳定表达这个任务。任务能被系统表达成模型图、图像流、音频流、传感器事件或安全请求，才适合进入对应专用硬件路径。

13.3 CPU / GPU / NPU 的任务边界

CPU、GPU 和 NPU 的边界可以按六个维度判断：灵活性、吞吐、延迟、内存访问、功耗和模型支持范围。CPU 的灵活性最高，适合分支复杂、任务规模小、后处理多、需要快速适配的代码。GPU 的吞吐高，适合纹理、图像、矩阵和大量并行 kernel。NPU 的单位能效高，适合被编译器和 runtime 支持的模型子图。

灵活性决定了 fallback 路径。一个人像分割模型如果包含 NPU driver 不支持的算子，runtime 可能把整个模型交给 GPU 或 CPU，也可能把模型拆成多个子图，部分在 NPU 执行，部分在 CPU 执行。拆分会带来额外 buffer 同步、数据格式转换和调度开销。模型作者看到的是“同一模型在不同设备上延迟差异很大”，系统内部的原因是硬件后端支持范围和图拆分策略不同。

吞吐和延迟需要分开判断。NPU 可能在大 batch 或固定形状模型上拥有高吞吐，但相机预览要求每帧在固定时间内返回，例如 30 FPS 约对应 33.3 ms 的帧预算，60 FPS 约对应 16.7 ms 的帧预算。模型推理、ISP 处理、GPU 合成、UI 更新和显示提交共同使用这个预算。单次推理速度高并不自动保证预览流畅，系统还要考虑排队、buffer 等待和热状态变化。

内存访问是移动推理的常见瓶颈。NPU 计算核心本身很快，但 tensor 在 CPU、GPU、ISP、NPU 和 display pipeline 之间移动时，格式转换、cache 同步、shared memory、DMA buffer 和 fence 等机制会引入延迟。一个模型如果需要频繁在多个后端之间切换，实际耗时可能由数据搬运主导。系统 runtime 因此倾向于把连续子图放在同一后端，或者使用 driver-managed buffer、memory domain、IOSurface、AHardwareBuffer 等平台机制减少复制。

功耗边界决定长时间体验。CPU 在短任务上响应直接，但持续图像模型会推高电量消耗和温度；GPU 可以复用图形并行能力，但也要承担渲染和合成负载；NPU 单位推理能效通常更适合持续推理，但模型大小、内存带宽、driver 支持和温控状态仍会限制持续帧率。用户可见结果可能是预览帧率下降、增强效果关闭、模型切换到低分辨率输入或后台任务延后执行。

模型支持范围是 App 最容易忽略的系统边界。Android 公开 NNAPI 文档把 CPU、GPU 和 accelerator 统称为 NNAPI 语境中的 device，并说明 runtime 可以把工作负载分配到可用处理器；AOSP NN HAL 文档进一步说明 framework 会查询 driver capabilities，用性能和能效信息做分配。Apple 公开 Core ML 文档强调端侧执行、低内存占用和低功耗，具体后端由 Core ML 配置、模型结构、设备能力和系统策略共同决定。跨平台写法应把“模型能运行”和“模型稳定使用专用硬件运行”分开评估。

13.4 Driver、Runtime、Framework 对专用硬件的封装

专用硬件的开放路径通常分为四层：Framework 提供 App 可见对象，Runtime 编译和调度模型或媒体任务，系统服务或 vendor service 持有资源状态，Driver 负责队列、内存、同步和硬件命令提交。App 调用的是高层 API；runtime 与 driver 之间处理的是模型图、compiled plan、buffer handle、fence、priority、timeout 和 capability query。

Android 的公开路径可以用 NNAPI 和现代 ML runtime 共同理解。历史上，NNAPI 为 TensorFlow Lite 等高层框架提供基础层；Android 15 起 NNAPI NDK API deprecated，说明 App 侧性能关键路径需要按官方迁移方向选择替代 runtime。底层 Neural Networks HAL 继续作为 vendor driver 抽象，定义 framework 与 driver 的能力查询、模型准备和执行边界。这个版本边界很重要：读 Android 设备上的 ML 路径时，应区分 App 使用的 ML runtime、系统是否经 NNAPI 层、vendor 是否提供 NN HAL 或 GPU delegate、最终后端是否实际命中专用硬件。

Apple 的公开路径集中在 Core ML、Vision、Speech、Natural Language、Metal 和 Accelerate 等 framework。Core ML 面向模型部署和端侧执行；Vision 把图像分析封装成更高层请求；Metal 和 Metal Performance Shaders 面向 GPU 图形与计算；Accelerate 适合 CPU 上的低延迟数值和信号处理。公开 API 允许开发者配置模型加载、输入输出和部分 compute policy，但 Apple Neural Engine 的内部调度、驱动队列和系统 daemon 细节通常没有完整公开接口。工程判断应基于 Xcode 性能报告、Core ML 模型支持情况、设备系统版本和可观察性能表现。

下面的 Mermaid 图把 App 调用本地模型时的请求和返回分开。它表达的是通用责任链，名称不绑定单一平台。

这条链路中的关键检查点有四类。第一类是模型检查：数据类型、tensor shape、算子、量化格式和动态维度。第二类是资源检查：内存、buffer、优先级、timeout、设备热状态和电量策略。第三类是权限检查：相机、麦克风、照片库、定位、蓝牙、健康数据和用户授权状态。第四类是生命周期检查：App 是否前台、任务是否允许后台运行、系统是否处于低电量或高温状态。任何一类检查失败，用户看到的都可能只是“功能不可用、效果降低、等待变长或 App 返回错误”。

对开发者和系统读者来说，最稳定的追踪顺序是：先确认 App 调用的公开 API，再确认 API 背后的 runtime，再确认 runtime 支持哪些后端，再确认 driver 是否声明 capability，最后观察结果是否满足延迟、功耗和隐私目标。这个顺序比直接猜测“用了 NPU”更可靠，因为专用硬件命中情况往往由模型、系统版本、设备驱动和热状态共同决定。

13.5 隐私、功耗与本地推理的系统意义

本地推理的系统意义来自三个可见结果：数据留在设备上、网络往返减少、交互延迟降低。Android NNAPI 文档明确把 latency、availability、speed、privacy 和 cost 列为端侧推理收益，同时也提醒计算会增加电量消耗，模型体积会影响应用大小。Apple Core ML 文档也强调模型在用户设备上运行，减少网络依赖并保持响应性和数据私密性。两边公开材料共同指向同一个移动 OS 判断：端侧推理把云端服务问题转化为本机资源调度问题。

隐私边界需要落到数据路径。相册搜索如果把照片上传到服务器做识别，系统要处理网络传输、账号、云端存储、服务端日志和跨设备同步。相同识别如果在本地执行，照片像素、embedding 或中间特征可以留在设备上的受控存储和内存中。系统仍要处理照片权限、模型访问、缓存清理和索引权限；隐私风险没有消失，但暴露面从网络和云端服务收缩到设备内的 App、framework、system service 和存储边界。

功耗边界决定功能能否持续打开。一次离线图片分类对电池影响有限；持续相机预览增强、实时字幕、离线翻译和语音唤醒会长时间占用 compute unit、内存带宽和传感器路径。移动 OS 会通过分辨率、帧率、模型版本、后台限制、低电量模式和 thermal policy 调整任务。用户看到的结果可能是增强效果在低电量时关闭，后台相册索引延后，相机预览降低帧率，或者实时翻译在温度升高后响应变慢。

本地推理还改变了系统服务的责任。过去很多“智能”能力由云服务承担，移动 OS 主要负责网络请求、权限和缓存。端侧模型进入系统后，OS 需要管理模型下载、模型版本、硬件后端、内存占用、调度优先级、隐私声明和失败降级。一个相册搜索功能的责任链会变成：照片库权限决定可索引范围，系统媒体服务决定扫描时机，ML runtime 决定模型后端，存储服务保存索引，搜索 UI 展示结果，低电量和温控策略决定后台索引速度。

本地推理的正确判断方式是同时看收益和约束。收益包括低延迟、离线可用、减少数据外发和降低服务端依赖；约束包括模型体积、内存峰值、持续功耗、硬件兼容、后端支持和系统策略。把这两组条件放在一起，才能解释为什么同一个 AI 功能在高端设备上实时运行，在旧设备上改为低频索引，在后台状态下延迟执行，在高温状态下降级。

13.6 专用计算单元对现代手机平台的影响

专用计算单元让手机平台从“执行 App 指令”扩展到“持续理解本机数据和环境”。影像增强、语音识别、实时翻译、相册搜索、手写识别、OCR、健康特征、输入法预测、通知摘要和系统智能功能都依赖端侧计算能力。硬件演进带来的变化覆盖峰值算力、低功耗常驻、传感器融合、模型压缩、统一内存、硬件安全边界和系统服务编排能力。

影像系统是最直观的例子。早期手机拍照主要依赖 sensor、lens、ISP 和后期算法；现代手机把 NPU、GPU、ISP 和多摄硬件组合起来，在预览、抓拍、夜景、HDR、人像、视频防抖和语义增强中持续协作。用户看到一张照片，系统实际输出的是多个硬件单元、多个 buffer、多个模型和多个策略选择的合成结果。

语音与翻译体现了低延迟路径。唤醒词检测适合低功耗 DSP 或 sensor hub 级常驻路径，语音识别和翻译可以进入 NPU、GPU 或 CPU 后端，文本生成和摘要可能受模型大小与内存限制影响。系统需要在麦克风权限、音频会话、后台运行、网络状态、语言包、模型下载和热状态之间做选择。用户看到“离线可用”时，背后条件通常是模型已经在设备上、输入权限已授予、后端支持任务并且电源状态允许执行。

相册搜索和系统智能体现了长期后台计算。照片库中的对象识别、人物聚类、文字识别和地点推断需要批处理大量数据。移动 OS 通常把这类任务安排在充电、空闲、温度合适或用户不活跃时执行，并把结果存进本地索引。这样做把瞬时推理变成平台级数据资产：搜索框、回忆、推荐、辅助功能和跨 App 分享都能使用这些结果，但访问仍受照片权限、隐私设置和系统策略约束。

专用计算单元也提高了平台差异。Android 设备来自不同 SoC vendor 和 OEM，NPU、DSP、ISP、driver、HAL、delegate 和模型支持范围差异明显；同一个 App 需要准备 CPU/GPU fallback、模型裁剪、量化和设备能力探测。Apple 平台硬件和系统整合度更高，开发者主要通过 Core ML、Vision、Metal 等公开 framework 接触能力，但内部后端选择和 Neural Engine 细节受平台封装控制。两种平台的共同点是：App 访问的是能力接口，系统掌握硬件调度和策略边界。

本章建立的最终判断是：NPU 和专用计算单元应放在移动 OS 的“能力代理链”里理解。硬件提供可用算力，driver 暴露队列和能力，runtime 把模型或媒体任务映射到后端，system service 处理权限、生命周期、电源和温控，framework 把结果整理成 App 能使用的 API。读任何手机 AI 功能时，先还原这条链，再判断任务属于推理、图像处理、信号处理还是安全处理，最后用延迟、隐私、功耗和兼容性验证系统选择。

最小自检任务

你正在分析一个相册 App 的“离线搜索宠物照片”功能。用户首次打开搜索页时，系统提示需要照片访问权限；授权后，App 在设备空闲和充电时逐步完成索引；搜索“cat”时可以离线返回结果；低电量模式下，新照片的索引明显延后。请写出这项功能从 App 到专用计算单元的系统路径，并判断 NPU、GPU、CPU、ISP、sensor hub 在这个场景中的责任边界。

答案要点

这项功能的 App 意图是对照片库建立本地视觉索引。Framework 入口可能是 Photos、MediaStore、Vision、Core ML、TensorFlow Lite 或平台媒体/机器学习能力；具体 API 取决于平台和 App 架构。第一道策略边界是照片权限，系统用授权范围决定 App 或系统服务能访问哪些图片。授权后，系统或 App 的索引任务读取图片，解码成可输入模型的 buffer，再交给 ML runtime 选择 CPU、GPU、NPU 或其他 accelerator 后端。

NPU 的责任是执行受支持的视觉模型子图，例如宠物分类、对象检测或 embedding 提取。GPU 可以承担图像预处理、通用并行计算或模型 fallback。CPU 负责任务调度、图片解码的一部分、模型前后处理、索引写入和错误处理。ISP 主要服务相机采集链路，对已经存入相册的图片通常不处于核心路径；如果图片来自实时拍摄阶段，ISP 已经在成像时完成 raw 到可用图像的流水线处理。Sensor hub 在离线相册搜索中通常只提供低功耗状态或设备空闲判断的辅助信息，并非视觉模型的主要执行单元。

低电量模式下索引延后，说明系统把后台 ML 任务纳入电源策略。充电和空闲时逐步索引，说明任务被系统调度为后台批处理。离线返回结果，说明至少一部分模型执行和索引存储发生在设备本地。正确结论是：这项功能的用户可见体验由照片权限、后台调度、ML runtime 后端选择、存储索引和电源策略共同决定，专用硬件只是执行链中的一个责任段。

本章知识点总结

• NPU 位置：NPU 位于 SoC 的专用计算区域，面向模型推理中的张量计算和高能效执行。
• DSP 角色：DSP 适合音频、语音、传感器信号和低延迟流式处理。
• ISP 角色：ISP 负责 camera raw data 到预览、照片或视频帧的图像流水线。
• Hub 常驻：Sensor hub 适合低功耗采样、活动识别、姿态事件和系统唤醒辅助。
• 安全单元：Secure processor 处理密钥、身份认证、可信状态和受保护数据边界。
• 任务分工：推理、图像处理、信号处理和安全处理应按输入、输出、实时性和权限边界区分。
• CPU 边界：CPU 适合控制逻辑、后处理、小规模任务、复杂分支和 fallback 路径。
• GPU 边界：GPU 适合图像、纹理、矩阵和大量并行计算，也可能承担 ML fallback。
• NPU 边界：NPU 适合被 runtime 和 driver 支持的模型子图，命中情况受算子、形状、量化和系统版本影响。
• Runtime 作用：ML runtime 负责模型准备、后端选择、buffer 绑定、fallback 和结果合并。
• Driver 作用：Driver 负责能力声明、队列提交、同步、内存交换和硬件执行状态返回。
• Android 边界：Android 15 起 NNAPI NDK API deprecated，但 Neural Networks HAL 仍是理解 vendor ML driver 抽象的重要公开材料。
• Apple 边界：Apple 平台应以 Core ML、Vision、Metal、Accelerate 等公开 framework 和可观察行为描述端侧 ML 路径。
• 本地推理：本地推理降低网络依赖和数据外发，同时把模型大小、内存、功耗和温控变成系统约束。
• 平台影响：专用计算单元推动影像增强、语音识别、实时翻译、相册搜索和系统智能进入端侧能力链。