1. 端侧模型这波密集上新到底在热闹什么最近几个月做移动端和PC端应用的朋友应该都有同一种感受端侧模型的新品发布节奏快得有点让人喘不过气。前脚刚把某个小参数模型集成进App后脚就冒出来一个同尺寸但推理速度翻倍的新版本这边还在纠结要不要上量化版本那边已经有人把MoE架构塞进了手机里跑。作为一个从早期端侧推理框架一路踩坑过来的人我对这波密集上新的态度是既兴奋又警惕——兴奋的是可选项终于多了警惕的是很多团队根本没搞清楚自己需不需要端侧模型就跟着热度往上冲。先把概念说清楚。所谓端侧模型指的是直接部署在用户设备手机、PC、平板、车机等本地运行的模型推理过程不依赖云端服务器。它和云端大模型最本质的区别不在于参数大小而在于推理位置决定了它的能力边界、成本结构和隐私特性。很多人一上来就问端侧模型能不能替代云端大模型这个问题本身就问错了——它们解决的是不同的问题不是替代关系。这波上新的核心驱动力有三个。第一是硬件算力上来了新一代手机SoC的NPU算力已经能支撑十亿到几十亿参数级别的模型做实时推理AI PC这边更是直接把独立NPU做成了标配。第二是模型架构在瘦身MoE混合专家架构让模型在总参数量不变的情况下每次推理只激活一小部分参数等于用更少的计算量换到了更强的表达能力。第三是应用场景在倒逼用户对响应速度、隐私保护、离线可用的要求越来越高纯云端方案在这些维度上天然吃亏。但我要泼一盆冷水密集上新不等于市场空间自动打开。模型多了选择成本反而更高了。我见过太多团队在选型阶段就卡住纠结于用哪个模型却没人回答这个功能为什么必须放端侧。这篇文章我想做的不是罗列最近发布了哪些模型而是把这波上新背后的技术逻辑、选型方法、落地坑点讲透让你在面对一堆新模型时能快速判断哪个跟自己有关。关键词里的MoE、AI手机、AI PC、Agent这四个词其实正好对应了这波上新的四条主线架构创新、终端载体、交互形态。下面我会一条条拆开讲中间穿插我自己在项目里踩过的坑和总结的判断标准。2. MoE架构为什么成了端侧模型的瘦身密码2.1 从稠密模型到稀疏激活一次推理到底省了什么要理解MoE为什么在端侧火起来得先搞清楚稠密模型Dense Model的推理成本是怎么来的。一个传统的稠密Transformer不管你输入什么问题前向传播时每一层的每一个参数都要参与计算。参数量越大单次推理的浮点运算量FLOPs就越高延迟和功耗也就越难看。在云端这不算大问题因为可以堆GPU但在手机上电池和散热是硬约束稠密大模型基本跑不动。MoE的思路很直接把原来一个大FFN前馈网络拆成多个专家子网络再加一个路由网络Router/Gating Network。每次输入进来路由网络先判断该激活哪几个专家然后只让被选中的专家参与计算。假设一个MoE层有8个专家每次只激活2个那么这一层的计算量大约只有同等总参数量稠密层的四分之一。注意是总参数量可以做得很大但单次激活参数量很小。这里有个特别容易混淆的点我必须强调MoE模型的参数量要分两个口径看——总参数量和激活参数量。一个总参数70亿的MoE模型如果每次只激活20亿那它的推理成本接近20亿稠密模型但表达能力可能接近甚至超过70亿稠密模型。这就是它在端侧的核心价值用有限的算力预算撬动更大的模型容量。不过MoE不是没有代价。路由网络本身要计算专家之间的负载均衡要处理显存/内存占用因为要装下所有专家而变大。在端侧内存往往比算力更紧张所以MoE在端侧的落地并不是无脑上而是要精打细算。2.2 端侧MoE的三个现实约束内存、功耗、路由开销我在实际项目里测过几个端侧MoE方案总结下来有三个绕不开的约束任何一个没处理好MoE的优势就会被吃掉。第一个是内存墙。MoE的总参数量大意味着模型文件大加载到内存后占用也大。手机端可用内存本来就紧张还要跟系统、其他App抢。我见过一个方案模型本身推理速度确实快但因为模型文件太大冷启动加载就要好几秒用户体验反而更差。解决办法通常是专家分组加载按需换入换出但这又引入了IO开销需要权衡。第二个是功耗。端侧推理最怕的就是持续高功耗导致降频。MoE虽然单次激活参数少但路由决策、专家调度这些额外逻辑会增加CPU侧的负担。如果路由网络设计得不够轻量省下来的算力可能又被调度开销吃回去了。实测中我发现路由网络的参数量最好控制在总参数的1%以内否则得不偿失。第三个是路由开销与负载均衡。训练时如果路由总是偏向某几个专家那几个专家就会被过度使用其他专家形同虚设MoE退化成稠密模型。端侧推理时如果路由分布不均还会导致某些计算单元过热。所以端侧MoE对训练阶段的负载均衡损失Load Balancing Loss要求比云端更严格。下面这张表是我整理的不同架构在端侧场景下的粗略对比参数是经验值具体项目要实测架构类型单次激活算力内存占用冷启动速度端侧适配难度稠密小模型1-3B低低快低稠密中模型7B量化中中中中MoE总参大、激活小低-中高慢高MoE总参中、激活小低中中中2.3 什么场景下MoE在端侧才真正划算不是所有端侧场景都适合MoE。我的判断标准是看任务复杂度是否分层。如果应用里的请求大部分是简单任务比如意图识别、短文本分类偶尔才有复杂任务比如多轮推理、长文摘要那MoE就很划算——简单任务激活少量专家复杂任务激活更多专家算力按需分配。反过来如果应用场景是高频、同质化的请求比如每秒钟要处理几十次相同的短指令那MoE的路由开销就是纯浪费不如用一个专门优化过的稠密小模型。我见过一个语音助手项目硬上MoE结果发现90%的请求都是打开XX设置XX这类固定意图路由网络每次都在做无用功最后换回稠密模型延迟直接降了一半。所以选MoE之前先问自己我的请求分布是长尾的还是集中的长尾分布MoE有优势集中分布稠密模型更实在。这个问题不搞清楚盲目追MoE就是给自己找麻烦。3. AI手机与AI PC端侧模型真正的落地战场3.1 AI手机端侧推理的算力账本怎么算聊AI手机绕不开一个核心问题手机到底能跑多大的模型这个问题没有标准答案因为它取决于三个变量——NPU算力、内存带宽、散热能力。我拿几个主流旗舰芯片的公开数据做过粗略估算结论是当前旗舰手机在保证可接受延迟首token 200ms以内的前提下能稳定跑动的稠密模型大约在3B到7B量化后之间MoE模型总参数可以更大但激活参数要控制在这个区间。这个账是怎么算的简单说模型推理的瓶颈通常不在算力峰值而在内存带宽。每生成一个token都要把模型权重从内存读一遍或者读激活的那部分。假设一个7B模型量化到4bit权重大约3.5GB内存带宽如果是50GB/s那么理论上每秒能读约14次也就是理论上限约14 token/s。实际因为各种开销能到一半就不错了。所以内存带宽才是端侧推理的真瓶颈不是NPU的TOPS数字。这也是为什么很多厂商在宣传AI手机时狂吹NPU算力但实际体验却一般——算力再高内存喂不上数据也是白搭。你在选型时优先看设备的内存带宽和可用内存而不是NPU的峰值算力。这个经验是我踩过坑才明白的早期我盯着TOPS选设备结果发现瓶颈全在内存上。3.2 AI PC的端侧优势和它特有的麻烦AI PC相比手机端侧推理的条件好太多内存大16GB起步32GB常见、散热好、可以插电不考虑功耗。这意味着AI PC能跑的模型规模可以到13B甚至更大而且可以做更激进的量化策略。但AI PC有它自己的麻烦。第一个麻烦是碎片化。手机的SoC就那么几家适配相对集中PC的CPU、GPU、NPU组合千奇百怪Intel、AMD、高通、苹果各有一套推理加速方案。你要做一个跨平台的AI PC应用光是适配不同厂商的推理后端就能耗掉大半精力。我的建议是优先用跨平台的推理框架把厂商特定的优化作为可选项而不是一开始就绑死某一家。第二个麻烦是用户预期。PC用户对本地AI的期待往往更高他们觉得PC性能强就应该能跑大模型。但实际上即便是AI PC跑一个未量化的13B模型也很吃力。所以产品设计上要管理好预期明确告诉用户哪些功能是本地跑的、哪些是云端的。第三个麻烦是模型分发。PC端模型文件动辄几个GB怎么分发、怎么更新、怎么管理版本都是工程问题。我见过团队用应用商店分发模型结果用户下载等待时间过长直接流失。后来改成基础模型随应用打包增量更新体验才好起来。3.3 端云协同别把端侧模型当成孤岛我特别想纠正一个误区上端侧模型不等于要抛弃云端。最务实的方案是端云协同——简单、隐私敏感、需要低延迟的任务放端侧复杂、需要大知识库、需要强推理的任务放云端。这个分工不是拍脑袋定的而是根据任务特性来的。具体怎么分我一般用三个维度判断延迟敏感度、隐私敏感度、任务复杂度。延迟敏感隐私敏感复杂度低放端侧延迟不敏感隐私不敏感复杂度高放云端中间地带做动态路由。比如输入法联想必须端侧因为每次按键都要响应而帮我写一篇周报这种云端更合适。端云协同的工程难点在于路由决策和状态一致性。路由决策要做在端侧因为如果连路由都要请求云端那端侧的低延迟优势就没了。状态一致性则是指端侧和云端的对话上下文要能衔接用户不会感知到中间换了模型。这块我踩过的坑是端侧模型和云端模型的输出格式不一致导致前端解析出错。后来统一了输出schema才解决。4. Agent在端侧跑起来难点到底在哪4.1 端侧Agent和云端Agent的本质差异Agent这个词最近被炒得很热但端侧Agent和云端Agent完全是两码事。云端Agent可以随便调用各种API、访问大模型、做复杂规划因为它有无限的算力和网络资源。端侧Agent则要在算力受限、网络可能不可用、内存紧张的条件下完成类似的任务这就决定了它的设计思路必须不同。端侧Agent最大的价值在于隐私和离线可用。比如一个帮用户管理本地文件的Agent它需要读取用户的文档、图片、日程这些数据如果上传云端隐私风险很大放端侧数据不出设备用户才放心。再比如在飞机上、地铁里这种网络不稳定的场景端侧Agent能保证基本功能可用。但端侧Agent的能力边界也很明显。它做不了需要大量外部知识的任务做不了需要调用多个云服务的复杂编排也做不了需要超大模型才能完成的深度推理。所以端侧Agent的定位应该是轻量级、高频、隐私敏感的个人助理而不是全能型智能体。4.2 端侧Agent的记忆与工具调用怎么落地Agent的核心能力有两个记忆和工具调用。这两个在端侧都有特殊的实现难点。先说记忆。云端Agent可以用向量数据库存长期记忆查询时做相似度检索。端侧做向量检索要么用轻量级的本地向量库要么用更简单的关键词匹配。我实测下来端侧做长期记忆检索用轻量级嵌入模型本地索引是可行的但索引大小要控制否则内存吃不消。短期记忆对话上下文则要严格控制长度因为端侧模型的上下文窗口通常比云端小。再说工具调用。云端Agent调用工具就是发个HTTP请求端侧Agent调用工具要复杂得多——它可能调用的是本地系统API、本地文件、本地传感器。这里最大的坑是权限管理。端侧Agent要访问用户的文件、通讯录、位置每一个都需要系统权限而且用户随时可能撤销。所以端侧Agent的工具调用逻辑必须能处理权限被拒绝的情况不能假设工具永远可用。还有一个容易被忽略的点端侧Agent的工具调用延迟。云端调用API有网络延迟端侧调用本地API虽然快但如果工具本身很重比如图像处理延迟也不低。所以端侧Agent的规划逻辑要考虑到工具执行时间不能像云端那样假设工具调用是瞬时的。4.3 端侧Agent的安全边界哪些事绝对不能让它做Agent安全是个大话题端侧Agent尤其敏感因为它直接操作用户设备。我给自己定的几条红线是端侧Agent不能自主执行不可逆操作比如删除文件、发送消息、支付这些操作必须经过用户确认端侧Agent不能自主访问网络除非用户明确授权端侧Agent的所有操作要有日志用户能追溯它做了什么。这几条听起来简单但实现起来需要架构上的支持。比如不可逆操作需确认意味着Agent的执行流程要能暂停、等待用户输入、再继续这对端侧的状态管理提出了要求。我见过一些端侧Agent项目为了追求自动化体验把这些确认步骤省了结果出了事故用户信任度直接归零。另外端侧Agent的提示注入防护也很重要。如果Agent会读取本地文件内容作为上下文那恶意文件里可能藏有指令诱导Agent执行危险操作。端侧Agent必须在把外部内容喂给模型之前做清洗和隔离不能让文件内容直接变成指令。5. 面对密集上新团队该怎么选型和落地5.1 先回答为什么必须端侧再谈选哪个模型这是我给所有团队的第一个建议也是最容易被跳过的一步。在选模型之前先写清楚这个功能为什么必须放端侧。如果理由只是端侧是趋势那大概率不该上端侧。合理的理由通常有三类延迟要求比如实时交互、隐私要求数据不能出设备、离线要求网络不可用场景。如果这三类都不沾云端方案通常更省事、效果更好。我见过一个团队为了技术先进性把图像分类放端侧结果发现端侧模型精度比云端低一截用户体验反而下降。后来老老实实放云端只在网络不可用时降级到端侧体验才平衡。所以端侧不是目的是手段想清楚目的再动手。5.2 端侧模型选型的五个硬指标确定要上端侧之后选型看什么我总结五个硬指标按优先级排序指标说明为什么重要内存占用模型加载后的峰值内存端侧内存是硬约束超了直接崩首token延迟从输入到第一个输出token的时间决定交互是否跟手生成速度每秒生成token数决定长文本体验量化友好度量化后精度损失端侧必须量化损失大就没法用生态成熟度推理框架支持、社区活跃度决定踩坑时有没有人帮你这五个指标里内存占用和首token延迟是硬门槛不达标直接淘汰生成速度和量化友好度是体验分生态成熟度是长期成本。我一般会先按前两个筛掉一批再在剩下的里比后三个。5.3 从Demo到量产中间隔着哪些工程坑Demo跑通和量产上线之间隔着无数工程坑。我挑几个最典型的讲。坑一模型加载时机。Demo里模型是启动时加载的量产时用户可能希望点开就用。如果模型加载要几秒用户就跑了。解决办法是预加载懒加载结合常用功能预加载冷门功能懒加载。坑二多任务并发。Demo里一次只跑一个推理量产时用户可能同时触发多个。端侧算力有限并发推理会互相抢资源。我的做法是推理请求排队优先级调度高优先级任务用户正在等待的先跑低优先级任务后台预计算让路。坑三模型更新。模型迭代很快怎么让用户无感更新全量下载太大增量更新又复杂。我目前用的是模型分片差量更新只下载变化的分片实测能省70%以上的流量。坑四异常降级。端侧环境复杂模型可能因为内存不足、权限问题、系统限制而失败。必须有降级方案——端侧失败时自动切云端或者返回简化结果。没有降级方案的端侧功能上线就是定时炸弹。5.4 一个务实的端侧落地节奏建议最后给一个我实践下来比较稳的落地节奏分四步走第一步单点验证。选一个延迟或隐私最敏感的功能用最小的端侧模型跑通验证技术可行性。这一步不要追求效果只验证能不能跑。第二步体验打磨。在单点功能上把延迟、内存、功耗优化到可接受水平建立性能基线。这一步要建立监控把端侧推理的各项指标采集起来。第三步端云协同。引入云端作为补充建立路由和降级机制。这一步的关键是让用户感知不到端云切换。第四步扩展场景。在验证过的技术底座上逐步把更多功能迁到端侧。这一步要控制节奏每迁一个功能都要重新评估内存和功耗预算。这个节奏的核心逻辑是先验证再扩展先单点再全局。我见过太多团队一上来就想做全端侧App结果卡在内存和功耗上项目直接黄掉。端侧模型的能力在快速进步但工程约束是实打实的尊重约束才能走得远。6. 我对这波端侧上新的真实判断聊了这么多技术细节最后说点我自己的判断。这波端侧模型密集上新技术上是真进步但市场空间不会因为模型变多就自动打开。模型只是工具真正决定市场的是场景——有没有一个场景用户愿意为端侧这个特性买单。目前我看好的端侧场景有三类隐私敏感的个人数据处理文档、照片、健康数据、低延迟的实时交互输入法、语音助手、游戏NPC、离线可用的基础功能翻译、摘要、简单问答。这三类场景的共同点是端侧带来的价值隐私、延迟、可用性是云端给不了的用户能感知到差异。不太看好的场景是那些为了端侧而端侧的功能——比如把本来云端跑得好好的通用问答硬搬到端侧结果精度下降、体验变差用户根本不买账。这种上新再多也打不开市场。对开发者来说我的建议是别被上新节奏带着跑盯住你的场景和用户。模型每个月都有新的但你的用户需求是相对稳定的。把场景想清楚把工程做扎实等真正适合你场景的模型出现时你才有能力快速接住。反过来如果场景没想清楚模型再新也跟你没关系。端侧模型的未来肯定是向好的算力在涨、架构在优化、工具链在成熟。但这个未来不是均匀到来的它会先在那些真正需要端侧的场景里落地再慢慢扩散。作为从业者我们要做的是找到那个真正需要的点然后把它做透。
