Dify MCP功能实测,小参数模型竟然全军覆没!

测试内容

工具:Dify + Ollama

内容:简单地图的天气 MCP Server 调用

  • 高德地图
  • 百度地图

(腾讯地图因无法返回内容被踢出了测试)

大模型:

  • deepseek-r1:8B(本地)
  • qwen3:8B(本地)
  • qwen3:14B(硅基流动)
  • qwen3:32B(硅基流动)
  • qwen2.5:14B(硅基流动)
  • qwen2.5:32B(硅基流动)
  • llama3:8B(本地)
  • deepseek-chat(Deepseek 官方)

测试结果

高德地图

高德地图需要的内容比较简单,把城市名包裹在 city 里即可。

json 复制代码
{"map_weather": { "city": "深圳" }}

返回的内容也比较简单:

json 复制代码
{
    "map_weather":
    {
        "city": "深圳",
        "forecasts": [
             {
                 date: '2025-7-24',
                 ... // 这里是具体的数据
             },
             ... // 其他日期的数据
        ]
    }
}

10B 以下的模型

7月20日初次尝试 10B 以下本地大模型模型全军覆没。

  • deepseek-r1:8B-发送错误。无法完成测试。
  • Qwen3:8B-发送错误,推理啰嗦,多次纠正无果
  • llama3.1:8B-发送正常,读取错误

几天后,7月24日再次尝试之后,所有模型都成功发送。好像是高德做了兼容,直接传城市名称也可以,更容易使用,当然也导致大模型容易蒙混过去了:

json 复制代码
{"map_weather": "深圳"}
  • deepseek-r1:8B-显示的结果跟 mcp 返回的完全不一致。
  • Qwen3:8B-多次尝试,最后显示正常,但是有一次突然中断了。
  • llama3:8B-依然无法解析返回的内容。

本地 deepseek-r1 传送格式及返回,信息错误,基本的昨天今天明天的时间都错了。

Qwen3 查询格式及返回,查询一次,失败中断,第二次后,正常了,但结果有今天和明天,今天只取了白天天气,当时已经是晚上。

llama 传输正常,但是结果无法解析。

14B 模型

14B 的模型,使用了硅基流动的api。由于平台缺少 llama3.1,所以后续不再测。 整体表现虽然好点。但是也有不少问题

  • deepseek 依然传着最简单参数形式 {"map_weather": "深圳"} ,还是有蒙混过关的可能。回答中没区分白天与夜晚的天气,晚上的中雨没显示出来。
  • Qwen3 回答正常,还添加了雷雨天注意事项。表现已经相当好了。

30B 以上的模型

  • deepseek:32B 发送的参数正确了,只是跟14B返回结果一致,晚上的天气情况没显示出来。另外表现不稳定,中间突然飙英文出来。
  • Qwen3-30B-A3B 和 Qwen-32B 表现差不多,开始出现 emoji。排版更舒服。
  • 满血版的 deepseek 和 Qwen3 自然不在话下。

百度地图

百度地图有两个参数可以选。要么选择地区码:

json 复制代码
{"map_weather": { "district_id": "440200" }}

要么选择经纬度:

json 复制代码
{"map_weather": { "location": "113.3667,22.5667" }}

数据返回结构更复杂:

json 复制代码
{
	"map_weather":
    {
        "status": "0",
        "result":
        {
            "location": {}, //地点
            "now": // 实时天气预报
            {
                 "temp": '27',
                 "uptime": "20250724221500", //更新时间
                 ... // 这里是具体的数据
             },
             "indexes": [], // 各种指数
             "alerts": [], // 警报
             "forecasts": [], // 一周天气
             "forecast_hours": [] // 小时天气
        }
    }
}

10B以下大模型

  • deepseek-r1:8B-发送错误。无法完成测试。district_id 理解成了区的id。
  • Qwen3:8B-发送错误,推理啰嗦,多次纠正无果。
  • llama3.1:8B-发送正常,读取错误

本地 deepseek-r1,无法完成

本地 Qwen3 两次调整之后获取了正常的返回。

但是 Qwen3 却对结果无法解析,口吐鸡肠,阵亡。

llama3.1 跟高德地图返回一样,解析阶段陷入了死循环,也未能完成任务。

14B 模型

  • deepseek-r1 输入错误,失败
  • Qwen3:14B 表现不错,指数也解析出来了,还带上温馨提醒。

30B 以上的模型

  • deepseek:32B 经过两次思考,输入正确,但是回答过于简单,只把now 的部分解析出来了。
  • Qwen-32B 表现不错,将高温预警也解析出来了。
  • 满血版的 deepseek 和 Qwen3 跟调用高德地图 mcp 的一样,表现优秀。

大模型版本问题

由上面几次测试可以判断,MCP 主要考验大模型对 Json 的处理能力。之前就有报道,OpenAI 也是花了 1-2 代才解决 Json 输出输入稳定性。

于是为了测试是否有代际问题,选了 Qwen 来做第二轮测试。 结果正如所想的,Qwen3 明显要好于 Qwen2.5。

  • Qwen3 的 14B 已经有不错的表现了。
  • Qwen2.5 的 32B 对返回的内容解读还是有点勉强。

看来 deepseek 非满血版的确是基于 Qwen2.5 的蒸馏而来,两者的表现基本一致。

总结

  1. 对 MCP 处理能力基于模型对 JSON 的处理能力。
  2. 模型对 JSON 的处理能力跟参数大小相关,但跟模型大小相关性更强。
  3. 最新小参数模型能处理好 MCP 的输入,但是 MCP 如果返回大量的数据,只有大参数模型才能处理好。
  4. 后面能不能出现小参数模型有更好的 JSON 解读能力,也许能优化,也许已经是目前的极限了。

如果要在本地实践 MCP,至少也要选择 Qwen3-14B 这种规模的模型,因此配置 32GB 内存的 Win 或 16G 内存的 Mac 勉强能用。

如果从效率出发,选择第三方可能是更好的选择。

价格问题

用第三方就要涉及价格问题了。

以下是某平台的价格对比。

可以看到,8B 模型在第三方平台上是免费的,因为它能做的事情真的非常有限,14B开始收费,还不便宜,即使是百万 Token 的费用,正规项目经过几轮测试下来,也要花不少钱。

这样看来要做 MCP 开发,费用是必不可少了。

本次测试就用了 0.47 元。

希望这5毛,能给大家带来一些帮助吧。

相关推荐
AlfredZhao10 小时前
如何在Oracle Agent Factory中配置国内厂商的LLM?
deepseek·agent factory·paf
ZengLiangYi11 小时前
MCP Server 集成:让 AI Agent 自动调用知识库
ai编程·mcp
ZengLiangYi11 小时前
MCP + Claude Code:新对话自动回忆历史经验
ai编程·mcp
winlife_13 小时前
把 Godot 编辑器接入 AI:Funplay MCP for Godot 介绍
人工智能·编辑器·godot·ai编程·游戏开发·mcp
大模型真好玩14 小时前
大模型训练全流程实战指南工具篇(十二)—— 大模型评测方法及典型评测集介绍
人工智能·agent·deepseek
prog_610314 小时前
【笔记】用cursor手搓cursor(六)deepseek v4
人工智能·笔记·agent·deepseek·claude code
倾颜14 小时前
做 AI 应用时,Agent、RAG、Tool、Skill、MCP 这些概念怎么分工?
agent·ai编程·mcp
掉鱼的猫15 小时前
用 Solon AI 从零构建 MCP 工具服务:让 AI Agent 拥有真实世界的能力
java·llm·mcp
jianwuhuang8216 小时前
Kimi怎么导出pdf
人工智能·chatgpt·pdf·deepseek·ai导出鸭
带刺的坐椅17 小时前
用 Solon AI 从零构建 MCP 工具服务:让 AI Agent 拥有真实世界的能力
java·ai·solon·mcp·solon-ai