📌 项目地址：cactus-compute/needle | ⭐ 6,447 颗星 | 🔧 Python | 📜 未标注
这个项目是什么
Needle 2，6447 star，Python 包。一个 45M 参数的模型，打包成单个 14MB 二进制文件，跑完一个完整会话的内存占用约 28MB。功能三样：工具调用、设备控制、结构化抽取。
对标的是 FunctionGemma 270M、LFM2.5 230M 和 Apple FM。基准上互有胜负，但体积是对手的 1/5 到 1/70，权重精度是 2-bit（CQ2），对手是 f16。45M 打 270M 还能赢下部分项目，靠的是架构，不是提示词技巧。
安装就一行：
pip install cactus-needle
推理引擎第一次从 Hugging Face 拉取后缓存，之后推理不联网，不需要编译。气隙设备的离线部署方案在 doc/apis.md 里。权重在 Hugging Face。
为什么 14MB 能干活
底层是作者自己的 Simple Attention Network，论文在 arXiv:2607.18363。看组件清单会发现一条清晰的主线：用无权重或低开销的结构换掉传统 Transformer 里的重量级部件。
Hadamard MLP 替代 FFN。 Walsh-Hadamard 变换是一个固定正交矩阵，n log n 时间算完，没有权重要读。FFN 通常占 Transformer 参数大头，这里直接砍掉了。
GQA 注意力。 分组查询注意力，多头共享 KV，省的是 KV cache 的内存。
engram 键值记忆。 (kₜ, vₜ) 行从哈希 n-gram 表里取。这是用查表代替全量的 key-value 存储。
multi-lane 超连接。 四路残差流做 RMS 归一化后展平，路由 logits 经过 Sinkhorn 迭代做双随机归一化，a、b、g 和所有 σ-gates 都是可学习的、依赖输入。残差走 sandwich-norm 加 gating，engram 在两层触发。
再加上 Cactus Quants 的 CQ2 2-bit 压缩，14MB 和 28MB 这两个数字是一套设计算出来的结果。
工程上的四个设计
README 列的五个特性里，我认为有四个直接命中了在小设备上跑 LLM 工具调用的常见痛点。
输出不合法。 程序化调用模型，最常见的事故是生成的 JSON 缺括号、字段类型错。Needle 把你声明的 schema 编译成字节级文法，解码时每个 token 都受约束。非法 token 根本生成不出来——这是生成时拦截，不是生成后校验加重试。
该不该自动执行。 每个响应带一个校准过的置信度分数，来自一个专门训练的 head。你设一个阈值：高于直接执行，低于转人工。这个决策信号由模型提供，不用从输出文本里猜。
工具目录太大。 声明一个大目录，内置的检索 head 每轮只把前五个工具交给模型，文法也只约束这五个的 schema。目录加到几百个工具，每轮推理成本不涨。
会话越聊越长。 256 token 滑动窗口，工具描述作为 KV sinks 钉住不动。对话多长，总内存都停在 28MB 附近。
这四条凑在一起，指向同一个使用场景：资源受限的设备上，模型做窄执行器，指令进来，结构化调用出去，复杂规划和判断交给上游。
怎么用
用法是装饰器：函数签名给参数类型，docstring 当工具描述。README 原文说得很直白：”describing them well is the whole game”。
这句话值得展开。模型靠读你的描述决定调什么工具、怎么填参数。文法约束只保证格式正确，不保证意图正确——描述写得含糊，模型选错工具或填错参数，文法救不了你。用这类模型，工程重心从写解析代码挪到了写工具描述。
用之前想清楚两件事
置信度阈值没有默认值。不同任务、不同工具集下分数分布不同，先拿自己的数据跑一遍再定。
45M 参数做不了复杂推理。别指望它做多步规划或多工具编排，那是上游模型的活。
可以单独拿走的一条思路
就算不用这个模型，“schema 编译成字节级文法约束解码”这一条是通用的。任何做 LLM 结构化输出的系统都可以参考：与其生成后校验加重试，不如让非法输出在解码阶段就无法产生。重试浪费 token 和延迟，文法约束只多花一次编译成本。
许可证未标注，商用前先去仓库和 Hugging Face 页面确认。