如果你做Python开发超过半年，你一定用过venv。大概率你也遇到过这种情况：项目A要求torch 2.1+CUDA 11.8，项目B要求torch 2.3+CUDA 12.1，你傻傻地把它们装在同一个环境里，然后pip告诉你依赖冲突，或者更惨——装上了但跑起来报莫名其妙的CUDA错误。这时候你才意识到，原来虚拟环境不只是"推荐做法"，而是"生存必需"。
我这AI口播视频工具项目更夸张——三个微服务各自需要不同的Python依赖环境。这篇文章我想聊聊我是怎么管理多个venv的，包括为什么需要多venv、怎么组织、怎么自动化、以及踩过的那些坑。如果你也在做需要多个Python环境的项目，这篇文章应该能给你一些启发。
噩梦的开始：一个环境装不下两个AI模型
事情的起因很简单：我的项目需要两个AI模型——IndexTTS2做语音合成，LatentSync做唇形同步。这两个模型都是基于PyTorch的，听起来没什么问题对吧？
但问题出在CUDA版本上。IndexTTS2用的是比较新的PyTorch版本，要求CUDA 12.1以上。而LatentSync当时的最新release是基于PyTorch 2.0+CUDA 11.8编译的。我在同一个venv里尝试统一版本，选择了PyTorch 2.3+CUDA 12.1。结果IndexTTS2跑得很开心，LatentSync直接报了一堆CUDA kernel launch失败的错误，完全跑不起来。
那反过来呢？我试了试装CUDA 11.8版本的PyTorch。这次LatentSync好了，但IndexTTS2又不行了，因为它的某些依赖需要CUDA 12.1的新特性。
这一下我明白了：这两个模型不可能装在同一个Python环境里。不是代码的问题，是底层CUDA库的二进制兼容性问题。PyTorch的CUDA版本是编译时就确定的，同一个环境里只能有一个CUDA版本的PyTorch。
解决方案：一个服务一个venv
想通了这个问题之后，解决方案就很清晰了：给每个微服务建一个独立的venv。
API服务不需要GPU，不需要PyTorch，只要FastAPI和一些工具库。所以它的venv最轻量，一个requirements.txt只有十几行。
TTS服务需要IndexTTS2 + PyTorch 2.3 + CUDA 12.1。这个环境比较大，PyTorch本身就要2GB多，加上IndexTTS2的依赖，总共大概有3GB。
Latent服务需要LatentSync + PyTorch 2.0 + CUDA 11.8。同理，也是一个大环境。
这三个venv完全独立，各自有自己的Python解释器、各自的site-packages、各自的PyTorch版本。井水不犯河水。
目录结构大概是这样：project/
├── envs/
│ ├── api/
│ │ └── Scripts/python.exe
│ ├── tts/
│ │ └── Scripts/python.exe
│ └── latent/
│ └── Scripts/python.exe
├── services/
│ ├── api_server/
│ ├── tts_server/
│ └── latent_server/
└── electron/
坑一：CUDA版本的"看起来一样"陷阱
管理多个venv的时候，有一个特别容易踩的坑：CUDA版本号不能只看大版本。
比如说，PyTorch官网下载页面写着"CUDA 11.8"和"CUDA 12.1"。你以为只需要选对版本就行了？没那么简单。CUDA 11.8本身还有很多小版本：11.8.0、11.8.1等等。你的NVIDIA驱动支持的最高CUDA版本、你的显卡驱动版本、PyTorch编译时用的CUDA小版本，这三者必须兼容。
我遇到过一个诡异的问题：Latent服务在开发机上跑得好好的，换到我笔记本上就报 CUDA error: no kernel image is available for execution on the device。查了半天发现是笔记本的RTX 5060显卡架构太新了（Blackwell架构），而PyTorch 2.0+CUDA 11.8这个组合是在老架构上编译的，对新显卡支持不完整。最后我不得不给Latent服务换了一个更新版本的PyTorch，但这就意味着要放弃原来的CUDA 11.8，重新适配。
教训：选PyTorch版本的时候，不光要看CUDA大版本，还要确认它支持你的显卡架构。
坑二：依赖传递——一个库的更新可能破坏整个环境
三个venv独立管理，听起来清爽，但实际上对依赖管理的要求更高了。
举个例子：TTS服务的venv里装了numpy 1.24，一切都好好的。有一天我要给TTS加一个新功能，引入了一个第三方库，这个库依赖numpy 2.0。pip install的时候pip说"numpy版本不兼容"，然后"好心地"帮我把numpy升级到了2.0。结果IndexTTS2炸了，因为它的一些底层代码用到numpy 1.x的API，在2.0里被移除或者改名了。
这种问题在单一venv的项目里也会出现，但在多venv的场景下更危险——因为你会潜意识里觉得"这是个独立环境，随便折腾不影响其他服务"，于是就少了敬畏心。pip install之前不看依赖树，装完才发现炸了。
后来我养成了一个习惯：每个venv的requirements.txt都锁死版本号。不是 numpy 而是 numpy==1.24.3。每次添加新依赖的时候，先用 pip install --dry-run 看看会不会导致版本冲突，确认没问题了再真正安装。虽然麻烦，但省了无数次debug的时间。
坑三：环境创建——手动的噩梦，自动化的救赎
三个venv，每个都要手动创建、手动激活、手动pip install一堆东西。第一次搭建环境的时候我搞了整整一个下午，装完TTS环境装Latent环境，切来切去脑子都乱了。更要命的是，如果换一台电脑或者重装系统，这些步骤还得再来一遍。
所以我很早就写了一个 setup_envs.py 脚本，自动化整个环境搭建流程。这个脚本做了几件事：
- 检查系统Python版本是否满足要求（>= 3.9）
- 在
envs/目录下依次创建三个venv - 每个venv用对应的requirements.txt安装依赖
- 验证每个环境的PyTorch是否能正确识别CUDA
- 生成一个环境报告，列出每个venv的Python版本、PyTorch版本、CUDA版本
有了这个脚本，环境搭建从半天缩短到了一行命令：python setup_envs.py。唯一的等待时间是下载PyTorch（大概5-10分钟），但至少不用人工盯着了。
另外我还做了一个验证脚本 check_envs.py，每次启动应用的时候Electron会调用这个脚本，快速检查三个venv是否完整、依赖是否正确安装。如果检测到环境有问题（比如venv文件夹不完整、关键包缺失），就提示用户重新运行环境搭建脚本。这个验证大概只需要2秒钟，但能避免很多运行时才发现的问题。
坑四：Windows上的路径地狱
在Windows上管理多个venv，有一个绕不开的问题：路径。
Windows的路径分隔符是反斜杠（\），而Python、Node.js、各种配置文件里有时要求正斜杠（/），有时要求双反斜杠（\\），稍不注意就出错。更麻烦的是，Windows的路径长度有260字符的限制，如果你的项目路径比较深，venv里的某些依赖路径可能会超过这个限制，导致pip install失败。
我踩过一个特别蠢的坑：在Electron主进程里用Node.js的 path.join() 拼接Python venv的路径，传给了Python子进程。Node.js的 path.join() 用的是反斜杠，在Windows上没问题。但Python子进程里我用了 os.path.join() 做了一些路径拼接，结果某些地方反斜杠被当成了转义字符，路径直接解析错误。花了一个多小时才定位到问题。
解决方案是：所有跨进程传递的路径统一用正斜杠，Python端接收后用os.path.normpath()转换。Node.js端用 path.posix.join() 代替 path.join() 来生成正斜杠路径。
坑五：磁盘空间——三个venv加起来有多大？
三个venv里，最大的就是TTS和Latent的环境，每个大概3GB左右。加上API环境大概200MB，总共约6.5GB。再加上项目代码、Electron的node_modules（这个也是大户，大概1.5GB），整个项目文件夹接近10GB。
10GB对于一个桌面应用来说不算小。如果你用的是一块256GB的固态硬盘，10GB占比也不小。而且三个venv里其实有大量的重复内容——比如numpy、scipy这些基础库，三个环境可能都装了，但因为venv是隔离的，它们各自存了一份。
目前我还没有很好的方案解决重复依赖的问题。想过用符号链接或者硬链接来共享相同的包文件，但Windows上符号链接需要管理员权限，硬链接在不同分区之间不生效。另一个思路是用pip的 --target 参数把所有共享的包安装到一个公共目录，但这会让环境管理变得复杂。权衡之后我还是接受了10GB的代价——反正现在的硬盘容量动辄1TB，10GB还在可接受范围内。
我的venv管理法则
经历了这么多坑之后，我总结了一套管理多venv项目的法则：
- 一个环境只做一件事。如果一个venv里同时需要两个有依赖冲突的包，说明你应该拆成两个venv。
- 版本号锁死。requirements.txt里不要用
>=，用==。可重现性比"最新版本"更重要。 - 自动化搭建。花点时间写一个环境搭建脚本，回报远超投入。
- 环境验证前置。应用启动时先检查环境完整性，不要等到用到某个功能的时候才发现依赖缺失。
- 记录环境配置。每次改了依赖，在CHANGELOG里记一笔。三个月后你会感谢现在的自己。
管理多个venv确实比管理单个venv麻烦，但这种麻烦是结构性的——它解决的是依赖冲突这个根本问题。当你不用再为"这个包要求numpy 1.x，那个包要求numpy 2.x"而头疼的时候，你会觉得多几个venv的代价完全值得。
最后的话
虚拟环境是Python生态里最基础也最容易被忽视的工具。很多开发者觉得"我就是一个小项目，一个venv够了"。但在AI领域，依赖冲突几乎不可避免——不同的模型、不同的PyTorch版本、不同的CUDA版本，这些东西的排列组合太多了，指望它们都兼容同一个环境是不现实的。
与其花时间在依赖冲突上debug，不如一开始就用多venv做好隔离。麻烦一次，省心一直。这就是我在这个项目中学到的最重要的一课。