git.kernel.org тратит 20% мощности на ИИ-краулеров вопреки Proof-of-Work-защите
Оператор git.kernel.org, площадки, через которую ведётся разработка ядра Linux, опубликовал разбор нагрузки от ИИ-краулеров на инфраструктуру. Главный вывод: процессорного времени на рендеринг коммитов в HTML для скрейперов уходит больше, чем на весь остальной легитимный доступ вместе взятый, включая обычные git clone. Из 90 ядер на 5 геораспределённых узлах 14, 16 постоянно заняты только рендерингом коммитов для ботов, в среднем это 20% всей вычислительной мощности площадки, при этом реальная нагрузка идёт волнами и превышает эту среднюю величину.
Причина интереса именно к этому сайту: история коммитов ядра Linux, гарантированно «чистый», человеческий текст, без следов текста, сгенерированного другими ИИ. Автор поясняет это метафорой: обучение модели на тексте, произведённом другой моделью, даёт эффект, аналогичный прионной болезни, поэтому источник, заведомо свободный от ИИ-контента, ценится на вес золота. Вместо того чтобы просто клонировать репозитории, единственный эффективный способ забрать всю историю разом, боты поштучно перебирают commit-страницы через веб-интерфейс cgit: у одного только linux.git 1,48 млн коммитов и 922 форка на git.kernel.org, а вместе с патчами, диффами и сравнениями произвольных коммитов число возможных URL для одного форка автор в шутку оценивает как «1,2 метрических биллиона».
Автор описывает эскалацию защиты примерно за год. Сначала банили IP по user-agent бота; когда боты начали маскироваться под обычные браузеры, стали банить по IP, затем по подсетям и целым ASN. Когда атаки пошли с миллионов случайных резидентных и мобильных адресов (по словам автора, из-за индустрии «монетизации прокси-SDK», в том числе через бытовые устройства вроде телевизоров), баны потеряли смысл: IP делал 4, 5 запросов и больше не появлялся. Тогда сайт поставил перед всем контентом Anubis, Proof-of-Work-защиту, которая заставляет клиента подобрать строку, дающую SHA-256-хэш с нужным числом ведущих нулей, прежде чем пройти дальше. Сначала это сработало: боты массово отступали. Через несколько месяцев боты научились решать сложность 4; сложность подняли до 5, решение стало занимать у мобильных устройств легитимных пользователей заметное время и ощутимо их греть, и через некоторое время боты подобрали решение и для неё.
На момент публикации git.kernel.org получает около 6 млн запросов в день на случайные коммиты. 66% из них отбивает вызов Anubis, но 33% решают задачу и проходят на сайт. По собственной, намеренно щедрой оценке автора, легитимным можно считать не более 2% всего трафика, остальное скрейперы. Сам сайт пока не падает от ботов (обычно проблемы создают криво настроенные CI-системы, которые делают shallow-clone одного и того же репозитория с десятков узлов одновременно), но команда уже отключает часть функций и сокращает число доступных URL, чтобы снизить нагрузку, предупреждая, что часть функциональности при анонимном доступе будет потеряна. При этом обещают сохранить возможность скачать весь массив данных всем, кто попросит, просто придётся пройти больше шагов, чем раньше.
Ключевые факты
- 14, 16 из 90 процессорных ядер на 5 геораспределённых узлах git.kernel.org постоянно заняты только рендерингом коммитов для ИИ-краулеров, в среднем 20% всей вычислительной мощности площадки.
- Из ~6 млн ежедневных запросов 66% отбивает Proof-of-Work-защита Anubis, но 33% решают задачу и проходят; по щедрой оценке автора легитимным можно считать не более 2% трафика.
- Боты не клонируют репозитории напрямую (что было бы эффективнее), а поштучно рендерят каждый из 1,48 млн коммитов linux.git и его 922 форков через веб-интерфейс cgit.
- Защита эскалировала от банов по user-agent и IP/ASN до Proof-of-Work-задачи Anubis сложности 5, и каждый раз боты через несколько месяцев учились её обходить.
- git.kernel.org отключает часть функций и сокращает число индексируемых URL, но обещает сохранить возможность скачать весь архив по запросу.
Почему это важно
Это редкий случай, когда жертва ИИ-краулинга приводит не оценочные жалобы, а измеренные цифры: конкретную долю процессорной мощности (в среднем 20%, до 14, 16 из 90 ядер), долю трафика и историю того, как боты раз за разом обходили каждую следующую меру защиты, от бана по user-agent до Proof-of-Work сложности 5. Это документирует гонку вооружений между открытой инфраструктурой и ИИ-скрейперами, съедающими её ресурсы ради обучающих данных, причём именно неэффективным способом (рендер HTML вместо git clone), который бьёт по инфраструктуре сильнее, чем по-нормальному скачивание тех же данных.
Кому это важно
Тем, кто держит открытую инфраструктуру с большим объёмом клонируемых или индексируемых данных: майнтейнерам git-хостингов, форумов, вики, архивов рассылок и других открытых источников, привлекательных для обучения ИИ-моделей. А также тем, кто занимается защитой от скрейпинга и оценивает эффективность Proof-of-Work-систем вроде Anubis, здесь показана конкретная динамика того, как быстро боты подбирают решение под растущую сложность.
Как это применить
Автор описывает пройденный путь как последовательность мер, каждая из которых работала временно: бан по user-agent → бан по IP → бан по подсети/ASN → Proof-of-Work (Anubis) с растущей сложностью → отключение части функций и сокращение числа доступных URL. Для тех, кто администрирует похожую инфраструктуру, это готовый список приёмов и честное предупреждение об их сроке годности: банить IP смысла нет, когда атака идёт с миллионов адресов, каждый из которых делает по 4, 5 запросов и исчезает; Proof-of-Work даёт отсрочку в несколько месяцев, а не постоянное решение.
Можно ли доверять
Это первичный источник, рассказ от лица оператора самого git.kernel.org, приводящего собственные измерения (число ядер, доля трафика, история сложности Anubis). Цифры не проходили независимый аудит, а сам автор прямо оговаривает: оценка «легитимного трафика в ~2%» построена на «щедрых допущениях», то есть это внутренняя прикидка, а не строгий замер; отличить бота от человека по логам «невозможно с уверенностью», это тоже прямая оговорка автора, а не точный критерий.
Риски и подводные камни
Гонка вооружений выглядит открытой: боты уже дважды подбирали решение под возросшую сложность Anubis, и нет гарантии, что сложность нельзя поднимать бесконечно, рост сложности одновременно нагружает мобильные устройства обычных пользователей (заметное время ожидания и нагрев телефона). Ответные меры, отключение функций и сокращение доступных URL, снижают открытость и удобство площадки для реальных разработчиков, то есть у защиты есть цена и для легитимной аудитории, а не только для ботов.
«Обучение ИИ-модели на тексте, сгенерированном другой моделью, даёт ей эффект, эквивалентный цифровой прионной болезни.»
— оператор git.kernel.org