Needle2

一句话定位

一个 14MB、45M 参数的 agent 模型，塞进 28MB 内存就能在手机、穿戴设备、 智能家居和机器人上做工具调用——把"听懂一句人话、调一个设备功能" 这件事从云端搬到了本地。

做这个东西的人

Cactus Compute（官网 cactuscompute.com，称 Cactus），做端侧 AI 的公司， 产品线三件套：Needle（极小型 agent 模型）、Engine（边缘推理运行时）、 Hybrid（边云协同后训练）。Needle 2 是开源模型。

它拿到了一个很有分量的背书：Pebble（智能手表厂商）创始人 Eric Migicovsky 的证词，称 Pebble 已把 Needle 用在 Index 01 应用里做本地语音指令处理。

判断：被 Pebble 采用是"端侧小模型"赛道最有含金量的信号——Pebble 的硬件 对功耗、内存、响应速度的约束比任何评测都要苛刻。但注意，模型是开源的、 公司层面的商业化靠 Engine/Hybrid，模型本身是获客入口。

它到底能做哪几件事

• 设备功能调用 → 把设备能力建模成带类型参数的函数，把自然语言句子映射到 正确的函数和参数（"打开灯"→ setLight(on=true)），45M 参数够用
• 结构化提取 → 把信息提取当工具调用：给定 schema 和文档，返回类型化字段； 语法编译器按 schema 生成语法规则，从结构上禁止产生非法 JSON
• 边云协同 → 每次响应带一个学出来的置信度分数：高于阈值本地执行， 低于阈值再问用户或升级云端；无关请求返回空调用而不是瞎猜
• 原生 2bit 训练 → CQ2-bit 量化贯穿预训练到后训练，部署的 2bit 模型 就是训练时的模型，绕开"小模型事后量化就崩"的老问题
• 确定性内存 → 256-token 滑动窗口锁死 KV 缓存，会话 RAM 恒为 28MB， 不随对话变长而增长；工具声明做成"永久 sink"不会被挤出窗口

技术底座：Simple Attention Network 架构（Hadamard MLP + engram 哈希记忆 + 多通道残差流，27 层 512 宽）；单次解码只读 14MB blob；语法感知解码跳过 最多 98% 的词汇投影计算；每 token 计算量比同尺寸模型少 7-85 倍。 预训练 115B token + 后训练 38B 推理轨迹数据。

它在替代什么旧行为

设备上做语音助手/意图识别，以前两条路都贵：

接云端大模型 API。延迟、隐私、断网即失效，而且对"开个灯"这种任务， 走一个千亿参数模型是荒谬的资源配置——但以前没有别的选择。

在设备上跑大模型。通用小模型（LFM2.5 230M、FunctionGemma 270M、 Apple FM 3B 这类）要么内存超预算、要么功耗撑不住、要么速度太慢。 Needle 用 45M 参数 + 14MB 打平甚至反超它们，把"设备上跑 agent 模型" 从不可能变成可能。

它替代的核心动作：把一个本来要花钱、要联网、要等几百毫秒的云端调用， 变成一个免费的、离线的、几十毫秒的本地函数调用。

商业模式

模型开源免费（"默认路径保持私有、快速、免费"）。公司层面靠 Engine（推理运行时）和 Hybrid（边云协同）商业化，具体定价未披露。

判断：这是典型的"开源模型获客、平台收费"打法——模型证明能力， 平台赚部署和协同的钱。风险是开源模型无壁垒，谁都能微调出类似的 14MB 模型， 获客价值的窗口有限。

硬数字

• HN 509 分 / 171 条评论（2026-08-12 Show HN），当日高热度
• 45M 参数 / 14MB 单文件 / 28MB 峰值会话 RAM（无依赖 C++ 二进制）
• 速度：树莓派 5 上 500 tok/s；VR 设备（Quest 3S、Vision Pro）400-1500 tok/s； 200 美元以下手机 300-700 tok/s
• 基准（端到端用发布二进制测）：Mobile Actions 63.7%（vs LFM2.5 230M 的 69.1%）； Seal-Tools 域外 28.7%（vs 17.0%，显著胜出）；Irrelevance 60.8%（大幅领先， 拒绝无关请求）；BFCL v4 42.6%（落后 Apple FM 61.7%，差距集中在 Java/JS 等 训练未覆盖语言）；格式正确率 93.4%
• 已被 Pebble Index 01 应用采用
• 每 token 计算量：35M matmul 活跃参数 / 70 MFLOPs（对比 LFM2.5 460、Apple FM ~6000）
• 目标硬件：从 Cortex-M 微控制器（ESP32-S3、STM32H7）到 x86 到 WebAssembly

四维评估

判断

这是"小模型 for 工具调用"赛道上目前技术叙事最完整的一篇，值得关注。 FunctionGemma、LFM2.5、Apple FM 同场竞技，Needle 用"原生 2bit 训练 + 特殊架构"把体积打到对手的 1/5 到 1/70，还能在 Mobile Actions、DroidCall 上打平、在 Seal-Tools 域外测试上反超——如果这些数字可信，它就是 "资源受限设备的 agent 能力"问题目前最好的答案。

三个诚实的保留： 一是基准全部自测。端到端用自家二进制、自家工具检索、自家提示词模板， 域外泛化的胜出尤其需要独立复现。 二是BFCL v4 整体落后。说明在复杂工具生态（Java/JS 等）上它还不完整， "agentic"的含金量要打个折。 三是开源无壁垒。45M 参数可微调，Pebble 采用是背书也是唯一公开案例， 能不能变成第二、第三家设备厂商的采用是关键。

给"值得关注"：509 分的 HN 热度 + 被 Pebble 采用 + 完整技术叙事， 数据不是编的；但模型层面的一切都还需要独立验证。

下一步看什么

① Pebble 之外有没有第二家设备厂商公开采用（硬件采用是这类模型最硬的证据） ② 有没有第三方在标准评估协议下复现它的基准数字 ③ 模型是否在 HuggingFace 可下载、社区能否微调复现——开源程度决定生态

可借鉴的做法

产品逻辑：当任务边界清晰（映射到有限函数集）时，别默认"越大越好"—— 先问"这个任务需要多少世界知识"。像 Needle 这样把"设备控制"从"通用对话" 里切出来单独做模型，是任务切分的范例。

定价结构：开源模型免费 + 平台（运行时/边云）收费，是端侧 AI 的 标准打法，可作参考但无独家信息。

结论

值得关注。 技术叙事完整、被真实硬件采用、讨论热度高—— "14MB 的 agent"这个数字本身就有传播力。但模型自测的基准、 唯一公开案例、开源无壁垒这三个点决定了它现在是"值得关注"而不是"强烈推荐"。 三个月后拿上面三条验证。