Cactus Compute 这次开源的 Needle，参数量只有 2600 万。

这个数字放在今天的模型语境里很小。官方给它的定位也很窄：不是陪你聊天，不是做长推理，而是做单轮函数调用。

有意思的地方正在这里。端侧个人 AI 真正卡住的，很多时候不是“能不能写一段漂亮回答”，而是它能不能在本地快速判断：该调用哪个工具，该传哪些参数，能不能少耗电、少占内存、少等几秒。

所以 Needle 这件事不能按“又一个小模型挑战大模型”来读。它更像把个人 AI 的执行入口，单独切出来做小。

Needle 到底发布了什么

Needle 是一个 26M 参数的函数调用模型。项目 README 称，它由 Gemini 3.1 蒸馏而来，采用 Simple Attention Network 架构。

官方已经开放了两部分东西：模型权重放在 Hugging Face，数据生成流程放在 GitHub。这一点对开发者比较重要，因为它不只是给一个结果，也给了复现和改数据的入口。

训练信息也比较清楚。官方称，Needle 先用 200B tokens 做预训练，再用 2B tokens 的单轮函数调用数据做后训练。公开信息里还提到，预训练使用 16 块 TPU v6e，耗时 27 小时；后训练耗时 45 分钟。

官方给出的 Cactus 运行速度是：6000 tokens/sec prefill，1200 decode speed。这个数字可以当成官方栈里的性能锚点，但不能直接理解成所有手机、手表、眼镜上都能跑到这个水平。

项目Needle 的公开信息该怎么理解
模型规模26M 参数目标是压进更小端侧预算
模型架构Simple Attention Network不是常见大通用模型路线的简单缩小版
训练方式200B tokens 预训练 + 2B tokens 单轮函数调用后训练重点学习工具格式和参数生成
开放内容Hugging Face 权重、GitHub 数据生成流程方便复现、替换工具数据、再微调
官方速度Cactus 上 6000 tokens/sec prefill、1200 decode speed只能先看作官方环境数据
能力边界单轮函数调用不是完整对话助手

一个典型用法很简单。用户说“查一下旧金山天气”，模型输出要调用 get_weather，并填入 location: San Francisco。

这件事看起来小，但它是个人 AI 从“会说”走向“会做”的入口。入口能不能小到本地跑，决定了很多产品体验。

小模型函数调用，赢的是成本，不是全能

函数调用已经是 AI 应用的底层能力。模型不只回答问题，还要连接日历、地图、邮件、智能家居、企业系统。

问题是，大模型上端侧并不轻松。内存、延迟、功耗、发热，都会从技术指标变成产品问题。手机还能扛一部分，可穿戴设备更紧。

Needle 的取舍很明确：不争全能，只争一小段链路。它要解决的是“自然语言到工具调用”的转换，而不是知识问答、复杂推理、多轮对话。

官方称，Needle 在个人 AI 的单轮函数调用测试中，超过 FunctionGemma-270m、Qwen-0.6B、Granite-350m、LFM2.5-350m。这个结论要收着看。

因为这些模型并不是只为单轮工具调用而生。它们参数更大，能力范围也更宽。在对话、泛化任务和复杂指令上，Needle 不能被顺手写成替代品。

更合适的对比是路线选择：

路线适合做什么主要代价
Needle 这类小型工具调用模型本地快速选择工具、生成参数能力窄，对 schema 敏感
Qwen、Gemma 等更大通用模型对话、问答、复杂指令、部分工具调用端侧成本更高，部署压力更大
云端大模型复杂任务、跨工具编排、多轮纠错网络依赖、延迟、隐私和成本问题

对端侧 AI 团队来说，比较现实的动作不是“迁移到 Needle”。更可能是把它放进评估队列：拿自家的工具 schema 跑一遍，看它能不能承担轻量路由。

如果能跑稳，团队可以把简单工具调用留在本地，把复杂问答交给更大的本地模型或云端模型。这样省下的是延迟、功耗和云端调用成本。

如果跑不稳，就不该急着替换现有方案。小模型失误一次，可能不是“回答不好看”，而是闹钟设错、设备控制错、权限动作走偏。个人 AI 的工具调用，对稳定性比对文采更敏感。

最该看的不是榜单，是 schema、微调和真机

Needle 最适合的读者，是端侧 AI 开发者和做个人助理硬件的产品团队。尤其是手机 App、手表、眼镜、低功耗设备这类场景。

他们可以先做三件事。

第一，拿自己的工具 schema 测。不要只看官方 benchmark。工具命名、参数层级、必填字段、枚举值，都会影响小模型表现。

第二，评估是否需要微调。项目方也提醒，small models can be finicky。小模型容易“挑格式”，换一套工具定义就可能掉点。

第三，测真机。官方 Cactus 速度说明了一个方向，但不同芯片、内存带宽、运行时优化和电池策略，都会改变最终体验。端侧 AI 不是只看 tokens/sec，还要看持续运行时的功耗和发热。

目前最看不清的，也正是这些工程变量。

Needle 的开放性让它适合做实验和原型。团队可以改数据生成流程，可以按自己的工具集做后训练，也可以把它嵌进现有 agent 架构里做路由器。

但它离稳定产品还有距离。单轮函数调用表现好，不等于多轮澄清可靠；能生成参数，不等于能处理权限确认；能选对工具，不等于失败后会恢复。

这才是 Needle 的真实位置：小而专，适合试，不适合神化。

回到开头那个问题，2600 万参数到底小出了什么价值？答案不是“小模型也会聊天”，而是工具调用这件事开始被拆成更细、更便宜的部件。端侧个人 AI 要落地，靠的往往不是一招通吃，而是各司其职。