第一次在手机上跑本地模型，我的预期很低：一个几 GB 的东西，答得慢，还经常一本正经地胡说。用了一周之后，我反而觉得它在某些时刻比云端更可靠。不是因为更聪明，而是因为它不会在我按下回车之后转三秒圈，然后把请求发出去。
这个体验上的差别，比那些跑分对比更能解释厂商为什么会往这个方向押。
端侧先解决的是三件不性感的事
第一件是成本。云端推理按调用量线性增长，用户越多，账单越难看。放到端侧之后，这部分算力被摊到用户自己买的硬件上，厂商的边际成本接近于零。这笔账在几亿台设备的量级上非常可观，也解释了为什么很多 AI 功能敢直接免费放开。
代价是它把负担转移给了用户。手机发热、掉电、后台被占，这些都变成体验问题，而且用户不知道自己为此付了多少。免费的东西从来不免费，只是账单换了个地方出现。这是端侧方案里最少被提及的一处取舍，也是我在评测这类功能时会特别留意的地方。
第二件是延迟。云端要经历上传、排队、推理、下载，任何一环抖动都会变成转圈。端侧没有这一段，飞行模式下也能用，弱网环境下不会突然失效。对于输入法预测、实时翻译这种需要跟手的场景，这是决定性的。
它带来的另一个变化是交互形态。云端延迟高，产品只能设计成“提交一个问题，等一个答案”；端侧延迟低，功能可以嵌进打字、滑动、拍照这些连续动作里。这不是优化，是换了一种用法。
第三件是隐私。这不是宣传语，是架构上的差别：数据没有离开设备，也就不存在泄露路径。厂商能读本地日历、邮件、照片来做服务，前提是这些内容不出机器。反过来说，只要还走云端，这类功能在合规上就很难讲清楚。
我对隐私这条的理解比较朴素：它不是一个可以打折的卖点，而是一条要么成立要么不成立的边界。设备上跑不通的模型，就是跑不通，不能靠“我们会加密传输”补上。
量化和 NPU 是入场券
手机的内存和散热都撑不住一个按常规精度存储的模型。一个 3B 参数的模型用 FP16 存，光权重就要六 GB 左右，这在主流手机上等于把后台全杀了。
所以端侧方案几乎都要走低比特量化。Apple 在公开的技术材料里提到过混合 2-bit 和 4-bit 的策略，把平均位宽压到 3.5 bit 上下，让 3B 级别的模型能常驻内存。数字听起来很激进，实际效果是精度掉一点，换来了能跑起来这个前提。
我对这件事的判断比较保守：量化不是免费午餐。它在摘要、改写、指令遵循这类任务上损失很小，但在需要细粒度推理的时候，退化会突然出现——不是慢慢变差，而是在某些题型上整段崩掉。厂商选择在哪些功能上用这个模型，本质上是在选择在哪些地方容忍退化。
另一块是 NPU。它专为矩阵运算设计，能效比 CPU 和 GPU 高得多，模型被编译成对应的指令流，才能在生成文本时不至于立刻降频。这也是为什么同样参数量的模型，在不同芯片上的表现差距会那么大。
真正卡住体验的往往不是算力，是内存带宽。大模型推理是典型的内存密集任务，参数要一遍遍从内存搬到计算单元，带宽不够的时候算力再强也在等数据。功耗也是在这里涨起来的，不是算的时候费电，是搬的时候费电。
还有一种常被混在一起讲的手段是蒸馏。量化的目标是把同样的模型压小，蒸馏是让一个小模型去学大模型的输出分布，结构都换了。后者能省更多，但需要重新训练，也要有足够的高质量数据，改一次成本高得多。厂商在宣传里经常把两者说成一件事，实际是两套工程。
这也是为什么参数量的提升在端侧格外昂贵。云端加一层卡就行，手机上加不了，只能从架构和精度里抠。
Apple 和小米的两条路
两家的目标都是把模型装进手机，但站的位置不一样。
Apple 走的是极轻量的路线。它公开的 OpenELM 有一系列规格，从两亿多参数到 3B，覆盖手表、手机、平板几个算力层级。真正落到系统里的那个模型，重点不在对话，而在于做一个随时在线的组件：整理通知、改写邮件、理解屏幕内容。为了做到常驻，它用了 KV-cache 共享、低比特训练这类偏底层的手段，还配了一套基础模型加 LoRA 适配器的结构，不同任务共用一个底座，需要时再挂上对应的适配器。这样省内存，切换也快。
这个选择的代价是能力上限明显。它不会跟你聊很久，也不会写长文，遇到复杂请求要转给私有云。Apple 接受这个代价，因为它卖的是顺手，不是聪明。它希望的是你根本感觉不到在用 AI，只觉得这台机器做事变快了。
更值得看的是它接在哪儿。模型被做进系统框架里，第三方应用可以通过统一的意图接口来调用，助手能读屏幕内容、能操作别的 App。这一步比模型本身重要：能力再强，接不进系统，就只是一个独立应用，用户还得先想起来打开它。代价是开放度低，开发者能做的事被限制在框架允许的范围内。
小米走的是另一头。MiLM 有 1.3B 和 6B 两个档位，6B 在手机端已经算很重了，对内存和带宽的要求都高。换来的是更强的通用能力，能处理长一点的文档，也能把“把客厅调得温馨一点”这种模糊指令翻译成一串设备操作。小米的生态里有大量 IoT 设备，这种模糊语义的解析能力，价值比在手机上写诗大得多。
问题在于重。6B 常驻对续航不友好，实际使用里更可能是按需加载，加载本身又要时间。它更像一个被塞进口袋的云端模型，而不是系统组件。用户感受到的是等一两秒，然后得到一段像样的回答，这个体验其实也不错，只是它不属于“无感”那一类。
两家在适配上的处境也不同。Apple 自己控制芯片和系统，模型可以针对特定硬件深度优化；小米要在高通和联发科两套平台上都跑得动，还要兼顾车机和 IoT，工程量大得多，优化空间也更窄。这不是能力差距，是位置差距。
这两条路没有谁更正确。选轻量，就要接受它只能做小事；选全能，就要接受它贵、热、慢。真正的分歧在于厂商认为用户在什么时刻最需要 AI。
还有一个常见的误解是参数小就等于笨。它在知识广度上确实窄，记不住那么多冷门事实，但在具体任务上未必。训练数据洗得干净、任务边界清楚的时候，一个几 B 的模型在摘要、改写、按格式输出这些事上可以做得相当稳。真正掉链子的是它没见过的场景，不是它记住的少。
这也是端侧方案成立的前提：厂商不需要一个什么都懂的模型，只需要一个在几十个明确任务上不出错的组件。按这个标准衡量，很多看起来“不够聪明”的模型其实是够用的。
我暂时只相信端云混合
纯端侧的说法我不太信。现在的 3B 到 7B 模型，知识面窄，长链推理容易断，遇到没见过的任务会硬答。把这些短板藏起来不难，难的是用户真的碰上时怎么办。
有一种常见的辩解是“小模型只做特定任务就够了”。这话在单个功能上成立，在系统级助手上不成立。用户不会按照设计好的边界提问，他会在同一个输入框里问今天天气、让他写一段代码、再让他查一份合同里的条款。这三件事对模型的要求完全不同。
所以现实里的架构基本都是分层的：高频、低算力、强隐私的任务放端侧，长文处理、复杂推理、需要最新信息的请求路由到云端，中间还要处理一个很麻烦的问题——什么时候切。切得太早，端侧模型形同虚设；切得太晚，用户在等一个注定答不好的结果。
我更关心的是切换时的透明度。现在多数产品的做法是悄悄发出去，用户不知道自己的内容去了哪里。这个默认值对我来说不太能接受，尤其当讨论的是邮件和照片。理想的做法是给一个明确的提示，或者让用户自己选某类内容永远留在本地。
还有一层现实：这类功能的上线节奏和地区强相关，很多能力在发布时只覆盖部分语言和机型。宣传里的端侧智能，和手里这台设备实际能做的事，往往差着一年。评测时如果不区分这个，很容易把发布会当成产品现状。
发热和续航的问题也没有被真正解决。跑几分钟摘要还好，连续处理长文档或者本地生成图片，机身温度和电量掉得都很明显。这不是调优能解决的，是物理限制，只能靠使用频率和时间来摊薄。
现在的端侧智能也还停在单任务优化上：修图、摘要、改写、搜索照片。它不能自己跨应用完成一件事，每一步仍要用户触发和确认。宣传语里的一句话说清所有需求，离实现还有距离。
评测也是我比较在意的部分。跑分高不代表好用，这类模型的体感差异往往集中在很具体的地方：中文标点会不会乱、数字会不会改写、长一点的输入会不会丢后半段。这些都不在榜单上，只能自己用一段时间才能发现。
端侧模型的竞争不是参数竞赛，是谁能把“够用”这件事做得足够稳定。
我现在的判断是，小模型的价值会继续涨，但不会取代云端。它更像是把 AI 从一次远程请求，变成设备的一个基本能力，像定位、像蓝牙。用户不会为此专门打开一个 App，也不会觉得在跟 AI 对话，只是觉得这台机器变顺手了。
这大概也是它最容易被低估的地方。真正好的端侧 AI，是没有存在感的那种。用户不会夸它聪明，只会觉得这台手机该有的样子本来就是这样。
评论