Andersonin kulma
Python-pakettien asennukset paikallisen tekoälyn käyttöönoton mittarina
Lisää Unite.AI suosikkilähteisiisi Google-palvelussa
Python-pakettien latausmäärien vaikeasti mitattava kasvu kertoo tekoälyn leviämisestä, kun tietää, mistä etsiä.
Mielipide Jokainen paikallisen tekoälyn mahdollisuuksia kokeillut on jo menettänyt pelottavan paljon levytilaa. Sitä vievät paitsi valtavat mallit myös niihin liittyvä Python ja vastaavat järjestelmät, jotka ohjaavat päättelyä, koulutusta ja satoja muita käyttötapoja — muun muassa paikallisten automaatiojärjestelmien luomista.
Tämä viimeinen käyttötapa on yleisin lähiverkkoni eri koneissa. Olen käyttänyt tekoälyä yksinkertaisten Python-pohjaisten automaatioiden rakentamiseen esimerkiksi varmuuskopiointia, määräaikaistarkistuksia, verkkosivustoni ylläpitoa ja kymmeniä muita tehtäviä varten.
Lähes kaikki, mitä näissä ohjelmointi-istunnoissa haluan tehdä, näyttää edellyttävän uutta Python-kirjastoa. Siksi PIP eli Pythonin pakettiasennin on yksi lähiverkkoni koneiden suurimmista tilansyöjistä.
PIP näyttää komentorivillä ja graafisissa käyttöliittymissä pieneltä, mutta sen vaikutus tiedostojärjestelmään on suuri. Välimuisti voi kasvaa erittäin suureksi ja jopa lamauttaa järjestelmän.
Paikallisen tekoälyn kokeileminen kääntää päälaelleen tietokoneiden aiemman yltäkylläisyyden, joka vallitsi ennen nykyistä tekoälylaitteiston kysyntäaaltoa. Runsas RAM-muisti kuluu laskennan siirtämiseen näytönohjaimelle; teratavun levytila täyttyy nopeasti suurista malleista, olivatpa ne kvantisoituja tai eivät; ja jopa 24 gigatavua VRAM-muistia, joka näyttää uudelta vähimmäistasolta, vaatii edelleen oikoteitä ja niksejä, jotta päättely valmistuu kohtuullisessa ajassa.
Asennetut PyPI-paketit (Python Package Index) eivät näy tavallisten käyttöjärjestelmien ”Asennetut ohjelmat” -näkymissä. Ne on pyydettävä erikseen Pythonin kautta, esimerkiksi PowerShell-komennolla pip freeze --all.
Luettelosta voi tulla yllättävän pitkä:
| Paketti | Versio | Paketti | Versio | Paketti | Versio |
|---|---|---|---|---|---|
| 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 |
Otos yhden vilkkaammin käytetyn koneeni PyPI-asennuksista. Joidenkin lyhyiden nimien taakse kätkeytyy gigatavuja levytilaa, erityisesti Torch- ja PyTorch-pakettien kohdalla.
Paikallinen tekoäly voi siis palauttaa tietokoneen käyttökokemuksen 1990-luvun alkuun: hieman sen ajan jälkeen, jolloin Wordin kaltainen ohjelma ladattiin muutamaan kilotavuun RAM-muistia suurelta levykkeeltä pala kerrallaan, mutta ennen kuin kiintolevytila alkoi tarjota hengähdysvaraa.
Pintaa syvemmällä olevien trendien etsiminen
Halusin selvittää, voisiko PyPI-asennusten viime vuosien voimakas kasvu toimia paikallisen tekoälyn käyttöönoton mittarina. Kehitystä on yleensä vaikea seurata muuten kuin osallistumalla eri tekoäly-yhteisöihin ja tarkkailemalla, mitkä alustat ja paketit saavat suosiota.
Nopea vilkaisu PyPI:n tilastosivustoon näyttää valitettavan lyhyen ajanjakson, mutta siinäkin latausmäärät kasvavat tasaisesti.
Kaikkien Python-pakettien latausmäärät ovat kasvaneet vuoden 2026 alusta, vaikka saatavilla oleva ajanjakso on hyvin lyhyt. Lähde
Olisi hyödyllistä ulottaa aikaväli vuoteen 2020 ja nähdä, pysyikö kasvu tasaisena vai kiihtyikö se — kuten voisi olettaa — vuosina 2024–2026, jo pelkästään agenttitekoälyjärjestelmien valvomattomien toimien vuoksi.
PyPI:n virallisissa ohjeissa kuitenkin todetaan, ettei lataustilastoja julkaista useista syistä. Näitä ovat CDN-välimuistien kuormitus, välimuistien ja peilipalvelinten aiheuttamat epätarkat latausmäärät, epävirallinen latausten paisuttaminen ja historiallisten tietojen laatuongelmat. Pythonin sivuston mukaan latausmäärät kertovat myös rajallisesti paketin laadusta.
Ei niin nopeasti
PyPI tarjoaa silti tarvittavat rakennuspalikat, jotta muut voivat analysoida lataustrendejä. PepySiten kaltaiset palvelut näyttävät yli kuukauden mittaisia jaksoja, mutta useimmat toimivat tilausmaksulla. Pitkän aikavälin trendit ja tilastot voivat maksaa yhdessä palvelussa jopa 490 dollaria kuukaudessa ”VC”-paketilla.
Voiko Pythonista siis päätellä jotakin tekoälyn kiihtymisen mittarina ilman kalliita API-rajapintoja, jotka esittävät trendit vain maksukykyisille käyttäjille?
PyPIStats on avoimen lähdekoodin resurssi, mutta se tarjoaa jostain syystä vain viimeisimmän kuukauden tilastot, eikä ajanjaksoa voi pidentää edes maksamalla.
Onneksi yksi sivusto on anteliaampi. ClickPy antaa tarkastella yksittäisten pakettien käyttöönoton historiaa, vaikka niitä ei yhdistetä yleiskuvaksi, josta laajemmat ja toisiinsa liittyvät trendit näkyisivät helposti. Esimerkiksi Transformers-kirjaston kehitys voidaan näyttää vuodesta 2016, vaikka aineisto on varsinaisesti merkityksellistä vasta sen vuoden 2019 julkaisusta alkaen.
Transformers-paketin suosion jyrkkä kasvu. Lähde
Entä kunnianarvoisa Torch, joka julkaistiin ensimmäisen kerran vuonna 2002? Vasta sen kehittyminen PyTorchiksi sekä Transformereihin perustuvien VLM-mallien ja kuva- ja videogenerointiin liittyvän tekoälyn nousu tekivät siitä kotitekoisen tekoälyn harrastajien riesan.
Torchin latausmäärät vuodesta 2017; viimeiset kaksi–kolme vuotta näyttävät jyrkkää kasvua.
PyTorch samalla ajanjaksolla: tasaantumisia ja piikkejä vakaan perustason päällä.
PyTorchin tapauksessa erityisen kiinnostava on käyttöönoton jakauma eri Python-versioiden välillä vuodesta 2017 lähtien.
PyTorchin lataukset Python-version mukaan vuodesta 2017 tarjoavat lisänäkökulman käyttöönottoon tämän kolmannen tekoälyvallankumouksen kuumimmasta vaiheesta lähtien.
Jos edellä olevat tilastot valaisevat käyttöönoton kasvua todella kyvykkäiden LLM- ja VLM-järjestelmien tulon jälkeen, käyttöjärjestelmäkohtainen näkymä tekee kehityksestä vielä selvemmän.
PyTorchin käyttöönotto vuodesta 2017 käyttöjärjestelmän mukaan.
Sama kehitys näkyy accelerate-paketissa, joka on yksi yleisimmin tarvituista kirjastoista VRAM-muistin puutteesta kärsiville tekoälyn käyttäjille heidän yrittäessään saada järjestelmiensä rajoista kaiken irti.
accelerate-paketin käytön kasvu käyttöjärjestelmän mukaan.
Sama tarina toistuu lukuisissa ClickPyssä tutkituissa paketeissa ja kirjastoissa. Olisi kiinnostavaa muodostaa kokonaiskuva sen sijaan, että osat etsittäisiin yksi kerrallaan.
Käyttöjärjestelmäkohtaiset kaaviot paljastavat muun muassa Linuxin käytön kasvun. Linuxin työpöytäkäyttö lisääntyy tasaisesti mutta hitaasti, ja epäsuositut Windows-ratkaisut vauhdittavat kehitystä. Linux-ympäristöjen käyttö puolestaan kasvaa selvästi nopeammin.
Esimerkiksi ajan Ubuntu-järjestelmää virtualisoituna Windowsin WSL2:ssa erilaisia Docker-säilöjä varten. Docker voi näin käyttää aitoa Linux-järjestelmää kehittäjien tarkoittamilla ehdoilla. Fyysisen laitteiston näkökulmasta täysin Windows-pohjaisessa lähiverkossani toimii siis kaksi aktiivista Linux-järjestelmää, ja natiivia Linuxia käyttävä kannettava odottaa irrotettuna rauhallisempia aikoja.
Johtopäätös
Komentoriviltä ladattavien pakettien kohdalla on kiinnostavaa nähdä, kuinka innokkaasti tämä hyvin tekninen alue on kasvanut tekoälyn seurauksena.
Pakettien käytön kasvu alkaa muodostaa turvallisuusriskin toimitusketjun myöhemmissä vaiheissa slopsquattingin yleistyessä. LLM-mallit keksivät helposti olemattomia pakettien nimiä ja voivat lähettää niistä todellisia latauspyyntöjä. Koska samankaltaiset nimet voivat toistua muissa kirjastokutsuissa, rikollisten kannattaa julkaista väärennettyjä paketteja haitallisine hyötykuormineen tulevia latauksia varten.
Tutkimuksesta ”We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs”. Tekoälypohjainen koodintuotanto laajentaa toimitusketjun hyökkäyspintaa. LLM-mallit keksivät usein olemattomia pakettinimiä ja synnyttävät slopsquatting-haavoittuvuuksia, joita hyökkääjät voivat käyttää automatisoitujen työnkulkujen hakiessa riippuvuuksia ilman tarkistusta. Lähde
Julkaistu ensimmäisen kerran perjantaina 24. heinäkuuta 2026.
