网页喂给LLM要烧多少Token？20个真实页面实测

如果你在做 RAG 流水线或能读取网页的 Agent，每个页面最终都会变成输入 Token：嵌入阶段要算、塞进上下文窗口要算、每次查询还要再算一遍。你交给模型的到底是什么形态，直接决定了成本。与其估算，不如实测——有人拿了 20 个真实页面做了一次系统性对比。

核心结论：原始 HTML 是最贵的形态

实验选取了 20 个德语公开页面，混合了 6 个起始/概览页（菜单和推荐位密集）与 14 篇文章页（新闻、百科、文档、法条、菜谱、指南），来源包括 Wikipedia、MDN、tagesschau.de、heise online、德国环境署、gesetze-im-internet.de、Chefkoch、DHL、Siemens 等。每个页面都会被保存为四种形态：原始 HTML、全页转文本 Markdown、仅正文 Markdown、以及面向 LLM 进一步清洗的 Markdown。

结果显示，样本中的中位页面原始 HTML 约为 128,000 Token——单个页面就能塞满一个 128k 上下文窗口。而面向 LLM 的 Markdown 形态，中位数比原始 HTML 节省 98% 的 Token，比全页转文本 节省 63%。

什么是 Token，为什么它决定了成本？

Token 是大语言模型处理文本的最小单位。模型并不直接读字符，而是先把文本按分词器（tokenizer）规则切成 Token 序列，再转成向量做计算。一个英文单词通常对应一到两个 Token，一段 HTML 标签如 <div class="nav"> 可能被切成十几个 Token。计费与上下文窗口约束都以 Token 为单位：API 按输入、输出 Token 数收费，模型能“记住”的上下文长度上限同样以 Token 计。因此，同一页面的不同表示形态——原始 HTML 还是清洗后的 Markdown——在语义上差别不大，但在 Token 数量上可能相差几十倍，这直接映射为账单金额和可处理的页面数量。理解这一点，是判断 RAG 流水线是否高效的前提。

四层形态的 Token 差距有多大

从总量看，20 个页面的原始 HTML 合计超过 371 万 Token，全页转文本降到约 24.3 万，仅正文 Markdown 约 11 万，LLM Markdown 进一步压到约 9.5 万。按中位页面算，原始 HTML 约 128,051 Token，全页文本约 10,917，仅正文约 3,241，LLM Markdown 约 2,948。

这意味着，仅「把 HTML 转成纯文本」这一步就能砍掉一个数量级的开销，而「正文抽取 + 清洗」又把剩余开销再压缩超过一半。

节省来自两段：正文抽取是主杠杆

拆开看，全部节省中的大头来自正文抽取——丢掉导航、页脚、Cookie 提示、推荐位——这部分单独就贡献了相对全页文本 51% 的中位节省。之后的额外清洗（去掉残留噪音、加上简短的来源头信息）再多贡献约 9%。这个拆解很关键：大部分收益其实来自任何靠谱的正文抽取器，而不是什么独门清洗技巧。

正文抽取与样板内容

网页通常由“正文”和“样板（boilerplate）”两部分构成。正文是用户真正想读的内容，如文章段落、菜谱步骤或法条条文；样板则是导航栏、面包屑、页脚链接、Cookie 同意横幅、广告位、相关推荐等在所有页面上重复出现的结构。正文抽取（main content extraction）就是自动识别并只保留正文、丢弃样板的过程。它并不等同于“去掉 HTML 标签”——后者只剥掉尖括号，菜单和页脚的文字仍然留在结果里。主流做法包括基于 DOM 密度与文本密度的启发式算法、Readability 类库，以及近年来用小型模型做语义判断的方案。抽取质量直接决定 Token 节省的上限，也影响检索质量：样板文本进入向量索引后，会与真正相关的内容竞争相似度分数。

页面类型决定节省幅度

节省比例的范围非常宽：相对全页文本，节省从 18% 到 90% 不等。门户页和概览页省得最多，长而干净的整篇文章省得最少。

页面类型	vs 原始 HTML	vs 全页文本
全部 20 页	98%	63%
起始页（6 个）	99%	64%
文章页（14 个）	98%	59%

具体到单个页面，德国消费者中心的指南页只省了 17.6%，而 Chefkoch 起始页省了 90.3%，Wikipedia 的 Big Data 条目省了 37.8%。一个中位数会掩盖这种差异，实际规划时要按区间来考虑。

省 Token 不只是省钱

按中位页面估算，全页文本约 10,900 Token，LLM Markdown 约 2,900 Token，每页每次传递省下约 8,000 输入 Token。按每百万输入 Token 约 1 美元的示意价格，相当于每 1,000 页每次传递省约 8 美元——RAG 流水线在嵌入阶段就要付一遍，Agent 每次把页面塞进上下文窗口又要再付一遍。

但成本只是一方面。更少的 Token 意味着上下文里的噪音更少，模型不用在无关内容里翻找；向量索引里与目标段落竞争的不相关文本也更少。对检索质量的影响可能比账单更值得关注。

分词器差异与 o200k_base

同一段文本在不同分词器下会得到不同的 Token 数。o200k_base 是 OpenAI 为 GPT-4o 系列引入的分词器，词表约 20 万，对多语言（尤其是非英语）文本的压缩效率明显优于早期的 cl100k_base。文章用 o200k_base 计数，因此绝对 Token 数会随模型切换而变化：换成词表更小的分词器，同一页面的 Token 数可能上升；换成对 HTML 更“友好”的分词器，原始 HTML 的膨胀幅度也可能不同。但研究反复表明，不同表示形态之间的相对比例远比绝对值稳定——原始 HTML 比清洗 Markdown 贵一到两个数量级这个结论，不会因为换分词器而反转。做预算时用比例做规划、用具体分词器做验收，是更稳妥的做法。

实测的边界与保留意见

作者本人是 Ragfeed 的创始人——一个兼容 Firecrawl、托管在德国的网页数据 API，上述四种变体正是用它生成的，「LLM Markdown」是其 llmMarkdown 格式。脚本、页面清单和原始数据都在 GitHub 上公开，可以自行复现，甚至换用其他兼容 Firecrawl 的 API 对比（--ohne-llm 参数）。

实验本身的局限也写得清楚：样本只有 20 个页面，且全是德语站点，英语站点可能不同；Token 计数基于 o200k_base（GPT-4o 的分词器），绝对值会随分词器变化，但比例变化小得多；页面会变，这是 2026 年 10 月 1 日的快照；「全页文本」是他们自己的整页 Markdown 转换，并非某个具体第三方工具；实验未对其他抽取服务或库做基准测试，比较的是页面表示形态而非产品。

最后一条提醒尤其重要：Token 数不等于答案质量。作者另外做过一个基于标题分块与固定长度分块的检索对比（58 个问题、一个嵌入模型），那是另一项规模更小的独立研究。

给 RAG 和 Agent 开发者的实操建议

永远不要把原始 HTML 直接丢给模型。 哪怕样本里最精简的页面（一段法条，1,265 Token 的 HTML）也损失了 72%。典型页面的 HTML 是 10 万到 50 万 Token，而真正的内容只有几千 Token——剩下全是脚本、内联样式、追踪代码和标签。

「转成文本」并不等于精简。 HTML 转文本去掉了标签，但菜单、页脚链接、Cookie 提示和推荐位一个不少，中位页面上这仍是实际内容 Token 的三倍多。

确认你的抽取器真的在做正文抽取。 每个工具都该检查它是否真的丢掉了样板内容，并抽查输出——切得太狠的抽取器比切得太少的更糟。

按页面类型规划预算，而非用单一中位数。 门户页和概览页收益最大，长而干净的文章收益最小，规划时用区间而不是均值。