终端大模型操作系统的架构、优化与展望

演讲嘉宾 ｜徐梦炜 博士

编辑｜Kitty

策划｜QCon 全球软件开发大会

通过本地化搭载大模型，终端设备的智能能力将获得飞跃式提升，铸造移动计算的下一个黄金时代，对学术界和产业界都是巨大的机遇。为了更好地适应这个过程中上层应用编程接口、用户交互范式、底层资源管理的重要变化，操作系统可能会被重新定义和改写。本文整理自北京邮电大学副教授、博士生导师徐梦炜博士在 2025 年 QCon 全球软件开发大会（上海站） 的分享“终端大模型操作系统的架构、优化与展望”。徐老师介绍了团队在大模型操作系统设计和优化方向的思考和尝试，包括 GUI/API 终端智能体构建、面向 NPU 的端侧大模型推理优化加速等。

预告：将于 4 月 16 - 18 召开的 QCon 北京站设计了「小模型与领域适配模型」专题，将深入探讨：如何通过持续预训练、高质量数据筛选、大模型蒸馏、强化学习、MoE 架构等技术提升大模型的专业能力；如何通过模型压缩、显存管理、算子优化、解码优化、系统调度等推理优化技术提升大模型的推理性能；vLLM、SGLang 等推理框架的应用经验等等。如果你也有相关方向案例想要分享，欢迎提交至 https://jinshuju.com/f/Cu32l5。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

Mobile intelligence before LLM

我今天讲得可能不会那么技术，主要想说说我们团队和我个人对端侧大模型的一些看法。背景我就快速带过：从读博开始，我就一直在做端侧 AI 的优化，到现在刚好十年——前五年在读书，后五年在北邮工作。其实那时候端侧已经有不少 AI 应用了，比如“集五福”就是一个很典型的例子。但在学术界做端侧 AI，我总觉得缺了点劲儿，因为它做不到我真正想做的事。

我想做的事是什么？这里举一个《美国队长 2》里的一段情节：车载 Agent 跟角色不断对话，能听懂指令，还能感知车窗即将破裂，最后甚至弹出机枪帮他脱困。这个场景一直是我心里端侧 AI 该有的样子，不是炫技，而是真正能在关键时刻帮到人。

On-device LLM

现在车载 agent 本身已是一个重要方向，我们团队也在做这类应用。过去做不了，是因为模型能力不够；到了大模型时代，我们觉得机会来了——大模型有理解、推理、生成这些能力，而且很多任务必须在端侧完成。原因很简单：隐私。大模型能用的数据越多，理论上手机里产生的每一比特都能让它更懂你、更贴心，可这些数据没人愿意随便上传。所以我个人非常看好端侧大模型。当然，端侧大模型不等于云端大模型会消失。未来一定是端云协同，就像高通说的：The future of AI is hybrid。

我在 2023 年初就开始做端侧大模型。到了 2023 年中，我在学术界做交流时，发现很多人并不买账。他们最直接的疑问是：大模型怎么可能放到端上跑？要是能在端上跑起来，那还能叫大模型吗？毕竟最朴素的 scaling law 告诉我们，云端的大模型一定比端上的更强；既然有更强的，为什么还要用相对弱的呢？

我现在常举的一个例子是：人脑本身就是一台端侧大模型。它不需要连云端，只靠二十瓦左右的功耗，就能完成复杂的推理、规划等任务。所以，我们的长远目标，是让端侧也能跑起具备 AGI 能力的模型，把终端设备做得像人脑一样。这个终端可以是手机，也可以是机器人，或者其他形态。

我们团队虽然把题目叫作“操作系统”，听着有点噱头，但确实是从操作系统一路做到上层：推理引擎、模型、应用 agent，都摸了一遍。我本身在北大软件所出身，最早只做系统软件，后来才慢慢往上走，做到算法和应用。

这里放的是一个比较早的 demo，本质就是本地 RAG 加大模型推理。我们把它跑通的意义在于，整个链路——推理引擎、模型、API agent——都是我们自己从头搭的。当时正好有资源，从预训练、微调，到上层的 agent 接口，全走了一遍。

上述 demo 是“数字世界”里的 Agent，现在我们更关注具身 Agent。无人机是重点场景之一，我们把它当成端侧大模型，或者说端侧 VLA 的重要平台。无人机经常要在弱网甚至无网环境工作，自主化是刚需；不管是军用还是载人载物，未来都得靠“大脑”。现在的飞控只能算小脑，能避障、做简单路径规划，离真正的自主还差得远。我们想在机上跑一个 3B 到 7B 的端侧模型，让它具备更高阶的决策能力。比如让它飞到黑板前看一眼，再去找黑板里提到的东西。这类任务在大模型出现之前根本做不了，现在我们认为可以一试。核心就是提供一种泛化能力，让无人机像人脑一样现场思考、工作。

在推理引擎方面，我们主要想对标 llama.cpp，用更高效的思路搭一套自己的生态。框架叫 mllm，定位是给非 CUDA 的端侧 NPU 用的推理引擎。除了最基础的 LLM，我们重点做 VLM，以及现在流行的 Omni、MoE 和机器人 VLA 这类模型。刚才也有人问 NPU SDK 的事，高通确实做了，我们也做过。由于看不到高通最底层的指令集，我们的目标是在性能上尽量接近他们的端到端 SDK，哪怕略差一点，但换来更大的灵活性：可以测试新的量化算法，也能更快支持他们暂时不支持的 MoE、Omni 等特性，从差异化角度把开源生态做起来。

我今天想围绕一个问题讲：十年前我开始做端侧 AI，到现在带着二十多位同学做端侧大模型及其应用，到底有没有不一样？如果只是把 CNN 换成 Transformer，其他原封不动，那其实没多大意思。产业界的专家肯定比高校师生做得更快更好。我们要找的是偏研究的机会，需要长期探索、甚至要冒点风险、花长时间才能啃下来的问题。最后我们欣喜地发现，确实大不相同：从应用到系统再到硬件，整个软件栈都出现新挑战。接下来我就从这三个层面，谈谈我们的体会。

The changes LLM brings: App

先讲应用。过去做端侧 AI，业界常做的是 TTS 这类任务，我们则把重点放在机器学习模型的压缩与加速上。但这类工作本质上是优化一个独立任务，而非端到端的应用，所以可玩性有限——不同应用需要不同的优化策略。到了大模型时代，出现了一个非常集中的“杀手级”应用：小爱、小艺、Siri 这类助手。它们背后几乎都由 LLM 或 VLM 驱动，这就给学术界提供了一个可以长期聚焦、深入研究的明确方向。

在 Agent 方面，我们做了一些初步尝试。Agent 有两条路线：API 与 GUI，未来肯定是混合的。从研究角度看，GUI Agent 更值得做，因为 API Agent 更多依赖工业界生态，而 GUI agent 距离 C 端商业化还很远，远没到能提供 99% 以上准确率的地步。

虽然自媒体天天推送“某模型已能像人一样操作手机”，小红书上也刷到 ICLR 今年七十多篇基于 RAG 的投稿，但现实是：这个方向确实前景很大，却还没到落地阶段。核心问题是端到端任务完成率仍偏低。很多任务之所以交给 Agent，是因为用户懒得做或做不好，往往涉及 10～20 步的长程操作。每一步都可能出错，错误累积导致整体成功率下降。更大的瓶颈是效率：点 20 次屏幕，就得做 20 次多模态大模型推理， 延迟和能耗都吃不消。因此，效率成了阻碍 GUI agent 真正部署落地的关键难题。

搭一个 GUI Agent 的 workflow 其实不复杂：先选个 VLM，端侧部署就用 3B 或 7B 的模型；然后收集 GUI 数据，构造下游任务，通过后训练提升它在 GUI 上的 grounding、指令跟随、CoT 等能力。现在不少 VLM 在预训练阶段就已经混入了大量 GUI 数据，比如千问的技术报告里就列出了 GUI 任务准确率，但我们觉得仍有空间。只要设计出更好的 GUI 任务，就能继续拉高模型对界面理解与操作的水平。

模型训好后，就进入在线 Agent 构建阶段，跟 Deep Research 或 Coding Agent 类似：搭 memory、拼上下文、选工具、定制 test-time 调度策略。做完再放到 Testbed 跑分。GUI Agent 的麻烦在于 Testbed 本身就不完善，不像 ImageNet 那样“是猫还是狗”一目了然。GUI 任务的路径几乎无限，界面又随时可能弹出广告，评判难度高，所以 Testbed 至今仍是研究热点。

这里说一点我们最近关于训练的想法。训 VLM 理论上需要大量带标注的 GUI 轨迹数据，一连串界面截图和对应的操作。这种数据很难规模化。传统做法像 DeepMind 那样雇几千人、花几千万美元标上百万条轨迹，成本高还容易错。我们就在想，能不能把无标注的轨迹也用起来：不给具体任务，让工具自动在 GUI 里探索。其实很多大厂做 App 测试时就有专门的 GUI Testing 团队，用爬虫把应用界面遍历一遍，收集大量无标注的 GUI 序列。这些数据如果能被有效利用，就能省掉一大笔标注费。

我们重新梳理 GUI 任务后发现，当前 VLM 对单张界面图的理解已经很强：把手机截屏丢给 GPT 或豆包，做 VQA 或 Grounding 都能答得不错。真正的难点在于“跨页关联”，给出当前界面，执行某个动作后，下一界面会变成什么样。这种能力在长程 GUI 任务里尤为关键，却几乎没出现在 VLM 的预训练目标中。它很像机器人里的世界模型：给定状态与动作，预测下一状态。事实上，数字 Agent 与实体 Agent 在能力需求上越来越重叠，比如如何利用无标注数据、如何构建世界模型，这些问题是相通的。

顺着这个思路，我们设计了一个极简的下游任务：输入两个界面截图，让模型预测在前一界面上该执行什么操作才能到达后一界面。两图之间可以相隔 k 步，无需连续。这相当于机器人里的逆动力学，已知起点与终点，反推所需关节动作。好处是无需人工标注：只要用爬虫遍历 App 时把动作记录下来，就能自动生成大规模训练对。

我们用这套方法收集数据，训了最大 7B 的模型；卡不够后，又与小米合作，在他们的 Mimo 模型上继续实验。结果在相同数据量下，我们的模型效果甚至优于用人工标注数据训出的基线。原因很简单：人工标注成本高，且 GUI 任务远比猫狗识别复杂，标注错误率不低；而爬虫数据可无限扩展，噪声反而更少。

我们实验里还发现，用强化学习，比如 DeepSeek GPPO，效果比 SFT 好。现在大家的共识是：要做 Agent，就得用 RL。不管是最近很火的 Agentic RL，还是 GUI Agent 这种垂域任务，RL 已经成了实现强泛化的标配。

The changes LLM brings: OS

回到操作系统这个话题，正好呼应我今天报告的题目。我觉得大模型时代一个很有意思的现象是“下沉”。以前 CNN 那种小模型完全由应用自己管：自己训、自己部署，操作系统既不知道也不关心。现在模型太重，会慢慢往下沉。不一定沉到操作系统本身，也可能沉到支付宝、微信这类超级 App，然后以统一接口把大模型能力开放给第三方。再想回到以前那种碎片化、去中心化的部署方式，已经不太可能。

原因很现实：如果每个第三方服务都自己部署一个千问级别的模型，既没资源也没必要。Google 已经在这么做了，因为它有全栈能力：TPU、安卓、Pixel 手机、自己的大模型，华为也类似。这种大厂能把硬件潜力真正榨干。

一旦大模型变成系统级服务，就会出现一些新问题。从操作系统角度看，可用性、效率、安全都值得重新研究；对工业界来说，甚至可能催生新的商业模式。

当大模型成为系统级服务后，第三方应用还是得靠 LoRA 接入，因为端侧 3B 模型毕竟知识有限。可模型还能升级吗？操作系统升级不会影响应用，但大模型服务从千问 3 升到千问 4，原来训的 LoRA 就失效了。这是个全新问题。

我们做了一些非常早期的尝试，远没到“千问 3 升 4 后旧 LoRA 完全可用”的程度。目前能做到的是：原来需要 1 万条数据才能训出的 LoRA，现在用我们的方法可能只需 10～100 条就能在新模型上复现同样效果。作为初步探索，我们把训练放到了端侧，也跑过端侧大模型的微调实验。

从效率角度看，我觉得很有意思的一点是：一旦大模型变成系统级服务，就跟在云端一样，得考虑怎么调度、怎么缓存复用、怎么做 batch。以前端侧几乎只考虑 batch size 等于 1 的场景，可将来如果大模型无处不在，不光喊“Hi Siri”时才触发，后台也可能一直跑，主动感知、主动推荐。到那时，它得同时处理很多请求，就跟云上一模一样。

我们做过一个实验：怎样让大模型提供弹性服务。有的应用希望 prefill 快，有的希望 decode 快，有的对延迟不敏感，只想要生成质量高。于是我们把 token-level 的剪枝和模型 -level 的剪枝结合起来，在保障 QoS 的前提下，尽量把生成质量做到最好。

The changes LLM brings: H/W

关于我们在推理引擎方面的工作。面向未来，尤其是具身智能这类场景，我觉得应该把 NPU 真正用起来。长期来看，大模型终究要落在 NPU 上跑。

之所以这么说，是因为在大模型出现之前，我们做了很久的端侧 AI 优化，当时一度觉得“没活可干”：像 ResNet-50 这类网络在高通早年的 NPU 上 5 毫秒就能跑完，远远满足需求；ResNet-152 也很快。可大模型一来，学术界突然又有饭吃了。Scaling law 让资源缺口可以无限放大。不是今天把 3B 模型塞进去、明天换成 7B 就完事，而是永远想跑更大的模型：明年 50B，后年 500B，需求没有尽头。

纯技术角度看，国产或各类专用加速器在大模型时代应该更有用武之地。当年 865 那代，我在 Wikipedia 上查到 73 TOPS，肯定不到，因为今年发布的新品才标 80 TOPS。但不管怎样，NPU 靠定制指令和架构级优化，在绝对算力上相对 CPU、GPU 仍有优势，所以我们团队一直坚持做面向 NPU 的框架。蚂蚁那边已经把 CPU、GPU 做到极致，我们就专攻 NPU。选 NPU 还有一个原因：它对系统软件要求更高。硬件算力可以堆得很好看，但上层怎么跟量化算法结合、怎么做 kernel 优化（如果允许写 kernel 的话），能做的事更多，也更难。学术界正好可以往深里钻。

我们那个推理引擎其实是比较早期的项目。2023 年初，高通自己的端到端 SDK 还没发布，我们就先基于它的 DSP（本质上也是 NPU）动手。当时 NPU 显然不是为大模型设计的——虽然发布会上号称“首款为生成式 AI 打造的芯片”，但 GPT 才火了几个月，硬件不可能转得这么快。

实际上，真跑起来就会发现一堆不兼容：动态 shape 不支持；很多 NPU 缺乏足够的 FP 算力，可我们当时的量化算法里，attention 里不少算子还是会溢到 FP；官方暴露的算子也不支持 group-level 量化，而大模型又必须靠 group-level 来抑制 outlier，否则精度掉得没法看。我们没法像海思那样直接改芯片，只能在一块“成品”硬件上，用算法和系统手段去填大模型语义和 NPU 能力之间的沟。当时提的 chunked prefill 之类的小技巧，现在看已经挺常见，高通内部的 Gini 框架也在用类似思路。

不同模型对 outlier 的敏感程度不一样，但总之我们能把 prefill 做得比 CPU、GPU 都快——decode 阶段是 memory-bound，就先没碰。开源过程中遇到的问题比预期多：benchmark 里输出短，选 ABCD 准确率掉得不多；一旦生成长文本，准确率就明显下滑。学术界的小 demo 离真正能用还差得远。我们的论文一年前就写完，之后学生一直围着开源框架做落地。最近一两周会把版本升到 V2，目标是新模型发布当天就能在高通或其他 NPU 上跑通 0-day 支持，也在和面壁等模型厂商谈合作，争取端侧模型一发布就有 demo。

当然，之前的工作留了不少尾巴：decode 没优化、算法还依赖 CPU。最近我们在补这些坑，用 NPU 做投机采样来加速 decode、解决 long context、尽量把 FP 算力需求压到最低。我的愿景是做到“NPU-only”的端到端大模型推理，全程用整数运算跑完。

我们不仅想用 NPU 做推理，还想用它做大模型的微调训练。和小米合作的项目就是端侧大模型微调。要解决的问题是 NPU 本身不支持反向传播。我们用了一些算法层面的技巧，主要是临界优化，把推理和训练并到一条前向通路里，只需前向就能算出 loss 并更新参数。虽然端到端性能一般，但确实在端侧跑通了 7B 模型的微调。

Takeaways

关于未来，我前面提过“人脑”的例子。Hinton 把智能分成两类：一类是“凡人计算”，即人脑知识无法直接迁移，人死灯灭，只能靠师徒口传；另一类是“永生计算”，硅基软硬件解耦，程序换块板子就能继续跑。永生计算虽“不死”，却做不到人脑的低功耗强智能。Hinton 认为，若想逼近人脑，也许得放弃永生计算。我部分同意：软硬必须高度耦合。

我的一个很不成熟的想法是：面向手机或其他端侧场景，应垂直协同设计，从上层模型到下层硬件一体优化。最理想的情况是，终端里有一块专用电路，只跑 Transformer（前提是 Transformer 仍是主流架构），并配独立高带宽内存。今天手机用统一内存，未来或许该给大模型和它的 KV Cache 划一块专属存储。牺牲通用性换取极致功耗与性能；损失的灵活性可在 Agent workflow 层补回来。模型与硬件垂直整合，才能把性能压到极限。

总结本次分享：第一，端侧大模型正在重塑移动终端——无论无人机、机器人、手机，还是未来可能出现的新形态，它们的核心能力都会被改写。第二，这件事不是简单的模型替换，而是整个移动 AI 生态的范式转移：操作系统、运行时、模型、应用（Agent）必须一起重新设计，需要学术界和产业界一起做真正的全栈研究。

演讲嘉宾介绍

徐梦炜博士，北京邮电大学副教授、博士生导师，在端侧智能方向发表 CCF-A 类论文 30 余篇，获 USENIX ATC 2024 最佳论文奖等，入选中国科协青托、北京市科技新星、微软研究院“铸星计划”等，主导了开源端侧大模型推理引擎 mllm 等。

会议推荐

2026，AI 正在以更工程化的方式深度融入软件生产，Agentic AI 的探索也将从局部试点迈向体系化工程建设！

QCon 北京 2026 已正式启动，本届大会以“Agentic AI 时代的软件工程重塑”为核心主线，推动技术探索从「AI For What」真正落地到可持续的「Value From AI」。从前沿技术雷达、架构设计与数据底座、效能与成本、产品与交互、可信落地、研发组织进化六大维度，系统性展开深度探索。开往 2026 的 Agentic AI 专列即将启程！汇聚顶尖专家实战分享，把 AI 能力一次夯到位！