本文对多种大模型（包括Deepseek、Qwen、Llama系列）在调用高德地图和百度地图API进行天气查询的实际测试结果进行了详细分析。测试发现，模型对JSON格式的处理能力是关键，参数量和模型代际（如Qwen3优于Qwen2.5）显著影响结果的准确性和稳定性。10B以下模型普遍表现不佳，而14B及以上模型，特别是Qwen3系列，在解析复杂数据和提供额外信息方面表现突出。文章还探讨了本地部署与第三方API调用的成本效益，指出即便8B模型在第三方平台免费，但对于需要处理大量数据的MCP开发，成本依然不菲。

💡 模型对JSON的处理能力是调用地图API的关键：测试表明，大模型能否准确地解析和生成JSON格式的数据，直接影响其调用地图API（如高德、百度）获取天气信息的能力。MCP（Map Call Process）的成功与否，很大程度上取决于模型对JSON的稳定性处理。

🚀 模型规模与代际是影响表现的重要因素：10B以下的模型在处理地图API调用时普遍存在错误或无法解析的情况，而14B及以上的模型，特别是Qwen3系列，表现出明显优势。Qwen3相比Qwen2.5在处理复杂数据返回时更加稳定和准确，显示出代际进步的重要性。

📈 不同地图API的调用难度与模型适应性存在差异：高德地图API返回的数据结构相对简单，易于模型解析；而百度地图API返回的数据结构更为复杂，包含实时、指数、预警、周/小时预报等，对模型的解析能力提出了更高要求。部分模型在处理百度地图数据时暴露了更多问题。

💰 本地部署与第三方API调用的成本考量：文章指出，虽然8B模型在第三方平台可能免费，但对于需要稳定、高效处理大量数据的MCP开发项目，使用第三方API会产生显著的成本。本地部署模型（如Qwen3-14B）需要较高的硬件配置（如32GB内存），而选择更强大的模型则成本更高，需权衡效率与费用。

⚠️ 模型表现不稳定，存在随机性：即使是表现较好的模型，在测试过程中也出现过发送错误、推理啰嗦、中断、返回内容不一致、甚至突然输出英文等问题，表明大模型在处理复杂API调用时仍存在不稳定性，需要多次尝试或模型优化。

测试内容

工具：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 里即可。

{"map_weather": { "city": "深圳" }}

返回的内容也比较简单：

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

10B 以下的模型

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

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

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

{"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 自然不在话下。

百度地图

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

{"map_weather": { "district_id": "440200" }}

要么选择经纬度：

{"map_weather": { "location": "113.3667,22.5667" }}

数据返回结构更复杂：

{"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 的蒸馏而来，两者的表现基本一致。

总结

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

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

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

价格问题

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

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

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

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

本次测试就用了 0.47 元。

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