14MB的AI 能调用工具，还能塞进手表

DeepSeek 涨价那天，微博上哀嚎一片。我正好在 GitHub Trending 上刷到一个刚冲上榜单的项目，14MB 就能跑一个会调用工具的 AI 小模型。这个对比太刺激了，当场就装了实测。

项目叫 Needle 2，作者是 Cactus Compute 团队。45M 参数，打包成一个 14MB 的单文件，28MB 内存能跑完整会话。

先看它到底多能装

我在这台 Ubuntu 上装的，4 核 CPU，没显卡。安装就一条命令，用虚拟环境装，干净不污染系统。

uv pip install cactus-needle

装完我盯着本地缓存看半天，那个推理引擎 libneedle.so 真就 14MB，整个目录加起来 14M。对比一下你电脑里随便一个聊天软件，光安装包都几百 MB。

跑起来的实测数字更离谱。让它调用一个查天气的工具，英文请求下模型正确生成了调用，返回了结构化结果。峰值内存几十 MB 到一百 MB 出头，CPU 上每秒生成一百来个 token。具体数字下面贴真实输出。

105MB 什么概念，你开一个浏览器标签页都远不止这个数。我在后台又开了内存监控，跑完内存几乎没波动，4G 的旧电脑都能轻松带。

下面是终端里真实跑出来的结果，一个英文请求让它查天气，模型自己生成了工具调用并返回结构化数据。

$ python demo.pyNeedle 2 (cactus-needle) 实测版本: 2.0.5[1] 英文单工具调用: 查天气>>> what's it like in Lagos right now?    type=respond    success=True    confidence=0.6334    peak_ram_mb=38.7    prefill_tps=262.0    decode_tps=85.9    function_calls=[]    results=[{'city': 'Lagos', 'temp_c': 27, 'sky': 'clear'}]    reasoning=user asked a question; respond with the current conditions.

注意那行 peak_ram_mb=38.7，一次调用峰值内存 38.7MB，CPU 上 decode 每秒 86 token。多跑几次会在几十 MB 到一百出头 MB 之间浮动，总体都在一个很小的量级。

最炸的点在官方直接给全平台预编译库

我去翻了它的 Hugging Face 权重仓库，那文件列表看得我直呼好家伙。官方把所有平台的预编译库都做好了直接放那儿。

安卓给了 arm64、armv7、riscv64 三个版本。苹果系更全，iOS、macOS、电视的 tvOS，连手表的 watchOS 都有。Linux 从 arm 到 mipsel 到 riscv64 全覆盖，Windows 给了 x86 和 arm，最后还压了个 wasm 版本，能在浏览器里直接跑。

意思是这东西真能塞进智能手表、路由器、智能门锁、扫地机器人里。编译好的二进制都给你备齐了，实打实能落地。

先泼盆冷水，中文是硬伤

评测必须诚实，我上来先把这个最要紧的说清楚。

这模型的英文能力不错，但中文能力几乎不可用，这是我实测反复确认的。

我声明了一个查天气的工具，用中文问它"北京今天天气怎么样"。结果它没认出来天气工具，reasoning 里还把中文文本给丢字了，"北京今天天气"在它那成了"北京今天气"。置信度只有 0.176。

再问"帮我查一下上海的天气"，更离谱，reasoning 直接复用了上一条的中文，完全没处理新请求。置信度掉到 0.015。

我换了个思路，工具描述用英文，请求还是中文。结果它把"北京天气怎么样"整句话当成城市名填进参数，根本没从里面把"北京"拎出来。置信度归零。

最严重的一次，我输入"广州现在天气如何"，模型直接生成了一段损坏的字节，程序当场报 UnicodeDecodeError 崩溃。

这个中文缺陷在 playground 里看得最清楚。我在智能家居场景下输入"北京今天天气怎么样"，结果模型把它当成了一条锁门指令，把整句中文填进了门锁参数。

它不但没听懂中文，还强行套用了手里的工具，连该拒绝都没拒绝。上面这行 door: "北京今天天气怎么样" 就是它给出的回答，置信度只有 0.0001。

结论很明确，这模型对中文基本不可用。 无论工具描述用中文还是英文，纯中文请求都处理不了。它认不出中文里的城市名，中文句子里的参数提不出来，多轮对话还会串场，严重时直接崩溃。

对国内读者来说，这一条就是决定性的。一个连中文都不支持的 AI 工具，折腾半天也跑不起来，你要用就得全程英文，还得把工具描述和请求都写成英文，这不现实。

英文场景下，它的能力边界

中文翻车，但英文场景我测了个遍，该夸的夸，该批的批。

单工具调用很稳。 查天气、设空调、排会议、调灯光，英文请求下模型都能正确识别工具、填对参数、返回结构化结果。

一次请求连续调两个工具也能干。 playground 里默认是智能家居场景，我输入"把卧室灯调到20%然后锁前门"，它一次返回了两条调用，一个是 set_lights 填了卧室、开、亮度20，一个是 lock_door 填了前门。置信度 0.97，生成速度 117 token 每秒。

结构化提取是英文强项。 我给了一段英文发票文本，让它提取供应商、金额、到期日，三个字段全对。这个能力对后端处理英文文档挺实用。

系统事实能解析相对时间。 我传了当前日期作为系统事实，然后问"明天上午7点开个会"，它正确解析成 8 月 18 日上午 7 点这个绝对时间。

离题请求会被拒绝。 我让它写一首秋天的诗，它没有可用的工具，返回了空调用，reasoning 还解释了原因。不会瞎编，这点做得规矩。

英文场景里也有的短板

多工具场景挑场景。 单一工具集很稳，但一旦工具性质差异大，它就抓瞎。我给它配了空调和转账两个工具，让它"调到21度制冷"，模型推理出来了参数，但置信度直接归零，拒绝执行。让它"给 @alice 转 50 美元"，它更离谱，开始念叨调温度的参数，把两个工具搞混了。这个安全机制倒是好，拿不准就拒绝，不瞎操作，但这路由能力确实弱。

算术工具认不出来。 我声明了一个 add_numbers 工具，问它"3加5等于几"，它 reasoning 直接写"没有可用的数学工具"。一个叫 add_numbers 的工具摆在它面前，它愣是没认出来。这种基础能力缺失，说明小模型对工具名的理解有限，你得把工具描述写得很直白它才接得住。

多工具混合 + 复杂约束是重灾区。 用装饰器加正则约束、枚举约束的时候，模型对复杂 schema 的处理明显退化。原生 JSON schema 声明、场景单一的工具集反而稳。这点写代码的人得注意，工具声明方式直接影响成功率。

这玩意到底适合谁

跑完整个评测，我的判断挺明确。

它做不了通用聊天，没有自由文本回复，一切问题都是函数调用，离题就直接拒绝。中文又不可用，这两个限制叠加，对国内普通读者来说基本劝退。

它的价值场景，一是纯英文环境下的智能家居和物联网本地指令处理，二是端侧英文结构化提取，三是需要离线、隐私敏感、不想把数据发到云端的场景。这些场景里它够快够小，单工具、场景清晰的英文调用完全够用。

对国内读者，除非你的工具和请求都能全英文，否则它多半折腾完就吃灰。想先试试的话，那个 playground 一条命令起服务，浏览器里点两下就能玩，内置了十几个官方测试场景。装个 Python 环境就能上手，不需要显卡。

几句实话

14MB 的 AI 能调用工具、能提取信息、能塞进手表和浏览器里，这个工程本身确实提气。它当然干不过几百 GB 的大模型，反手做一个极致的微型模型，方向有想法。

但评测归评测，我得把话说全。它英文场景是真有两下子，单工具调用和结构化提取都靠谱，速度内存都优秀。可对中文的支持几乎是零，加上多工具路由的短板，这两个硬伤叠在一起，决定了它现在更适合英文生态、物联网嵌入式那批开发者。国内读者想拿它当中文工具，路还长着。

本文为原创内容，首发于公众号「新一技术宅」，转载请注明出处。

项目地址：

• • Needle 2：https://github.com/cactus-compute/needle
• • 模型权重：https://huggingface.co/Cactus-Compute/needle2数据来源：Needle 2 实测（2026.08.17）