端侧AI进入手机之后，最先承受压力的通常是操作系统。

一次语音问答可能同时唤醒麦克风、音频前端、语音识别、模型推理、网络连接和界面渲染。一次图像识别还会占用相机、内存带宽、GPU或NPU，并在短时间内产生高密度计算。生成式AI的连续解码则会持续消耗算力、内存、带宽和电量。

这些任务共同挤进一台终端，操作系统面对的资源问题随之发生变化。过去，系统主要围绕进程、前后台状态和用户交互分配资源。端侧AI进一步引入模型状态、首次响应时间、推理截止期限、KV Cache、加速器队列和热预算。

由此来看，端侧AI带来的变化远远超过算力需求上涨。操作系统开始从进程管理走向模型与任务管理，从CPU调度走向异构算力编排，也从本地资源分配走向设备、边缘和云端之间的联合决策。

传统操作系统已经具备复杂调度能力

讨论AI终端时，首先需要澄清一个技术事实。现代操作系统早已采用分级调度。

Linux调度器会综合任务优先级、CPU利用率、核心容量和硬件拓扑安排任务。Energy Aware Scheduling还会借助能耗模型，在异构CPU之间选择兼顾吞吐和能效的执行位置。系统进入高负载状态后，调度器会根据新的资源条件调整策略。​​Linux EAS官方文档​​

Android同样通过cgroups和task profiles管理CPU、内存及进程组。厂商可以针对前台应用、系统服务和后台任务设置不同资源策略。Android 10之后，这套抽象层进一步支持厂商在系统与供应商分区中配置任务组。​​AOSP cgroup抽象层​​

内存管理也采用动态压力判断。Android的lmkd持续监测内存状态，并结合进程重要性、交换空间和压力信号选择回收对象。Android 10以上版本还可以通过PSI观察任务因CPU、内存或I/O争用产生的停顿时间。​​AOSP lmkd​​​ ​​Linux PSI​​

因此，端侧AI提出的真正问题集中在调度语义。现有系统认识前台应用、后台服务和系统进程，AI任务却同时横跨这些类别。一次AI请求可能从低功耗监听开始，经过突发推理，进入持续解码，随后转入缓存和等待。每个阶段都拥有不同的资源目标。

操作系统需要识别这种阶段变化，并根据响应期限、用户可见性、模型状态、热余量和硬件适配度调整资源。

AI任务拥有五种特殊资源特征

图一　一次AI请求的资源负载曲线

端侧AI的第一项特征是突发性。

唤醒词检测可以长期保持极低功耗，一旦用户开始说话，系统会迅速启动语音识别、语义分析和模型推理。算力需求会在很短时间内快速升高，任务结束后又迅速回落。传统应用也会出现负载波动，AI任务的峰值更高，模型加载成本也更明显。

第二项特征是状态性。

普通计算任务结束后通常释放工作数据，生成式AI则需要保留模型权重、运行上下文和KV Cache。下一轮推理能否复用这些状态，会直接影响首Token时间、内存占用和能耗。

第三项特征是异构性。

AI计算会同时接触CPU、GPU、NPU、DSP和传感器Hub。CPU适合控制流和小规模任务，GPU适合高度并行的计算图，NPU更适合受支持的张量算子，DSP则适合语音前端和低功耗感知。任务执行位置取决于模型结构、算子覆盖、精度格式和当前负载。

第四项特征是持续性。

实时翻译、语音对话和连续生成会长时间占用计算资源。此类任务需要稳定吞吐。短时峰值速度只能描述启动阶段，热平衡之后的持续性能更接近真实体验。

第五项特征是耦合性。

AI推理常常与通信、音频、界面、相机和网络同步运行。AI任务提高资源占用时，通话稳定性、触控响应和系统服务仍需保持。资源调度因此承担多项服务等级。

算力调度开始从CPU选核走向异构编排

“AI专属算力池”可以作为传播比喻，工程实现更接近动态资源预算。

固定划分一组CPU核心或长期独占某个加速器，会降低硬件利用率。低配置终端拥有更紧张的资源，长期闲置一部分算力会进一步增加成本。更实际的方案通常结合cgroup、cpuset、uclamp、任务期限、加速器队列和资源配额，为AI提供最低保障，同时允许系统动态共享空闲资源。

交互式推理可以获得短时性能提升。后台预计算可以进入能效队列。语音唤醒可以下沉至DSP或传感器Hub。持续生成则按照热预算运行在稳定工作点。通话、音频、输入和系统看门狗继续保持更高保护等级。

Android Dynamic Performance Framework中的Performance Hint API已经体现了这种思路。应用向系统报告目标工作时长和实际工作时长，系统结合设备状态调整CPU频率和核心类型。应用表达任务目标，系统负责选择具体资源。​​AOSP Performance Hint API​​

算力编排还要考虑计算图的分割成本。LiteRT通过Delegate将受支持的子图交给GPU、DSP或NPU。部分算子留在CPU时，系统需要处理张量复制、格式转换和执行同步。计算图被切成许多小块后，数据搬运可能消耗大量时间。​​LiteRT Delegate机制​​

因此，NPU的峰值算力只提供理论上限。算子覆盖率、图分区数量、数据复制和驱动队列共同决定终端体验。

内存管理需要理解模型价值

模型权重只是AI内存的一部分。

推理过程还会占用输入输出张量、激活数据、运行时工作区、图像或音频缓存，以及生成式模型的KV Cache。模型冷启动还涉及闪存读取、解压、编译、内存映射和加速器初始化。

如果系统频繁回收模型状态，下一次请求就会重新读取和初始化。冷启动时间增加，闪存和内存带宽产生额外负载，电量消耗也会上升。如果系统长期固定模型内存，通信栈、界面和基础服务可用空间会随之缩小。

更成熟的设计会为不同数据建立分级驻留策略。

高频模型可以保留权重页和编译缓存，低频模型可以采用按需加载。多个应用可以共享系统级模型服务，减少重复副本。系统还可以通过mmap、张量缓冲区复用和零拷贝路径减少数据搬运。内存压力升高时，系统可以裁剪上下文、切换小模型、释放冷缓存或转向云端。

生成式AI尤其需要管理KV Cache。上下文越长，缓存占用通常越高。系统可以根据当前RAM、任务优先级和用户体验目标调整上下文长度，而非任由缓存持续扩张。

量化也属于系统级资源优化。LiteRT资料显示，Float16量化可以将模型尺寸最多缩减约50%，动态范围量化和整数量化可以达到约75%的尺寸缩减。具体收益仍取决于模型精度、运行时实现和硬件算子支持。​​LiteRT模型优化​​

量化后的模型通常减少存储读取、RAM占用和内存带宽，同时也可能提升推理速度。硬件缺少对应低精度算子时，部分任务会回到CPU执行，整体收益则需要通过真机测试判断。

功耗管理需要区分峰值和稳态

端侧AI追求两个性能目标。

第一个目标是快速响应。用户发出指令后，系统需要尽快启动模型并产生结果。此时，系统可以根据时延目标和热余量调用较高性能档位。

第二个目标是持续吞吐。语音对话、实时翻译和长文本生成会持续运行。设备进入热平衡后，CPU、GPU和NPU需要稳定工作。系统如果长时间追逐峰值，机身温度会快速升高，随后进入降频，最终体验可能出现明显波动。

Android持续性能模式展示了这一差异。官方示例中，短时性能可以达到较高水平，热节流后则出现下降；受控频率能够维持更稳定的输出。​​AOSP持续性能管理​​

现代Android还通过Thermal HAL和Thermal Service持续监测热状态。AI系统可以在现有热管理基础上增加模型级策略，根据热余量调整模型规模、输出长度、线程数量、执行器、采样频率和推理位置。​​AOSP热管理​​

这套策略的目标是稳定完成任务。系统需要同时观察首响应时间、持续吞吐、单位任务能耗和机身温度。

图二　峰值性能与持续性能

AI常驻更适合采用分层唤醒

“AI常驻”常常被理解为完整模型长期运行。低功耗终端更适合采用分层架构。

DSP、传感器Hub或微型NPU可以运行语音活动检测、关键词识别和简单场景分类。这些模块检测到有效事件后，再唤醒主NPU、GPU或CPU执行复杂推理。任务完成后，系统重新进入轻量感知状态。

这种架构将低功耗感知与高强度推理解耦。它既保留快速响应，也控制平均功耗。高通等芯片平台已经使用DSP和Sensing Hub支持持续感知场景。​​Qualcomm AI Engine​​

操作系统在这里承担生命周期管理。系统需要知道哪个前端持续工作，哪个模型按事件启动，哪些状态值得缓存，以及任务结束后哪些资源可以释放。

存储、带宽和I/O决定模型启动速度

端侧AI讨论经常聚焦算力，模型加载路径同样重要。

一个模型从闪存进入执行状态，可能经历读取、校验、解压、编译、内存映射和加速器准备。闪存速度、文件系统、模型格式和缓存状态都会影响冷启动。

大型模型还会持续访问权重和KV Cache。内存带宽不足时，计算单元会等待数据。CPU、GPU和NPU之间频繁复制张量，也会消耗带宽与电量。

因此，系统优化需要覆盖完整数据路径。模型压缩、按需加载、预编译、缓存复用、共享内存和零拷贝，往往与调度算法拥有同等价值。Apple Core ML和新一代Core AI也将模型加载、计算单元选择、内存控制和有状态执行纳入统一框架。​​Apple Core ML​​​ ​​Apple Core AI​​

运行时更新速度决定生态活力

模型技术的更新速度远高于传统OS版本节奏。

Android曾经通过NNAPI提供统一推理接口，并将任务分配至CPU、GPU、DSP和神经网络加速器。Android 15已经弃用NNAPI。Google给出的迁移方向包括Google Play服务中的TensorFlow Lite、GPU运行时和AICore。​​Android NNAPI迁移指南​​

这一变化说明，AI运行时需要更快的更新节奏。Transformer、扩散模型、量化格式和新型算子持续演进，固定在系统版本中的接口更新周期较长。可独立升级的运行时、Delegate和系统AI服务更适合承接快速变化。

ONNX Runtime采用Execution Provider连接CPU、CUDA、TensorRT、OpenVINO、Qualcomm QNN、Core ML等后端。运行时识别每个后端可处理的子图，再按照优先顺序安排执行。​​ONNX Runtime Execution Providers​​

这种架构降低应用与单一芯片后端之间的耦合，也带来运行时体积、算子兼容和跨设备调优工作。系统厂商需要在统一接口与硬件深度优化之间寻找平衡。

系统级共享模型能够改善资源利用

每个应用分别打包模型，会重复占用存储、内存和更新流量。系统级AI服务可以统一托管基础模型、运行时、硬件加速和权限。

Android AICore代表了这条路线。AICore负责Gemini Nano的模型分发、更新、运行时管理和安全隔离，应用通过受控接口调用共享能力。系统由此减少重复部署，并建立统一的权限与模型生命周期。​​Android AICore与Gemini Nano​​

系统级模型服务仍需处理公平性。多个应用同时请求推理时，系统需要建立队列、配额、超时和取消机制。高优先级请求还可能等待低优先级任务持有资源，驱动锁和共享缓冲区会进一步增加尾延迟。

因此，AI调度需要覆盖线程、模型、加速器队列和共享内存。单一的进程优先级只能解决其中一部分。

端云协同已经进入资源调度范围

低配置终端可以承担隐私过滤、语音前端、缓存、权限和快速交互，云端可以承担大模型、长上下文和复杂工具调用。设备、边缘和云端共同构成新的计算边界。

系统需要根据网络质量、数据敏感程度、本地模型能力、云端费用、电量、热状态和当前内存压力选择执行位置。弱网场景可以优先采用本地小模型，稳定网络可以支持云端增强，网络波动时则需要恢复和重试机制。

这种调度已经超出传统CPU资源管理。网络时延、流量成本和服务可用性也成为系统资源。

对于功能手机和资源受限设备，端云协同往往具有较高工程价值。设备保留高频、实时和隐私敏感任务，云端承担更复杂的生成与检索。系统通过缓存和状态同步保持体验连续。

权限与安全同样属于AI资源管理

AI常驻服务会接触麦克风、相机、位置、联系人和屏幕内容。AI Agent还可能调用通信、支付和设备控制功能。

操作系统需要验证请求来源，隔离不同应用的上下文，管理模型文件签名，并在高风险操作前请求用户确认。模型下载、升级和回滚也需要进入安全链路。

后台感知还需要用户可见性。系统可以通过明确权限、状态提示和生命周期规则管理传感器访问。资源调度与隐私治理由此连接起来。系统赋予某项AI服务更多运行时间时，也需要同步限定它的数据范围和操作权限。

操作系统重构存在三种深度

图三　操作系统重构的三种深度

第一种路径集中在运行时增强。团队保留成熟内核、驱动和应用生态，增加LiteRT、ONNX Runtime、模型管理、量化和硬件Delegate。这条路径适合单一或少量AI功能，也适合量产周期较短的消费终端。

第二种路径进入系统服务层。系统统一托管共享模型、推理队列、权限、缓存、端云路由和模型更新。多个应用可以调用同一套AI能力。这条路径适合拥有多个AI应用、长期OTA和统一安全治理的设备。

第三种路径进入OS架构层。团队围绕低内存、强实时、低功耗和特定芯片重新设计模型管理、硬件抽象和资源策略。这条路径适合功能手机、专用AI终端和长生命周期行业设备，也要求厂商掌握BSP、驱动、系统服务和OTA链路。

三条路径对应不同成本。运行时增强继承成熟生态，开发周期较短；系统服务层获得更强的模型共享和安全治理；深层重构可以针对硬件进行更精细的裁剪，同时带来驱动、认证、开发工具和生态维护投入。

项目团队需要根据AI功能数量、设备规模、硬件生命周期和生态依赖选择深度。

AI原生调度需要一套新的验收指标

传统性能测试经常观察平均响应时间和CPU占用。端侧AI还需要一组更完整的指标。

首Token时间衡量用户首次感知速度。P95和P99延迟反映尾部体验。持续吞吐描述热平衡后的长期性能。单位推理或单位Token能耗体现能效。峰值RAM、内存压力停顿和模型重载次数揭示内存策略质量。

系统还要观察AI运行期间的通话质量、音频连续性、消息到达率、界面响应和后台任务完成率。加速器算子覆盖率、计算图分区数量、端云切换时间和云端调用成本也应进入测试体系。

最终，AI原生调度可以用一个服务等级框架评价。

• 交互任务关注首响应和尾延迟；
• 持续任务关注稳态吞吐与温度；
• 常驻感知关注平均功耗和漏触发率；
• 通信任务关注稳定性和到达率；
• 模型管理关注内存峰值与重载次数；
• 端云协同关注恢复时间、流量与服务成本。

这些指标能够连接系统设计、用户体验和商业成本。

结语

端侧AI推动操作系统重新认识资源。

CPU时间只是其中一部分。模型权重、KV Cache、内存带宽、加速器队列、存储I/O、热余量、网络质量和云端费用都进入同一张资源表。操作系统需要理解任务处于感知、启动、推理、持续生成还是等待阶段，再配置相应资源。

AI原生操作系统的价值也由此变得具体。系统识别任务目标，协调异构算力，管理模型状态，控制能耗与温度，并保护通信、安全和交互体验。AI获得与任务相匹配的资源，基础服务也获得明确保障。

下一代终端的竞争将覆盖模型、编译器、运行时、驱动、内存路径、热管理、权限和开发者工具。操作系统真正需要重新设计的部分，正是这些层之间的协同方式。