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毛,能给大家带来一些帮助吧。

相关推荐
skywalk81639 小时前
用ollama启动duan-translator 小模型
服务器·ollama·段言
AC赳赳老秦9 小时前
招投标公开数据自动化采集实战:基于 OpenClaw 的定时抓取与业务关键词精准推送
运维·服务器·数据库·自动化·测试用例·deepseek·openclaw
麦哲思科技任甲林10 小时前
Codex+ChatGPT 胜过TRAE+DeepSeek组合的感受
chatgpt·deepseek·trae·工程化ai
MicrosoftReactor12 小时前
技术速递|智能体构建智能体:基于 Microsoft Agent Framework 与 Foundry 的 Skill 优先架构蓝图
ai·架构·agent·智能体·mcp
正在走向自律1 天前
Deepseek V4 Flash 高效应用实战指南
人工智能·deepseek·deepseek v4·ai赋能中心
牧艺1 天前
从 Tool Calling 到 MCP Server:把业务能力做成 Agent 可复用接口
agent·全栈·mcp
凡泰AI1 天前
如何借助MCP打通企业APP内部服务:从统一调用到小程序承接
小程序·uni-app·app·mpaas·mcp·小程序容器
小月土星1 天前
1.0 从零构建 DeepSeek R1 WebGPU 浏览器推理应用:一次现代前端工程与端侧 AI 的深度碰撞
浏览器·deepseek
云卷云舒___________1 天前
阿里开源Qwen3.8 2.4T模型预览版、并推出Token Plan订阅、DeepSeek Harness与V4正式版同发 | 7月20日 AI日报
ai·阿里·deepseek·ai日报·harness·qwen38·tokenplan