前段时间给一款智能硬件做AI功能评估接触了北大系团队的技术负责人聊到“设备即环境”这个提法。初听像一句口号再一听他补了一句“端侧模型才是未来”我当时是不太信的——这几年端侧模型落地我看过不少大部分情况是“能跑起来”而已演示很热闹一上真实场景就露怯。但那轮聊完我花了两周时间把手头的端侧推理框架重新拉出来测了一遍翻了一些他们公开的技术思路也跟几个做移动端AI的朋友交换了意见。这篇文章就是想把这两周看到的、验证过的东西整理出来给正在做边缘AI、智能硬件、移动端功能的朋友留一份可以复查的参考端侧模型到底是什么、能解决什么问题、哪些场景值得做、哪些坑必须绕开以及“设备即环境”这四个字背后到底藏着一套什么样的技术逻辑。1. “设备即环境”这个提法改变的不是口号而是工程起点1.1 一次差点被“口号”劝退的对话先复盘一下那次交流的现场。对方给我演示了一个端侧OCR加一个端侧文档摘要的小工具设备是台普通的Android平板飞行模式下跑完全流程。演示不惊艳毕竟功能本身不算新鲜。但他说了一句让我当时接不上来的话“我们不是在做一个离线版App我们是把设备当成交互环境来设计整套模型系统。”“把设备当成交互环境”——这句话后来反复出现在我脑子里。因为大多数做AI应用的人包括我工程起点其实是反过来的先选一个大模型然后把它被部署到云端再考虑手机怎么连上去。设备只是模型的接收器、显示器它的存在感很弱。而那个团队做的事情是把摄像头、麦克风、传感器、屏幕刷新率、电池余量都当成模型输入的一部分模型在设备内部感知环境、做出决策、立刻反馈。设备不再是客户端而是推理发生的现场。1.2 设备不是“显示器”而是推理发生的现场传统云端方案里设备承担的是一个“输入和展示”的工作你对着手机说一句话语音流上传服务器服务器返回文本或动作手机播放结果。整个过程里设备本身没有智能它就是一个远程桌面的显示器。“设备即环境”的说法把这句话整个翻了过来。它强调模型要跑在数据产生的地方推理必须在行为发生的时间窗口内完成。比如智能音箱唤醒词如果每次都要上传云端做识别网络抖动一次就废了比如工业流水线质检摄像头每秒拍几十帧这一帧和下一帧之间没有时间去等云再比如车载语音助手进隧道断网的那几秒恰恰是驾驶员最需要辅助的时候。这种高频、低延迟、强交互的现场感云端再强也给不了。换个直白比喻云端模型像一个远程专家设备本地模型像一个贴身助理。远程专家知识渊博但打电话需要排队、信号可能不好贴身助理知识范围有限但随叫随到知道你桌面摆着什么、周围正在发生什么。这几年的大模型赛道把注意力都放在“专家”身上反而忽略了“助理”的价值。“设备即环境”就是要把助理这个角色重新立起来。1.3 不是所有智能都要上天从云端思维到现场思维那次交流后我意识到我不是反对端侧我反对的是“为了端侧而端侧”的形式主义。很多人把模型往手机里一塞就说自己是端侧智能结果既不快也不准体验反而更差。真正把这套思路跑通的人会把工程起点重新定位成四个问题设备上有什么算力设备现在处于什么状态用户在这个场景里的反馈时限是多少哪些数据绝对不能离开这个设备这四个问题问完你会发现端侧和云端的分工自然就出来了——能现场完成的现场完成需要全局知识的再上云。这种思考方式最开始只是一句话到后来真的会改变产品架构的起点。这也是为什么我愿意花两周时间去验证它而不是直接当口号略过。2. 端侧不是“小云”算力、功耗、隐私三方权衡的边界2.1 端侧模型和云端模型差的不只是“跑在哪”很多人觉得端侧模型就是“参数少一点的云端模型”这是最需要纠正的误区。两者的物理条件、约束环境和评价指标都完全不同。我整理了一张对比表方便大家直接对照对比维度云端大模型端侧模型参数规模数十亿到数千亿1B到8B为主流甜区运行位置数据中心GPU集群手机、车载、网关、摄像头首响延迟秒级到数秒网络波动影响大百毫秒级本地完成离线能力断网即停飞行模式下完整可用单次推理成本GPU时长、token计费消耗电池边际成本趋近于零数据隐私数据出设备依赖传输链路数据不出设备模型更新云端热更新OTA推送或出厂固化个性化依赖云端画像用户标识直接读取设备上下文天然个性化重点说后两行。云端模型的个性化本质上是通过用户画像凑出来的一套“猜你喜欢”端侧模型的个性化是真正看着你的手机里的日程、位置、使用习惯做推理。两者获取上下文的方式完全不同这也决定了隐私边界和使用体验的差异。2.2 端侧能跑起来靠的是四根技术支柱但凡做过端侧部署的人都知道“模型能跑”和“模型能用到生产环境”之间隔着四条沟哪条沟都要靠技术填量化把FP16的参数压成INT8或者INT4模型体积直接缩小到原来的1/4到1/8。比如一个7B模型FP16权重大概14GBINT4量化后大约4GB才能在手机内存里摆得下。代价是精度损失需要靠校准数据去补。知识蒸馏用一个参数量小很多的“学生模型”去学大模型的输出行为而不是单纯学参数。蒸馏做得好的小模型在特定任务上可以达到大模型八九成的效果。结构剪枝把网络里贡献很小的权重、通道甚至整层结构去掉瘦身之后模型变小变快代价是要重新微调。算子融合与内存重排把多个计算步骤合并成一个算子减少内存来回搬运这在端侧比扩张算力更直接有效。这四根支柱缺一不可。很多团队只做量化模型是塞进去了但精度崩得没法用有些团队只做蒸馏结构没问题但计算图效率太低帧率上不去。真正跑通生产环境得四件事一起上。2.3 不是说云没用了而是权力边界变了这里必须说清楚我写这些不是要否定云端。事实上端侧模型越普及云端反而越重要。但两者的关系会从“云端包办一切”变成“端云分工”。我拿“智能助手”举例。让助手关灯、定闹钟、发消息这种确定性任务端侧完全能搞定让助手分析“帮我写季度复盘提纲”需要领域知识和全局视野得交给云端大模型。再比如手机上的相册搜索人脸聚类在端侧先做一遍跨照片的复杂语义检索再上云。端侧负责快、稳、私密云端负责博、深、全局。这个边界不是技术能力决定的而是产品体验和安全边界决定的。想清楚这个边界架构设计自然会顺很多。3. 我跑通的三种端侧部署路径框架选型、量化精度与掉坑记录3.1 路径一传统视觉和文本小模型走MNN、NCNN如果你的任务还是OCR、人脸识别、文本分类这类传统深度学习任务我认为最稳的思路是用阿里的MNN或者腾讯的NCNN。这两个推理框架在中国Android生态里的兼容性做得非常细对ARM芯片的指令集适配很成熟。我这次测试手里有几个训练好的ONNX模型。转换命令很简单但容易卡在“算子支持”这个环节# 以MNN为例把ONNX模型转成MNN格式 mnnconvert -f ONNX --modelFile your_model.onnx --MNNModel your_model.mnn --bizCode MNN转换完之后记得跑一下MNN.py的量化工具用INT8或者INT16做一次校准。我第一次没做量化校准直接跑了原始FP32模型内存占用直接超了目标设备预算。MNN的量化工具一般可以这样用# 用校准数据生成量化模型 python quantize.py --model your_model.mnn --calib_data ./calibration_images --quant_model quantized_model.mnn有一个容易踩的坑如果你的模型里有自定义算子转换器大概率直接报错或者生成一个“降级到CPU”的图。这时候别硬刚转换器回到PyTorch/ONNX侧把自定义算子用标准算子重写一遍比在推理框架里写算子插件省事得多。3.2 路径二LLM类的3B-6B模型走llama.cpp或MLC-LLM这次测试的重点其实是“在端侧跑量化版的对话模型”。我用llama.cpp跑了一个3B模型的Q4_0量化版目标设备是一台8GB内存的旗舰安卓手机。流程本身不复杂# 克隆并编译llama.cpp cmake -B build -DCMAKE_BUILD_TYPERelease cmake --build build --parallel # 把HF的GGUF模型放进对话工具里跑 ./build/bin/llama-cli -m qwen2.5-3b-instruct-q4_0.gguf -p 写一段端侧模型的简介 -n 128跑通本身只用了十几分钟真正花时间的是性能调优。实测下来3B模型在旗舰手机CPU上大概能跑到每秒15到20个token看着还行但连续生成超过200个token后机身开始发热然后触发降频速度掉到10 token/s以下。这个体验做智能问答勉强可用做长文生成完全不够。解决方案有两个方向一是消减上下文长度把窗口控制在1024以内减少KV Cache内存占用二是改用真正支持NPU的SDK让算力分担一部分但这取决于芯片厂商的工具链是否支持llama.cpp这类通用框架。实测下来NPU跑LLM仍然是个半开放状态各家的支持程度差异很大。3.3 路径三NPU加速路线绕不过算子支持矩阵我在另一台高通骁龙平台上尝试用厂商SDK把模型一部分算子挪到NPU上去跑。视觉模型还好Conv、Pool、FC这些算子基本都有硬件实现但一旦模型结构里带了动态Shape的Attention、复杂非线性函数比如GELU变种、RoPE位置编码NPU支持矩阵就开始打问号。这轮测试里我比较实际的收获是这句话端侧加速的第一原则不是“全部上NPU”而是“只把最热、最稳定的算子交给NPU其余留给大核CPU”。别追求一张计算图全部加速那样只会把自己困在厂商工具链的文档里。先跑全CPU版本打底再用性能分析工具找到热点算子逐个试验能否用NPU算子重写。3.4 我在实测中遇到的三类硬坑既然我花了两周时间踩坑那就把最有代表性的三类问题列出来供各位避开量化后精度崩溃但崩溃得毫无规律视觉模型INT8量化通常只掉零点几个点但一个BERT类的文本分类模型INT8后F1直接掉到接近乱猜。排查之后发现问题出在某个动态范围极大的层上。解决办法是开启混合精度计算图中保留少量层用FP16其余用INT8。这个策略下模型体积只增加了一点点精度回来了。算子不支持编译期狂报错前面说过了应对方法是回模型定义侧改写结构别在推理框架侧写复杂插件那样维护成本太高。内存带宽是隐形天花板LLM生成速度主要不取决于算力而取决于内存带宽——因为每一步生成都需要把整个模型权重过一遍。这也是为什么模型体积从4GB降到3GB速度能明显提升原因就是少了1GB的搬运量。选型时不要只看“模型能不能塞进内存”更要看按你的带宽条件算出的预估吞吐。4. 北大系团队主张的“设备即环境”到底做对了什么4.1 不做“第二个大模型”做“围绕设备的模型系统”回到那家北大系团队。了解了他们公开的技术走廊和演示能力之后我发现他们和大多数做端侧的公司有一个明显区别他们不是把一个通用大模型压缩一下塞进设备而是把设备的物理信息、状态信息、交互节奏直接设计进了模型系统里。举个例子。他们演示过一个“会议记录助手”的端侧版本做的事很简单实时转录会议语音然后在本地生成要点列表。市面上同类功能基本都走云端ASR加云端总结他们却把ASR和摘要全部放到了设备里。区别在于云端方案只能在“会议结束后”给你一份纪要而他们的端侧版本可以在“会议进行中”随时打断、问上一段讲了什么因为模型就在本地上下文可以持续保留延迟又低。这个例子本身不难但把“设备即环境”落地得很清楚——模型感知到了会议这个正在发生的事件可以随时响应而不是把一段录音上传上去等服务端返回。设备在这里不是录音笔而是推理的现场。4.2 环境感知的价值从“被动响应”到“主动适配”“设备即环境”更深一层的意思是模型可以持续感知环境状态进而改变自己的行为策略。云端模型也能做类似的事但它拿到的是脱敏后的用户行为序列永远是“二手信息”。端侧模型则可以直接拿到第一手信息。举个例子智能座舱里的语音助手。云端方案只能根据用户说出的文字内容做应答但如果模型跑在车内设备上它可以读到空调温度、车窗状态、驾驶员最近几十分钟的驾驶习惯那么面对同一句“我有点热”端侧模型的动作路径是先确认当前温度再结合用户习惯决定开空调还是调风速而云端模型能做的只是回一句“好的马上帮您打开空调”。信息层级差了一截。这种环境感知能力很难靠云端做到极致因为数据先天到不了云端或者到了云端但已经缺少时间上下文。端侧模型的优势就在这里它在现场它能看到一切。4.3 端云协同的关键是“更新在云执行在端”北大系团队还有一个我现在比较认可的观点端侧模型不该是静态的。设备上跑的模型可以通过OTA升级也可以通过设备端采集的数据做轻量自适应调整。云端负责训练、蒸馏和发布端侧负责执行、反馈和本地进化。两者之间有一条轻量的数据回路但原始数据永远不出端只有模型更新包和设备状态摘要会通过安全通道传输。这套逻辑很像“大脑和脊椎”的分工云端是大脑负责思考和学习端侧是脊椎反射弧负责快速反应。大脑指导脊椎升级但每一次防御动作不需要先汇报大脑。这种端云协同不是把功能拆开而是把生命周期拆开从模型设计之初就考虑两边怎么配合。5. 端侧模型适合做什么、不适合做什么我的实战筛选清单5.1 建议优先上端的四类场景我这轮调研下来有四类场景最适合端侧模型而且已经能看到规模化落地语音唤醒与实时交互智能音箱、蓝牙耳机、车载语音唤醒词必须在端侧做否则断网即哑。这类场景对延迟和稳定性要求极高恰好是端侧的地盘。隐私敏感的数据处理医疗记录、金融流程、企业内部文档数据出设备本身就是风险。本地推理加脱敏处理是合规成本最低的方案。弱网与无网环境下的连续性服务电梯间、隧道、地下停车场、偏远工地这些场景里云端方案基本不可用端侧模型是唯一答案。低功耗传感器异常检测工业设备振动监测、冷链温度监控、穿戴设备健康预警这类任务模型很小但需要7x24小时运行设备端推理省去了大量无线传输的功耗。5.2 不建议硬塞到端侧的三种场景对应的我也给几个劝退场景需要海量事实知识的事实问答比如“某公司2024年第三季度财报中的现金流是多少”这类问题依赖最新、最全的数据库端侧模型更新频率不如云端跑错了还不如不回。超长文档跨页推理大上下文带来的是KV Cache内存暴涨端侧一次顶多放几万token真拿一本几百页的说明书去问细节体验大概率翻车。需要频繁联网更新的高频业务数据比如股市实时查询、电商价格比选数据源本身在云端把推理放在端侧没有意义。5.3 一张评分表帮你做需求判断我给自己做需求评估时用的是一张很粗但很实用的评分表。每项打1到5分分数越高考量越偏端侧评估维度决策指向延迟敏感度尺度到毫秒级则5分分数越高越需要端侧隐私等级数据绝不出设备则5分分数越高越需要端侧可用性要求弱网也要干活则5分分数越高越需要端侧数据量级单设备闭环数据则5分分数越高越适合端侧更新频率知识变化极快则给低分分数越低越适合云端你拿任何一个需求过来把这五项打完分方向基本就清楚了。我自己做完这套表之后最大的感受是端侧不是“什么都能做”但该做的那些事云端确实做不了。6. 端侧模型的几块硬骨头碎片化、带宽围城与持续迭代6.1 最头疼的是芯片碎片化说句实在话端侧模型落到真实设备上最大的麻烦不是模型本身而是底下的硬件太碎。苹果的ANE、高通的Hexagon、联发科的APU、华为的达芬奇NPU各自的中间表示、算子集合、量化格式都不一样。你在骁龙上调通的算子换到天玑平台上可能要重新编译甚至重写。这个问题的短期解法是靠ONNX Runtime、MNN、NCNN这些跨平台框架做一层统一接口但底层还是各家SDK各自为战。我自己养成了一个习惯在项目评估阶段就锁定目标芯片列表并按这个列表的“最小公倍数”约束模型结构能用标准算子就不用花哨变体。6.2 内存带宽是看不见的围城很多人看端侧设备参数只看算力TOPS但LLM这类模型的推理瓶颈其实是内存带宽——每一步推理都要把权重从内存搬运到计算单元权重越大搬运越久生成速度越慢。我用一张表格方便你理解端侧大模型体积按LPDDR5常见带宽估算的单字平均生成上限3B INT4约2GB每秒25到40 token7B INT4约4GB每秒10到18 token13B INT4约7GB每秒7到10 token不是说跑不了而是长文本生成的速度会被“搬砖”卡死。如果产品必须要每秒40 token以上的生成速度端侧模型参数最好控制在3B级别以内或者把KV Cache和权重都做二次压缩。设计产品时请把带宽当成CPU核心数量一样看待。6.3 模型更新与OTA端侧不是一锤子买卖端侧模型跑上线之后后面还有一个很容易忽略的问题模型怎么持续改进。云端模型训一版新的可以直接发布端侧模型却要考虑用户设备上的旧模型怎么升级——网络环境各异、设备型号各异动辄几十MB到几百MB的更新包稍有不慎就会变成卸载率危机。比较务实的做法是把端侧模型拆成“基座”和“增量”两层。基座模型出厂固定少更新增量模块通过OTA小包升级。同时做好灰度更新和自动回滚设备上保留上一版模型作为兜底。我见过不止一个团队模型调好了却因为更新策略没设计好最后被一堆差评逼得连夜撤回上线计划。6.4 生态还在混战但方向已经看得见即便有这么多问题我仍然认为端侧模型的趋势已经很难逆转。原因很简单芯片端的算力每年都在涨成本每年都在降推理框架的兼容性在变好GGUF、ONNX这样的开放格式正在成为事实标准更重要的是用户对隐私和离线体验的要求只会越来越高。端侧模型也许不会替代云端大模型但它一定会成为AI产品里一个不可或缺的组成部分。我自己的习惯也已经被这次调研改变了。现在看任何一个AI功能我都会先问一句“这个功能如果断了网还能不能体面地完成”凡是回答“不能”但业务上又要求稳定、隐私和低延迟的我都会重新考虑一次架构。端侧模型不一定能解决所有问题但它让“智能”这件事第一次真正回到了用户手里。