Python-pakkeinstallasjoner som et indeks for lokal AI-tilpasning

Den vanskelige å kvantifisere økningen i nedlastinger av Python-pakker forteller historien om AI-diffusjon, hvis du vet hvor du skal se.

Meninger Alle som har utforsket potensialet for lokal AI vil nå ha tapt en skremmende mengde diskplass, ikke bare til de gargantuelle modellene, men også til de relaterte Python– og lignende systemer som orkestrerer inferens, trening og hundrevis av andre potensielle bruksområder – ikke minst i generering av lokale automatiseringssystemer.

Dette siste bruksområdet er det vanligste på de forskjellige maskinene på mitt lokale nettverk, der jeg har brukt AI til å sette opp “flate” Python-baserte automatiseringsrutiner, som backup, periodiske sjekker, administrasjon av min nettside og et dusin andre bruksområder.

Praktisk talt alt jeg ønsker å oppnå under disse kodeøktene synes å kreve en ny Python-bibliotek, i slik en grad at PIP (Package Installer for Python) er en av de største plasshoggerne på mine lokale nettverksmaskiner:

PIP’s beskjedne tilstedeværelse i CLI og GUIer skjuler dens påvirkning på filsystemet. Cachen kan nå meget høye, til og med system-kvelende filstørrelser.

Eksperimentering med lokal AI reverser den betydelige overflødig luksus av lokale datamaskiner, før AI-hardware-grabben i denne æraen. Hvis du hadde en generøs RAM-tilgang, vil den bli spist opp i GPU-offloading; en terabyte harddiskplass, likaledes, vil raskt fylles opp med høyvolumsmodeller, kvantisert eller ikke; og selv om, som jeg gjorde, du har utstyrt deg med 24 GB VRAM (en ny minimum..?), vil systemet likevel trenge en rekke snarveier og triks for å kjøre inferens på rimelige tidsrammer.

Installerte PyPi-pakker (Python Package Index) vises ikke i standard “Installerte programmer”-GUIer i et vanlig operativsystem, og må hentes eksplisitt, via Python, for eksempel med PowerShell-kommandoen pip freeze --all.

Listen kan være overraskende lang:

En dump av PyPi-installasjoner på en av mine travle maskiner. Noen av disse små ordene skjuler gigabyte med diskplass – særlig noe som er relatert til Torch/PyTorch.

Kort sagt, lokal AI kan ta din datamaskin-erfaring tilbake til tidlig på 1990-tallet, bare litt etter perioden hvor et program som Word måtte lastes inn i noen få KB RAM, en stor floppy-disk om gangen; men før harddisk-allokasjoner ga deg noen plass å puste.

Å finne understrømmene

Jeg lurte på om en økning i PyPi-installasjoner de siste årene kunne tjene som et indeks for lokal AI-tilpasning, som generelt er ganske vanskelig å spore, bortsett fra gjennom intuisjon når man deltar i ulike AI-samfunn og merker hvilke plattformer og pakker som får oppmerksomhet.

En uformell gjennomgang av PyPi-stats-nettstedet viser en skuffende smal rekke med datoer, alle av dem indikerer likevel konstant oppadgående vekst i nedlastinger:

Økning i nedlastinger over alle Python-pakker siden starten av 2026 – selv om rekken med datoer er svært smal. Kilde

Det ville være fantastisk å utvide denne datorekken til 2020 og se om økningen forblir konstant, eller (som en kunne mistenke), øker mer skarpt 2024-26 – hvis ikke bare for de uledede handlingene til agente AI-systemer.

Dessverre sier offisielle PyPi-kilder at nedlastningsstatistikk for PyPi ikke er tilgjengelig, av ulike årsaker, inkludert CDN-cachekostnader, uakkurate nedlastningstall forårsaket av cacher, speil, uoffisielle nedlastningsinflasjon og historiske datakvalitetsproblemer – og ifølge Python-nettstedet, deres begrensede nytte som et mål på en pakkes kvalitet.

Ikke så raskt

Men PyPi gir ut komponentene nødvendige for andre å analysere nedlastningstrender; det finnes derfor diverse nettsteder som tillater mer enn en måneds rekke, som PepySite – men de fleste er abonnementsbasert, og du må betale for å se lengre rekke trender og statistikk (opptil $490 USD per måned i ett tilfelle, for ‘VC’-pakken).

Er det noe vi kan lære, da, om Python som et indeks for AI-akselerasjon, bort fra de dyre API-ene som legger ut disse trendene for de velstående?

Selv om PyPiStats er en FOSS-resurs, tilbyr den av noen grunn kun den siste månedens statistikk, og denne rekken kan ikke utvides, selv ikke mot betaling.

Fortuignet er ett nettsted mer generøst – på ClickPy kan du i alle fall søke etter adopsjonshistorien til enkelt-pakker, selv om summen av disse ikke er orkestrert i en oversikt som lett avslører bredere, koordinerte trender. Her, for eksempel, er passasjen til Transformers-biblioteket siden 2016 (selv om bare gyldig siden lanseringen i 2019):

Den meteorske oppstigningen til transformers. Kilde

Hva med den venerable Torch, først lansert i 2002, men ikke bestemt til å plage hjemme-bryggede AI-entusiaster før utviklingen til PyTorch, og oppblomstringen av Transformer-basert VLM og generativ AI relatert til bilder og videoer..?

Torch-nedlastinger siden 2017, med en bratt oppadgående kurve de siste 2-3 årene.

PyTorch over samme periode, med en platå og noen ganger en spik over en stabil basis.

Mer interessant, for eksempel i tilfelle PyTorch (se bildet rett over), er oversikten over adopsjon over diverse Python-versjoner siden 2017:

Nedlastinger av PyTorch over tid siden 2017, etter Python-versjon, og gir en ekstra dimensjon av innsikt i oppakning siden ‘het’-æraen i denne tredje AI-revolusjonen.

Hvis statistikkene ovenfor belyser oppblomstringen i oppakning siden oppkomsten av virkelig kapable LLM- og VLM-systemer, blir dette enda mer tydelig når sett etter system:

Adopsjon av PyTorch siden 2017, tolket etter operativsystem.

Det er en lignende historie for accelerate-pakken – en av de mest nødvendige bibliotekene for VRAM-sultne AI-brukere som søker å presse så mye som mulig ut av systemets begrensninger:

Oppstigningen til ‘accelerate’, etter operativsystem.

Slik går det for en rekke pakker eller biblioteker du forsker på ClickPy, og det ville være interessant å lage en oversikt i stedet for å se på delene ett og ett.

En ting som blir tydelig fra ‘etter operativsystem’-grafene er økningen i Linux-tilpasning. Mens Linux-skrivebords-tilpasning gjør en stabil, men langsom økning i møte med upopulære Windows-strategier, er bruken av Linux-miljøer tydelig i en betydelig oppstigning.

For eksempel kjører jeg Ubuntu virtuelt på WSL2 i Windows for diverse Docker-containere, hvor Docker kan utnytte et ekte Linux-system på samme vilkår som (antageligvis Linux-native) utviklerne tenkte. Det er to aktive Linux-systemer i et helt Windows-basert nettverk (sett fra maskinens perspektiv), med en naturlig Linux-laptop som venter ubrukt i vingen for mer avslappede tider.

Konklusjon

I forhold til CLI-basert pakke-nedlasting er det interessant å merke hvordan ivrig og ettertraktet dette svært geeky rommet har blitt i kjølvannet av AI.

Økningen i pakke-forbruk begynner å bli en sikkerhetsfare nedover, med oppkomsten av slopsquatting. Ettersom LLM-er er utsatt for å hallucinere pakker, er de sannsynlig til å sende forespørsler om oppfunnet pakker. På grunn av likhet i konvergens, er de falske pakkene sannsynlig til å gjenta seg i andre bibliotek-kall, til den grad at det er verdifullt for dårlige aktører å faktisk gjøre de falske pakkene tilgjengelige for fremtidige trekk/call – selvfølgelig, med en skadelig nyttelast:

Fra artikkelen ‘We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs’ – AI-drevet kodegenerering utvider angrepsflaten for leverandørkjeden. LLM-er hallucinerer ofte ikke-eksisterende pakkenavn, og skaper ‘slopsquatting’-sårbarheter som dårlige aktører utnytter når automatiserte rørledninger blindt trekker uverifiserte avhengigheter. Kilde

Først publisert fredag, 24. juli 2026