AI 爬蟲的成本：來自 git.kernel.org 的教訓

AI 抓取工具消耗了 git.kernel.org 20% 的 CPU 容量

AI 爬蟲在 git.kernel.org 上造成了持續的系統負載「背景輻射」，永久地佔用了大量的運算資源，而這些資源僅用於產生用於訓練大型語言模型 (LLMs) 的數據。目前，在總共 90 個核心的分佈式節點中，大約有 14 到 16 個核心僅用於將 git commit 渲染成 HTML 以供抓取工具使用。這代表了該網站總容量的約 20%。

HTML 抓取與 Git Clone 的效率差異

儘管有非常高效的數據獲取方法，但 AI 爬蟲卻選擇了最耗費資源的方式。雖然整個 Linux kernel 歷史和 LKML 存檔都可以透過 git clone 獲取——這允許抓取工具一次下載整個歷史記錄並在本地進行處理——但機器人卻是在將每個 commit 渲染成 HTML 並解析產生的頁面。

這種低效率因可用 URL 的組合爆炸而進一步加劇。在 linux.git 中約有 148 萬個 commit，加上 922 個 fork，使得 commit、patch、純渲染頁面和 diff 的有效 URL 數量達到數十億個。抓取工具經常針對這些數十億個 URL，包括那些在已廢棄的 fork 中，這在不提供任何獨特數據的情況下產生了巨大的伺服器負載。

機器人防禦策略的演進

隨著機器人變得越來越複雜，阻擋這些爬蟲的努力已演進至幾個階段：

User-Agent 與 IP 封鎖： 最初嘗試根據其自我聲明的 User-Agent 或明顯的數據中心 IP 範圍（例如 Google Compute Engine）來封鎖機器人，但隨著機器人開始偽裝成標準網頁瀏覽器，這些嘗試很快就被繞過。
住宅代理網路 (Residential Proxy Networks)： 爬蟲轉向使用數百萬個住宅和行動裝置 IP，這些 IP 通常透過「代理 SDK 變現」方案進行路由，例如使用家用電器（如智慧電視）作為代理。這使得基於 IP 的封鎖變得無效，因為每個 IP 可能在消失之前僅發出幾次請求。
工作量證明 (Proof-of-Work, PoW) 挑戰： 為了扭轉抓取行為的經濟成本，git.kernel.org 實施了 Anubis，這是一個工作量證明系統，要求客戶端在存取內容之前必須解決一個數學挑戰 (SHA-256)。

工作量證明作為永久解決方案的失敗

雖然 Anubis 最初很有效，但它已演變成一場軍備競賽。該系統目前每天處理約 600 萬個隨機 commit 的請求；其中 66% 被挑戰機制封鎖，但 33% 的機器人現在可以解決數學問題並繼續存取網站。

社群的技術分析指出，PoW 是一種不可持續的策略，因為運算成本是不對稱的。高功率的抓取工具可以比行動裝置上的合法用戶更有效率地解決這些挑戰。例如，一名 iPhone 用戶可能會發現高難度的挑戰需要花費數秒鐘並導致裝置發熱，而使用優化過的 C kernel 或專用硬體使用的機器人可以毫秒級別地解決相同的挑戰。

社群洞察與替代方案建議

開發者與網站管理員之間的討論顯示，這是一個影響許多公共資源的系統性問題，而不僅僅是 Linux kernel。

觀察到的模式

針對性抓取與一般性抓取： 有人認為機器人並非專門針對 git host，而是僅僅在一般性的網頁抓取中遵循每一個可用的連結，這導致它們進入了由 git web 介面組合特性所產生的「爬蟲陷阱」。
合成數據風險： 作者指出，不含 LLM 的數據（如 kernel commit）非常珍貴，因為在 LLM 生成的內容上訓練 LLM 可能會導致「數位普里昂病」（model collapse)。

建議的技術緩解措施

用戶端渲染 (Client-Side Rendering)： 透過 JavaScript 將 HTML 渲染邏輯移至用戶的瀏覽器，將伺服器轉變為僅存放扁平文件和 diff 的簡單對象存儲器。 -Gated Access (門控存取)： 要求 HTML 視圖的身份驗證，同時保持 git clone 不受限制，或者對未經身份驗證的請求實例施加嚴格的速率限制。
Tarpitting (陷阱設置)： 實施「ioicaine-style」陷阱，向被偵測到的機器人提供虛假數據或極慢的響應，以浪費他們的資源。
變現 (Monetization)： 從工作量證明轉向微支付 (例如 L402) 以支付使用伺服器資源的實際成本。

目前狀態與未來展望

git.kernel.org 目前正在減少匿名用戶的功能，並關閉昂貴的功能以減輕負載。管理層強調，雖然所有數據都仍然可以下載，但用戶可能會遇到更多「障礙」才能存取取。長期解決方案仍不明朗，因為對訓練數據的需求持續增長，且住宅代理網路的基礎設施正在擴張。