AI创业内参
Agent工坊

【Agent工坊】14MB跑Agent？Needle2微型模型让200元手机也能本地执行AI工具调用，Pebble已上车

AI创业内参

HN 297 points / 108 comments | 来源：cactuscompute.com | 2026年8月11日

"开灯不需要GPT-5。"

这是Cactus Compute团队发布Needle 2时的核心论点。这个仅45M参数、14MB二进制文件、28MB内存跑完整会话的agentic LLM，在HN上迅速冲到297分，引发108条深度讨论。它的目标极其聚焦：只做工具调用（tool calling）、设备操作（device use）和结构化提取（structured extraction）——不做聊天、不写文章、不答常识题。

但就是这个"只做一件事"的定位，让它能以FunctionGemma 270M模型六分之一的大小达到同等准确率，以Apple FM模型1%的计算量跑推理。Pebble创始人Eric Migicovsky已经在Index智能戒指中部署了它。

为什么微型Agent模型是刚需

先看一组关键数据：全球210亿台联网IoT设备，而PC只有约15亿台。在新兴市场，大多数手机售价低于200美元。把廉价手机、树莓派、微控制器、可穿戴设备、小型机器人、智能家居设备加起来——大约每5台边缘设备中有4台售价不到200美元。

这些设备才是真正的"边缘"。但目前的Edge AI话语权被MacBook和旗舰手机垄断——Llama 3.2的小模型需要1-3B参数才能在手机上勉强跑，放到200美元的三星A系列或ESP32上就是灾难。

更关键的是成本问题。如果你做一个智能戒指（比如Pebble Index），每次用户说"打开客厅灯"都要调用云端GPT API——延迟、网络依赖、隐私风险、API费用，每一项都在吃掉产品价值。而Needle 2的设计目标是一次部署到固件，终身免费推理，完全离线。

Cactus团队的核心洞察可以用一句话概括：工具调用不需要世界知识。开灯、关空调、打开窗帘——这些指令的语义空间极其有限。一个预定义的工具集合（函数名+参数类型）已经框定了所有可能的输出。因此问题简化为：把一句口语映射到正确的函数调用和参数值上。这个任务，45M参数绰绰有余。

架构深度拆解：Simple Attention Network

Needle 2不是简单地压缩了一个通用Transformer。它的Simple Attention Network架构从零开始为边缘推理设计，每一个组件都在回答"如何在14MB里塞进最多的工具调用能力"。

1. Hadamard MLP：用数学省参数

传统Transformer的MLP层有两个密集矩阵——up-projection和down-projection。在一个45M参数的小模型里，这两个矩阵会吃掉大部分参数预算。

Needle的解决方案是Walsh-Hadamard变换：一个固定的正交矩阵，可以在$n \log n$时间内完成变换，不占任何可学习权重。学习参数只保留在对角缩放和偏置中，参数量骤减。

# 伪代码：传统MLP vs Hadamard MLP
# 传统MLP (假设hidden=512, intermediate=2048)
up_proj = Linear(512, 2048)    # 1,048,576 参数
down_proj = Linear(2048, 512)  # 1,048,576 参数
# 合计: ~2M 参数

# Hadamard MLP
hadamard = fixed_walsh_hadamard(512)  # 0 可学习参数
diag_scale_up = Parameter(512)        # 512 参数
diag_scale_down = Parameter(512)      # 512 参数
# 合计: ~1K 参数

这个设计的代价是表达能力有所下降——但对工具调用任务来说，损失可接受。

2. Engram：把世界知识移到模型外面

Needle 2最大的创新是Engram机制。传统语言模型把"世界知识"编码在权重中——Paris是法国首都、冰箱有冷藏功能——但这些知识与工具调用无关。

Needle把外部知识从权重中移出，放入哈希n-gram表中。每次推理时根据输入token从表中检索几行，不参与矩阵乘法，消耗零算术运算。

Needle 2 参数分解：
- 35M 参数参与 matmul（attention + Hadamard MLP）
- 10M 参数存储在 Engram 表中（纯检索，零运算）
- 总计：45M 参数，14MB 存储

对比之下，FunctionGemma的270M参数中仅embedding table就占了170M——这些参数每次推理都要跑一遍矩阵乘法。

3. 多通道残差流 + Sinkhorn路由

27层、512宽的架构通过4个并行残差流实现灵活的路由能力。每条流有自己的attention和MLP，流之间通过Sinkhorn迭代计算双随机注意力矩阵进行混合。

这个设计让一个窄网络获得了接近宽网络的路由灵活性，成本仅为每层增加几个点积。配合RMS归一化和学到的门控机制，模型可以在不同流之间分配信息，相当于"软性的专家混合"。

4. CQ2-bit量化：训练即部署的哲学

这是整个架构最本质的工程决策，也是Needle 2能跑在微控制器上的关键。

传统模型量化流程：训f16 → 后训练量化(PTQ) → 部署。问题是，小模型做PTQ到2bit几乎必然崩溃——精度损失太大，模型变成随机数生成器。

Needle 2反其道而行：从预训练到后训练，全程使用Cactus Quants进行量化感知训练（QAT）。 权重、激活值、KV cache、路由表全部按2bit精度训练。部署的2bit模型就是训练的那个模型——零精度损失。

更进一步，2bit编码在向量寄存器内部展开为int8，融合为整数点积。权重从不展开到RAM中，常驻内存始终14MB。算术路径端到端int8，一块数据从flash读入寄存器，算完才替换，从未在DRAM中完整展开。

引擎启动时自动探测CPU指令集，自选最优内核：SDOT、NEON、AVX2、RISC-V向量、wasm SIMD或标量。线程池在token生成的短串行段之间自旋而非休眠，仅这项优化就接近翻倍了解码吞吐量。

5. 约束解码：语法即优化

因为工具调用的输出格式是一组预定义的函数签名，Needle不需要每次生成128K词汇表上的完整分布。它在生成每个token之前就知道哪些token是合法的——由此编译了一个字节级语法来约束解码。

效果：在结构性token上跳过高达98%的词汇投影计算；在已经被语法确定的token上，完全跳过整个logits计算。这不是"约束"——这是把约束变成计算优化。

引擎的每一层优化都遵循同一原则：要么精确，要么与参考路径逐token验证通过。 没有近似，没有采样偏差。

基准测试：45M凭什么打270M

Needle 2在5个公开benchmark上评测：Google Mobile Actions、DroidCall、Seal-Tools（域内+域外）、BFCL v4单轮。评分标准极其严格——严格精确匹配（ordered strict exact match）——函数名、调用顺序、每个参数值都必须一字不差。

Mobile Actions（961条）

模型 准确率 非空命中 单调用 双调用
LFM2.5 230M (f16, vLLM) 69.1% 93.0% 98.9% 76.1%
FunctionGemma 270M (f16, vLLM) 64.0% 87.3% 98.9% 73.0%
Needle 2 (CQ2-bit, 实体引擎) 63.7% 98.3% 99.4% 71.3%
Apple FM (on-device) 57.6% 94.2% 95.5% 64.5%

三个重要发现：

第一，非空命中率98.3%是全场最高——几乎每条指令都被映射到了至少一个工具，极少出现"不知道调用什么"的掉链子情况。这对产品体验至关重要：用户说"开灯"，系统至少尝试了，而不是沉默。

第二，63.7% vs 64.0%（FunctionGemma 270M）——准确率差距仅0.3个百分点，但模型大小差了6倍。这说明在工具调用这个窄域，参数效率远未被穷尽。

第三，Apple FM的on-device实测只有57.6%，提示苹果的端侧模型在工具调用场景可能有不少提升空间。

基准公平性说明

Cactus团队坦率地指出了两个不对称：

  • 精度不对称（对基线有利）：基线模型跑f16，Needle跑CQ2-bit。传统PTQ到2bit会崩溃，CQ2是训出来的。
  • 范围不对称（对Needle有利）：Needle只训工具调用，基线模型带聊天、常识、写作能力。

"没有干净的方式同时拉平两者，所以我们不尝试。"——这种坦诚在AI论文中很少见。

DroidCall（200条）

模型 准确率
FunctionGemma 270M (f16) 17.5%
Needle 2 (CQ2-bit) 17.0%
LFM2.5 230M (f16) 16.0%

DroidCall的绝对准确率都不高——说明Android设备控制确实很难——但Needle 2再次证明了45M=270M。

计算效率：真正的护城河

模型 参数总量 Matmul活跃 MFLOPs/Token
Needle 2 45M 35M 70
同参Transformer (dense) 43M 43M 87
同形Transformer (dense) 82M 82M 164
LFM2.5 230M 230M 230M 460
FunctionGemma 270M 270M 270M 540
Apple FM ~3B ~3B ~6,000

Needle 2每token的计算量只有LFM2.5的15%，Apple FM的1.2%。

Cactus团队在发布页上专门解释了为什么这很重要："在设备端硅片上，从flash或DRAM移动一个字节的能耗比一次乘加运算高几个数量级。真正的预算是每token的FLOPs和每token的字节数。Needle在这两项上都做到了极致——更少的参数参与算术，更少的字节从flash读取，从不重新水化权重到RAM。"

在高端手机上，一个始终在线的AI助手活在一个严格的功耗预算内。每MFLOP都是毫瓦时，Needle每token消耗的MFLOPs比竞品少7到85倍。

Pebble实战：智能戒指里的14MB引擎

Pebble创始人Eric Migicovsky的背书可能是这个发布页上最有分量的几行字：

"Pebble Index Ring没有屏幕。当你对它说话时，动作必须发生——每一次，无论有没有网络连接。我们在App中本地运行Cactus Needle，完全替代云端推理。这个模型的体积小到不可思议，性能从未让我们失望。"

这句话包含了三个产品级验证：
1. 离线可靠性：无网环境仍能工作，对可穿戴设备是刚需
2. 体积可接受：14MB对现代App来说微不足道
3. 性能稳定：不是"偶尔灵"，而是"从未失望"

Index Ring的使用场景：用户通过语音说"记下我今天的步数"、"开始跑步模式"、"给Eric发条消息说晚点到"——Needle在本地将语音转文字后的指令映射为App内的具体操作。全程离线，即时响应，零隐私泄露。

部署实战：从微控制器到浏览器

Needle 2的部署范围之广令人惊讶：

树莓派 / Linux 单板机

git clone https://github.com/cactuscompute/needle.git
cd needle
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j$(nproc)
# 推理
./needle_engine --model needle2.needle \
  --tools my_device_tools.json \
  --prompt "turn on the living room lights"

在Raspberry Pi 5上达到500+ tok/s解码，500+ tok/s预填充。

微控制器

// ESP32-P4 示例（需32MB PSRAM）
#include "needle_engine.h"

needle_ctx_t* ctx = needle_init("needle2.needle", NULL);
needle_bind_tools(ctx, my_tools_json);

const char* result = needle_call(ctx,
    "turn on the air conditioner to 24 degrees");

printf("Function: %s, Args: %s\n",
    needle_get_function(result),
    needle_get_arguments(result));

编译为Cortex-M4/M7/M55的裸机静态库。支持ESP32-P4（32MB PSRAM）、STM32H7、NXP i.MX RT（带外部SDRAM）。

WebAssembly（浏览器内推理）

在线Playground展示了完整功能——Needle 2在浏览器WebAssembly沙箱中运行，加载工具定义，执行真实的工具调用。如果你做的是Web端的低代码Agent平台，14MB的wasm引擎可以直接嵌入前端。

微调：在你的Mac上训你的工具

pip install needle-ml

# 准备你的工具定义
cat > my_device_tools.json << 'EOF'
[
  {"name": "set_thermostat", "params": {"temp": "int", "mode": "string"}},
  {"name": "toggle_light", "params": {"room": "string", "on": "bool"}},
  {"name": "start_robot_cleaner", "params": {"zone": "string"}}
]
EOF

# 生成训练数据 + 微调（几十分钟到几小时）
needle-finetune \
  --tools my_device_tools.json \
  --base needle2 \
  --output my-product-needle.needle \
  --synthetic-samples 5000

45M参数意味着不需要A100集群。Cactus团队说Python包可以在你自己的电脑上完成全流程，几十分钟到几小时。训练完得到一个专属的.needle文件，直接嵌入固件。

HN社区讨论：赞扬与质疑

297分、108条评论的讨论质量很高，有几个关键辩论值得整理：

置信度真的可靠吗？

有人输入"potato"测试，模型返回了{"function": "lock_door", "confidence": 0}。评论区立刻分成两派：

  • 批评派：即使置信度为0，依然输出了一个函数调用（lock_door），如果前端忽略了置信度就直接锁门了。
  • 辩护派：置信度为0本身就是信号——应该在应用层加阈值过滤，低于某个值就回退到"抱歉，我不理解"。

Cactus团队成员回应："这正是我们引入置信度功能的原因。模型知道自己错了。我们可以隐藏错误结果，返回占位符'抱歉，我只做函数调用'——你觉得哪种更好？"

这个问题触及了边缘AI的一个核心挑战：模型必须在"执行"和"拒绝"之间做出快速决策，而决策本身也是推理任务。Needle的选择是同时返回答案和置信度，把决策权交给上游——这比黑盒模型直接瞎猜要好，但也有工程负担。

"这就是规则引擎2.0？"

有人质疑：如果工具集是预定义的，这和传统的意图识别+规则匹配有什么区别？

支持者的反驳更有力：区别在于泛化能力。 传统规则引擎需要穷举所有指令变体。但用户说"太热了，降到24度"和"把空调调到24度制冷模式"——Needle能理解语义等价性，而不需要为每句话写if-else。这是模型的核心价值：对自然语言的鲁棒性，而非死背书。

硬件生态的壁垒

评论区有一个务实的声音：ESP32-S3虽然"技术上"够用，但大多数IoT厂商的固件栈并不支持在MCU上跑AI推理引擎。工具链集成、调试、OTA更新——这些工程成本可能比模型本身高得多。Needle提供裸机静态库是一个好的开始，但真正普及需要更多中间件生态。

微型Agent模型赛道全景

Needle 2不是孤例。2026年H1，我们已经看到了多条并行路线：

  • Needle 2 (Cactus Compute)：14MB, 45M参数，工具调用专用，Apache 2.0
  • Needle2（另一个项目，不要混淆）：Show HN上的另一个微型agent LLM，14MB针对手机/可穿戴/机器人
  • LFM2.5 230M (Liquid AI)：Liquid神经网络架构，也主打高效率
  • FunctionGemma 270M (Google)：Gemma家族的工具调用变体
  • Apple FM (Apple)：设备端多个变体，具体规格未公开
  • Ante (Antigma Labs)：128分HN，15MB Rust二进制，专注coding agent而非设备端

值得注意的是，这个赛道正在从"谁能做最大模型"转向"谁能做够用且够小的模型"。对于80%的IoT场景（指令控制、状态查询），14MB已经够用了。

对AI创业者的实操建议

1. 评估你的产品是否适合微型Agent

如果你的产品满足以下条件，微型agent模型可能是比云端API更好的选择：
- 工具集<100个函数
- 指令空间可枚举（开灯/关灯/调温度/设置模式...）
- 有离线/隐私/延迟要求
- 硬件有≥32MB RAM

2. 工具定义的质量决定一切

Cactus团队在发布页反复强调："准确的描述 + 窄工具范围 = 成功"。你的工具描述写得好不好，直接决定45M参数能不能完成任务。

// ❌ 糟糕的工具描述
{"name": "set_ac", "params": {"v": "int"}, "desc": "ac control"}

// ✅ 好的工具描述
{
  "name": "set_air_conditioner",
  "desc": "设置空调温度和工作模式。用户说"太热了"或"冷"时应调用此函数。",
  "params": {
    "temperature": {"type": "int", "desc": "目标温度（摄氏度），范围16-30"},
    "mode": {"type": "string", "desc": "工作模式：cool制冷、heat制热、fan送风、auto自动"}
  }
}

3. 分层架构是务实方案

不要试图让14MB模型做所有事。一个更合理的架构：

用户语音 → 本地Needle2（工具调用）
                ↓ 置信度<阈值
          降级到云端大模型（复杂指令）
                ↓
        返回结构化操作→执行

Needle处理90%的日常指令（"打开客厅灯"），云端处理10%的边缘情况（"帮我设置一个节能的温控计划，白天26度晚上24度，周末下午用送风模式"）。这是成本最优的混合方案。

4. 当前已知限制

  • 不支持长上下文：256 token的滑动KV窗口意味着复杂多轮对话会丢失历史
  • 没有多模态：只处理文本，不能看图片或听原始音频
  • 语言覆盖未知：训练语料偏英语，中文工具调用的效果需要实测
  • 微调管线不成熟：虽然提供了Python包，但生成高质量合成训练数据仍需要工程投入

同类微型Agent模型速览

除了Needle 2，2026年8月还有几个值得关注的微型工具调用模型：

  • Needle2（注意拼写）：Show HN上前几天的一个独立项目，同样是14MB级别，主打手机/可穿戴/智能家居，但与Cactus Compute的Needle 2是不同团队的产品，不要混淆。
  • Mcptoon：29分HN项目，主打token高效的MCP CLI客户端，不完全是模型，但在微型Agent工具链生态中填补了重要一环。
  • Ante：128分HN项目，15MB Rust二进制，聚焦离线coding agent，和多提供商支持。虽然定位不同（编程而非设备控制），但同样验证了"单二进制、零依赖、本地运行"的Agent范式的可行性。

这几个项目共同指向一个趋势：Agent运行时正在从"需要Python环境+多个依赖+API密钥"的庞然大物，瘦身到"一个二进制文件拖进去就能跑"的轻量形态。 这对于做嵌入式产品的团队来说，是巨大的工程简化。

总结

Needle 2不是在证明微型模型比大模型强——它不是。它证明的是AI Agent的部署边界正在被重新定义。

过去，设备端AI要么是关键词识别（"Hey Siri"唤醒来调用云端），要么是旗舰手机上的大模型（仍需联网）。Needle 2展示了一条第三条路：一个极致聚焦的45M参数模型，以14MB的体积，在200美元手机上稳定运行，在Pebble戒指上出货。

对AI创业者来说，这是一个信号：工具调用的AI化正在从"云端大模型专属"变成"所有设备标配"。当14MB的AI引擎能嵌入硬件固件，一次部署终身免费，你就再也不用为每个用户的每次"开灯"付API费用。

工具本身Apache 2.0开源，在线Playground可玩。值得花一个下午试试。

数据来源：Cactus Compute Needle 2发布页 (cactuscompute.com/needle)、HN讨论帖 (item?id=49246804, 297 points, 108 comments)、Pebble Index Ring公开信息