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

相关推荐
SelectDB8 小时前
Apache Doris Data Agent 解决方案:开启智能运维与数据治理新纪元
github·apache·mcp
老纪的技术唠嗑局1 天前
AI 替代传统 GUI:基于 MCP 的 OBCloud 工作流
运维·mcp
量子位1 天前
WAIC抢先爆料:金融“黑马”大模型超DeepSeek刷新SOTA,论文已上线
deepseek
会写代码的斯皮尔伯格1 天前
Spring Boot 3整合Spring AI实战:9轮面试对话解析AI应用开发
openai·微服务架构·java面试·rag·ollama·spring ai·spring boot 3
聚客AI1 天前
📊构建企业AI Agent中台:基于MCP的统一工具调用架构设计
人工智能·agent·mcp
老周聊大模型1 天前
大模型如何突破“认知茧房”?RAG+MCP构建外部脑接口
langchain·agent·mcp
Younglina1 天前
🔮 用Vue3+TypeScript打造沉浸式AI塔罗牌占卜应用 > 一个集成DeepSeek AI、支持PWA的现代化塔罗牌Web应用开发实战分享
前端·vue.js·deepseek
AI大模型2 天前
超实用!Dify快速接入本地MCP服务
程序员·llm·mcp