本地LLM如何装下更多网页搜索数据：Markdown输出实测

本地大模型能用的网页搜索结果，永远受限于上下文窗口的大小。SerpApi 团队此前构建过一个开源应用，让运行在 LM Studio 中的本地模型获得联网搜索能力，但单个搜索响应常常比整个上下文窗口还大，只能靠 JSON Restrictor 在服务端裁掉字段。SerpApi 新增的 Markdown 输出改变了这个预算：同样的数据用 Markdown 表示，token 更少，于是限制器可以保留更多内容，多数搜索甚至不再需要限制器。

Markdown 输出省了多少 token

SerpApi 的 Markdown 输出通过给请求加上 output=md 参数启用，返回的是带标题、列表和表格的 Markdown 文档，而不是带键名、引号和花括号的 JSON。它覆盖 100 多个 API，费用与 JSON 搜索相同。

据 SerpApi 官方博客的基准测试，使用与上一篇博客相同的限制器字符串、把同样七类搜索（Search、Finance、News、Maps、Flights、Hotels、Shopping）分别以 JSON 和 Markdown 发送，JSON 版本共 4,668 tokens，Markdown 版本 3,412 tokens，减少了 27%。

节省幅度取决于数据嵌套的深度。航班结果包含航段，航段又包含机场和时间，JSON 在每一层都要重复键名、引号和括号；而 Markdown 把结果列表转成表格，列名只写一次。Shopping 结果本身扁平，每个商品只有标题、价格和商店，所以几乎没有可省的空间（仅 −5%）。Flights 的节省最显著，达到 −47%，Finance 和 News 都是 −38%。

这个数字对本地部署有直接意义：如果你的 32K 窗口原本只够放三条搜索结果，换成 Markdown 后同样预算可以放四条甚至更多。

上下文窗口与 token 预算：上下文窗口是模型单次推理能“看到”的 token 总量上限，包括系统提示、对话历史、工具返回结果以及模型自己生成的内容。本地部署时这个上限通常由加载模型时设置的 n_ctx 决定，超出部分会被截断而非报错。token 是分词器切分文本后的基本单位，英文中约等于 0.75 个单词，中文则往往一字一 token 甚至更多。因此“省 token”实质上是同一块固定预算里能装下多少有效信息的较量：JSON 中大量键名、引号和括号都要计入预算却不携带语义，Markdown 用表头和分隔符替代重复结构，把预算腾给内容本身。

tiktoken 与分词器差异：tiktoken 是 OpenAI 开源的分词库，cl100k_base 是其 GPT-3.5/GPT-4 时代使用的编码表，常被当作跨模型的通用 token 估算基准。但每个本地模型都有自己的分词器（如基于 SentencePiece 或 BPE 的不同词表），同一段文本在不同模型下切出的 token 数可能相差 10%–30%。这意味着用 tiktoken 算出的“Markdown 省 27%”是一个格式间的相对比值，迁移到具体模型时绝对数字会变，但“Markdown 比 JSON 更省”的方向性结论通常成立。

同一套限制器，两种输出共用

Markdown 没有单独的限制器机制。你在发送 output=md 的同时带上原来的 json_restrictor 参数即可，SerpApi 会先过滤字段，再把剩下的内容渲染成 Markdown。

应用里每个工具维护两套限制器字符串：JSON 用原始那套，Markdown 用更宽松的一套，保留更多结果和更多字段。以 Maps 为例，JSON 限制器保留 5 个地点，Markdown 限制器保留 6 个地点，并额外带上营业时间和地点描述。应用默认使用 Markdown 加限制器的组合。

各工具花掉这笔"省下来的预算"的方式不同：Search 从 5 条网页结果增加到 5 条但附带 answer box 列表、8 个 AI Overview 区块和 3 条头条新闻；News 从 5 条故事每条 1 篇相关文章变成 7 条故事每条 2 篇；Flights 从 3+3 个选项变成 4+4 个，并带上机型、腿部空间、过夜中转和价格洞察。

这些额外字段会体现在回答质量上。测试中，被问到奥斯汀最好的烧烤时，Qwen 3.8 27B 用 JSON 列出 5 家店，用 Markdown 列出 6 家，新增的 Good BBQ Company 是评分最高的两家之一；Markdown 回答还引用只有该模式才保留的地点描述，把 Terry Black's 形容为"第四代坑烤师，老派烟熏肉"。

跳过限制器会发生什么

更大的变化是完整响应——应用里称为 Raw 模式。在上一篇博客中，把原始 SerpApi 响应发给本地模型根本不可行：七个原始 JSON 响应合计 326,949 tokens，接近上下文窗口的 10 倍。同样七个响应转成 Markdown 后是 71,244 tokens，小了 4.6 倍，而且没有任何一个单独超过 32K 窗口。这是 Markdown 带来的质变，而不只是量变。

能装下不等于跑得快。使用 Markdown Raw 时，模型读取的 token 是 Markdown 限制器模式的两到三倍，回答耗时最多延长到 2.7 倍。

还有一个容易被忽略的坑：一个问题里放两个完整页面仍可能溢出上下文窗口。测试中有一个模型在比较 AAPL 和 TSLA 时，prompt 超过了 32K tokens，LM Studio 在无报错的情况下截断了部分内容，导致模型把苹果的当日涨跌算错了。这类静默截断比显式报错更危险，因为用户无从察觉。

静默截断为何危险：多数推理引擎在 prompt 超过 n_ctx 时的默认行为是从头部或尾部丢弃 token，而不是抛出错误。对于检索增强场景，被丢弃的往往是较早的搜索结果或系统提示，模型仍会照常生成一段看似连贯的回答，但它依据的是残缺的上下文。这类失败没有异常信号，用户很难从输出中察觉，只能通过答案与事实的偏差间接发现。缓解手段包括：在应用层预估 token 数并主动分页、为每个搜索结果单独做摘要后再拼接、以及在提示中要求模型引用来源以便事后核对。

限制器（Restrictor）的作用：JSON Restrictor 是在服务端对 API 响应做字段级裁剪的机制，通过一份白名单式的字符串描述保留哪些路径、丢弃哪些字段，从而在数据进入模型之前就把体积压下来。它的价值在于确定性——裁剪发生在模型之外，不消耗推理预算，也不会因模型“理解偏差”而漏掉关键字段。Markdown 模式下沿用同一套参数，说明裁剪逻辑与渲染格式解耦：先按路径过滤结构化数据，再序列化为 Markdown，因此两套限制器可以独立调松紧。

四种输出怎么选

作者的推荐很明确：

• Markdown（限制器）：默认选项，只要模型要读结果就用它。
• JSON（限制器）：当你的代码要读结果时用，例如按价格排序。
• Markdown（Raw）：当回答确实需要完整页面、且能接受最多三倍等待时间时用。涉及两个大搜索的问题（比如比较两只股票）应避免。
• JSON（Raw）：不要发给本地模型。

如果硬件内存充足，可以通过应用的 LMSTUDIO_CONTEXT_LENGTH 设置提高 32K 窗口上限。

四个本地模型的横向对比

测试在 48 GB 内存的 MacBook Pro M5 Pro 上进行，通过 LM Link 连接两台 MacBook，四个模型都在 32K 上下文窗口下运行，均完成了全部问题。以下为 Markdown（限制器）模式下每个搜索类问题的平均耗时：

• Qwen 3.8 27B：约 42 秒/题。它是应用在已安装时的默认模型，在长对话中能把"那附近""其中哪个"这类追问正确转换成搜索词，表现最稳。
• Meta Muse Glimmer 30B：约 62 秒/题，最慢。它的分词方式让相同搜索结果占用更少的窗口，这是它的一项隐性优势。
• Prism Bonsai 27B：约 24 秒/题。LM Studio 标注体积仅约 4 GB，性价比突出。
• Gemma 4 12B QAT：约 16 秒/题，最快；切到 Markdown Raw 后约 43 秒。但在长对话中问题最多，例如给出搜索结果中不存在的价格。

作者也提醒，48 GB 以下的机器可能加载更小的窗口，能放下的搜索数据也更少；而且新的开源模型几乎每周都在出现，最优选择变化很快。LM Studio 模型搜索里的 staff picks 会根据你的硬件做匹配，是合理的起点。

搜索结果与模型知识冲突时

所有模型的知识都停在训练截止日。2026 年 9 月 1 日，John Ternus 接任苹果 CEO，Tim Cook 转任执行董事长——这件事对训练数据截止在此之前的模型来说是不可知的。

当被问到"苹果现任 CEO 是谁"时，Qwen 3.8 27B 的推理过程记录了它的判断：它知道 Tim Cook 自 2011 年起担任 CEO，但意识到这是时效性问题，决定先搜索确认。这一步是对的。更难的环节出现在搜索结果与它原有认知冲突时：某次运行中，第一条结果的 AI Overview 已经写明 John Ternus，Qwen 却没有直接接受，而是表示"这是一个重大声明"，并打算再做一次新闻搜索核实，以免这是幻觉。

这段推理之所以可见，是因为模型跑在本地——LM Studio 会把每个模型的推理逐字写入服务器日志。托管推理模型通常只给你摘要：OpenAI 在发布 o1 时就选择不展示原始思维链，其他实验室近年也跟进，其中一个竞争性顾虑是知识蒸馏，即让小模型学习大模型的输出，完整的推理过程是极有价值的训练材料。本地部署在这里反而提供了一个研究视角上的额外好处。

实践建议

Markdown 输出对本地 LLM 联网场景的价值可以归纳为一条操作路径：请求里加上 output=md，每个引擎保留一套限制器，把 Markdown 省下的 token 花在问题真正需要的字段上。想动手的话，克隆 GitHub 上的 serpapi/local-llm-web-search 仓库并填入 API key 即可，免费账户每月含 250 次搜索。

需要留意的是，这套基准衡量的是 payload 大小和端到端表现两个维度，前者用 OpenAI 的 tiktoken（cl100k_base 编码）估算，而每个本地模型有自己的分词方式，所以这些 token 数应视为格式间的相对比较，而非绝对值。另外测试样本是 7 次搜索加 13 个问题的组合，规模不大，换硬件或换模型后结论可能需要重新验证。