6 millones de requests diarias y solo el 2% son humanos
Konstantin Ryabitsev, uno de los que mantiene git.kernel.org, soltó los números esta semana y son brutales. De los 90 cores distribuidos en 5 nodos geográficos que tiene la infraestructura del kernel de Linux, 14 a 16 cores están permanentemente ocupados renderizando commits para scrapers de IA. No para usuarios reales. No para desarrolladores. Para bots que están entrenando modelos.
Seis millones de requests diarias. Solo el 2% es tráfico legÃtimo. El resto son crawlers.
El método más bruto posible
Acá lo que me impressiona no es solo el volumen, sino la estupidez del método. git.kernel.org ofrece git clone. Puedes clonar todo el historial del kernel de Linux, LKML incluido, con un solo comando. Es la forma más eficiente de obtener los datos.
Pero los crawlers no hacen eso. En vez de clonar, recorren cada commit individualmente como HTML. linux.git tiene 1.48 millones de commits. Hay 922 forks en git.kernel.org. Los bots están pidiendo miles de millones de URLs para obtener 922 copias duplicadas de los mismos commits. Es como pedir un libro entero fotocopiando una página a la vez.
Y por qué lo hacen as� Porque los datos del kernel son pre-IA. Entrenar un LLM con contenido generado por otro LLM le da una especie de enfermedad priónica digital, asà que los commits del kernel, garantidamente escritos por humanos, valen oro para entrenamiento.
La guerra que ya perdieron
Ryabitsev cuenta cómo intentaron todo. Primero, identificar bots por user-agent y banearlos con fail2ban. Los bots cambiaron su user-agent a navegadores normales. Luego banearon por IP. Los bots se dispersaron a subredes enteras. Después detectaron que venÃan de Google Compute. Los bots empezaron a venir de residential proxies, SDKs de apps que venden tu conexión de casa a terceros.
Finalmente pusieron Anubis, un challenge que te pide calcular un hash SHA-256 con 4 ceros iniciales. Funcionó. Por unos meses. Los bots aprendieron a resolverlo. Subieron la dificultad a 5. Los bots también lo resolvieron. Hoy el 33% de las 6M requests diarias resuelven el challenge matemático y pasan al sitio.
Estamos hablando de crawlers que queman CPU calculando hashes solo para poder scrapear commits del kernel. La economÃa de esto tiene que ser absurda, pero claramente alguien está pagando lo suficiente para que valga la pena.
Lo que se viene
git.kernel.org va a empezar a desactivar funcionalidades para reducir las URLs crawleables. Acciones anónimas van a perder caracterÃsticas. Van a tener que saltar más hoops para acceder a los datos. Y me carga tener que decirlo, pero lo entiendo.
Como administrador de VPS, me toca lidiar con crawlers todos los dÃas. No a esta escala, claro, pero el patrón es el mismo. Bots que ignoran robots.txt, que rotan IPs, que se esconden detrás de proxies residenciales. Y la pregunta es siempre la misma: ¿hasta dónde quieres llegar para defender tu infraestructura antes de empezar a molestar a los usuarios reales?
Mi take
Esto no es un problema de kernel.org. Es un sÃntoma de algo más grande. Cada empresa que lanza un nuevo modelo de IA necesita datos de entrenamiento, y los datos gratuitos y accesibles se están acabando. Lo que queda es scrapear todo lo que encuentren, del modo más inefficiente posible, sin importar cuánta infraestructura ajena quemen en el proceso.
El año pasado todos celebramos que el open source era oro para entrenar IA. Hoy los mantenedores de la infraestructura que sostiene ese open source están pagando el costo. 14 cores de 90, permanentemente, para servir a bots que ni siquiera tienen la cortesÃa de hacer git clone.
Y lo peor: no hay solución simple. Mientras sigan saliendo empresas de IA nuevas todos los dÃas, todas hambrientas de datos, esto va a empeorar. La próxima vez que alguien te diga que la IA va a hacer todo más eficiente, acuerdate de esto: el 98% del tráfico de uno de los repositorios más importantes del mundo es basura automatizada.
Fuente de inspiración: Creepy crawlies — Konstantin Ryabitsev
