Погляд Anderson
Українські пакети Python як індекс локального прийняття штучного інтелекту

Важко квантювати зростання завантажень пакетів Python, яке розказує історію розповсюдження штучного інтелекту, якщо ви знаєте, де шукати.
Опінія Хтось, хто досліджував потенціал локального штучного інтелекту, вже зараз втратив велику кількість місця на диску не тільки через величезні моделі, але й через пов’язані з ними пакети Python та інші системи, які керують висновком, навчанням та сотнями інших потенційних застосунків – не в останню чергу, у генерації локальних систем автоматизації.
Цей останній випадок використання є найпоширенішим серед різних машин у моєї локальної мережі, де я використовував штучний інтелект для створення “плоских” автоматизованих процедур на основі Python, таких як резервне копіювання, періодичні перевірки, адміністрування мого веб-сайту та десятки інших застосунків.
Практично все, чого я хочу досягти під час цих сесій програмування, здається, вимагає нового пакету Python, до того ступеня, що PIP (інсталатор пакетів Python) є одним з найбільших споживачів місця на диску серед моїх машин у локальній мережі:
Незначна присутність PIP у командному рядку та графічних інтерфейсах приховує його вплив на вашу файлову систему. Кеш може досягати великих, навіть критичних для системи розмірів файлів.
Експериментування з локальним штучним інтелектом змінює суттєву надмірність локальних комп’ютерів, що існувала до початку дéficitу оперативної пам’яті у сучасній ері. Якщо у вас була щедра пам’ять, вона буде використана для відкладання на графічний процесор; терабайт місця на диску також швидко заповниться великими об’ємами моделей, квантованими чи ні; і навіть якщо, як я, у вас є 24 ГБ відеопам’яті (новий мінімум…?), система все одно потребуватиме різних скорочень і трюків для виконання висновку за прийнятні часові рамки.
Встановлені пакети PyPi (Python Package Index) не відображаються у стандартних інтерфейсах “Встановлені програми” у звичайній операційній системі та потрібно явно викликати через Python, наприклад, за допомогою команди PowerShell pip freeze --all.
Список може бути досить довгим:
| Пакет | Версія | Пакет | Версія | Пакет | Версія |
|---|---|---|---|---|---|
| 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 |
Вивантаження пакетів PyPi на одному з моїх зайнятих машин. Деякі з цих малих слів ховають гігабайти місця на диску – особливо все, що пов’язано з Torch/PyTorch.
У короткому вигляді, локальний штучний інтелект може повернути ваш досвід роботи з комп’ютером до початку 1990-х років, трохи пізніше періоду, коли програма типу Word мала бути завантажена в кілька кілобайт оперативної пам’яті, один великий диск за раз; але до того, як розміщення на жорсткому диску дало вам будь-яке місце для дихання.
Пошук підводних течій
Я був цікавий, чи зростання кількості завантажень пакетів PyPi за останні кілька років може слугувати індексом локального прийняття штучного інтелекту, яке загалом досить важко відстежувати, окрім інтуїції при участі в різних спільнотах штучного інтелекту та спостереженні за тим, які платформи та пакети привертають увагу.
Порівняльний погляд на сайт статистики PyPi показує розчаруючу вузьку діапазон дат, всі з яких, однак, вказують на постійний зростання завантажень:
Зростання завантажень по всіх пакетах Python з початку 2026 року – хоча доступний діапазон дат дуже вузький. Джерело
Було б чудово розширити цей діапазон дат до 2020 року та побачити, чи зростання залишається постійним, або (як можна підозрювати), чи воно зросло більш різко у 2024-26 роках – якщо не тільки через необмежені дії агентних систем штучного інтелекту.
На жаль, офіційні джерела PyPi зазначають, що статистика завантажень пакетів PyPi не надається, з різних причин, включаючи накладні витрати на кешування CDN, неточні підрахунки завантажень через кеш, дзеркала, неофіційне завантаження та історичні проблеми якості даних – і, згідно з сайтом Python, їх обмежену корисність як міри якості пакету.
Не так швидко
Однак, PyPi надає компоненти, необхідні для інших аналізів тенденцій завантажень; існують різні сайти, які дозволяють побачити більше, ніж місяць, наприклад, PepySite – але більшість з них мають платну підписку, і вам потрібно платити, щоб побачити довгострокові тенденції та статистику (до $490 USD на місяць у одному випадку, за пакет “VC”).
Чи є щось, що ми можемо дізнатися про Python як індекс прискорення штучного інтелекту, поза дорогими API, які розкладають ці тенденції для багатих?
Хоча PyPiStats є відкритим ресурсом, він по якихось причин пропонує тільки статистику за останній місяць, і цей діапазон не може бути розширений навіть за плату.
На щастя, один сайт є більш щедрим – на ClickPy можна хоча б шукати історію прийняття окремих пакетів, навіть якщо їх підсумок не оркестрований у підсумковий огляд, який легко дає широкі, узгоджені тенденції. Тут, наприклад, показано проходження бібліотеки Transformers з 2016 року (хоча тільки з 2019 року):
Метеоритне зростання трансформерів. Джерело
А що стосується старовинного Torch, першої версії якого вийшло у 2002 році, але який не був призначений мучити ентузіастів локального штучного інтелекту до його розвитку у PyTorch, та зростання трансформерів та генерації штучного інтелекту, пов’язаного з зображеннями та відео..?
Завантаження Torch з 2017 року, з різким зростанням упродовж останніх 2-3 років.
PyTorch за той самий період, з плато та різким зростанням над стабільною основою.
Більше цікаво, наприклад, у випадку з PyTorch (див. зображення вище), побачити огляд прийняття різних версій Python з 2017 року:
Завантаження PyTorch упродовж часу з 2017 року, за версіями Python, що дає додатковий вимір розуміння прийняття з часів «гарячої» ери цієї третьої революції штучного інтелекту.
Якщо статистика вище освітлює зростання прийняття з появою справжніх моделей LLM та VLM, це стає ще очевиднішим, коли дивитися на це з точки зору системи:
Прийняття PyTorch з 2017 року, інтерпретоване за операційною системою.
Це схоже й для пакету accelerate – одного з найбільш необхідних бібліотек для користувачів штучного інтелекту, які мають обмежену відеопам’ять та намагаються витиснути з системи все можливе:

Зростання популярності пакету accelerate за операційними системами.
Так само відбувається з будь-яким іншим пакетом чи бібліотекою, яку ви досліджуєте на ClickPy, і було б цікаво створити підсумковий огляд замість пошуку окремих частин.
Одна річ, яка стає очевидною з графіків «за операційною системою», – це зростання прийняття Linux. Хоча прийняття Linux на робочому місці відбувається повільно, використання середовищ Linux явно зростає.
Наприклад, я запускаю Ubuntu у віртуальній машині на WSL2 у Windows для різних контейнерів Docker, де Docker може використовувати справжню систему Linux на тих самих умовах, що й розробники. Це два активні середовища Linux у повністю вікнальній локальній мережі (з точки зору голого металу), з рідним ноутбуком Linux, який чекає на свій час.
Висновок
У термінах завантажень пакетів у командному рядку це цікаво бачити, як ця дуже технічна галузь стала популярною після появи штучного інтелекту.
Зростання споживання пакетів починає ставати загрозою безпеки вниз по ланцюжку, з появою slopsquatting. Оскільки моделі LLM схильні до «галюцинацій» пакетів, вони, ймовірно, будуть надсилати запити на вигадані пакети. Через подібність збіжності фальшиві пакети, ймовірно, будуть повторюватися в інших бібліотечних викликах, до того ступеня, що буде вигідно для зловмисників насправді створити фальшиві пакети для майбутніх запитів – звичайно, з шкідливим вмістом:
Зображення з статті «We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs» – генерація коду штучним інтелектом розширює площину атаки ланцюга постачання. Моделі LLM часто «галюцинують» неіснуючі імена пакетів, створюючи вразливості «slopsquatting», які зловмисники використовують, коли автоматизовані конвеєри бездумно завантажують неверифіковані залежності. Джерело
Опубліковано вперше у п’ятницю, 24 липня 2026 року












