这件事为什么有意思
现在大家都在追求更大的模型——千亿参数、万亿参数。但 Cactus Compute 反其道而行，做了一个只有 26M 参数的模型，专门做一件事：函数调用（Function Calling / Tool Calling）。
26M 参数是什么概念？大概是你手机里一张高清照片的大小。它可以跑在 Raspberry Pi、手机甚至某些微控制器上。
技术路径
Needle 的核心方法是知识蒸馏（Knowledge Distillation）：
- 用 Gemini（大模型）作为 teacher，生成大量 tool calling 的训练数据
- 用一个 26M 参数的小模型作为 student，学习 teacher 的 tool calling 行为
- 关键洞察：tool calling 本质上是一个结构化输出任务——给定用户意图，输出正确的函数名和参数。这个任务的"信息密度"其实没那么高，小模型完全可以学会。
这个思路在直觉上是成立的。就像一个经验丰富的老师傅带徒弟——老师傅（Gemini）知道怎么在各种复杂场景下选择正确的工具，徒弟（Needle）不需要理解所有背景知识，只需要学会"什么情况下调用什么工具"这个映射关系。
实际价值
1. 边缘设备上的 AI Agent
如果你想在手机、IoT 设备上跑一个能做 tool calling 的 agent，现在不需要把完整的 LLM 塞进去。Needle 可以本地运行，只在需要推理时才调用云端大模型。这是一个典型的"端云协同"架构。
2. 降低 API 成本
在一个复杂的 Agent 工作流中，tool calling 可能是最频繁的操作。如果每次都要调用 GPT-4 来决定"该调用哪个函数"，token 成本会很高。用一个 26M 的本地模型做这个决策，成本几乎为零。
3. 延迟优化
本地 26M 模型的推理延迟可能在毫秒级，而云端 API 调用至少几百毫秒。对实时性要求高的场景（语音助手、实时控制），这几十倍的延迟差很关键。
需要注意的事
212 stars vs 228 commits
项目还很新（最近 11 小时才 restructure），社区验证不足。1 个 open issue 和 8 个 open PRs 说明处于早期快速开发阶段。
功能单一
Needle 只做 tool calling。它不会聊天、不会推理、不会写代码。如果你的场景只需要 tool calling，它是合适的；如果需要通用能力，还是需要完整的 LLM。
蒸馏质量取决于 teacher
Gemini 的 tool calling 能力本身也在迭代。如果 teacher 有系统性错误，student 会继承这些错误。蒸馏模型的质量天花板就是 teacher 的质量。
和同类方案的对比
目前 tool calling 小型化的路线主要有三条：
- 蒸馏路线（Needle）：从大模型学行为，参数最小，但依赖 teacher
- 微调路线：在开源模型上微调 tool calling 能力，参数中等（7B-14B），灵活性高
- 专用架构路线：从头设计适合 tool calling 的小模型架构，最激进但也最不确定
Needle 选择了最务实的路线——先用蒸馏证明小参数可行，后续再考虑架构优化。
一句话
26M 参数做 tool calling 是一个有趣的信号：它说明 AI Agent 的基础设施正在从"一个万能大模型"走向"多个专门小模型"的混合架构。这条路线如果走通，边缘 AI Agent 的门槛会大幅降低。
主要来源：