AI-scrapers slokken 20 procent van cpu-capaciteit Kernel.org op

Bij Kernel.org gaat inmiddels zo’n twintig procent van de cpu-capaciteit op aan het renderen van commits voor AI-scrapers. Dat vergt veel meer cpu-capaciteit dan andere vormen van legitieme toegang, waaronder Git-clones. Kernel.org ziet zich daardoor genoodzaakt om bepaalde functionaliteit uit te schakelen.

Git.kernel.org krijgt dagelijks zo'n 6 miljoen verzoeken voor individuele commitpagina's, schrijft Konstantin Ryabitsev, die bijdraagt aan de infrastructuur van Kernel.org. Daardoor zijn op elk moment 14 tot 16 cpu's alleen maar bezig met Git-commits omzetten naar HTML. In totaal heeft Kernel.org 90 cpu's, verspreid over vijf locaties.

Het probleem zit hem volgens Ryabitsev in hoe de scrapers door de geschiedenis van Linux heengaan. Een scraper kan alle repository's klonen en lokaal alle commits doorlopen. Maar in plaats daarvan vragen veel scrapers om één commitpagina per keer. Die pagina moet dan omgezet worden naar HTML, waarna de scraper om de volgende vraagt.

De algemene Linux-repository heeft nu zo'n 1,48 miljoen commits. Daarnaast zijn er zo'n 922 forks op git.kernel.org, met doorgaans diezelfde commits. Dat levert enkele miljarden valide URL's op die allemaal gescrapet kunnen worden, concludeert Ryabitsev. "Om vervolgens te eindigen met 922 duplicaten van dezelfde 1,48 miljoen commits." Daarnaast kunnen de scrapers om patches, diffs en platte tekst vragen, waardoor het aantal URL's nog verder toeneemt.

Weinig echte oplossingen

Kernel.org heeft op verschillende manieren geprobeerd het verkeer terug te dringen. Zo blokkeerde Kernel.org bepaalde IP-adressen en netwerken. Maar de scrapers stapten over op residentiële en mobiele proxynetwerken, waardoor dat minder effectief werd.

Kernel.org heeft ook Anubis ingezet, dat bezoekers een kleine uitdaging laat oplossen voor ze een site kunnen bezoeken. De scrapers wisten zich daar ook op aan te passen en een deel lost inmiddels ook moeilijkere uitdagingen op.

Kernel.org ziet zich nu genoodzaakt om bepaalde functies uit te zetten om het aantal crawlbare URL's te verminderen. Daarnaast worden kostbare acties beperkt voor anonieme gebruikers. "Maar we beloven dat al onze gegevens te downloaden blijven voor iedereen die daarom vraagt. Het kan alleen zijn dat je door meer hoepels moet springen om ze te bemachtigen", zegt Ryabitsev.

Activiteit van de cpu's van git.kernel.org. Bron: Konstantin Ryabitsev

Door Eveline Meijer

Nieuwsredacteur

31-08-2026 • 12:42

21

Submitter: Bedge85

Reacties (21)

Sorteer op:

Weergave:

Misschien meebewegen en een speciale "AI API" toevegen en daarnaar verwijzen in je llms.txt. Op die manier maak je het proces efficient voor de bots.

Voor de gewone API een stevige rate-limiter invoeren.

[Reactie gewijzigd door Keypunchie op 31 augustus 2026 12:50]

En dat is een gentlemen's agreement. Die scrapers gaan zich daar niet aan houden, al helemaal niet als je er een rate limiter op gaat zetten. Want dan gaat het te traag terwijl ze via de gewone website aan volle snelheid kunnen gaan.
Ik bedoel rate limiter op de gewone website (wat weinig invloed op mensen zou moeten hebben).

(overigens kan ik nu zelfs niet eens een standaard robots.txt vinden, maar misschien kijk ik op de verkeerde plek).

[Reactie gewijzigd door Keypunchie op 31 augustus 2026 13:03]

ipv alle pagina's constant te recoden naar html.. kun je ook gewoon alles van tevoren 1x baken, en dan alleen wanneer een commit erbij komt de relevante pagina's opnieuw doen, en voor al die requests kan je ze dan gewoon doorverwijzen naar de prebaked pagina.. hup, meeste CPU usage meteen weg
Een probleem is eigenlijk dat deze scrapers gewoon heel dom te werk gaan, want als ze echt efficient (en slim) te werken willen gaan kunnen ze gewoon de git repository clonen en daarop trainen.

Voor de oplossing die jij aanbied ga je er een beetje vanuit dat deze content scrapers zich netjes aan de regels in een llms.txt gaan houden. De groten in de industrie, zoals OpenAI en Antropic, zullen dit wel doen. Maar veel andere A.I cowboys gaan zich denk ik niet aan de instructies in een txt bestandje houden.
Als de groten het doen, zal dat al flink schelen is mijn gedachte. Het valt me wel op dat ik nu niet eens een robots.txt kan vinden. (Maar misschien kijk ik verkeerd).
Misschien moet je het bron artikel eerst eens lezen?
Ik lees dat ze manieren hebben geprobeerd om het te blokken. Mijn voorstel is om te kijken of je het niet kunt mitigeren door het naar een minder intensief proces te leiden.

Beetje aggresieve reactie, overigens, waarom?
Je zou denken dat je hier goed een cache voor kan inzetten, of oude data naar statische html renderen.
Cache gebruik je om bepaalde veelgevraagde content snel te kunnen leveren. Wanneer je je complete website in cache kun je eigenlijk niet meer van cache spreken. Waar jij misschien op doelt is pre-rendering waarbij je in dit geval vooraf de gehele git database al omzet naar statische HTML.
Dat is het probleem verschuiven. Kernel.org ziet dit niet als legitieme access, vooral als misbruik (want daar is de clone functionaliteit voor). Dit is vooral het crawler probleem aankaarten waarbij er een in feite amplification attacks voorkomen doordat de crawlers extreem "dom" zijn en vooral maximaal tokens will kauwen.
Bizar dat scrapers dit zo doen. Iedereen kan de git repo gewoon klonen en dan lokaal je ding doen. Scheelt je vrij veel tokens.
Jamaar die scrapers, die hebben die data nodig om te verkopen als .. tokens.
Maar nu verplaats je die CPU cycles dus naar de infra van kernel.org in plaats van dat je die lokaal moet doen. En als je tienduizenden repos scraped, begint dat op te tellen natuurlijk.
En zo helpt AI het eens zo vrije internet stilaan helemaal om zeep. De honger naar data is zo groot dat niemand ontzien wordt en alles maar gehamerd moet worden totdat men de functionaliteit begint uit te schakelen. Tegengaan is moeilijk, want de AI is vaak inventiever in het omzeilen van de tegenmaatregelen dan dat jij ze zelf kunt nemen en implementeren.

En terwijl AI heel het internet de dieperik in trekt, doen ze wel heel de tijd moeilijk als jij je eens niet aan de regels bij hen houdt. Zij mogen alles en wij hebben het maar te slikken.
Is er niet zoiets als een robots.txt voor AI tegenwoordig?
De mogelijke oplossing is bij een paar vrijwilligers (die gescreend zijn) alles opslaan en dat men dan via usb stick fysiek alles uitwisselt. Lekker ouderwets
offtopic:
Ah nu snap ik waar die cartoon character (blijkbaar Canadese Anubis) vandaan komt op best wel zeer serieuze websites. Vond het altijd al apart.

[Reactie gewijzigd door grasmanek94 op 31 augustus 2026 12:53]

Wat is dan hetgeen ze ermee te proberen te bereiken?
Misschien is dit ook wel de manier van tech-bedrijven die aansturen op een overname. Kernel.org, kan het niet meer aan dus in de verkoop om door te groeien.

Wat ik dan weer vreemd vind is fat zodra het gerenderd is, het blijkbaar uit de cache verdwijnt, waarom niet de .html opslaan dan heb je alleen de data en de bamdbreedte die je anders ook hebt naast het cpu gebruik.

Om te kunnen reageren moet je ingelogd zijn