10 月 2 日，一位开发者在 Needle 的 GitHub 仓库提交了 166 号 issue。他用官方权重跑三条简单指令：打开台灯、关闭台灯、把台灯亮度调到 35%。只给模型 5 个或 6 个工具时，三条都选对；工具目录扩到 25 个，三条都选成了不相干的媒体播放工具；把这 25 个工具倒过来排，又有两条选对，剩下一条选成了待办清单里的删除操作。同一天他升级到 3.1.0 版引擎重跑，结果和置信分数都没有变。
这是一组只有三条指令的合成测试，不能代表 Needle 3 的整体准确率。它说明的是另一件事：这个端侧模型在固定的小目录里表现不错，工具一多，选哪个工具就成了最容易出错的一步。错的调用里，设备名都抄对了，模型写的推理文字也是在说开灯、关灯和调亮度，只有工具名选错了。
同一套权重，可以导出 2 到 20 层
Cactus Compute 在 9 月 18 日发布 Needle 3，主打工具调用、结构化抽取和文本嵌入，不做通用聊天。它最特别的设计是 Cactus 所说的“智能阶梯”：20 个网络块按固定规则排序，先选首尾两块，再反复在已选块之间最宽的空档中点补一块。这样 2 层子网包含在 3 层里，3 层包含在 4 层里，一直到 20 层，一套权重就能导出 19 个深度。
这些子网在训练阶段就一起练过。按 Cactus 的博客，训练中有 20% 的步骤只更新随机抽到的较浅深度，浅层子网还要用自蒸馏去贴近完整模型的输出。Cactus 做过一组 18 层、3000 步的对照：带阶梯训练的完整模型验证损失为 1.958，不带的为 2.037；训练后期才打开阶梯，各个深度都更差。
部署时，needle build --layers N 只保留目标深度需要的网络块、对应的 n-gram 记忆表和置信头参数，写成一个 .cact 文件，由一个不到 1 MB 的引擎加载。KV 缓存按块分配，层数越少，缓存也越小。
文件大小，几处官方数字对不上
发布页写的是“8–29 MB”，同一页后文又写成“9 到 29 MB”。Hugging Face 仓库里的完整 needle3.cact 是 35,335,380 字节，约 35.3 MB。9 月首批生产构建的提交记录里，同名文件的 LFS 大小是 46,393,604 字节。这几个数字可能来自不同版本或不同统计方法，但官方没有把宣传区间、下载文件和运行时内存逐项对上。给内存很小的设备做预算，应当按准备上线的那个版本，实测文件大小、引擎大小和峰值内存。
输出格式有保证，选对工具没有
Needle 3 的用法是：应用把工具名称、描述和参数结构交给模型，模型返回 JSON 调用；没有合适的工具时，返回空列表。解码时有一层字节级语法约束，保证输出一定能解析。它只管格式，不管模型有没有选对工具、参数有没有填对。
模型本身为这类窄任务做了压缩。按 .cact 格式说明，大部分矩阵用 Cactus 的 CQ2 量化存储，平均每个权重 2.125 bit，引擎直接读量化后的字节计算。
另一道防线是置信分数。引擎默认把置信度低于 0.1 的调用放进 suppressed_calls，不直接执行，由应用决定是让用户确认还是拒绝。166 号 issue 里按原顺序出错的三条调用，置信度在 0.11 到 0.18 之间，都高于这条线。官方文档还写明两点限制：置信头只针对基础模型校准，本地微调后的权重会把置信值报成空；非英语请求要谨慎看待这个分数，正确的西班牙语调用曾被打出 0 分。
“超过 DeepSeek”的前提条件
Cactus 说 Needle 3 在手机工具调用上胜过大 10 倍的模型，在抽取任务上追平大 2 到 3 倍的模型；4 层以上的子网在单一任务上微调后，能超过通过云端 API 调用的 DeepSeek V4 Flash。比较用的是 Mobile Actions、DroidCall、BFCL v4 三个工具调用测试集，以及 DSTC8、SNIPS 两个抽取测试集。
测试条件并不一致。Needle 3 跑的是发布的 2 bit 文件，其他开源基线在 vLLM 里以 f16 精度运行，DeepSeek 走云端 API。微调对比里，微调前后都是强制模型输出调用。DroidCall 测试集只有 200 条。
在 DroidCall 上，20 层基础模型得分 47.0，DeepSeek V4 Flash 为 60.5。2 层子网开着置信门控时几乎拒绝所有调用，得分是 0；强制输出调用时是 20.5，在 DroidCall 上微调后升到 56.5。这组数字说明，小子网经过窄任务微调能补回很多能力，但前提是任务和工具都固定。
Cactus 自己的微调指南也给出了大目录的办法：先用完整目录跑一轮，让模型选出工具；再只带这一个工具跑第二轮，让语法约束把输出锁定在这个调用上。这等于用多一次推理来弥补模型在大目录上的不足。
上线前要测的四件事
Needle 3 适合工具集合稳定、参数能直接从用户的话里找到、数据不该离开设备、或者没有网络的场景，比如智能家居控制、通知抽取和设备内搜索。权重用 Apache-2.0 许可，引擎覆盖多个平台，子网可以按设备预算导出，嵌进现有产品的门槛不高。
在固定版本上，团队至少要测四件事：
- 目标硬件上的文件大小、峰值内存和首个 token 延迟。
- 按真实工具数量、真实排列顺序测精确调用率，并逐步加入名字相近的工具。
- 换成产品实际使用的语言、换成微调后的权重，置信分数还能不能用来区分执行、确认和拒绝。
- 参数是否确实来自用户输入，选错工具时业务权限能否拦住。
166 号 issue 里的现象，到 3.1.0 版引擎仍能复现。目录从 6 个扩到 25 个就出错，几十上百个相近工具的情况还没有公开数据。
