--- layout: post.njk source: https://yage.ai/share/bonsai-iphone-on-device-model-routes-20260726.html speaker: yage.ai title: |- 27B 模型进了 iPhone，问题终于从“能不能跑”变成“跑它有什么用” date: '2026-07-26' summary: 文章探讨了将大语言模型（LLM）部署到iPhone等移动设备上的可行性与应用场景。核心观点是端侧模型的价值在于处理本地的、私密的实时理解需求，如屏幕识别、票据整理和敏感信息摘要，以减少数据上传和网络延迟。文章对比了两种主流路线：一是通过极低比特量化保留大模型推理能力（如Bonsai 27B），适用于通用文字推理；二是采用小模型结合高精度视觉编码器（如MiniCPM-V或Gemma），更适合处理图片、截图等多模态任务。最终结论强调，选择哪种路线取决于具体任务需求和对可靠性、功耗的权衡。 area: tech-engineering category: ai-application tags: - on-device-llm - mobile-inference - model-quantization - multimodal-agent people: [] companies_orgs: [] products_models: - Bonsai 27B - MiniCPM-V 4.6 - Gemma media_books: [] draft: true status: evergreen --- 把大语言模型放进 iPhone，最常听到的疑问有两个：手机上跑 LLM 到底能做什么，以及就算跑得起来，又怎么可能好用。这两个问题比单纯看参数量更重要。刚发布的 Bonsai 27B 并没有证明手机能取代云端 Agent，但它给这两个问题提供了一个更具体的讨论参照。 手机集中保存着大量个人隐私：相册、截图、聊天记录、位置、健康数据、银行通知和工作文件，往往同时集中在同一块屏幕上。特别是图片输入，发往云端既有隐私泄露的顾虑，也要面对文件体积大、网络波动与等待返回的时间成本。用户拍下收据、截取付款页面或打开医疗报告时，最希望设备能在本地当场处理完毕，省去数据上传远端并等待响应的过程。 端侧模型的用处就在这里。与其让聊天机器人在地铁里离线写诗，不如把那些短小、私密、需要立刻看到结果的理解需求留在本地：读取屏幕、识别票据、整理照片、从本地资料中提取关键字段，或者把敏感内容压缩成一段摘要，由用户决定要不要发送出去。这样数据不用离开手机，首轮交互也省下了一次网络往返。 再往前看，ambient agent 给手机带来了新的应用空间。Google 在 I/O 上演示过这类探索：系统能理解用户眼前的屏幕和当前情境，在合适的时机给出建议，或者在拿到明确授权后替用户完成操作。它不会频繁打断人，更像个安静的协作者。ambient agent 的逻辑也是如此：Agent 要想看懂屏幕、图片和即时上下文，手机就是离这些原始数据最近的地方。端侧视觉模型给这个方向划出了更合理的隐私与延迟边界，但它本身还没能解决权限控制、失败恢复、后台调度和责任认定这些关键工程问题。 端侧模型的两条路线：高效视觉理解与极低比特大模型压缩 ## 真正难的不是下载一个模型 手机端模型推理的限制主要集中在四个地方。 一是内存。模型文件能塞进手机闪存，不代表运行时就能顺利装进内存。运行时的实际内存占用（也就是工作集），除了模型本身，还要算上上下文 KV cache、激活值、runtime buffer 以及视觉编码器。一个模型即使表面指标“只有 4 GB”，一旦读入大图或拉长对话，依然可能直接撞上 iOS 的进程内存上限。 二是功耗与发热。生成每一个 token 都要反复读取模型权重；模型越大，内存带宽和散热极限就越早变成瓶颈。跑完一次 20 秒的回答并不难，但要连续生成 30 分钟 token、在插拔充电器时保持速度稳定、并且从后台切回来后还能正常恢复，才是真正的产品门槛。 三是视觉 prefill（预填充阶段）。对手机上的多模态任务来说，耗时主要集中在最初的图像处理环节，而非后半段逐字生成。图片需要先解码、缩放、切分，再通过视觉编码器转换成语言模型能读取的视觉 embedding。模型在纯文字聊天时反应快，不代表它能迅速看清一张密集的表格。 四是可靠性。Agent 任务能否完成，取决于整条交互链条，绝非模型输出一段顺畅的话那么简单。它还得准确看懂屏幕、判断要不要调用工具、拿到用户授权、处理网络或系统中断，同时留好随时能恢复的任务状态。端侧模型解决的，只是这整条链路中的一步。 ## 主流路线：把模型做小，并把视觉做省 过去主流的思路，是先缩减模型体量，再在架构与量化策略上精打细算，省下每次推理的开销。 MiniCPM-V 4.6 就是典型的例子。它由 SigLIP2-400M 视觉编码器和 Qwen3.5-0.8B 语言模型组合而成，总参数量约 1.3B。它的优势在于处理手机上的图片、截图、文档、OCR、视频和 UI 界面，而非通用的长文本推理。这个模型设计了 4x 和 16x 两档视觉 token 压缩率：16x 跑得更快，4x 能保留更多细节。这也解释了许多人使用时的直观体感：图片刚进入模型时处理最慢，一旦视觉 prefill 跑完，后面的文本生成就会显得飞快。但在读取精细的 OCR 资料时，速度模式替代不了细节模式。 在 OpenBMB 公布的数据里，MiniCPM-V 4.6 在 4x 设置下的成绩是：OCRBench v2 英文 40.6、中文 47.3，OmniDocBench 84.6，DocVQA 89.4；在 Artificial Analysis 的发布测试中得到 13 分的 Intelligence Index 指数，在 2B 以下的开源权重模型中名列前茅。这些跑分虽然替代不了拿真实票据或财务表格去实测，但方向很明确：先把手机需要的这双“眼睛”做出来。 Google 的 Gemma 系列也是这个方向。最新的 Gemma 4 E2B/E4B 主打移动与边缘场景，支持文本、图片、音频和视频输入；其中 E4B 的有效参数约 4.5B，总参数约 8B。Artificial Analysis 与 Google 官方数据显示，E4B 在 MMLU Pro、AIME 2026、LiveCodeBench v6 和 Tau2 测试上的得分分别是 69.4、42.5、52.0 和 42.2。它的策略避开了对超大稠密模型的强行硬压缩，选择在手机能容纳的内存工作集内，守住多模态感知与工具调用的能力。 微软的 Phi 系列则更偏向纯文本。Phi-4 Mini 是个 3.8B 左右的文本模型，适合做轻量的本地文字推理；若需要看图或语音，就得换成 Phi 的多模态版本或其他模型。这也说明，“小而强”不能直接和“手机上的视觉 Agent”划等号：模型的模态支持、runtime 优化以及应用集成，都缺一不可。 MiniCPM5-1B 则提供了另一种搭配思路。它不处理视觉输入，而是聚焦于 1B 级别纯文本模型在本地总结、任务规划、写代码和轻量工具调用上的效率。把它和 MiniCPM-V 4.6 放在一起看，能看到一种比单纯比较参数更实用的分工协作方式：视觉模型负责“看见和提取”，文本模型负责“读懂文字、做规划并决定下一步操作”。 ## Bonsai 的不同赌注：保留大模型，压缩每个权重 Bonsai 27B 选择了不同的路线。它没有重新训练一个 1B 或 4B 模型，而是直接拿 Qwen3.6-27B 当基座，把语言网络的权重压成二元 {-1,+1} 格式，每 128 个权重共享一个 FP16 缩放因子（scale），实际折算约为 1.125 bit/weight。经过这种处理后，27.3B 参数的语言模型在运行时的原生工作集约为 3.9 GB；加上大约 0.63 GB 的可选视觉塔，公开发布的 MLX 权重包总共大约 5.13 GB。 这次设计的启发点在于打破了传统的端侧选型假设，而非“27B”这一规格标签。过去的惯性思维认为，模型要进手机必须先缩小基础参数。而 Bonsai 提出的假想是：只要量化足够激进，同时计算内核（kernel）可以直接高效处理打包好的二进制权重（packed binary weights），就有机会把大模型自带的推理和代码能力塞进手机的内存窗口里。 根据 PrismML 官方公布的数据，1-bit 版 Bonsai 在 15 项思考模式（thinking-mode）测试中的平均成绩是 76.11，相比 Qwen3.6-27B FP16 基座的 85.07 分，保留了大约 89.5% 的能力。细看分类，它在数学类别得分 91.66、代码类别得分 81.88；但在工具调用上降至 66.03，视觉类别只有 59.57，说明极端压缩并不是没有代价。在 iPhone 17 Pro Max 上，PrismML 测得它的 TG128 decode 速度是 11 tok/s，连续生成约 10.8 tok/s；但这组数据来自厂商自测，且演示中注明使用了预先缓存/预填充的图像上下文（cached/prefilled image context），不能当成未缓存图片的冷启动 OCR 端到端速度。 ## 大模型加 1-bit，还是小模型加较高精度？ 这才是 Bonsai 真正提出的核心问题。两条路线针对不同的使用场景，在实际选型中并非由单一路线全面胜出。 在通用文字推理、数学、写代码和边界清晰的工具任务上，“大模型加极低比特”的优势相当突出。Bonsai 靠着 27B 的基座，保留了小模型难以补回的知识与复杂推理空间；厂商自己的测试也说明，它在 1-bit 下对数学和代码的保留，明显好于工具调用和看图。如果主要拿它做离线阅读、总结、写草稿或辅助编程，且手机内存足够装下模型与短上下文，它确实触及了此前手机上未曾出现过的能力上限。 但在面对看图、解析文档和操作手机界面时，“小模型加更高精度”未必会落后。视觉任务的瓶颈往往卡在图像编码与预处理上，而不只是语言模型的 decode 阶段。MiniCPM-V 4.6 的做法是用小一点的语言模型、专门优化的视觉编码路径以及可调的压缩率，把首次读图的开销压到实用范围内；Gemma 的边缘型号则补充了多模态与音频能力。遇到“快速看懂高分辨率票据并准确提取字段”这种具体需求，较小但专门优化过视觉的模型，可能比极低比特的大模型更可靠、更省电，工程上也更容易落地。 公开测试数据衡量的是不同维度的侧重点。Bonsai 的 76.11 分是 PrismML 在 H100 显卡上用 EvalScope 和 vLLM 测出的 15 项思考模式均分，侧重评估纯文本逻辑与代码能力，却反映不出手机上的热衰减与无缓存视觉延迟；MiniCPM 的 13 分是 Artificial Analysis 推出的综合能力指数，无法直接衡量复杂财务单据的提取精度；Gemma 的数据则源自其特定的多模态测试配置。即便同在 OCRBench v2 上，Bonsai 公布的 58.65 与 MiniCPM-V 4.6 的 40.6（英文）/ 47.3（中文），也因图像预处理、prompt、视觉 token 压缩率及评分条件的不同而无法横向换算。对产品构建者而言，这些指标揭示了模型在各自设定下的强项，但文本推理、视觉识别与设备端实际运行是三个独立的选型决策，不能试图用单一的分数来笼统覆盖。 更具参考价值的结论，应当分条件来看： 任务主要是文字推理、代码与短上下文综合，并且模型能稳定装进手机时，优先评估“大基座加极低比特”这条路线。 任务主要是图片、截图、表格、票据和视频时，视觉编码效率、图像 token 数量、OCR 细节保留与首轮延迟，比语言模型的参数量重要得多；这时应该优先评估 MiniCPM-V 或 Gemma 这类专门做端侧多模态优化的方案。 要做高可靠的多步 Agent，绝不能只看模型跑分。工具调用准不准、权限怎么设计、出错了能否恢复、设备发热稳不稳定，以及后台运行有什么限制，才是决定它能否替用户真正完成任务的关键。 ## 从演示到产品，还差一组手机上的共同实验 Bonsai 的出现说明：27B 级别的模型不再必然被存储与内存门槛挡在手机门外。MiniCPM-V 4.6 则说明：模型不用很大，也能把手机上的看图能力做得很顺畅。这两条路线展现的并非简单的替代关系，而是两种完全不同的端侧系统设计思路。 接下来真正需要横向对比的，绝不是宣传页上的 token/s 速度，而是在同一部 iPhone 上，面对同一组收据、表格、截图和屏幕交互等真实任务，同时测出冷启动耗时、无缓存图片 prefill 延时、首 token 响应时间、decode 速率、字段级 OCR 准确率、峰值内存、单 token 能耗以及连续跑 30 分钟后的发热衰减。只有完成这组实测，才有可能对“手机上的大模型有什么用”给出一个有据可依的答案：端侧模型究竟更适合当一个私密的本地 copilot、一双看懂屏幕的眼睛，还是一个能在拿到授权后可靠执行操作的 ambient agent。