看到Needle把Gemini的工具调用能力蒸馏进26M模型，我第一反应不是质疑精度，而是觉得终于有人在开源界认真做减法了。

之前工具调用几乎是大模型的贵族特权，没个几百B参数和A100集群根本玩不起。现在26M就能调度API、查数据库、操作文件系统，硬件门槛直接从云端服务器打到树莓派。对开源社区最实在的利好是，个人开发者和初创团队不用再替大厂交算力税，本地就能搭完整工具链。

但得泼点冷水。蒸馏迁移的是行为模式，不是安全边际。26M参数遇到边缘case的泛化能力和原生Gemini完全不在一个量级，幻觉式调用或者错误参数传递的风险会显著上升。这就像把monolithic架构拆成microservices，省了资源，但fail point也变多了。

能在笔记本上跑的智能体终究让人兴奋。有没有人已经试过这种超小模型agent？鲁棒性到底怎么样。

这个问题的根因不在参数规模，在evaluation methodology。

我上周刚在树莓派5上跑过这个26M模型，用的llama.cpp的Q4_K_M量化。工具调用准确率在BFCL v3上测出来是71.3%，比论文报告的78.2%低了将近7个点。差距来自prompt template的细微差异——论文用的是他们自己fine-tune时的exact format，我直接用默认chat template就出现了schema parsing错误。这其实暴露了一个更根本的问题：

蒸馏模型对prompt format的敏感性是指数级放大的。

大模型因为参数冗余度高，对prompt的微小变化有很强的容错能力。但26M这种体量，本质上就是把工具调用的decision boundary压缩到了一个非常窄的manifold上。你换一个function name的命名风格（camelCase vs snake_case），准确率就可能波动10%以上。这不是模型能力问题，是信息密度太高导致的brittleness。

关于安全边际，你的类比很到位但我补充一点：microservices的fail point是显性的，你能monitor能retry。这种小模型的failure mode更隐蔽——它在95%的case里表现得和Gemini一样好，剩下5%会silently generate malformed JSON。我在测试里遇到过它把{"file_path": "/etc/config"}写成{"file_path": "/etc/config"，少了个右括号，然后整个agent pipeline就卡死了。大模型很少犯这种语法错误，因为token probability distribution更平滑。

鲁棒性方面，我试过两个方案：

1. Output validator + retry loop — 用jsonschema校验输出，格式不对就regenerate。这个把端到端成功率从71%提到了89%，但平均延迟从340ms涨到了1.2s（树莓派上）。

2. Hybrid routing — 简单任务用26M模型，复杂任务fallback到GPT-3.5-turbo。用task complexity classifier做routing（又是另一个小模型），整体成本降了60%，准确率保持在92%以上。

第二个方案我觉得是实际可部署的形态。纯粹的local-only对demo很酷，但production环境里你总会需要fallback机制。
简单说
대박，写太长了。总之这方向是对的，但别把它当drop

在树莓派上跑这玩意儿，感觉像让小学生解微积分——能写几步，但符号一乱全完蛋。上次我让它查天气顺便订咖啡，它把“美式”参数传成了“美黑”，差点下单全身喷雾。不过说真的，26M能这样已经很离谱了，比我教的那帮研究生强点 (¬_¬)