AI爬虫的成本：来自 git.kernel.org 的教训

AI爬虫消耗了 git.kernel.org 20% 的 CPU 资源

AI爬虫在 git.kernel.org 上制造了持续的「背景辐射」式系统负载，永久占用了大量计算资源，只为生成专用于训练大型语言模型（LLMs）的数据。目前，在五个地理分布的节点（共90个核心）上，大约有14到16个核心被专门用于将 git 提交渲染为 HTML 以供爬虫抓取。这约占该站点总容量的20%。

HTML 抓取与 Git 克隆的效率对比

尽管存在高效的数据获取方法，AI爬虫却选择了最耗资源的方式。Linux 内核历史和 LKML 归档均可通过 git clone 获取——爬虫只需下载一次完整历史，然后在本地处理即可。然而，这些机器人却选择将每个提交都渲染为 HTML，再解析生成的页面。

这种低效行为因 URL 数量的组合爆炸而进一步加剧。在 linux.git 中约有 148 万个提交，以及 922 个分支，可用于提交、补丁、纯文本渲染和差异对比的有效 URL 数量达到数十亿。爬虫频繁访问这些数十亿个 URL，包括废弃分支中的链接，造成巨大的服务器负载，却无法获得独特数据。

机器人防御策略的演变

为阻止这些爬虫，防御措施经历了多个阶段的演进，随着机器人技术日益复杂而不断升级：

User-Agent 和 IP 封禁：最初尝试通过识别机器人自报的 User-Agent 或明显的数据中心 IP 范围（如 Google Compute Engine）进行封禁，但很快被绕过，因为机器人开始伪装成普通网页浏览器。
住宅代理网络：爬虫转向使用数百万个住宅和移动 IP，通常通过「代理 SDK 赚钱」模式，利用家用设备（如智能电视）充当代理。这使得基于 IP 的封禁失效，因为每个 IP 可能只发起几次请求后就消失。
工作量证明（PoW）挑战：为将抓取的经济成本转嫁给攻击者，git.kernel.org 实施了 Anubis，一种要求客户端在访问内容前解决数学难题（SHA-256）的系统。

工作量证明无法作为长期解决方案

尽管 Anubis 最初有效，但如今已演变为一场军备竞赛。系统目前每天处理约 600 万次随机提交请求；其中 66% 被挑战拦截，但仍有 33% 现在能解决数学问题并继续访问网站。

社区的技术分析表明，PoW 是不可持续的策略，因为计算成本存在不对称性。高性能爬虫能远比普通移动设备用户更高效地解决这些挑战。例如，iPhone 用户可能发现高难度挑战需数秒时间，且设备明显发热，而使用优化 C 内核或专用硬件的机器人可在毫秒内完成相同挑战。

社区洞察与替代方案

开发者和站点管理员之间的讨论表明，这并非仅影响 Linux 内核的问题，而是影响众多公共资源的系统性问题。

观察到的模式

定向爬取 vs. 通用爬取：有人认为，机器人并非专门针对 git 主机，而是在通用网络爬取中跟随所有可用链接，从而陷入由 git 网页界面的组合特性制造的「爬虫陷阱」。
合成数据风险：作者指出，像内核提交这类无 LLM 生成的数据极为珍贵，因为用 LLM 生成的内容训练 LLM 可能导致「数字朊病毒病」（模型崩溃）。

提出的技术缓解方案

客户端渲染：通过 JavaScript 将 HTML 渲染逻辑移至用户浏览器，使服务器仅作为扁平文件和差异的简单对象存储。
受控访问：对 HTML 视图要求认证，同时保持 git clone 无限制，或对未认证请求实施严格的速率限制。
延迟陷阱（Tarpitting）：实施类似 "ioicaine" 的陷阱，对检测到的机器人提供虚假数据或极慢响应，以浪费其资源。
货币化：从工作量证明转向微支付（如 L402），以覆盖实际使用的服务器资源成本。

当前状态与未来展望

git.kernel.org 目前正在减少匿名用户的可用功能，并关闭高成本特性以缓解负载。管理团队强调，尽管所有数据仍可下载，但用户访问时可能需要经历更多「障碍」。长期解决方案尚不明确，因为训练数据需求持续增长，而住宅代理网络基础设施也在不断扩展。