1. 从设备即环境这个说法说起端侧模型到底在赌什么第一次看到设备即环境这个提法我愣了几秒。过去几年我们聊端侧模型聊的都是把模型塞进手机本地推理省流量这类工程视角的事很少有人把它上升到一个环境层面的判断。但仔细想想这个说法其实点破了一件被行业长期忽略的事当模型跑在设备上设备本身就不再只是一个计算载体它变成了模型感知世界、理解用户、做出决策的完整上下文。这个判断背后有一个很硬的逻辑。云端模型再强它对用户的理解始终隔着一层——它看到的是你上传的片段、你授权的数据、你主动发起的请求。而端侧模型不一样它天然就活在设备里能接触到传感器数据、使用习惯、本地文件、应用状态、时间地点这些连续信号。这些信号单独看都不值钱但拼在一起就是一个人的数字生活全貌。我拿一个具体场景来说明。假设你想做一个真正懂你的日程助手。云端方案的做法是你告诉它我明天下午要开会它记下来到点提醒你。端侧方案的做法是它发现你最近三天晚上都在改一份文档日历上有个项目评审的标记手机定位显示你明天上午要去客户那边于是它主动问你要不要把评审材料提前同步到平板路上可以过一遍。后者不是更聪明而是它拿到的上下文更完整。这就是设备即环境的核心端侧模型的价值不在于参数规模而在于它和用户之间没有数据搬运的损耗。云端模型要理解你得先把你数字化再传上去端侧模型直接就在你的数字生活现场。那为什么是现在这个时间点三个条件同时成熟了。第一小模型的能力上来了几B参数的模型在特定任务上已经能打第二设备算力上来了手机、PC、车机的NPU不再是摆设第三用户对数据隐私的敏感度上来了越来越多的人不愿意把聊天记录、照片、位置这些数据往云端送。这三个条件缺一个端侧模型都只能是demo。北大系这家公司押注这个方向本质上是在赌一个判断未来的AI入口不在云端而在每一台设备里。这个判断对不对现在下结论还早但它至少解释了一个现象——为什么大厂都在做端侧模型却很少有人真正把设备即环境当成产品哲学来做。2. 端侧模型和Agent结合之后事情变得不一样了单独聊端侧模型容易陷入参数小、跑得快这种技术指标的比较。但端侧模型真正的想象力是和Agent结合之后才打开的。我甚至觉得端侧模型如果没有Agent价值要打对折。2.1 为什么Agent是端侧模型的放大器Agent的本质是感知-决策-执行的循环。云端Agent的问题在于它的感知依赖用户主动输入决策依赖云端算力执行依赖API调用。这三个环节每一个都有延迟、有损耗、有隐私风险。端侧Agent把这三个环节都拉到了本地感知来自设备传感器和应用状态决策来自本地模型推理执行来自本地系统权限。我举个实际例子。你在写一份报告端侧Agent可以做到检测到你打开了文档应用感知判断你正在写的是季度总结决策自动把上季度的数据文件调出来放在侧边执行。整个过程没有一次网络请求没有一次数据上传。这种体验云端Agent给不了因为它根本不知道你打开了什么应用。2.2 端侧Agent的三个能力层级我把端侧Agent的能力分成三层这个分层是我自己在做项目时总结的不一定严谨但很好用层级能力描述典型场景技术门槛L1 响应式根据用户指令执行本地操作语音设闹钟、本地文件搜索低L2 主动式根据上下文主动提供服务会议前自动准备材料、通勤时推送路况中L3 环境式持续理解设备环境并预判需求跨应用工作流编排、个性化内容生成高大部分号称端侧Agent的产品停在L1少数能做到L2L3基本还在实验室阶段。北大系这家公司如果真想做设备即环境目标显然是L3。但L3的难点不在模型在于如何在不侵犯隐私的前提下让Agent持续理解环境。这是一个产品设计问题不是技术问题。2.3 端侧Agent的并发问题比云端更棘手热词里有个ai agent 怎么扛并发这个问题在端侧其实更复杂。云端Agent的并发是请求级别的加机器就能扛。端侧Agent的并发是任务级别的——同一个设备上可能有多个Agent同时在跑一个在监听通知一个在处理语音输入一个在后台整理文件。这些任务共享同一个模型实例、同一块内存、同一个电池。我实测过一个方案用任务优先级队列来调度端侧Agent。高优先级任务比如用户主动发起的语音指令抢占模型实例低优先级任务比如后台文件整理排队等待。这个方案的问题在于低优先级任务可能永远等不到执行机会。后来改成时间片轮转每个任务分配固定的推理时间片效果好了很多但实时性又下降了。端侧Agent的并发调度本质上是在算力、电量、实时性三者之间做权衡。没有银弹只有取舍。3. 拆解端侧模型落地的四个硬骨头聊完方向得聊落地。端侧模型从论文到产品中间隔着四道坎。这四道坎我在不同项目里都踩过每一道都能让项目延期三个月。3.1 模型压缩不是越小越好而是越合适越好端侧模型的第一反应是压缩。量化、剪枝、蒸馏三板斧下去模型是小了但能力也掉了。我见过太多团队为了把模型塞进设备把量化做到4bit甚至2bit结果模型连基本的指令遵循都做不到。我的经验是先确定任务边界再选压缩策略。如果你的端侧Agent只做意图识别和槽位填充那模型可以压得很狠如果要做多轮对话和工具调用那压缩就得保守。具体来说意图分类任务4bit量化通常够用模型可以压到1B以下单轮问答8bit量化比较稳模型在3B左右多轮对话工具调用建议保持FP16或8bit模型至少7B这个对应关系不是绝对的但可以作为一个起点。关键是不要为了压缩而压缩要先明确模型要干什么再决定压到什么程度。3.2 内存管理端侧最容易被低估的瓶颈云端推理内存不够加内存。端侧推理内存是焊死的。我做过一个统计在端侧跑7B模型光是模型权重就要占14GBFP16加上KV Cache和运行时开销20GB起步。而大部分手机的可用内存也就8-12GB。所以端侧模型的内存管理核心是KV Cache的优化。KV Cache是Transformer推理时缓存的历史键值对对话越长缓存越大。优化手段有几个滑动窗口只保留最近N轮对话的KV Cache超出部分丢弃。简单有效但会丢失长期记忆。KV Cache量化把缓存也做量化8bit通常不影响效果4bit会有明显下降。分页管理借鉴操作系统的虚拟内存思路把不常用的KV Cache换出到存储需要时再换入。我实测下来滑动窗口8bit量化是最实用的组合能把7B模型的内存占用压到10GB以内基本能跑在高端手机上。3.3 功耗控制用户不会为了AI牺牲续航端侧模型跑起来功耗是绕不开的。我测过手机NPU满负荷跑7B模型功耗在5-8W相当于玩游戏的水平。如果Agent在后台持续运行续航直接崩。功耗优化的思路有两个方向。一是任务调度把推理任务集中在设备充电时或高性能模式下执行平时只做轻量级的感知和缓存。二是模型分级用一个小模型做常驻感知检测到需要复杂推理时再唤起大模型。这个思路类似CPU的大小核架构小核常驻大核按需唤醒。我见过一个团队的做法很聪明他们把端侧Agent的感知和决策拆开感知用规则引擎做几乎不耗电决策才调用模型而且只在特定触发条件下调用。这样平均功耗降到了1W以下。3.4 隐私边界端侧不等于绝对安全很多人觉得数据不出设备就安全了这个想法太天真。端侧模型本身可能成为隐私泄露的渠道。比如模型可能被诱导输出训练数据中的敏感信息Agent的日志可能记录用户行为模型更新时可能上传数据。端侧隐私保护要做三件事输入过滤、输出审查、日志脱敏。输入过滤是防止恶意prompt注入输出审查是防止模型泄露敏感信息日志脱敏是确保调试信息不包含用户数据。这三件事听起来简单但做起来很琐碎而且很容易在迭代中被忽略。4. 一个端侧Agent项目的完整搭建思路前面聊的都是判断和原理这一节聊点能直接上手的东西。我以一个本地文件智能整理Agent为例把端侧Agent的搭建流程走一遍。这个例子足够具体又不会太复杂适合作为第一个端侧Agent项目。4.1 需求定义先想清楚Agent要解决什么问题本地文件整理这个需求看起来简单其实可以拆成好几个层次L1根据文件类型自动分类图片、文档、视频L2根据文件内容自动命名和打标签L3根据用户习惯自动归档和清理我建议从L1开始做跑通了再往上加。原因很简单L1不依赖模型用规则就能做可以先把工程框架搭起来。L2开始需要模型但任务边界清晰容易评估。L3最复杂涉及用户习惯学习容易做成四不像。4.2 技术选型模型、框架、运行时模型选型上我推荐从3B级别的模型起步。这个规模的模型在意图识别和简单生成上够用内存占用可控推理速度也能接受。具体选哪个取决于你的设备平台平台推荐模型规模推理框架备注手机1B-3BMNN / NCNN优先考虑功耗PC7B-13BONNX Runtime / llama.cpp算力充足可以跑大一点车机3B-7BTensorRT / OpenVINO关注实时性边缘盒子7B-14BvLLM / TGI可以牺牲功耗换能力框架选型上我建议用现成的推理框架不要自己造轮子。llama.cpp在PC端很成熟MNN在移动端生态好ONNX Runtime跨平台支持好。选一个社区活跃的遇到问题能搜到答案。4.3 感知层实现Agent怎么知道发生了什么感知层是端侧Agent和云端Agent最大的区别。云端Agent的感知靠用户输入端侧Agent的感知靠系统事件。以文件整理Agent为例它需要感知的事件包括文件创建、修改、删除应用打开、关闭、切换用户操作点击、输入、拖拽设备状态时间、位置、网络、电量这些事件通过系统API获取然后经过过滤和聚合形成Agent的环境上下文。这里有个关键设计上下文不是越多越好而是要分层。我通常分成三层即时上下文最近几秒的事件用于响应式决策会话上下文最近几分钟的事件用于理解当前任务长期上下文历史统计和用户画像用于个性化决策三层上下文的更新频率和存储方式都不一样即时上下文放内存会话上下文放本地数据库长期上下文做聚合存储。4.4 决策层实现模型怎么用上下文做判断决策层的核心是prompt工程。端侧模型的prompt和云端不一样因为端侧模型的指令遵循能力通常弱一些prompt要更直接、更结构化。我常用的端侧prompt模板是这样的[系统指令] 你是一个文件整理助手。根据以下上下文判断是否需要执行操作。 可用操作分类、重命名、归档、删除、无操作。 输出格式{action: 操作名, target: 文件路径, reason: 原因} [环境上下文] 当前时间2024-01-15 14:30 最近事件 - 14:28 创建文件 /Downloads/报告_v3.docx - 14:29 修改文件 /Downloads/报告_v3.docx - 14:30 切换到浏览器 [用户习惯] - 用户通常将报告类文件归档到 /Documents/Reports/ - 用户习惯在文件修改后5分钟内归档 [输出]这个模板的关键是输出结构化。端侧模型容易跑偏结构化输出能约束它的行为。另外把用户习惯作为上下文传入能让决策更个性化。4.5 执行层实现操作怎么落地执行层相对简单就是调用系统API执行操作。但有几个坑要注意权限管理文件操作需要权限要提前申请并且做好权限被拒绝的降级处理操作确认删除类操作建议二次确认或者先移到回收站失败回滚操作失败要有回滚机制避免文件丢失操作日志记录操作历史方便用户追溯和撤销我踩过的一个坑是Agent在后台自动整理文件用户不知情结果把用户正在编辑的文件移走了。后来加了文件被占用时跳过的判断问题才解决。5. 端侧模型和云端模型的分工不是替代而是互补聊端侧模型很容易陷入端侧取代云端的叙事。我的判断是端侧和云端不是替代关系而是分工关系。搞清楚这个分工比争论谁更强有意义得多。5.1 什么任务适合端侧什么任务适合云端我总结了一个简单的判断标准判断维度倾向端侧倾向云端数据敏感度高个人数据、隐私数据低公开数据、通用知识实时性要求高毫秒级响应低秒级可接受任务复杂度低分类、抽取、简单生成高复杂推理、长文本生成网络依赖弱网或无网环境稳定网络环境成本敏感度高不想付API费用低愿意为能力付费按这个标准端侧适合做感知、过滤、预处理、简单决策云端适合做复杂推理、知识问答、内容生成。两者结合的方式是端侧做第一道处理把需要云端处理的部分脱敏后上传云端返回结果端侧再做后处理。5.2 端云协同的三种模式我见过三种端云协同模式各有适用场景模式一端侧优先云端兜底。端侧模型先处理置信度低时再调云端。这个模式适合对延迟敏感的场景比如语音助手。缺点是端侧模型能力有限兜底频率可能很高。模式二云端优先端侧缓存。云端处理结果缓存在端侧下次遇到类似请求直接返回缓存。这个模式适合重复性高的场景比如FAQ问答。缺点是首次响应慢且缓存命中率依赖场景。模式三端云并行结果融合。端侧和云端同时处理结果做融合。这个模式适合对质量要求高的场景比如内容生成。缺点是成本高且融合逻辑复杂。我实际项目中用得最多的是模式一因为它在延迟和成本之间平衡得最好。模式二适合客服类场景模式三我还没见过真正跑通的案例。5.3 端侧模型的更新策略端侧模型不是一次部署就完事需要持续更新。更新策略有三个选择全量更新直接替换模型文件。简单但下载量大用户体验差。增量更新只更新变化的参数。下载量小但需要差分算法支持。热更新模型分片加载按需更新。体验最好但工程复杂度高。我建议从全量更新开始配合后台下载和静默替换。等用户量上来了再考虑增量更新。热更新除非有强需求否则不建议碰坑太多。6. 踩过的坑和实测有效的经验这一节聊点实在的。下面这些经验都是我在实际项目中踩坑踩出来的文档里不会写但每一个都能帮你省下几周时间。6.1 模型量化后效果下降先别急着换模型模型量化后效果下降第一反应往往是量化太狠了换个模型。但我的经验是先检查量化校准集。量化不是简单的数值截断而是需要校准集来确定量化参数。如果校准集和实际使用场景不匹配量化效果就会很差。我遇到过一个案例模型在通用校准集上量化后意图识别准确率从95%掉到70%。后来换成业务场景的校准集准确率恢复到92%。所以量化前一定要准备和实际场景匹配的校准数据哪怕只有几百条。6.2 端侧推理速度慢先看是不是内存带宽瓶颈端侧推理慢很多人第一反应是算力不够。但实际上内存带宽往往是更大的瓶颈。模型推理需要频繁读写内存如果内存带宽不够算力再强也发挥不出来。判断方法很简单用性能分析工具看推理过程中的内存带宽利用率。如果带宽利用率接近100%那就是带宽瓶颈换更强的NPU也没用得从模型结构上优化比如减少内存访问次数、用更紧凑的数据格式。6.3 Agent行为不可控加约束比调prompt有效端侧Agent行为不可控比如该分类的时候去删除该沉默的时候乱说话。调prompt能解决一部分问题但更有效的方法是加硬约束。硬约束包括操作白名单、参数校验、频率限制、二次确认。比如删除操作不管模型怎么输出执行层都强制走二次确认。这样即使模型跑偏也不会造成严重后果。我的原则是模型负责判断规则负责兜底。不要指望模型100%可靠要用工程手段把不可靠的后果限制在可接受范围内。6.4 端侧Agent的测试比云端难十倍云端Agent的测试可以自动化端侧Agent的测试很难自动化因为环境太复杂。不同设备、不同系统版本、不同使用习惯都会影响Agent行为。我的做法是建一个场景库人工跑回归。场景库包含典型使用场景和边界场景每次模型或规则更新都人工跑一遍。这个做法很笨但很有效。自动化测试只能覆盖30%的场景剩下70%得靠人工。端侧Agent的测试本质上是在测试环境理解能力而环境是测不完的。所以测试策略应该是覆盖典型场景监控线上异常而不是追求100%覆盖。6.5 用户不信任Agent从可解释和可撤销入手端侧Agent最大的障碍不是技术是信任。用户不信任一个在后台自动操作文件的Agent这很正常。建立信任的方法有两个可解释和可撤销。可解释是指Agent每次操作都给出理由比如我把这份报告归档到Reports文件夹因为你上次也是这么做的。可撤销是指用户能一键撤销Agent的操作而且撤销要彻底不能有残留。我实测下来加了可解释和可撤销之后用户对Agent的接受度明显提升。这两个功能技术上不难但很多团队不做因为他们觉得用户不需要知道细节。这个想法是错的用户需要知道细节尤其是在Agent犯错的时候。7. 端侧模型的未来取决于三个问题的答案聊到最后我想把视角拉高一点。端侧模型能不能成为未来不取决于技术多先进而取决于三个问题能不能回答好。第一个问题端侧模型的能力边界在哪里现在大家都在试探有人觉得3B够用有人觉得要7B有人觉得要13B。这个边界不是固定的会随着模型架构和压缩技术的进步而变化。但有一点是确定的端侧模型不可能在所有任务上追平云端模型它必须找到自己的生态位。第二个问题端侧Agent的商业模式是什么云端模型按token收费商业模式清晰。端侧模型跑在用户设备上怎么收费卖模型卖服务卖硬件这个问题现在没有答案但必须有答案否则端侧模型只能是巨头的游戏。第三个问题用户愿意为端侧AI付出多少端侧AI消耗设备算力、电量、存储这些都是用户成本。用户愿意为数据不出设备付出多少成本愿意为离线可用付出多少成本这个问题的答案决定了端侧模型的市场规模。我个人判断端侧模型不会取代云端模型但会吃掉云端模型的一部分场景——那些对隐私、实时性、离线可用性要求高的场景。这部分场景有多大现在不好说但肯定不小。北大系这家公司押注这个方向赌的就是这部分场景会越来越大。至于设备即环境这个提法我觉得它更像是一个愿景而不是一个技术路线。它描述的是端侧模型的终极形态模型不再是设备上的一个应用而是设备本身的一部分像操作系统一样无处不在又像空气一样感觉不到存在。这个愿景能不能实现取决于上面三个问题能不能回答好。但至少它指出了一个方向一个和堆参数、拼算力不同的方向。