Anderson 视角

Python 包安装作为本地 AI 采用的指数

mm
将 Unite.AI 添加到您在 Google 上的首选来源
AI-generated article illustration (GPT-2): an orthographic, game-like view of a suburban street is bordered by a yellow frame labeled “AI FANTASY INSIDE” and “REALITY OUTSIDE.” Round wicker baskets sit outside each house. Near the center, one basket has its lid displaced and a python is emerging, raising its head above the rim.

难以量化的 Python 包下载量的增长为我们讲述了 AI 的扩散故事,如果你知道从哪里开始寻找。

 

观点 任何人如果曾经探索过 本地 AI 的潜力,到现在为止已经在磁盘空间上损失了大量的空间,不仅仅是由于 巨大的模型,还包括相关的 Python 和其他系统,这些系统编排了推理、训练和其他潜在的用途,包括生成本地自动化系统。

最后一个用例是我 LAN 上的机器中最常见的,我在这些机器上使用 AI 设置了“平坦”的 Python 基础自动化例程,例如备份、周期性检查、网站管理和其他用途。

在这些编码会话中,我想要实现的几乎所有事情都需要一个新的 Python 库,因此 PIP(Python 包安装器)是我 LAN 机器上最大的空间占用者之一:

PIP 的微小存在在 CLI 和 GUI 中掩盖了其对文件系统的影响。缓存可以达到非常高的文件大小,甚至可能导致系统崩溃。

PIP 的微小存在在 CLI 和 GUI 中掩盖了其对文件系统的影响。缓存可以达到非常高的文件大小,甚至可能导致系统崩溃。

使用本地 AI 反转了本地计算机在 AI 硬件抢占当前时代之前的冗余奢侈。如果你有一个慷慨的 RAM 允许,它将被 GPU 卸载所消耗;一个 terabyte 的硬盘空间,同样会迅速填满高容量模型,量化或不量化;即使你像我一样配备了 24GB 的 VRAM(一个新的最低要求),系统仍然需要各种捷径和技巧来在合理的时间范围内运行推理。

安装的 PyPi(Python 包索引)包不会在标准的“安装程序”GUI 中显示,需要通过 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 相关的任何东西。

简而言之,本地 AI 可以将你的计算机体验带回 20 世纪 90 年代初期,就在一个程序像 Word 需要加载到几个 KB 的 RAM 中,一个大型软盘一次;但是在硬盘分配给你呼吸空间之前。

寻找潜流

我很好奇,过去几年 PyPi 安装的激增是否可以作为本地 AI 采用的一个指标,这通常很难追踪,除了通过直觉参与各种 AI 社区并注意哪些平台和包获得了关注。

PyPi 统计网站 的随意一瞥显示了一系列令人失望地狭窄的日期,所有这些日期都表明 Python 包下载量在不断上升:

自 2026 年初以来所有 Python 包的下载量上升——尽管可用的日期范围非常狭窄。来源 - https://www.intel.com/content/www/us/en/docs/advisor/user-guide/2024-2/model-offloading-to-a-gpu.html

自 2026 年初以来所有 Python 包的下载量上升——尽管可用的日期范围非常狭窄. 来源

如果我们能够将该日期范围扩展到 2020 年,并查看增长是否保持一致,或者(正如人们可能怀疑的那样)在 2024-26 年更加迅速地上升——如果仅仅是由于 代理 AI 系统的无人监督行为,那就太好了。

遗憾的是,官方 PyPi 源 声明,由于 CDN 缓存、缓存、镜像、非官方下载和历史数据质量问题等原因,PyPi 包下载统计数据不可用。

不用着急

然而,PyPi 提供了分析下载趋势所需的组件;因此,有多个网站可以提供超过一个月的范围,例如 PepySite——但大多数都是基于订阅的,你需要支付费用才能看到更长范围的趋势和统计数据(在某些情况下,最高可达 $490 美元 每月,用于“VC”包)。

那么,我们是否可以在不使用昂贵的 API 来展示这些趋势的情况下,从 Python 中了解到关于 AI 加速的任何信息呢?

虽然 PyPiStats 是一个 FOSS 资源,但它出于某种原因只提供 最近一个月的统计数据,且此范围即使付费也无法扩展。

幸运的是,有一个网站更加慷慨——在 ClickPy 上,你至少可以搜索个别包的采用历史,即使这些历史不能被编排成一个总体的概览,很容易产生更广泛的协调趋势。例如,以下是 Transformers 库自 2016 年以来的走势(尽管仅自 2019 年 发布 以来有效):

变压器的崛起。来源 - https://pypistats.org/packages/__all__/

变压器的崛起。 来源

关于老牌的 Torch 呢,它 首次发布于 2002 年,但直到其发展成为 PyTorch,并且与图像和视频相关的Transformer 基础 VLM 和生成 AI 相关时,才开始困扰家用 AI 爱好者?

自 2017 年以来 Torch 的下载量,过去 2-3 年内呈现出陡峭的上升趋势。

自 2017 年以来 Torch 的下载量,过去 2-3 年内呈现出陡峭的上升趋势。

同一时期的 PyTorch,先是稳定,然后有时会出现激增。

同一时期的 PyTorch,先是稳定,然后有时会出现激增。

更有趣的是,例如在 PyTorch 的情况下(请参见上面的图像),是自 2017 年以来不同 Python 版本的采用概况,为我们提供了对其采用率的额外维度的洞察力:

自 2017 年以来,按 Python 版本划分的 PyTorch 下载量,提供了对第三次 AI 革命“热潮”以来采用率的额外维度的洞察力。

自 2017 年以来,按 Python 版本划分的 PyTorch 下载量,提供了对第三次 AI 革命“热潮”以来采用率的额外维度的洞察力。

如果上述统计数据阐明了自真正功能强大的 LLM 和 VLM 系统出现以来采用率的激增,那么当按系统查看时,这一点变得更加明显:

自 2017 年以来 PyTorch 的采用情况,按操作系统划分。

自 2017 年以来 PyTorch 的采用情况,按操作系统划分。

对于 加速 包来说也是如此,这是 VRAM 匮乏的 AI 用户最需要的库之一,他们希望从系统的局限性中榨取出尽可能多的东西:

加速的崛起,按操作系统划分。

加速的崛起,按操作系统划分。

因此,对于 ClickPy 上的任何包或库来说,情况都是如此;当然,编制一个总体概况将会很有趣。

从“按操作系统”图中可以看出,Linux 采用率的增加。虽然 Linux 桌面采用率正在 稳步上升,面对 不受欢迎的 Windows 战略,但 Linux 环境的使用率却明显上升。

例如,我在 WSL2 上的 Windows 中运行 Ubuntu 虚拟机,用于多个 Docker 容器,其中 Docker 可以利用与原生 Linux 开发人员相同的条件下的真正 Linux 系统。这是在一个完全由 Windows 组成的 LAN 中的两个活跃的 Linux 系统(从裸机的角度来看),并且在等待中还有一个本地 Linux 笔记本电脑。

结论

从 CLI 基础包下载来看,很有趣的是,这个极其极客的领域在 AI 的影响下已经变得多么热门。

包的消耗量的增加正在成为一个下游的安全隐患,随着 slopsquatting 的出现。由于 LLMs 容易出现幻觉,因此它们很可能会发送请求以获取虚构的包。由于收敛的相似性,虚假包很可能会在其他库调用中重新出现,以至于对于恶意行为者来说,创建虚假包以备将来拉取/调用是值得的——当然,带有恶意有效载荷:

来自论文“我们为您准备了一个包!代码生成 LLMs 的包幻觉的综合分析”- AI 驱动的代码生成扩展了供应链攻击面。LLMs 经常幻觉不存在的包名称,创建“slopsquatting”漏洞,恶意行为者会在自动管道盲目拉取未经验证的依赖项时利用这些漏洞。来源 - https://github.com/huggingface/accelerate

来自论文“我们为您准备了一个包!代码生成 LLMs 的包幻觉的综合分析”- AI 驱动的代码生成扩展了供应链攻击面。LLMs 经常幻觉不存在的包名称,创建“slopsquatting”漏洞,恶意行为者会在自动管道盲目拉取未经验证的依赖项时利用这些漏洞。来源 – 来源

 

首次发布于 2026 年 7 月 24 日

机器学习作家,人类图像合成领域专家。曾任Metaphysic.ai研究内容负责人,直至其解散并并入DNEG的Brahma.ai。
Portfolio site:martinanderson.ai
Contact:[email protected]