14MB 模型，凭什么跟 270M 对打？

它想证明的不是小模型也能聊天，而是 14MB 也能把工具调用收成结构化输出。
⚡️ 30 秒速读：cactus-compute/needle 以 4,933 星、今日 +768 登上 GitHub Trending #4，连续 2 天在榜，排名从昨日 #17 升到 #4。README 称 Needle 2 是开放的 45M 参数模型，面向工具调用、设备使用和结构化抽取；整包是单个 14MB 二进制，完整会话约 28MB 内存，用 pip install cactus-needle 做推理、LoRA 微调和导出。风险同样明确：README 写它在基准上与 FunctionGemma 270M、LFM2.5 230M、Apple FM 互有胜负，但 deep-pick 摘录没有收录具体分数；最新 Release v2.0.3 的说明被截断；材料展示的是 Python 包与本地 playground，没有给出手机或可穿戴设备的安装与实测流程。

项目概览

属性	值
仓库	cactus-compute/needle
定位	45M 参数的开源工具调用模型；本仓库是推理、LoRA 微调与导出的 Python 包
主要语言	Python（79.0%）
其他语言	JavaScript（10.6%）、CSS（6.7%）、HTML（3.0%）、Shell（0.4%）、Batchfile（0.3%）
许可证	MIT
总星标	4,933
今日新增	+768
Forks	333
最新版本	v2.0.3（2026-08-13）
建库时间	2026-02-24
最近推送	2026-08-13
开放 issue	23
订阅者	33
Trending 排名	#4，连续 2 天在榜；昨日 #17

能确认的趋势事实有两天：08-13 以 #17、当日 +346、总星标 4,180 上榜；08-14 升到 #4，当日 +768，总星标 4,933，Forks 333。deep-pick 没有更早的排名轨迹，因此不能写成长期连登。v2.0.3 发布于 2026-08-13T07:25:49Z，与首次上榜同一天，但现有材料不足以把名次上升归因于这次 Release 或 README 中的某一项能力。

它是什么

Needle 2 是 Cactus Compute 团队发布的开放 45M 参数模型。README 把它的任务写成三件事：tool calling、device use 和 structured extraction。GitHub 描述的定位是「14MB foundation model for tiny devices; phones, wearables, smart home, and robots」。引用标题则写成 Needle 2: A 45M-Parameter Foundation Tool-Calling Model for Tiny Devices 。主页为 cactuscompute.com。

当前这个 GitHub 仓库是 Python 包：pip install cactus-needle 之后可做推理、LoRA 微调和导出。README 写明推理引擎会从 Hugging Face 拉取一次并缓存，之后没有其他构建步骤；权重地址为 huggingface.co/Cactus-Comp...。它同时强调：权重烤进单个 14MB 引擎、没有独立模型文件要管理，并且 inference does no network。

调用合同也很具体。用 @needle.tool 装饰函数，由签名提供参数类型、docstring 作为工具描述；run() 完成选工具、执行函数、把结果喂回模型的闭环，最终在 results 里附上已执行的工具结果。结构化抽取则调用 extract()，传入 Pydantic 模型，得到类型化对象。更细的参数描述、取值约束、原始 JSON schema、complete()、response contract、system facts、工具检索和置信度门控，README 指向 doc/apis.md，但这份文件不在 deep-pick 摘录里。

技术要点

14MB 整包与约 28MB 会话内存：README 称整个模型是单个 14MB 二进制，完整会话约 28MB RAM；权重烤进自有引擎，无独立模型文件。有界记忆用 256-token 滑动窗口，并把工具钉成 KV sinks，因此「对话跑多久，总内存都接近 28MB」。
CQ2-bit 与 Simple Attention Network ：模型基于作者的 Simple Attention Network，用 Cactus Quants 压到 CQ2-bit，再烤进自有引擎。配方是：用 Hadamard MLP 替代 FFN、GQA attention、engram key-value memory，以及 multi-lane hyper-connections。设计与消融见 arXiv:2607.18363。
块内更新规则：README 写明每个 block 带着更新规则。x̂ 是四条残差流的 RMS 归一化展平；H 是正交 Walsh-Hadamard 变换（固定矩阵，n log n 时间，无权重可读）；(kₜ, vₜ) 从 hashed n-gram 表取出；P 是对路由 logits A 做 Sinkhorn 迭代得到的双随机归一化；a、b、g 和全部 σ-gate 是学习到的、随输入变化的。attention 与 MLP 残差都做 sandwich-norm 并加门控，engram 在两层触发，解码由声明 schema 编译出的字节级语法约束。
Text in, JSON out：工具调用以结构化数据返回；由 schema 编译的 byte-level grammar 约束每一个 token。README 还写了 value constraints 会被编进 decode grammar。
置信度门控：每个响应带一个由 learned head 给出的校准置信度分数；设定阈值后，高于阈值则执行，低于阈值则 escalate。
工具检索：可以声明大型工具目录，内置 retrieval head 每轮只渲染 top five tools，语法再约束到这个子集。
Python 工作流 ：needle playground 在 http://127.0.0.1:7860 提供浏览器试玩，首次查询前会下载并初始化模型；界面有 Finetune on these tools 按钮，可产出可下载的 .cact。微调是冻结底座上的 LoRA，导出时合并 adapter，调过的模型仍是单个 .cact，同一引擎可直接跑、无需重编译。训练是 plain JAX；cactus-needle[gpu] 走 NVIDIA CUDA，cactus-needle[metal] 走 Apple Silicon GPU。
微调默认值与导出位宽 ：needle finetune 的关键选项包括 --epochs（默认 3）、--lora-rank（16）、--lora-alpha（32）、--lr（1e-4）、--batch-size（16）、--max-len（1024）、--val-split（0.1）。合成数据需要 OPENROUTER_API_KEY，也可用 OPENROUTER_URL 指向 OpenAI 兼容网关。needle build 写明 --bits 2（default 4）可得到更小模型。
最新 Release ：v2.0.3 于 2026-08-13T07:25:49Z 发布，非 prerelease。deep-pick 收录的说明原文是 fix: enhance support for PEP 604 unions in schema generation and add ...，后半句被截断，不能补写未给出的其余变更。

README 还写「On the benchmarks below, Needle 2 trades wins with other small models like FunctionGemma 270M, LFM2.5 230M and Apple FM, at 5x to 70x smaller, and 2 bits against their f16」，并配有 assets/frontier.png。deep-pick 的 README 摘录没有收录那张图或任何具体分数、数据集名称或胜负条目，因此不能把「互有胜负」写成已核对的评测结果。

为什么现在火

热度可以量化，原因不能。两天轨迹是：昨日 #17、+346、总星 4,180；今日 #4、+768、总星 4,933。单日新增从 +346 升到 +768，排名一次跳了 13 位。仓库还有 333 个 Forks、33 个订阅者。能确认的是 08-13 到 08-14 关注在加速，不能确认增量来自哪个渠道、哪类用户，或是否由 v2.0.3 驱动。

README 呈现的产品冲突很鲜明：一边是端侧和微型设备想做工具调用，另一边是常见小模型体积仍以 230M、270M 计，且多用 f16。Needle 2 给出的回答是 45M 参数、CQ2-bit、14MB 整包、约 28MB 会话内存，再用字节级语法和置信度头把输出锁成 JSON。这个叙事与升榜同时出现，但现有材料不足以证明两者存在因果关系。

冷静思考

基准被提到了，分数没有。README 用「benchmarks below」和 frontier 图来支撑与 230M/270M 级模型互有胜负，但 deep-pick 摘录没有数据集、指标、分差或样本量。5x 到 70x 是一个很宽的区间，不能当成对某一个对照模型的单一压缩比。
2-bit 对 f16 不是同精度对比。作者把 CQ2-bit 写成压缩方法，同时 needle build 的默认位宽是 4、--bits 2 才更小。README 没有解释默认导出的 4-bit 模型与宣传中的 CQ2-bit 14MB 包是否为同一产物。
256-token 滑动窗口是硬边界。工具被钉成 KV sinks 以维持约 28MB 内存，但摘录没有说明超长指令、多步工具轨迹或大段 extract() 文本会如何被截断，也没有给出窗口溢出时的失败模式。
每轮只渲染 top five tools。语法约束在这个子集上，意味着目录再大，单轮可见工具也是五个。材料没有检索命中率、漏召回案例，或工具数增大时的评测。
「推理不联网」不等于开箱离线。引擎要先从 Hugging Face 拉取并缓存；合成微调数据还需要 OPENROUTER_API_KEY 或兼容网关。没有网、也不能用已缓存引擎时，摘录没有给出替代安装路径。
GitHub 描述写了 phones、wearables、smart home 和 robots，topics 含 on-device-ai，但 README 摘录里可执行的路径是 pip install cactus-needle、本机 playground 和 JAX 训练。没有 iOS/Android SDK、固件集成步骤，也没有这些设备上的延迟、功耗或成功率数字。
topics 含 gemini 与 gemma，正文只把 FunctionGemma 270M 列为对照小模型。摘录没有说明 Needle 2 是否基于 Gemma、是否兼容 Gemini API，不能把标签写成技术依赖。
最新 Release 说明被截断，只看清 PEP 604 union 在 schema generation 上的修复。不能据此判断 v2.0.3 相对前一版本改了推理、量化还是微调。仓库有 23 个开放 issue，这个数字不能直接解释为 23 个缺陷，也不能判断严重程度。

这套模型最有辨识度的判断不是把参数堆大，而是把工具调用收成 14MB 二进制，再用语法和置信度把输出锁死。

适合谁

需要在约 28MB 内存预算里做 Python 工具调用，并接受 text-in、JSON-out 合同的开发者
希望用 @needle.tool 或 Pydantic extract() 拿到结构化结果，而不是自由文本的人
打算在冻结的 Needle 2 底座上做 LoRA，并导出单个 .cact 的团队；有 NVIDIA GPU 或 Apple Silicon 时可走对应 extra
工具目录很大、但能接受每轮只露出 top five、并用置信度阈值决定执行或升级的工作流
关心 Simple Attention Network、Hadamard MLP 与 CQ2-bit 小模型设计、需要引用 arXiv:2607.18363 的研究者

如果你需要已公布的基准分数、超过 256 token 的会话、已验证的手机/可穿戴安装包，或者必须在完全离线、从未缓存引擎的环境里完成首次运行，当前 deep-pick 材料还不足以支持这些结论。

未来展望

从 README 已经写出的方向看，项目把端侧工具调用收成一条可复用管道：14MB 引擎负责体积，256-token 窗口和 KV sinks 负责内存上限，字节级语法负责结构，置信度头负责执行门槛，LoRA 加 .cact 负责定制。接下来最值得观察的是仓库是否把「下方基准」的分数表写进可核对材料、GitHub 描述中的手机与可穿戴路径是否出现可安装产物，以及 Release 说明是否不再截断；当前材料没有承诺这些后续计划。

📱 移动端怎么看

GitHub 描述明确提到 phones、wearables、smart home 和 robots；README 给出的可运行数字是 14MB 二进制与约 28MB 会话内存，并声称推理不联网。但摘录里的实际入口是 Python 包、needle playground 监听 127.0.0.1:7860，以及 JAX 的 GPU/Metal 训练 extra。材料没有声明 iOS 或 Android 客户端、可穿戴/机器人 SDK、触控工作流或端侧延迟与功耗数据。可以确认体积和内存数字是按微型设备写的，不能外推已经可在手机上安装使用。

如果只有约 28MB 内存和 256-token 窗口，你会把置信度阈值调高、让模型自动调用工具，还是因为摘录里没有基准分数，坚持人工确认每一步？在「足够小」和「足够可信」之间，你的门槛在哪？

📊 数据来源：GitHub Trending · 2026-08-14

本文是对今日 GitHub Trending #4 项目的深度解读。完整榜单见当日日报。

每天追踪 GitHub Trending，写日报和深度解读。更多内容可关注公众号「AI Agent 赛道解析」。