2600万参数工具路由器表明：工具调用应与推理分离

Needle 是一个用于单次工具调用的 2600 万参数模型。虽然“小模型”这个标题引人注目，但我认为更有价值的观点是关于代理架构的：许多工具调用并不涉及推理。它们是结构化预测。任务通常是将用户请求匹配到工具，复制或规范化几个参数，并输出有效的 JSON。如果这种框架是正确的，那么在每次工具调用决策中都使用 7B/70B 的聊天模型，就像在关键路径上使用通用大语言模型作为解析器一样。这虽然可行，但可能是错误的抽象。 Needle 的主张包括： - 来自 Cactus-Compute 的 2600 万参数函数调用模型。 - 专为单次工具调用训练，而非通用聊天。 - 据作者称，由 Gemini 3.1 Flash Lite 蒸馏而来。 - 报告的前向填充（prefill）速度为 6000 tok/s，解码（decode）速度为 1200 tok/s。 - 最终的 INT4 模型大小约为 14MB。 - 采用简单注意力网络（Simple Attention Network）设计：编码器-解码器结构，无前馈神经网络（FFN）。 - 代码仓库和权重公开，采用 MIT 许可证。 速度指标很重要，因为这两个阶段都直接位于代理延迟路径上。前向填充是模型读取提示的阶段：包括工具定义、用户请求，可能还有示例。解码则是它输出工具调用 JSON 的阶段。如果工具路由在代理循环中反复发生，将明显的工具调用从通用聊天模型转移到微小的本地路由器，将改变系统的形态。 架构主张也应与炒作区分开来。在标准 Transformer 中，O(N^2) 的注意力矩阵是序列长度的计算和内存成本，而不是 N x N 的学习参数矩阵。学习到的注意力参数主要是 Q/K/V/O 投影。FFN/MLP 通常占层权重的很大一部分，但具体比例取决于架构。因此，我会将 Needle 的无 FFN 设计视为一种架构赌注，而非证明：对于工具路由，也许有用的原语主要是将输入片段对齐到输出槽位。如果任务是模式匹配加上参数提取，那么以注意力为主的编码器-解码器可能比我们假设的更经常足够用。 这使得 Needle 感觉不那么像一个微小的自主代理，而更像是代理的一个编译器通道： - 大模型处理规划和实际推理。 - 小的本地路由器处理明显的工具选择和参数提取。 - 工具调用输出根据模式进行验证。 - 困难或模糊的情况回退到更大的模型。 这种分离似乎很重要。路由工具的模型不应被视为负责规划、推理、验证、记住上下文或决定副作用是否安全的那个实体。这些是不同的工作。 我认为这很重要的原因： - 许多代理栈中隐藏着一个推理接口内的路由问题。 - ReAct 风格的循环通常消耗昂贵的令牌来决定下一步调用哪个工具。 - 设备端路由有助于降低延迟、保护隐私、支持离线工作流程以及移动/可穿戴代理。 - 微小的专用路由器可能比进行有副作用调用的通用聊天模型更易于约束和审计。 - 规划边界变得更加清晰：推理模型决定意图，路由器发出结构化 I/O，验证器执行模式和权限。 警告仍然存在： - 公开声明需要更多独立的基准细节。 - 单次函数调用比多轮代理行为狭窄得多。 - 从 15 个工具类别扩展到数百或数千个工具的效果尚不清楚。 - 模糊请求是困难案例。“明天 10 点咖啡”加上“保存这个”根据上下文可以映射到日历、提醒、笔记、联系人或消息。 - INT4 大小很好，但我希望看到量化下的准确性和失败模式。 - 便宜的工具路由器仍然需要权限管理和验证。有效的 JSON 并不等同于安全的操作。 我的看法：重要的论点不是“小模型好”。而是工具调用应该更激进地从推理中分离出来。尽可能将其视为结构化预测，为大模型保留实际需要推理的情况，并严格验证边界。来源包括 Needle 代码仓库、Hugging Face 模型页面、架构文档和 HN 启动线程。我可以按照这个子版块的规则在评论中提供链接。