网页搜索 MCP server 搭配本地 LLM：实际运行的是哪个模型

大多数关于"搭配本地 LLM"运行网页搜索 MCP server 的教程，讲到安装命令就结束了。更有价值的问题是：你的机器最终实际用的是哪个模型？因为 CrawlForge 并没有把模型写死——它会对你已经安装的模型排名，然后挑出最好的那个。

先把两件事分开。search_web 负责找到网页，它是一次搜索 API 调用，不涉及任何 LLM。本地模型影响的是之后的环节——extract_with_llm、summarize_content、analyze_content、deep_research。所以"网页搜索 MCP server 搭配本地 LLM"真正的含义是：搜索在远端，阅读在本地。

网页搜索 MCP server 默认会使用本地 LLM 吗？

CrawlForge 会，而且无需任何配置。provider 按固定的优先顺序注册——openai、anthropic、ollama——但两个云端 provider 只在其 API key 存在时才会注册。Ollama 不需要密钥，因此在没有配置任何密钥的机器上，它是唯一注册的 provider，也就成了默认选项。

设置 OPENAI_API_KEY，OpenAI 就会排在 Ollama 前面。这是刻意的：云端密钥之所以存在，是因为有人特意配置了它，所以它优先于零配置的本地选项。设置 DISABLE_OLLAMA=true 可以把 Ollama 完全排除在外。

CrawlForge 实际会挑选哪个本地模型？

顺序如下：

1. 若已设置 OLLAMA_DEFAULT_MODEL——显式指定始终优先。
2. 否则，选择你实际安装的模型中排名最高的那个。
3. 否则，选择第一个已安装的模型，不论是什么。
4. llama3.2 仅在完全连不上 Ollama 时使用——这样错误信息里出现的是一个真实模型名，而不是占位符。

已安装列表来自对 OLLAMA_BASE_URL（默认 http://localhost:11434）的一次 GET /api/tags 调用，超时三秒，并在整个进程生命周期内缓存。

第 1 步最容易踩坑。本地 .env 里遗留的一个 OLLAMA_DEFAULT_MODEL 会悄无声息地让整个排名失效，而且不会有任何提示。

为什么 4B 模型能胜过 20B 模型？

因为这个排名是实测的，不是假设的。在三个真实商品页面上评测，参照独立核验过的标准答案，统计 18 个字段中正确的数量：

参数量并不能预测准确率。gemma3:4b 以大约三分之一的延迟追平了 20B 模型的得分，并在五次运行中保持 45/45。

真正有意思的是失败案例。llama3.2——过去写死的默认模型——在一个根本没有划线价的商品上凭空编造了一个，每一次运行都如此。这正是"挑选最好的已安装模型"取代"写死一个模型"的原因。

还有一套用于另一项任务的排名。判断论断——相关性、同义归组、矛盾检测——不同于抽取字段，目前只有 gemma3:12b 被列为胜任。抽取环节的冠军 gemma3:4b，曾把一个 Playwright 与 Selenium 的营销页面判定为与反爬虫主题 0.9 相关。不在该列表中的模型永远不会被要求做判断，因为一个在彼此一致的来源之间编造分歧的模型，比一个什么分歧都不报告的模型更糟。

如果 Ollama 没有运行会怎样？

系统只探测一次。若主机不可达，Ollama provider 会被注销并重新执行选择流程：持有云端密钥的机器会回退到云端，两者都没有的机器则会报告没有可用 provider，而不是一直挂起。能够降级为 CSS 或关键词抽取的 tools 会选择降级，而不是直接失败。

在本地运行模型能让搜索免费吗？

不能。本地推理本身不花钱，但 tools 依然消耗 credits：search_web 5、summarize_content 4、extract_with_llm 3、analyze_content 3、list_ollama_models 1。计费在选择 provider 之前就已执行，因此它无从得知作答的是本地模型。

本地推理改变的是数据的去向。使用 Ollama 时，抓取到的页面内容绝不会发送给第三方模型。再配合 search_web 的 provider: "searxng"，查询也不会离开你的网络——不过那是隐私层面的改变，不是成本层面的。