Andersons vinkel
Python-paketinstallationer som ett index för lokal AI-adoption

Den svårmätbara ökningen av paketnedladdningar för Python berättar historien om AI-diffusion, om man vet var man ska leta.
Åsikt Alla som har utforskat potentialen för lokal AI har vid det här laget förlorat en skrämmande mängd diskutrymme, inte bara till de jättelika modellerna som är inblandade, utan också till de relaterade Python– och liknande system som orkestrerar inferens, utbildning och hundratals andra möjliga användningsområden – inte minst för att generera lokala automatiseringssystem.
Denna sista användningsfall är den vanligaste över olika maskiner på mitt LAN, där jag har använt AI för att ställa in “platta” Python-baserade automatiserade rutiner, såsom säkerhetskopiering, periodiska kontroller, administration av min webbplats och ett dussin andra användningsområden.
Praktiskt taget allt jag vill uppnå under dessa kodningssessioner verkar kräva ett nytt Python-bibliotek, så till den grad att PIP (Package Installer for Python) är en av de största utrymmeskrävarna på mina LAN-maskiner:

PIP:s ringa närvaro i CLI och GUI förminskar dess inverkan på din filsystem. Cachen kan nå mycket höga, till och med system-krypande filstorlekar.
Att experimentera med lokal AI vänder den betydande överflödiga lyxen av lokala datorer, före AI-hårdvarugreppet i den nuvarande eran. Om du hade en generös RAM-tilldelning, kommer den att ätas upp i GPU-offloading; en terabyte hårddiskutrymme, likaså, kommer snabbt att fyllas med högvolymmodeller, kvantifierade eller inte; och även om, som jag gjorde, du har utrustat dig med 24 GB VRAM (ett nytt minimum…), kommer systemet fortfarande att behöva en mängd genvägar och tricks för att köra inferens inom rimliga tidsramar.
Installerade PyPi-paket (Python Package Index) syns inte i standard-“Installerade program”-gränssnitt i ett vanligt operativsystem och måste uttryckligen framkallas via Python, till exempel med PowerShell-kommandot pip freeze --all.
Listan kan vara förvånansvärt lång:
| Paket | Version | Paket | Version | Paket | Version |
|---|---|---|---|---|---|
| absl-py | 2.3.0 | Jinja2 | 3.1.4 | pip | 25.1.1 |
| attrs | 25.3.0 | jsonpatch | 1.33 | platformdirs | 4.3.8 |
| beets | 2.5.1 | jsonpointer | 3.0.0 | protobuf | 4.25.8 |
| certifi | 2025.11.12 | kiwisolver | 1.4.8 | psutil | 7.2.1 |
| cffi | 1.17.1 | lap | 0.5.12 | pybrisque | 1.0 |
| charset-normalizer | 3.4.4 | lazy_loader | 0.4 | pycparser | 2.22 |
| click | 8.2.1 | libsvm | 3.23.0.4 | pyparsing | 3.2.3 |
| colorama | 0.4.6 | Markdown | 3.8.2 | python-dateutil | 2.9.0.post0 |
| confuse | 2.1.0 | MarkupSafe | 2.1.5 | PyYAML | 6.0.2 |
| contourpy | 1.3.2 | matplotlib | 3.10.3 | pyyaml_env_tag | 1.1 |
| cycler | 0.12.1 | mediafile | 0.13.0 | requests | 2.32.5 |
| dlib | 20.0.0 | mediapipe | 0.10.21 | scikit-image | 0.25.2 |
| face-recognition | 1.3.0 | mergedeep | 1.3.4 | scipy | 1.16.0 |
| face_recognition_models | 0.3.0 | mkdocs | 1.6.1 | sentencepiece | 0.2.0 |
| filelock | 3.13.1 | mkdocs-get-deps | 0.2.0 | setuptools | 65.5.0 |
| filetype | 1.2.0 | ml_dtypes | 0.5.1 | six | 1.17.0 |
| flatbuffers | 25.2.10 | mpmath | 1.3.0 | sounddevice | 0.5.2 |
| fonttools | 4.58.4 | musicbrainzngs | 0.7.1 | sympy | 1.13.1 |
| fsspec | 2024.6.1 | mutagen | 1.47.0 | tifffile | 2025.6.11 |
| ghp-import | 2.1.0 | networkx | 3.3 | torch | 2.5.1+cu118 |
| idna | 3.11 | numpy | 2.1.2 | torchvision | 0.20.1+cu118 |
| image-quality | 1.2.7 | opencv-contrib-python | 4.11.0.86 | tqdm | 4.67.1 |
| imageio | 2.37.0 | opencv-python | 4.11.0.86 | typing_extensions | 4.12.2 |
| internetarchive | 5.7.1 | opt_einsum | 3.4.0 | Unidecode | 1.4.0 |
| jax | 0.6.2 | packaging | 25.0 | urllib3 | 2.6.2 |
| jaxlib | 0.6.2 | pathspec | 0.12.1 | watchdog | 6.0.0 |
| jellyfish | 1.2.1 | pillow | 11.0.0 |
En dump av PyPi-installationer på en av mina mer aktiva maskiner. Några av dessa små ord döljer gigabyte av diskutrymme – särskilt allt som är relaterat till Torch/PyTorch.
I korthet kan lokal AI ta din datorupplevelse tillbaka till början av 1990-talet, strax efter den period då ett program som Word måste laddas in i några kilobyte RAM, en stor floppydisk i taget; men innan hårddisktilldelningar gav dig något utrymme att andas.
Att hitta underströmmarna
Jag var nyfiken på om en uppgång i PyPi-installationer under de senaste åren kunde tjäna som en indikator för lokal AI-adoption, som i allmänhet är ganska svår att spåra, förutom genom intuition när man deltar i olika AI-samhällen och noterar vilka plattformar och paket som får uppmärksamhet.
En tillfällig blick på PyPi-statswebbplatsen visar en besvikande smal datointerval, alla av vilka dock indikerar konstant tillväxt i nedladdningar:

Ökning av nedladdningar över alla Python-paket sedan början av 2026 – även om datointervallet är mycket smalt. Källa
Det vore underbart att utöka det datointervallet till 2020 och se om ökningen förblir konstant, eller (som man kan misstänka), ökar mer kraftigt 2024-26 – om inte annat för de oövervakade handlingarna av agentic AI-system.
Tyvärr anger officiella PyPi-källor att nedladdningsstatistik för PyPi inte är tillgänglig, av olika skäl, inklusive CDN-cachekostnader, ofullständiga nedladdningsräkningar orsakade av cacher, speglar, obehöriga nedladdningar och historiska datakvalitetsproblem – och enligt Python-webbplatsen, deras begränsade användbarhet som en måttstock på ett pakets kvalitet.
Inte så fort
Men PyPi ger ut komponenterna som behövs för andra att analysera nedladdningstrender; det finns därför olika webbplatser som tillåter mer än en månads intervall, som till exempel PepySite – men de flesta är prenumerationsbaserade, och du måste betala för att se de längre trenderna och statistiken (upp till $490 USD per månad i ett fall, för “VC”-paketet).
Finns det något som vi kan utläsa, då, om Python som en indikator för AI-acceleration, bortom de dyra API:erna som lägger ut dessa trender för de välbärgade?
Även om PyPiStats är en FOSS-resurs, erbjuder den av någon anledning endast den senaste månadens statistik, och detta intervall kan inte utökas, inte ens för betalning.
Luckligtvis är en webbplats mer generös – på ClickPy kan man åtminstone söka efter antagandehistoriken för enskilda paket, även om summan av dessa inte är orkestrerad i en översikt som lätt ger breda, samordnade trender. Här, till exempel, är passagen av Transformers-biblioteket sedan 2016 (även om det bara är giltigt sedan lanseringen 2019):

Transformatorernas meteoriska uppgång. Källa
Vad gäller det ärevördiga Torch, först släppt 2002, men inte destinerat att plåga hemmabryggda AI-entusiaster förrän dess utveckling till PyTorch, och uppgången av Transformer-baserade VLM och generativ AI relaterad till bilder och videor..?

Torch-nedladdningar sedan 2017, med en brant uppgång under de senaste 2-3 åren.

PyTorch under samma period, med en platå och sedan en topp ibland över en stabil bas.
Mer intressant, till exempel i fallet med PyTorch (se bilden direkt ovan), är översikten av antagande över olika Python-versioner sedan 2017:

PyTorch-nedladdningar över tid sedan 2017, per Python-version, och ger en extra dimension av insikt i antagandet sedan den ‘heta’ eran av denna tredje AI-revolution.
Om statistiken ovan belyser uppgången i antagande sedan uppkomsten av riktigt kapabla LLM- och VLM-system, blir detta ännu tydligare när det ses per system:

PyTorch-antagande sedan 2017, tolkat per operativsystem.
Det är en liknande historia för accelerate-paketet – ett av de mest krävda biblioteken för VRAM-utsatta AI-användare som försöker få ut så mycket som möjligt av systemets begränsningar:

Accelerates uppgång, per operativsystem.
Sådant gäller för vilket paket eller bibliotek som helst som man undersöker på ClickPy, och det vore verkligen intressant att skapa en översikt istället för att titta på bitarna en och en.
En sak som blir tydlig från “per operativsystem”-graferna är ökningen av Linux-antagande. Medan Linux-skrivbordsantagande gör en stadig men långsam ökning inför omtyckta Windows-strategier, är användningen av Linux-miljöer tydligt i en betydande uppgång.
Till exempel kör jag Ubuntu virtualiserat på WSL2 i Windows för olika Docker-containrar, där Docker kan utnyttja ett riktigt Linux-system på samma villkor som (förmodligen Linux-nativa) utvecklare avsett. Det är två aktiva Linux-system i ett helt Windows-baserat LAN (från den obebyggda metallens synvinkel), med en inbyggd Linux-laptop som väntar oanvänd i vingen för mer avslappnade tider.
Slutsats
När det gäller CLI-baserade paketnedladdningar är det intressant att notera hur angeläget och eftertraktat detta mycket nördiga utrymme har blivit i kölvattnet av AI.
Ökningen av paketkonsumtion börjar bli en säkerhetsrisk nedströms, med uppkomsten av slopsquatting. Eftersom LLM är benägna att hallucinera paket, är de troligen att skicka förfrågningar om uppfunna paket. På grund av likhet i konvergens är de falska paketen troligen att återkomma i andra bibliotekssamtal, till den grad att det är värt för illvilliga aktörer att faktiskt göra de falska paketen tillgängliga för framtida drag/call – naturligtvis med en skadlig nyttolast:

Från artikeln ‘We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs’ – AI-driven kodgenerering utvidgar leverantörskedjeattackytan. LLM hallucinerar ofta icke-existerande paketnamn, skapar ‘slopsquatting’-sårbarheter som illvilliga aktörer utnyttjar när automatiserade pipelines blint drar overifierade beroenden. Källa
Publicerad första gången fredagen den 24 juli 2026












