Needle2：面向移动与物联网设备的14MB智能体大模型
- 4500万参数
- Pi5预填充速度：800+词元/秒
- Pi5解码速度：500+词元/秒
- CQ2位压缩
- 文件大小：14 MB
- 会话内存占用：28 MB
尺寸-性能前沿：移动端及更低配置设备
图1. 针对智能设备、移动端及更低配置场景设计的小模型，在Mobile-Actions数据集（google/mobile-actions测试集，共961条数据）上的严格精确匹配准确率与总参数量对比。Needle 2的测试基于CQ2位部署精度的成品二进制文件，全程开启工具检索；基线模型采用vLLM运行公开权重，Apple FM为设备端运行。
核心定位
让设备端AI走进200美元以下硬件： 如今提到边缘AI，人们想到的多是Mac和PC，但真正的"边缘"其实是海量低成本硬件：全球IoT设备已超210亿台，而PC仅约15亿台。新兴市场多数手机售价不足200美元，算上平价手机、树莓派、微控制器、智能穿戴设备、Reachy Mini这类小型机器人，以及智能家居设备，约八成边缘设备的成本都在200美元以下。这正是Needle瞄准的硬件场景：无需GPU或NPU，仅需数十MB内存即可运行。
聚焦功能调用与设备操作： 开灯这类简单操作根本不需要大模型。智能手表、智能家居助手、机器人早已将自身能力封装为带类型参数的函数，真正的难点在于将用户的自然语言指令映射到对应的函数——即确定调用哪个函数、传入哪些参数。从这个角度看，任务无需通用知识储备，也不要求生成开放式文本，因此4500万参数便足够支撑，而通用聊天模型通常需要数十亿参数。正是基于这一轻量化定位，Needle的所有设计逻辑才得以展开。
抽取任务与结构化输出： Needle将信息抽取视为工具调用的另一种形式。给定schema和文档，它会返回带类型的输出字段：用枚举值做分类，用数组存列表，用对象表示结构化记录。我们从schema编译生成语法规则，可避免生成格式错误的JSON或无效结构。如此一来，模型的4500万参数可集中用于筛选正确值，并与用户表述精准对齐。
边缘-云端协同： 小模型不可能做到尽善尽美，Needle会如实告知而非盲目猜测。遇到无关请求时，它会返回空调用，且每条响应都附带一个经过训练的置信度得分。用户可自行设置置信度阈值：高于阈值则本地执行，等于阈值可请求用户澄清，低于阈值则转由云端处理。多数设备操作请求可在本地完成，因此极少需要云端介入，默认路径始终保持隐私、快速且免费。
无损2位量化： 小模型在事后量化时性能会严重下降，因此Needle绝不采用事后量化方案：从预训练到后训练，Needle 2全程基于Cactus Quants进行训练，覆盖权重、激活值和KV缓存。部署的2位模型就是经过完整训练的模型，这也是它能将4500万参数压缩至14MB，同时在基准测试中性能无损的原因。
模型与推理引擎协同设计： 每一个架构组件都先在目标硬件上完成基准测试，才会被赋予参数。因此我们不单独提供模型权重，而是打包为一个无需依赖的C++二进制文件。文件启动时会自动检测CPU并选择适配的计算核心，同时内置模型、分词器和语法编译器。这一个文件即可在Cortex-M、x86、WebAssembly等多种平台运行，无需额外安装或下载任何内容。
在个人电脑上轻松微调： 每个产品都有专属的工具指令体系，而4500万参数的模型足够轻量化，可直接在运行设备上重新训练：通过代码库和Python包，只需几分钟到几小时就能在本地完成微调与测试，打造适配自家设备工具集的专属Needle，而非通用助手。
落地案例
对于需要极低内存占用、低延迟、隐私保护和离线可靠性的产品，Needle已具备生产就绪能力。现代可穿戴设备行业的先驱Pebble，已在Index 01应用中本地部署Needle，将语音请求转化为操作指令，完全无需依赖网络。
Pebble Index智能戒指没有屏幕，因此用户语音指令发出后，无论是否联网，都必须确保指令精准执行。我们选择在应用中本地运行Cactus Needle，而非依赖云端。模型占用极小，性能表现始终稳定可靠。
技术架构
简易注意力网络
图2. 简易注意力网络，每个模块标注了更新规则。其中x̂是四个残差流经RMS归一化后的扁平化结果；H是正交沃尔什-阿达玛变换——一个固定矩阵，可通过n log n时间复杂度计算，无需读取权重；(kᵢ, vᵢ)是从哈希n元语法表中提取的行；P是通过Sinkhorn迭代计算得到的路由对数A的双随机归一化结果；a、b、g及所有σ门均为可学习参数，且依赖输入数据。注意力和MLP残差均采用"三明治式归一化"并添加门控，记忆位点在两层激活，解码过程受从声明schema编译而来的字节级语法约束。
Needle 2在一个包含1150亿词元的专有语料库上完成预训练，随后在包含380亿词元的语料库上进行后训练，后者包含紧凑推理轨迹，且经过精心的数据集分布设计。对比规模来看：LFM2.5-230M的预训练语料达19万亿词元，约为Needle总训练语料的120倍，下文的评估将展示二者各有优劣。每个组件的设计都旨在不增加带宽开销的前提下提升模型能力：
- Hadamard MLP用固定沃尔什变换和可学习对角矩阵替代传统的稠密上下投影，使占据小模型权重读取主要开销的通道混合操作，几乎不消耗额外参数。
- 记忆单元将通用知识从模型栈转移到哈希n元语法表中，每个词元仅需读取几行数据：这种方式在解码时几乎不产生额外开销，对闪存读取每MB都关乎延迟和功耗的设备而言至关重要。
- 多通道残差流让27层、512宽度的网络拥有远超同规模模型的路由灵活性，仅需每层增加少量点积运算，无需扩大注意力或MLP模块规模。
内存系统专为固定内存设备逆向设计：注意力采用256词元滑动窗口，确保无论会话时长如何，KV缓存占用始终可控；系统提示词和工具声明被固定为永久缓存，从结构上保证工具调用模型绝对不会遗忘核心的工具信息。缓存本身采用量化感知训练（QAT），权重以平均2位的混合精度存储为Cactus Quants。这使得模型性能决策与部署决策相互独立：一个训练好的模型，可根据目标设备的能力适配不同精度和窗口大小。
推理引擎的速度优势源于它"有所不为"：权重无需解压到内存，2位编码直接在向量寄存器中展开，并融合为整数点积运算，常驻内存大小始终等于模型文件大小，且运算全程采用int8精度——覆盖激活值、KV缓存和通道路由表。语法规则不仅是输出格式的保障，更是一种优化手段：匹配器在生成对数前就知道哪些词元合法，因此引擎仅需计算候选词元的输出得分，结构化词元的词汇投影运算可最多跳过98%，输出已被强制约束的步骤则可完全跳过运算。通用二进制文件启动时会自动检测CPU，并选择适配的计算核心层级——SDOT、NEON、AVX2、RISC-V向量、wasm SIMD或标量；线程池会在词元处理的短串行阶段持续运转而非休眠，仅此一项就使解码速度提升近一倍。所有优化都不会改变输出结果：每一项技术要么是精确运算，要么已逐词元验证与参考路径结果一致。
所有设计最终都指向能耗优化。在设备芯片上，从闪存或DRAM读取一个字节的能耗，比一次乘累加运算高几个数量级，因此真正关键的预算是每词元的浮点运算数（FLOPs）和每词元的字节读取量。架构设计降低了前者：与Needle同宽度和深度的传统Transformer，每词元需1.64亿次浮点运算；即使压缩到与Needle参数量相当，仍需8700万次，因为模型的每个参数都要参与矩阵乘法。而Needle仅需7000万次，且五分之一的参数以读取内存的方式调用，不产生运算开销。二进制文件优化了后者：如推理引擎部分所述，无任何数据需重新加载，运算全程保持int8精度，语法规则直接削减运算量，因此解码一个词元最多仅需读取一次14MB的模型文件，结构化词元的读取量则更少。这正是续航能力的来源：即使是高端手机，始终唤醒的助手也受限于功耗预算；每百万次浮点运算对应毫瓦时的能耗，Needle每词元的能耗仅为对比模型的1/7至1/85。
每词元运算量
| 模型 | 参数总量 | 参与矩阵运算的参数 | 每词元浮点运算数（百万次） |
|---|---|---|---|
| Needle 2 | 4500万 | 3500万 | 70 |
| 同结构Transformer（稠密MLP） | 8200万 | 8200万 | 164 |
| 参数量相当的Transformer | 4300万 | 4300万 | 87 |
| LFM2.5 230M | 2.3亿 | 2.3亿 | 460 |
| FunctionGemma 270M | 2.7亿 | 2.7亿 | 540 |
| Apple FM | 约30亿 | 约30亿 | 约6000 |
固定的会话内存占用让微控制器也能运行Needle。由于滑动窗口限制了状态大小，Needle 2的内存占用最高为确定的28MB，不会随对话时长增加而增长。这足以适配带外部内存的MCU级芯片，如配备32MB PSRAM的ESP32-P4，或搭载SDRAM的STM32H7和NXP i.MX RT开发板。引擎可编译为单线程裸机版本，并以静态库形式支持Cortex-M4、M7和M55架构。
性能评估
我们在五个公开的工具调用基准测试集上进行评估：Google Mobile Actions、DroidCall、Seal-Tools域内和域外测试集，以及BFCL v4单轮对话测试集。评分采用严格精确匹配规则：只有当函数名、调用顺序和所有参数值完全匹配时，才算测试通过。所有Needle 2的测试数据均基于生产配置的C++引擎全程实测：采用CQ2位权重、开启工具检索、使用256词元滑动KV窗口。测试未做任何宽松处理，数据完全反映设备实际运行的引擎性能，包括窗口淘汰机制。基线模型采用vLLM运行公开权重并使用完整上下文，Apple FM为设备端运行。
本次对比存在两个不对称因素，我们在此提前说明：精度方面，基线模型刻意保持f16精度，因为传统的事后2位量化会让未针对极端压缩训练的模型性能崩溃，而Cactus Quants是从一开始就融入Needle训练流程的技术，这一差异对基线模型更有利；适用范围方面，Needle仅针对智能体工具调用任务训练，而所有基线模型都是通用语言模型，除工具调用外还具备聊天、文本生成和通用知识能力，这一差异对Needle更有利。目前无法同时消除两个差异，因此我们不做强行平衡。测试表格仅回答一个明确问题：在设备端资源预算内，哪个模型能更准确地执行工具调用。我们接受这些差异，它们仍能清晰呈现我们想要展示的结论。
Mobile Actions（961条数据）
| 模型 | 准确率 | 函数名准确率 | 非空调用占比 | 单函数调用准确率 | 双函数调用准确率 |
|---|---|---|---|---|---|
| LFM2.5 230M（f16，vLLM） | 69.1% | 93.0% | 98.9% | 76.1% | 55.0% |
| FunctionGemma 270M（f16，vLLM） | 64.0% | 87.3% | 98.9% | 73.0% | 46.2% |
| Needle 2（CQ2位） | 63.7% | 98.3% | 99.4% | 71.3% | 48.4% |
| Apple FM（设备端） | 57.6% | 94.2% | 95.5% | 64.5% | 43.8% |
DroidCall测试集（200条数据）
| 模型 | 准确率 | 函数名准确率 | 非空调用占比 | 单函数调用准确率 | 双函数调用准确率 |
|---|---|---|---|---|---|
| FunctionGemma 270M（f16，vLLM） | 17.5% | 37.5% | 59.5% | 22.7% | 0.0% |
| Needle 2（CQ2位） | 17.0% | 36.5% | 47.5% | 22.1% | 0.0% |
| LFM2.5 230M（f16，vLLM） | 11.0% | 21.5% | 22.5% | 14.3% | 0.0% |
Seal-Tools域内测试（700条数据）
| 模型 | 准确率 | 函数名准确率 | 单函数调用准确率 | 2-3函数调用准确率 | 4+函数调用准确率 |
|---|---|---|---|---|---|
| Needle 2（CQ2位） | 32.6% | 64.9% | 63.0% | 21.8% | 14.6% |
| LFM2.5 230M（f16，vLLM） | 26.9% | 45.4% | 54.5% | 17.1% | 10.4% |
| FunctionGemma 270M（f16，vLLM） | 16.3% | 56.0% | 47.0% | 4.5% | 2.1% |
Seal-Tools域外测试（654条数据）
| 模型 | 准确率 | 函数名准确率 | 单函数调用准确率 | 2-3函数调用准确率 | 4+函数调用准确率 |
|---|---|---|---|---|---|
| Needle 2（CQ2位） | 28.7% | 58.7% | 56.4% | 27.1% | 15.4% |
| LFM2.5 230M（f16，vLLM） | 17.0% | 35.0% | 42.6% | 13.7% | 9.8% |
| FunctionGemma 270M（f16，vLLM） | 15.6% | 48.9% | 50.0% | 11.0% | 6.3% |
Needle并非针对通用工具调用训练：其训练语料以消费级设备操作（智能家居、移动设备、可穿戴设备、电视、汽车）和结构化抽取为主，而BFCL中的通用及企业API场景（包括Java和JavaScript SDK分类）完全不在其训练数据范围内。即便如此，Needle仍具备一定的泛化能力：在Python简单调用任务中，其准确率与专门针对该任务训练、参数量是其6倍的FunctionGemma仅相差1个百分点；在全部3641条测试数据中，输出格式合规率达93.4%。性能差距主要集中在从未接触过的训练场景：Java、JavaScript及并行多函数调用分类。
BFCL v4单轮对话（3641条数据）
| 分类 | Apple FM（设备端） | LFM2.5 230M（f16，vLLM） | FunctionGemma 270M（f16，vLLM） | Needle 2（CQ2位） |
|---|---|---|---|---|
| 简单调用 | 73.3% | 63.2% | 48.1% | 40.8% |
| — Python | 86.8% | 85.5% | 62.3% | 61.2% |
| — Java | 67.0% | 48.0% | 38.0% | 29.0% |
| — JavaScript | 66.0% | 56.0% | 44.0% | 32.0% |
| 多函数调用 | 84.0% | 78.5% | 60.0% | 57.0% |
| 并行调用 | 65.0% | 64.0% | 36.5% | 30.0% |
| 并行多函数调用 | 52.0% | 51.5% | 30.5% | 22.5% |
| 实时简单调用 | 70.5% | 45.0% | 33.7% | 36.8% |
| 实时多函数调用 | 45.9% | 47.8% | 25.2% | 27.9% |
| 实时并行调用 | 50.0% | 43.8% | 18.8% | 25.0% |
| 实时并行多函数调用 | 58.3% | 45.8% | 25.0% | 29.2% |
| 相关请求识别 | 100.0% | 68.8% | 81.2% | 81.2% |
| 无关请求识别 | 28.3% | 77.7% | 72.1% | 60.8% |
| 整体准确率 | 61.7% | 60.8% | 46.1% | 42.6% |
| 输出格式合规率 | 95.0% | 94.2% | 100.0% | 93.4% |