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

相关推荐
维度攻城狮24 分钟前
科研提速!Zotero Awesome GPT 搭配本地 Ollama 模型使用指南
gpt·zotero·ollama·awesome gpt
AC赳赳老秦32 分钟前
Unity游戏开发实战指南:核心逻辑与场景构建详解
开发语言·spring boot·爬虫·搜索引擎·全文检索·lucene·deepseek
且去填词1 小时前
DeepSeek-R1 实战:数据分析
人工智能·python·mysql·语言模型·deepseek·structured data
酩酊仙人13 小时前
fastmcp构建mcp server和client
python·ai·mcp
且去填词14 小时前
DeepSeek API 深度解析:从流式输出、Function Calling 到构建拥有“手脚”的 AI 应用
人工智能·python·语言模型·llm·agent·deepseek
FranzLiszt184718 小时前
基于One API 将本地 Ollama 模型接入 FastGPT
langchain·fastgpt·rag·ollama·one api
AC赳赳老秦18 小时前
Shell 脚本批量生成:DeepSeek 辅助编写服务器运维自动化指令
运维·服务器·前端·vue.js·数据分析·自动化·deepseek
kwg1261 天前
本地搭建 OPC UA MCP 服务
python·agent·mcp
AC赳赳老秦1 天前
量化交易脚本开发:DeepSeek生成技术指标计算与信号触发代码
数据库·elasticsearch·信息可视化·流程图·数据库架构·memcached·deepseek
小小工匠1 天前
LLM - 从通用对话到自治智能体:Agent / Skills / MCP / RAG 三层架构实战
agent·rag·skill·mcp