Mano-P是我们做的一个开源项目，让一个4B参数的视觉语言模型跑在MacBook上，通过看屏幕截图来操作电脑。点击、输入、快捷键，模型看完截图决定下一步做什么，整个过程数据不出本机，不调云端API。之前发过1.0版本，最近迭代到2.0，在100个真实macOS GUI任务上重新跑了一轮。结果出来之后，有些事情跟我们预想的很不一样。

最后定在4B，主要还是16GB MacBook的内存限制。之前也试过通用VL模型，在我们的测试集上通过率只有39%，中文输入焦点处理不好，非浏览器应用适配差，步数限制经常截断长任务。通用VL能力和GUI Agent能力确实是两回事。后来内部也讨论过MoE，但端侧推理的瓶颈更多在内存，MoE所有专家的权重都得常驻内存，在Mac上反而不占优。最后留在MLX框架上，它对Apple芯片的统一内存利用比较直接。

这些都是背景。真正让我们意外的事情发生在2.0。

中文GUI的提升出乎意料

我们一直以为4B模型做不好GUI Agent，瓶颈是模型太小。2.0做完之后发现不是这么回事。第一个真正卡住我们的东西，是中文GUI训练数据。

1.0版本在中文UI元素上的表现比较差。模型对中文汉字的识别经常出现字符级错误，把某个字认成视觉相似的另一个字。这种错误看起来不大，但对GUI Agent是致命的，按钮在哪都找不到，后面什么都别谈。

英文界面上这个问题不明显。"Settings"和"Settinas"差别大，模型不容易混淆。中文不一样，汉字之间视觉相似度高，"确定"和"取消"这种短按钮笔画密度大，给模型的特征更密集也更难分辨。我们当时以为这是4B模型能力不够，中文汉字就是比英文字母难认，小模型搞不定。

2.0加了中文GUI的训练数据之后，发现不是这么回事。方法不复杂，就是把中文界面截图的量提上来。效果直接反映在企业IM类别上，1.0是33%，2.0跳到83%。微信也从33%涨到67%。

涨了50个百分点。现在回头看，1.0的数据覆盖确实不够。这个问题靠加数据就解了，没改架构没加大模型。当时我们其实以为要换更大的模型才能解决，后来发现根本不是。到现在也觉得挺讽刺的，花了那么多时间纠结模型选型，结果瓶颈在数据上。

浏览器退步这件事

2.0在浏览器和网页任务上从74%掉到68%。这个结果出来的时候团队内部有争论，是不是中文数据加过头了。

看细项的话，下降主要集中在英文网页的元素识别。中文网页变化不大。训练数据配比调整之后中文数据多了，英文数据相对少了，模型对英文UI元素的敏感度降了一点。

样本不算多，我们暂时不认为这是能力退化。但它暴露了一个一直没解决好的问题，中英文GUI数据的平衡。4B模型的容量有限，塞太多东西进去会互相干扰。目前的做法是总量控制，中文多了英文就少了，理想状态是两边都够，但这个模型尺寸下还做不到。

短期内打算在采样策略上做更细粒度的控制，按任务类型和UI复杂度来配比。能不能解决，没把握。这个问题可能要到更大模型上才有空间。

长链路和跨应用仍然是短板

1.0和2.0在长链路任务上都是30%，十步以上的任务2.0没有改善。跨应用从0涨到20%，5个任务过了1个。

从目前测试来看，更像是4B容量带来的限制。十步以上的任务需要全程维持上下文，每一步的结果要正确反馈到下一步。4B模型的工作记忆就那么大，前几步做了什么，做到第十步已经记不太清了。目前我们还没找到只靠数据继续提升的方法。

跨应用更麻烦。在微信里找到某个人发的文件，切到Finder保存到桌面。切一次窗口，4B模型就容易把之前的上下文丢掉。我们预计更大的模型会缓解这个问题，但还没验证。

内部在评估两条路。一条是继续在4B上加推理链路的训练数据看能拉多少。另一条是做大一点的模型，在M5 Pro 64GB的机器上跑。还没定。说实话到现在也没完全想明白哪条路更值得投入。

Cider解决的是体感问题

前面说的都是模型能力。Cider解决的是另一件事，用户等不了。

GUI Agent有一个很特殊的性能特征，每完成一步操作都要重新截屏，一整张图的token送进模型处理。这个prefill阶段的速度直接决定用户等多久。我们在M5 Pro上实测，MLX原生的W8A16模式prefill要2.839秒。

2.8秒听起来不长。但连续执行十步任务，每步等将近3秒，加起来半分钟。用户会觉得这东西反应迟钝。decode速度不是问题，80 tokens/s生成动作指令够用。

问题出在MLX没有在线量化激活值的算子。权重是静态的，可以提前离线量化存好。但激活值是动态的，每张截图过网络时产生的中间数值都不一样，MLX没提供这个能力。所以我们决定自己写。

实现上最纠结的是量化粒度选多大。粒度太粗，个别异常值会拉低整体精度。粒度太细，计算开销上去。最后选了per-token粒度，每个token的激活向量独立算量化参数。开销比粗粒度大，但精度损失可控。

效果：W8A8 prefill从2.839秒降到2.519秒，快了12.7%。峰值内存也有下降，对GUI Agent这种需要和其他应用共存内存的场景有帮助，具体省了多少我们还没精确测。

M5上有硬件加速所以效果明显，M4走纯Python回退，加速有限。评估过在M4上专门做优化，判断投入产出比不高。Cider不只给Mano-P用，任何MLX模型都能接。

接下来打算怎么办

模糊描述和跨应用是目前最明显的短板，都指向4B模型的推理能力。接下来大概率做更大参数量的版本。Cider继续做稳定性和兼容性。

分类数据附在最后，测试硬件MacBook Pro M5 16GB，云端模型Claude Sonnet 4.5，本地模型Mano-CUA-4B W8A16。

类别	任务数	1.0	2.0	云端
浏览器/网页	31	74%	68%	90%
企业IM	6	33%	83%	100%
微信	6	33%	67%	83%
WPS/Office	5	0%	40%	100%
系统设置	6	50%	83%	50%
备忘录/提醒	4	50%	50%	100%
文件管理	7	43%	43%	71%
系统工具	3	100%	100%	100%
长链路	10	30%	30%	80%
跨应用	5	0%	20%	60%
模糊描述	10	30%	30%	80%
无打开提示	5	20%	60%	80%

测试硬件：MacBook Pro M5 16GB。云端模型：Claude Sonnet 4.5。本地模型：Mano-CUA-4B（W8A16，MLX）。

GitHub: https://github.com/Mininglamp-AI/Mano-P

模型下载: https://huggingface.co/Mininglamp-2718/Mano-CUA-2.0-4B

Cider: https://github.com/Mininglamp-AI/Cider