网页抓取计费模式：按 GB、按页面还是按 Request？

网页抓取的计费单位从未统一

Bright Data 的 Web Unlocker 按千次 request 计费。Oxylabs 的 Web Unblocker 按 GB 计费。Firecrawl 每页消耗 1 个 credit。Zyte 按千次成功 response 计费，划分为 5 个难度梯队。Apify 则按计算单元（CU）结算，即 1 GB 内存运行 1 小时。

5 家服务商，5 种计费单位。如果脱离你自己实际测算出的业务指标，这些单位之间根本无法直接换算。没有哪家供应商会公开这个换算数值，因为该数值取决于你自己的流量特征，而非他们的产品。

我们在 2026 年 9 月 8 日查阅了这 5 家服务商的定价页面。以下是具体定价以及实际换算后的真实成本。

快速对比

从这张表中可以明显看出两点。

首先，Zyte 自身的价格跨度就高达 124 倍。同一家供应商，相同的计费单位，同一张账单明细：通过 HTTP 获取简单站点是每千次 $0.13，而在浏览器中渲染复杂站点则是 $16.08。任何脱离场景单谈“每千次 request”的人，都只是在这个巨大区间中各取所需。

其次，Bright Data 在自身产品线中切换了计费单位。Web Unlocker 按 request 计费，而 Browser API 则按 GB 计费。这绝非疏忽，而是有意为之的关键信号，本文接下来的内容将深入解析背后的原因。

1 GB 流量究竟能买到什么

决定所有换算结果的关键指标，是你抓取页面的平均体积，而公开的统计数据非常残酷。

HTTP Archive 发布的 Web Almanac 2025 显示，截至 2025 年 7 月的抓取统计，移动端主页的中位数体积为 2,559 KB，年增幅 8.4%。拆解这一中位数页面的内容构成：911 KB 图片、632 KB JavaScript、122 KB 字体、77 KB CSS。

而 HTML 只有 22 KB。

最后一个数字才是核心所在，因为 HTML 文档通常是你唯一需要解析的内容。在中位数页面中，HTML 仅占完整浏览器渲染下载总字节数的 0.86%。其余 99% 都是你不得不付费传输的无用附带资源。

以 Oxylabs 的 8 GB 套餐（$9.40/GB）计算：

• 仅获取 HTML 时，按每页 22 KB 计算，1 GB 大约可抓取 45,000 页。折合每 1,000 页约 $0.21。
• 渲染完整页面时，按每页 2,559 KB 计算，1 GB 大约仅能抓取 390 页。折合每 1,000 页约 $24。

同样的套餐，同样标明的单价，仅仅因为代码中的一个设置项，成本就产生了 116 倍的差距。

现在将 Firecrawl 放在一起对比。按年付方案 100,000 点数 $83 计算，每页消耗 1 点，无论页面大小是 20 KB 还是 4 MB，每 1,000 页的成本固定为 $0.83。对比仅获取 HTML 的场景，按流量计费便宜约 4 倍；但对比完整渲染场景，按流量计费要贵出约 29 倍。

交叉点位于 100 KB 附近

通过简单的换算即可得出两种计费模式重合的具体页面大小。Firecrawl 每页 $0.00083 除以 Oxylabs 每 GB $9.40，得出 88 KB。如果将 Firecrawl 改为按月付费（同样的 100,000 点数为 $99.50），交叉点则变为 106 KB。低于这个区间，按流量计费更划算；高于这个区间，固定按页计费更优，且由于页面体积没有上限，两者的差距会迅速拉大。

这里有一个有趣的细节。Oxylabs 在没有明确提及换算的情况下公布了自己的预估：其 Web Unblocker 免费试用版被描述为 "1GB (up to 10k results)"。这相当于每个结果 100 KB，正好落入我们刚刚根据其他两家供应商价目表推导出的区间内。他们自己的测算也预设了你是在抓取文档，而不是在渲染图片库。

因此，如果你使用按流量计费且正在驱动浏览器运行，最大的优化杠杆并不是选择哪家供应商，而是在页面加载前拦截图片和字体。因为在网页中位数大小中，这两项就占了 2,559 KB 中的 1,033 KB。与其假装发票上的供应商 Logo 决定了账单，我们更倾向于直接指出这个技术事实。

两个需要说明的实际情况：首先，这些是全网的中位数数据，而你的目标网站并非全网平均水平（电商和旅游类页面通常更大，而 JSON endpoint 则小得多）。其次，拦截了媒体资源的渲染页面体积会远低于中位数，这会在无需更改定价方案的情况下使交叉点向对你更有利的方向移动。相同的计算逻辑同样决定了 LLM 提取步骤何时不再划算：表面单价从来不是关键指标，最终保留的有效记录单价才是。

计费触发条件是另一个维度

计费单位是一个问题，而触发计费的条件则是另一个更容易被忽视的问题。

Bright Data 为 Web Unlocker 宣传"仅按成功计费"；Zyte 定价为"每 1,000 次成功 response"；Firecrawl 则根据不同 endpoint 每次 API request 消耗固定点数。而在按流量计费模式下，完全没有成功状态的判定条件：只要产生了流量传输就会计费，你丢弃的验证码拦截页面，同样是你花钱买下的流量。

这比听起来更重要，因为质询或插页通常伴随着 HTTP 200 返回。如果你的成功定义仅看状态码，你的重试逻辑和账单就会与你的实际数据集产生冲突。我们在 Validate Rules Now Decide What Counts as Success 中讨论过这种脱节，也正是这种断层会导致部分封禁演变成 a silent hole in a time series。

谁应该购买哪种计费单位

按 GB 购买：如果你只是获取文档而非渲染页面，且目标以文本为主（如搜索结果、JSON endpoints、列表页、sitemaps）。在每页 20 到 50 KB 的情况下，按字节计费是市场上最便宜的方案，其他计费方式无法相比。

按页面或按请求购买：如果你需要渲染页面、目标网站包含大量媒体资源，或者你根本无法预测大量长尾网站的页面大小。你在小页面上支付了溢价，以换取大页面上的成本上限，而在渲染工作负载中，这个上限非常有价值。

按分级购买（如 Zyte 的销售模式）：如果你的目标组合很稳定，且清楚每个网站属于哪个分级。这种模式直面了其他计费方式刻意平均化的问题，即抓取难度高的网站成本更高。但如果你的目标列表每周都在变动，这种模式并不适用。

按计算单元购买：如果你在平台上使用自己的代码运行长时间爬取任务。该计量方式按机器计费，而不是按数据计费，因此解析速度快的代码会节省成本，解析速度慢的代码则会增加开销。这是本列表中唯一一种优化代码能直接体现在账单上的计费模式。

这些计费单位都不是陷阱。每一种都是供应商基于对其客户群体的了解，对典型流量特征所做的预设。真正的错误并不在于选错了计费单位，而在于直接对比两个计费单位不同的报价，并仅凭更低的数字草率做出决定。

无论是否有人提价，价格都会上涨

在接受包括我们在内的任何人的报价之前，先去测量自己一周流量中的两个指标：每次抓取的字节数，以及成功返回有效保留数据的抓取比例。一旦有了这两个数字，本文中的每个报价都可以清晰换算，缺少它们则无法计算。

然后观察下一年会发生什么。主页大小的中位数在十二个月内增长了 7.8%，这种增长趋势是单向的。如果你的账单以字节计费，这就相当于一项无需通知、也未经协商的年度隐性涨价。

在 FourA，我们在 response 中直接返回每次调用的成本，因此你可以在调用过程中实时了解换算情况，而无需在月底通过发票来重新推算。这不会直接告诉你该买哪种单位，但它会告诉你每保留一个有效页面实际花费了多少，而这正是所有讨论的核心所在。