使用 pixi 管理 PyTorch CUDA GPU wheel 并配置阿里云源

buuzmvd
19 阅读21分钟

本文介绍了使用 pixi 管理 pytorch 时的一些配置语法与踩坑手记，实现了 Windows/Linux/macOS 三平台的国内源（阿里云源）配置，并提供了一些其他的配置方法，解决了官方源 pytorch cuda whl 下载对网络环境要求高的痛点。

Author: Ash (GitHub@aashen1, zhihu/csdn/cnblogs/juejin@buuzmvd)
Date: 2026-05-18
发表状态：已于 2026年5月18日 同步发布于知乎/博客园/CSDN/微信公众号@buuzmvd，2026年5月19日 发布于稀土掘金
AI生成内容声明： AI 生成内容在文章中以“AI 的解释：”等予以明确标识，且引用前后均以分隔线标明。其内容均来自 GLM-5.1 网页对话。除这些片段摘录外，本文的文字叙述部分不含其他 AI 生成内容。

TLDR

省流：在 pixi.toml 当中进行如下配置：

[workspace]
platforms = ["win-64", "linux-64", "osx-arm64"]

[system-requirements]
cuda = "12.6"

[dependencies]
python = "3.12.*"

[pypi-dependencies]
torch = { version = "==2.10.0+cu126" }
torchvision = { version = "==0.25.0+cu126" }
torchaudio = { version = "==2.10.0+cu126" }

[target.osx.pypi-dependencies]
torch = { version = "==2.10.0" }
torchvision = { version = "==0.25.0" }
torchaudio = { version = "==2.10.0" }

[pypi-options]
index-url = "https://pypi.mirrors.ustc.edu.cn/simple"
# extra-index-urls = ["https://pypi.org/simple"]
# index-strategy = "unsafe-best-match"
find-links = [
# Note: similar to --find-links option in pip.
    { url = 'https://mirrors.aliyun.com/pytorch-wheels/cu126' },
    { url = 'https://mirrors.aliyun.com/pytorch-wheels/cpu/' },
]

（这里只写了相关条目，其他条目该咋写还是咋写。比如可以参考 GitHub 上的各种项目写法，或者也可以参考笔者的个人项目的写法）

这样就可以实现跨平台的通用配置了。

如果不需要 macOS 或者不需要 Windows/Linux 的话，还可以相应地把对应配置删掉，进一步精简掉一半的内容。

另外，如果有 pypi 其他包解析失败，可以试试把上面的extra-index-urls和index-strategy两行取消注释，或许会有帮助。

本文的精华部分就是上面这些了，以下全文都是各种踩坑和碎碎念，很长，可以不看。

问题的起因

在 AI 与 LLM 等领域的项目中经常使用到 pytorch + CUDA 的组合。

pixi 是一个定位类似 conda，并用 uv 作为 pypi 解析器的环境管理工具，可以方便地管理这种组合。

相比于 miniconda 等前代方法，pixi 支持全局缓存，用链接的方式建立虚拟环境，解决了 conda 系的“多份环境重复占用磁盘空间”的痛点，其软件定位为“解决科学计算与机器人学当中的混合复杂依赖问题”。

使用 pixi 配置 pytorch+CUDA 的基本写法为，在 pixi.toml 当中以如下方式指定 index：

[workspace]
platforms = ["win-64", "linux-64", "osx-arm64"]

[pypi-dependencies]
torch = { version = "==2.10.0+cu126", index = "https://download.pytorch.org/whl/cu126" }
torchvision = { version = "==0.25.0+cu126", index = "https://download.pytorch.org/whl/cu126"  }
torchaudio = { version = "==2.10.0+cu126", index = "https://download.pytorch.org/whl/cu126" }

[target.osx.pypi-dependencies]
torch = { version = "==2.10.0", index = "https://download.pytorch.org/whl/cpu" }
torchvision = { version = "==0.25.0", index = "https://download.pytorch.org/whl/cpu" }
torchaudio = { version = "==2.10.0", index = "https://download.pytorch.org/whl/cpu" }

这样设置之后，pixi 解析器会自动尝试去到 pytorch wheel 源站，索引各平台所需的 whl 文件，例如：torch-2.10.0+cu126-cp312-cp312-win_amd64.whl，就是一个 AMD-64 架构下 Windows 平台的 python 3.12 + pytorch 2.10 + cuda 12.6 whl 文件，文件大小 2.4 GB，是同版本 linux wheel （约0.8 GB）的三倍大。

如果我们的网络环境不甚理想，从这个源站下载这样一个 whl 文件，可能需要相当不短的时间。这让我们想到镜像站。

各个镜像站的表现

一些没有真正拉取的“无效镜像”

经过搜索发现，pytorch CUDA wheel 的可用镜像站并不多。我们尝试了两个高校镜像站，但是在 CUDA 12.6 上面的效果都不甚理想：

上海交大镜像站：

mirror.sjtu.edu.cn/pytorch-whe…

南京大学镜像站：

mirrors.nju.edu.cn/pytorch/whl…

在本文撰写时（2026年5月18日），这两个镜像站似乎都没有真正拉取这一批 CUDA 12.6 的 whl，而只是设置了一个指向源站（ download.pytorch.org 或者 download-r2.pytorch.org/ ）的下载链接。

不过也有一个真正的镜像站，那就是阿里云镜像站：

mirrors.aliyun.com/pytorch-whe…

实测在这里下载，相对于官方源速度有明显改善。

但是如果将它配置进 pixi 作为 index，会报错说找不到对应 whl。

经 AI 分析，这大概是因为阿里云镜像站目前没有为 cuxxx 的镜像网址配置可用的 PEP 503 Simple API；

同时它也没有拉取 .whl.metadata 元文件，因此不管是将其设置为 index，还是通过全局的 $PIXI_HOME/config.toml 去设置 [mirrors] 以覆盖掉 pytorch 源站；

（或者不覆盖源站，只覆盖download-r2站，都没有能让 pixi 解析通过的办法。）

下面先写一下失败的踩坑尝试，都是目前用不了的，作为一些探索记录。

需要可行方案的读者可以跳过下面这一 part 往后拉。

一些看起来不错，但没能成功的尝试

笔者尝试了各种方法将阿里云配置为 pytorch wheel 的 index 镜像源，在 Windows 10 系统的 pixi 0.68.1 上都未能成功解析。

如果将来 pixi/uv/阿里云 中的某一方通过更新完善了相关支持，那么这些方法或许会成为可用的镜像配置方式。

以下列举几种笔者尝试过，但没能成功解析的镜像写法：

尝试一：直接将镜像站设置为 index

在 $PIXI_HOME/config.toml 中不配置全局 [mirrors]：

[mirrors]
# "https://download.pytorch.org/whl" = ["https://mirrors.aliyun.com/pytorch-wheels"]
# "https://download-r2.pytorch.org/whl" = ["https://mirrors.aliyun.com/pytorch-wheels"]
"https://conda.anaconda.org/conda-forge" = ["https://mirrors.ustc.edu.cn/anaconda/cloud/conda-forge/"]
"https://conda.anaconda.org/bioconda" = ["https://mirrors.ustc.edu.cn/anaconda/cloud/bioconda/"]

将镜像站直接写入 index：

[pypi-dependencies]
torch = { version = "==2.10.0+cu126", index = "https://mirrors.aliyun.com/pytorch-wheels/cu126" }
torchvision = { version = "==0.25.0+cu126", index = "https://mirrors.aliyun.com/pytorch-wheels/cu126"  }
torchaudio = { version = "==2.10.0+cu126", index = "https://mirrors.aliyun.com/pytorch-wheels/cu126" }

[target.osx.pypi-dependencies]
torch = { version = "==2.10.0", index = "https://mirrors.aliyun.com/pytorch-wheels/cpu" }
torchvision = { version = "==0.25.0", index = "https://mirrors.aliyun.com/pytorch-wheels/cpu" }
torchaudio = { version = "==2.10.0", index = "https://mirrors.aliyun.com/pytorch-wheels/cpu" }

失败信息：

$ pixi update
Error:   × failed to solve the pypi requirements of environment 'default' for platform 'win-64'
  ├─▶ failed to resolve pypi dependencies
  ╰─▶ Because torch was not found in the package registry and you require torch==2.10.0+cu126, we can conclude that your
      requirements are unsatisfiable.

经过 AI 分析，这是前面提过的，没有配置 PEP 503 Simple API 导致。以下是 AI 的解读：

pixi/uv 对 PyPI 的依赖解析，要求 index / extra-index-urls 满足 PEP 503 Simple API：
访问 /simple/ 或 /simple/<project>/ 要返回一列 <a href="...">*.whl</a> 的 HTML，例如：

https://pypi.org/simple/torch/
https://download.pytorch.org/whl/cu126/torch/

这类页面才是“合规”的 PyPI 索引。

而阿里云的 pytorch-wheels/cu126/ 是什么？是一个 “Index of /” 的文件列表目录，只罗列文件名，没有按项目名拆 /simple/<project>，也没有 PEP 503 那种链接结构

尝试二：用全局 mirrors 覆盖掉 pytorch 源站

在$PIXI_HOME/config.toml中配置全局[mirrors]，用镜像站覆盖掉官方源：

[mirrors]
"https://download.pytorch.org/whl" = ["https://mirrors.aliyun.com/pytorch-wheels"]
"https://download-r2.pytorch.org/whl" = ["https://mirrors.aliyun.com/pytorch-wheels"]
"https://conda.anaconda.org/conda-forge" = ["https://mirrors.ustc.edu.cn/anaconda/cloud/conda-forge/"]
"https://conda.anaconda.org/bioconda" = ["https://mirrors.ustc.edu.cn/anaconda/cloud/bioconda/"]

index 直接指向官方源：

[pypi-dependencies]
torch = { version = "==2.10.0+cu126", index = "https://download.pytorch.org/whl/cu126" }
torchvision = { version = "==0.25.0+cu126", index = "https://download.pytorch.org/whl/cu126"  }
torchaudio = { version = "==2.10.0+cu126", index = "https://download.pytorch.org/whl/cu126" }

[target.osx.pypi-dependencies]
torch = { version = "==2.10.0", index = "https://download.pytorch.org/whl/cpu" }
torchvision = { version = "==0.25.0", index = "https://download.pytorch.org/whl/cpu" }
torchaudio = { version = "==2.10.0", index = "https://download.pytorch.org/whl/cpu" }

失败信息与尝试一相同：

$ pixi update
Error:   × failed to solve the pypi requirements of environment 'default' for platform 'win-64'
  ├─▶ failed to resolve pypi dependencies
  ╰─▶ Because torch was not found in the package registry and you require torch==2.10.0+cu126, we can conclude that your
      requirements are unsatisfiable.

应该也是没有 Simple API 的问题。

尝试三：用全局 mirrors 部分覆盖掉 pytorch 源站

观察解析结果时，注意到实际下载常常是走官方源的download-r2站点，那么可否让索引走download官方源，获取到正确的信息，只把实际下载换到阿里云镜像源？

于是尝试：在 $PIXI_HOME/config.toml 中配置全局[mirrors]，只覆盖官方源中的download-r2。

[mirrors]
# "https://download.pytorch.org/whl" = ["https://mirrors.aliyun.com/pytorch-wheels"]
"https://download-r2.pytorch.org/whl" = ["https://mirrors.aliyun.com/pytorch-wheels"]
"https://conda.anaconda.org/conda-forge" = ["https://mirrors.ustc.edu.cn/anaconda/cloud/conda-forge/"]
"https://conda.anaconda.org/bioconda" = ["https://mirrors.ustc.edu.cn/anaconda/cloud/bioconda/"]

index 还是直接指向官方源：

[pypi-dependencies]
torch = { version = "==2.10.0+cu126", index = "https://download.pytorch.org/whl/cu126" }
torchvision = { version = "==0.25.0+cu126", index = "https://download.pytorch.org/whl/cu126"  }
torchaudio = { version = "==2.10.0+cu126", index = "https://download.pytorch.org/whl/cu126" }

[target.osx.pypi-dependencies]
torch = { version = "==2.10.0", index = "https://download.pytorch.org/whl/cpu" }
torchvision = { version = "==0.25.0", index = "https://download.pytorch.org/whl/cpu" }
torchaudio = { version = "==2.10.0", index = "https://download.pytorch.org/whl/cpu" }

失败信息：

$ pixi update
  ⠒ default:linux-64     [00:00:00] resolving torch==2.10.0+cu126
  ⠒ default:win-64       [00:00:00] resolving pypi dependencies
  ⠒ default:osx-arm64    [00:00:00] resolving pypi dependencies                                                                    Error:   × failed to solve the pypi requirements of environment 'default' for platform 'linux-64'
  ├─▶ failed to resolve pypi dependencies
  ├─▶ Failed to fetch: `https://download-r2.pytorch.org/whl/cu126/torch-2.10.0%2Bcu126-cp312-cp312-
  │   manylinux_2_28_x86_64.whl.metadata`
  ╰─▶ HTTP status client error (404 Not Found) for url (https://mirrors.aliyun.com/pytorch-wheels/cu126/torch-2.10.0%2Bcu126-
      cp312-cp312-manylinux_2_28_x86_64.whl.metadata)

可以看到，这次终于刷出了不一样的报错，不再是找不到 whl 了，而是找不到.whl.metadata，经与 AI 讨论，这是因为阿里云拉取镜像的时候没有把 metadata 一并拉过来，于是判定无法解析。

总的来说，阿里云镜像源可以对 whl 文件本身提供理想的下载速度，但是（在本文撰写的2026年5月18日时）它的 index 与 metadata 等相关信息配套不如官方源完善，因此 pixi 无法以 pypi index 的方式正确解析它。

能成功解析的配置方法

上面三种方法都失败了，那么有没有成功了的方法？

那当然是换一个理想的网络环境直接去官方源下载

方法一：使用 pypi-options.find-links 指向阿里云镜像站

这个方法是最接近我们理想需求的。

这也是本文写到最后才试出来的方法。

本来，在其他方法全部写完了之后，依然没有实现这个需求，总觉得不得劲，最后想想，作为踩坑手记也行吧，等阿里云或者 pixi 的更新了再说。

结果临了突然想到，find-links 不是也能设置在线 URL 的吗？怎么不试试看呢？

一尝试，居然真的解析成功了。

这个需求经历了和 AI 前前后后讨论十几个对话，居然从来没想到这一茬。

翻记录发现 AI 好像提过一嘴这个写法，但是又说什么这个行为是未定义啥啥的，也没明着把这种写法推荐出来让我试试。

哎，折腾。

一份通用配置搞定一切，跨平台可用，团队协作可用，不要求理想的网络环境就能把下载速度吃满。

阅读阿里云源的帮助文档可以找到一些线索，这个帮助页底部评论区，各位网友给出的建议都是使用 pip 的 --find-links 参数。

而 pixi 同样有这个参数，文档中对它的介绍也是 “similar to --find-links option in pip”，于是我们尝试将阿里云镜像源配置在这个参数中，发现可以成功解析。

另外，因为 macos 所需要的 wheel 和 Windows/Linux 都不同，是 cpu 的 wheel，所以为了同时支持 Windows/Linux/macOS 三平台，我们配置两条 find-links 即可。

最终 pixi.toml 当中所有的相关项如下：

[pypi-dependencies]
torch = { version = "==2.10.0+cu126" }
torchvision = { version = "==0.25.0+cu126" }
torchaudio = { version = "==2.10.0+cu126" }

[target.osx.pypi-dependencies]
torch = { version = "==2.10.0" }
torchvision = { version = "==0.25.0" }
torchaudio = { version = "==2.10.0" }

[pypi-options]
index-url = "https://pypi.mirrors.ustc.edu.cn/simple"
# extra-index-urls = ["https://pypi.org/simple"]
# index-strategy = "unsafe-best-match"
find-links = [
# Note: similar to --find-links option in pip.
    { url = 'https://mirrors.aliyun.com/pytorch-wheels/cu126' },
    { url = 'https://mirrors.aliyun.com/pytorch-wheels/cpu/' },
]

重点是最下面的find-links，上面还有个 index-url，作用是让 pypi 索引也走国内镜像源，是用来解决官方 pypi 索引速度不理想的问题，与 pytorch cuda wheel 应该无关。

方法二：使用 pypi-options.find-links 指向本地的 whl 文件

以上方法，不管是从官方源还是从阿里云源，最后缓存下来的都不是打包好的 whl 文件。

pixi 会直接把它“解压”，将这个单文件展开成一整个 torch 文件夹。whl 文件貌似是不会被 pixi 保存。

当我们使用pixi clean cache清理掉缓存，下次就会重新下载这个 whl 文件并再度解压。

那么，如果你希望在本机存储这个 whl 文件，从而指定它直接取来就用而不需要等待下载，那么另一种可行的方式是：使用 find-links 配置项指定本地路径。

这样全局 config.toml 也不用配置什么镜像，pixi.toml 里面也不用指定什么 URL，直接自己先去官方源或者阿里云源，用下载工具下到本地，然后配置里写上对应的路径就行了。

以 Windows 为例，在 pixi.toml 当中配置：

[pypi-dependencies]
torch = { version = "==2.10.0+cu126" }
torchvision = { version = "==0.25.0+cu126" }

[pypi-options]
index-url = "https://pypi.mirrors.ustc.edu.cn/simple"
extra-index-urls = ["https://pypi.org/simple"]
index-strategy = "unsafe-best-match"
find-links = [
# Settings of using local torch-cuda-whl cache.
# Modify or delete this before running pixi
# Note: similar to --find-links option in pip.
    { path = 'D:/some_folder/torch_cache' },
]

Linux 就改成对应风格的路径即可。

除了绝对路径，find-links也支持相对路径，比如 path = '.cache/'，但是解析锁文件的时候，还是会拼接成绝对路径，所以不能由这种方法做到配置文件跨平台通用。

另外，实测下来，这个地方也不会自动展开家目录~/.cache之类的写法，这样写只会让 pixi 把它当成相对路径，然后尝试在当前项目下找一个叫 ~ 的文件夹，并报错。

可以看到，我们没有指定 index URL，而是在最后告诉 pixi，找 pypi 的时候去到这个本地路径，那么它就会识别到文件夹里已经放好的，对应版本的 .whl 并正确解析 lock 文件。

不过这种方法有几个缺点：

一、对多人协作不友好

因为这样解析出来的 pixi.lock 会带有指向本地的 Windows 风格或者 Unix 风格路径，把这个路径“当作”URL。因此团队中的其他成员也必须在同样的绝对路径下放好一模一样的 whl 文件才能正常运行，否则就要重新 pixi update，无法做到全团队使用同一套 pixi.toml 与 pixi.lock。

听说 uv 好像已有find-links相对路径的支持了，如果未来 pixi 也实装了， 那么这个问题可以改善一些，比如团队成员约定，大家都在项目根目录下的.cache里面把 whl 文件放好（或者链接过去），那也算实现了 pixi.lock 的统一。不过目前可能还不行。

二、对跨平台不友好

同样的理由，在 Windows 下解析和在 Linux 下解析，路径的风格是不一样的，笔者也没有研究出来让 find-links 支持“一个平台一个版”的方法。

所以 Windows 这边成了，到 Linux 又要重新改掉 find-links 重新解析过，没法用一份文件统一多个平台。

注：pixi 截至 0.68.1 版本还不支持 [target.osx.pypi-options] 这样的写法，所以前文的方法一可以用多条 URL 为 find-links 实现多平台支持，但是如果写多个不同平台的 local path 却会报错。

如果选择这种方案，建议就只写自己开发所在的平台就行，比如

[workspace]
platforms = ["win-64"]

如果写多个的话，那么 pixi 是一定要把每个平台的 torch wheel 都找来的，所以你需要把每个平台的 whl 都放到那个文件夹里。

问题是非本平台的 whl 实际上又不会真的被使用，真换其他平台了本来就要重新解析的，所以就显得很蠢。

建议只写需要的平台就行了。

补一句吐槽：LLM 在分析这个 pixi 多平台find-links需求的时候，真的是幻觉满天飞，经常编一些像模像样的 pixi.toml 写法，写出来全部都是不对的，给我坑得死去活来。

不知道是不是因为 uv 有类似的功能，它就想当然觉得 pixi 也可以了。

试了四五个国内外的主流 LLM 网页对话 （仅限于免费版，笔者没开过会员）都是这样，各个满嘴跑火车。

得不断强调要它做好信源核实，比着 pixi 官方文档去说，那么说出来的才算靠谱一些。

当然，这种方法也有一个好处。

pixi 解析的时候，有时会变着变着，就把这个 cuda wheel 的 CDN 给变掉了。比如一开始是去https://download.pytorch.org/whl的，后来哪天 update 的时候又就跳成 https://download-r2.pytorch.org/whl 了。

这样虽然之前配好过虚拟环境的也不会出问题，但是一旦拿着这份配置去开新的虚拟环境，那么它就不认原来那个老的 whl 了，又要去 -r2下载一遍 2.4G 的一模一样的 whl，旧的那份还不会自动删掉，得自己去手动 clean ，纯折磨。

而如果你是 个人+单平台 的项目，能接受 pixi.lock 里面带有你本机的路径，那么这样配置好之后，只要你放在本地的那个 whl 文件还在，pixi 解析的时候就一直会直接去找这个 whl 文件，把本地路径解析为 URL，也就避免了被这个 CDN 变动坑到的风险。

笔者之前在 Windows 上面开发个人项目的时候，一直是用这种方法，稳定性是不错的。奈何想加上跨平台之后就不行了。

上面这段“好处”是相对于官方源写法来说的，写的时候还没摸索出来 find-links + url 的方法，相比配置 url 走阿里云源的方法，那感觉就没什么优势了。

方法三：迁移到 conda 侧

还有一种思路，是将 pytorch 挪回到 conda 这边。

因为 conda 镜像站的情况目前来看比 pytorch wheel 好多了，随便一搜就有很多活跃的高校和企业镜像源可用，这样当然也能解决下载速度的问题。

只需要这样写：

[system-requirements]
cuda = "12"

[dependencies]
python = "3.12.*"

[target.win-64.dependencies]
pytorch-gpu = "2.10.*"
cuda-version = "12.*"

[target.linux-64.dependencies]
pytorch-gpu = "2.10.*"
cuda-version = "12.*"

[target.osx.dependencies]
pytorch-cpu = "2.10.*"

[pypi-dependencies]
# .......

那么就把 torch 这条依赖整个交给 conda 管理了，经过配置镜像站（全局 config.toml，位于pixi总配置目录下）：

[mirrors]
"https://conda.anaconda.org/conda-forge" = ["https://mirrors.ustc.edu.cn/anaconda/cloud/conda-forge/"]
"https://conda.anaconda.org/bioconda" = ["https://mirrors.ustc.edu.cn/anaconda/cloud/bioconda/"]

（此处使用的是 USTC 镜像源，也可以换成其他 conda 源，搜一下就有很多可用的。）

就能很好地解决这个问题。

这种方法同样能完美解决下载速度慢的问题，而缺点主要有如下几条：

第一，如果未来要迁移到 uv，那么这种方案就不可用了，必须全 pypi。

不过 uv 似乎有一些 pixi 还没有的特性，比如 flat-links 识别阿里云站这样的源，或者多平台定义各自的 find-links 等等，它解决这个场景或许还更方便，大概是因为它的设计哲学和 pixi 不同。

因为笔者没有单独用过 uv，只是从 AI 那里道听途说，这些信息有待核实。

第二，conda 所维护的 pytorch wheel 版本较为滞后，例如本文撰写时，官方源已经有了torch-2.12.0+cu126-cp314-cp314-win_amd64.whl，即，对于 pytorch 2.12 的支持，而 conda 这边才刚到 pytorch 2.10，会落后一些。

第三，conda 这边管理 CUDA 的逻辑不一样，行为可能存在不同，不过笔者还不太了解这方面的底层细节。

第四，conda 配置的 torch 环境体积比 pypi 要更大。以笔者自己的一个 RAG 项目为例，全 pypi 途径配出来的虚拟环境体积为 7.4 GB，而同配置的 pypi 虚拟环境是 5.0 GB，需要多吃两个G的磁盘空间。

AI 的解释：

核心原因在于 PyPI 和 Conda 对 CUDA 运行时的打包哲学完全不同：

  1. PyPI 的哲学（精简定制） ：
    PyPI 上的 torch whl 包，是 PyTorch 官方自己打包的。他们把 CUDA 的底层库（cuBLAS, cuDNN 等）进行了高度定制和裁剪，只把 PyTorch 运行必需的函数编译了进去，然后作为 torch/lib/ 下的几个大 dll/so 文件打包。它不依赖你系统里装没装完整的 CUDA Toolkit。
    (另外，PyPI 版默认使用较轻量的 OpenBLAS 而非 MKL)
  2. Conda 的哲学（大包大揽） ：
    Conda-forge 的打包规范是 “组件化、系统级” 的。它不使用 PyTorch 官方定制裁剪的 CUDA 库，而是把完整的、通用的 CUDA 组件当作独立的包（cudatoolkit, cudnn, cublas 等）一股脑儿装进环境里。
    更要命的是，Conda 默认会给 PyTorch 配上 Intel MKL（数学核心库，就是你看到的 mkl_core.2.dll 和 mkl_avx512.2.dll），MKL 极其庞大，但对纯 GPU 运算来说几乎用不上。

以及这个额外空间是否有价值：

情况 A： Conda（占用额外空间）

  • 适用画像：你未来打算深入 LLM 底层，要在 WSL2 上折腾 FlashAttention、vLLM、DeepSpeed 等前沿库；或者你的 RAG 系统很重，需要榨干 CPU 的每一滴算力做传统检索（BM25/sklearn）。
  • 代价：Win10 原生环境白白浪费 1.5GB，看着有点心烦。

情况 B： PyPI（追求轻巧纯粹）

  • 适用画像：你的主要目标是“把 RAG 跑通”，主要使用 LlamaIndex、LangChain、HuggingFace 预训练模型。你不想折腾底层编译，大模型推理全走 GPU，CPU 只做简单的逻辑调度。
  • 代价：如果某天你真要在 WSL2 上装 FlashAttention，你需要自己手动装一遍 CUDA Toolkit 并配环境变量（大约需要折腾 1-2 小时）。

大概意思就是，Windows 10 上面这就是纯粹的垃圾空间占用，Linux 上面可能还会有点用，可能可以省掉一个 CUDA Toolkit 的空间，不过也得做底层编译库的时候才用得上，新手只做些基本的 RAG 项目，也不一定会需要这些玩意儿。

不过好在 pixi 有完善的全局缓存机制，不管建立多少个虚拟环境，始终只会存一份 cache，所以最终的额外开支也就是这么两三个 GB 的磁盘空间占用。

而 find-links 方案同样需要在磁盘上额外存一份两三个 GB 的 whl 文件（每次开新环境都要取用），这么一想，似乎方法二和方法三区别也不大。

当然了，只要阿里云源仍然可用，那么方法一肯定是首选。

一些可能的其他方法

这些方法都很不漂亮，写这些是因为当时还没试出来方法一，现在的话，这些好像也都没什么试的必要了。

目前这些方案中，pypi index 这里还是没有做到最干净的“多平台通用+团队协作可用+全走镜像”，目前最有希望的是阿里云能够补上 simple api 和 metadata 的支持。

不过用 find-links 体验上也没差，不必强求了。

还有一些其他的点子，没来得及实践过，有想法的朋友可以试试看。

比如将 pixi 当中的 uv 深度配置一下，用 uv 的配置实现抓取阿里云镜像站，这个需要更了解 uv 才行。

或者先用 find-links 在 pixi 的缓存里面生成一份“解压”（不知道这么说准不准，就是把 whl 文件变成一个展开的 Libs 文件夹）过后的缓存，再把它的名字改成 pytorch 官方源的那个 sha。

再或者手动修改 pixi.lock，把里面的下载链接给分离开。因为 pytorch 之所以麻烦，一部分原因是 pypi 是把索引站和下载站分开，而它是二合一的设计，所以阿里云站这个只有下载而没有索引的，就不能被识别上。但是 pixi.lock 是官方明确指出“不应该被人为修改”的文件，所以估计也不好弄，而且每次更新之后都要重新改过。

结论

在 pixi 中配置 pytorch 的几种可行方式如下。

一、如果有良好的网络环境，直接走官方源

优点：省心

缺点：网络不理想的话，下载速度可能非常慢，一个 win-64 的 whl 下载一两个小时未必下得完；linux 的因为体积小，相对还好一些。

二、（最推荐）使用 find-links 设置阿里云镜像源

优点：跨平台可用，团队协作可用

缺点：阿里云源对非常新的版本同步可能会存在滞后；另外 pytorch cuda wheel 可用的镜像源真的很少，阿里云感觉是独苗了。并且搜索以前的帖子发现它曾经也很长时间没有更新过，所以该方案的可用性完全取决于维护团队。

三、如果没有跨平台或者团队协作要同一份配置的需求，可以先在阿里云源下载好 whl，再走本地 find-links 方案

优点：稳定，一劳永逸；对于个人单平台项目很方便

缺点：pixi.lock 带有本地路径，不够漂亮，也不太符合 pixi 的“可复现性”设计理念

四、如果可以接受额外的空间占用和 conda 的解析逻辑，也可以把 pytorch 移到 conda 渠道

优点：国内有丰富的镜像源可选

缺点：会缓存额外的 MKL 和 CUDA 库，增加空间占用

后记

写到最后又顺手做了一下信源核实，找 AI 这么问了一嘴：

https://download.pytorch.org/whl/cu126

尽你所能搜索一下，国内有哪些这个 wheel 的镜像源可用

结果 AI 的回答居然很自然地就把我遇到的最大坑点给带上了：

……

镜像源cu126支持确认使用方式备注
阿里云✅ 明确提供--find-links需替换--index-url为--find-links
南京大学✅ 明确提供--index-url速度较快，更新及时
上海交大⚠️ 未明确替换URL方法为将官方URL替换，cu126支持需自行确认
清华TUNA⚠️ 未明确-i (PyPI)主要加速PyPI依赖，wheel包可能仍需官方源
其他源❌ 未提及-如豆瓣、华为云等，搜索结果未显示提供cu126 wheel

……阿里云开源镜像站提供了 pytorch-wheels 目录，其中包含 cu126 子目录。关键点在于使用 --find-links 参数而非 --index-url，这是成功安装的常见陷阱。

……命令参数混淆：这是最常见的错误。官方命令使用 --index-url，但部分国内镜像（如阿里云）需要改用 --find-links 才能正确识别 wheel 包。若遇到 ERROR: No matching distribution found 错误，请首先检查此参数。

可以看到，在我没有特意强调的情况下，整个回答里反复出现了index-url和find-links这两种方式的区别，这正是我在前面的各种失败尝试中，反复死磕最后才意外撞出来的那个重点。

不仅是 pip，使用 uv 安装时设置国内源，同样有相当不错的帖子，也都指出了这两种方式的要点。例如 AI 搜索出来的 这篇 CSDN 博客。

可以知道，LLM 的网络搜索能力，能方便地找到 pip 和 uv 安装时的这种“坑点”，但是同样的设置变成了 pixi 版本，道理是相通的，都是

这个用不了：

[pypi-dependencies]
torch = { version = "==2.10.0+cu126", index = "https://download.pytorch.org/whl/cu126" }

这个可以用：

[pypi-options]
index-url = "https://pypi.mirrors.ustc.edu.cn/simple"
# extra-index-urls = ["https://pypi.org/simple"]
# index-strategy = "unsafe-best-match"
find-links = [
# Note: similar to --find-links option in pip.
    { url = 'https://mirrors.aliyun.com/pytorch-wheels/cu126' },
    { url = 'https://mirrors.aliyun.com/pytorch-wheels/cpu/' },
]

参数名字都没变，只是换了个场景，AI 就走进死胡同了。

拼命想用 index 这条路跑通，带着我做了许多探索，唯独没想到 pypi-options 其实就是 pip 的同名参数，pip 和 uv 的诸多经验都可以迁移过来的。

估计很多 pixi 的用户一般是都有 pip 等传统安装途径的经验，所以 pixi 官方文档里也没有详细讲解[pypi-options]的内容，默认是“和 pip 一样的”，有经验的开发者只要了解这个事情，就能顺畅地迁移知识。

结果碰上我这种，没怎么用过 pip 或者 uv，一上手直接就是 pixi 的小白，还带着一个同样死脑筋的 LLM，一下就坑爹了。

复盘一下的话，这里面有一条隐性知识，如果我能一开始就给到 AI，说不定它能更早发现这个“正确答案”：

注意，pixi 遵循的设计哲学基本上是从 pip, uv, conda 等地方继承过来的，因此你可以尝试复用这些地方的经验，例如 pypi-options 当中就支持许多 pip 的安装参数，它的渠道指定和 uv 也有类似之处。

这条指令如果一开始点出来了，说不定 AI 就会“触类旁通”了。有空的话可以实验下看看。

（本文完）

2026年5月18日：初稿完成

avatar
文章
阅读
粉丝