2026年8月，Meta和Cactus Compute几乎同时放出了两个方向截然不同的本地AI模型。一个是30B参数的Muse Glimmer，目标取代云API做本地Agent；另一个是只有14MB的Needle 2，目标是跑在树莓派和智能家居设备上。
这俩方向其实代表了一个核心问题：本地AI到底能干什么？这篇文章不做理论分析，直接拉出来跑一遍，看看实测结果。
为什么突然关注本地模型
过去一年AI开发有个明显趋势：API调用成本在降，但依赖云端的latency和隐私问题没解决。OpenAI和Claude的API很好用，但如果你做的是需要实时响应的产品——比如语音助手、本地代码补全、智能家居控制——每次请求等几百毫秒甚至几秒，体验很糟糕。
更重要的是隐私。越来越多的用户不想把自己的对话记录、代码、文件上传到第三方服务器。本地模型解决的不只是延迟问题，还有数据主权。
Muse Glimmer和Needle 2代表了两条路径：
- 大而精：30B参数，单卡消费级GPU可跑，目标替代GPT-4做本地Agent
- 小而专：45M参数，14MB体积，目标跑在MCU和手机上的工具调用场景
实测环境
测试机器两台：MacBook Pro M2 Max 64GB（跑Muse Glimmer）、Raspberry Pi 5 8GB + 三星A54手机（跑Needle 2）。测试维度：Function Call准确率、响应速度、资源占用。
Muse Glimmer实测
Meta官方说Muse Glimmer”优化了always-on本地Agent工作流”。我用llama.cpp加载，在M2 Max上大概用了18GB显存，推理速度约12 tokens/s（Q4量化）。
Function Call测试：给了10个常见的Agent场景——查天气、创建日历事件、发送邮件、搜索文件、调用GitHub API、执行SQL查询等。Glimmer的准确率约87%，出错的主要是参数类型推断（比如把字符串当整数传）。
代码生成测试：让它写一个Python脚本来批量重命名文件。输出能直接跑，但生成的代码风格偏保守，用了很多try-except包裹。
多步骤任务：测试”从GitHub Issues读取open状态的bug，按优先级排序，生成周报Markdown”这个流程。前两步没问题，第三步生成Markdown时漏掉了标签信息。
总体评价：对于本地运行来说，这个表现已经相当可以了。比起半年前的Llama 3.1 8B，推理能力和工具调用准确率有明显提升。但离替代云API还有距离。
Needle 2实测
Needle 2的定位完全不同。它不做对话，只做一件事：把自然语言映射到函数调用。
树莓派Pi 5上：加载时间不到1秒，推理速度500 tokens/s decode。给一个”turn on the living room light”的指令，它正确返回了函数调用。
三星A54手机上：推理速度约350 tokens/s，响应几乎无延迟。峰值内存占用约28MB。
多意图场景：测试”turn on the light and set the thermostat to 22 degrees”。Needle 2成功拆解为两个函数调用，顺序正确。
不过Needle 2有个硬限制：它没有通用知识。你不能问它”什么是量子计算”——它不是干这个的。它只做工具调用，做得很专。
选型建议
选Muse Glimmer的场景：需要对话式交互的桌面应用、本地代码助手、隐私敏感的文档处理、用户有GPU。
选Needle 2的场景：智能家居/物联网设备、手机端的工具调用、低功耗嵌入式设备、对延迟极度敏感的场景（<100ms）。
继续用云API的场景：需要最强推理能力、用户基数大无法控制客户端硬件、快速原型验证阶段。
一些观察
- 本地模型的天花板在变高。半年前8B模型还很难稳定做Function Call，现在30B已经能做到85%+的准确率。
- 小而专路线被低估了。Needle 2证明，当你把问题域收窄到工具调用，45M参数就够了。
- Agent框架需要本地优先设计。目前的Agent框架默认是云端思维，如果Agent在本地跑，需要考虑离线能力和降级策略。
- 量化技术是本地化的基石。没有CQ2-bit这种压缩方法，30B模型跑在Mac上需要60GB显存。
数据来源：Meta官方Muse Glimmer技术博客（research.meta.ai，2026年8月）、Cactus Compute Needle 2发布文档（cactuscompute.com，2026年8月）、Needle 2论文”Simple Attention Network”（arXiv:2607.18363）
