被一个 Python 版本卡住半天，EXO 分布式 LLM 踩坑记
被一个 Python 版本卡住半天，EXO 分布式 LLM 踩坑记
dong4j
前言
说实话，我被一个 Python 版本问题折腾了整整一个下午。
事情的起因是这样的：最近看到 EXO 这个项目，说是能在多台设备上分布式运行 LLM。作为一个家里有好几台闲置电脑的人来说，这个项目简直太对我胃口了！
想象一下：家里那台吃灰的 MacBook、闲置的游戏本、还有 NAS，全部联合起来跑大模型…
想到这里我就兴奋起来了，马上准备开干。结果第一步就卡住了——需要 Python 3.12。
我当时还觉得这有什么难的，我用的 Conda 环境更新一下不就行了？结果… 真的被上了一课。
EXO 是什么？为什么让我这么兴奋？
在开始折腾之前，让我先说说为什么这个项目这么吸引我。
传统 LLM 运行方式：
- 一台电脑跑一个模型
- 内存不够就跑不动
- 显卡瓶颈很难突破
EXO 的思路：
- 多台电脑联合运行一个模型
- 自动分配计算任务
- 充分利用所有设备的算力
这意味着什么？意味着我那台 16GB 内存的 MacBook、32GB 内存的台式机、还有 NAS，理论上可以联合起来跑需要 64GB+ 内存才能跑的大模型！
这种想法简直不要太美好。特别是对于我们这种个人玩家来说，不用花大钱买高端显卡，也能体验到大模型的乐趣。
踩坑开始：Python 版本问题
带着这种兴奋的心情，我开始了安装：
1 | git clone https://github.com/exo-explore/exo.git |
结果直接报错：
1 | error: Python 3.12 is required |
当时我还没在意，想着我 Conda 环境里更新一下 Python 版本就行了：
1 | conda activate |
结果一看版本——依然是 3.10.x！
我当时就懵了，怎么会这样？Conda 不应该能直接升级 Python 吗？
查找原因：conda-forge 的坑
经过一番搜索，我才发现了问题的根源：
conda-forge 还没完成 Python 3.12 的迁移工作！
说实话，这是我第一次知道 conda-forge 还有这种”迁移”的概念。
原来每次 Python 大版本升级（比如从 3.11 到 3.12），conda-forge 都要重新编译所有的包来适配新版本。这个过程需要时间，而且不是所有包都能及时完成迁移。
我查了一下 conda-forge Python 3.12 迁移状态，发现确实还在进行中…
这时候我才明白：不是我操作有问题，是整个生态还没跟上。
寻找解决方案
知道了原因，就开始找解决办法。经过各种尝试，我总结了三种可行的方案：
方案一：死磕 Conda（最直接但可能失败）
这是最简单的思路，既然 conda-forge 迁移还没完成，那就等等或者试试看：
1 | conda search python |
这种方法的好处：
- 操作最简单，一步到位
- 和现有 Conda 环境完美兼容
- 依赖管理最清晰
但缺点也很明显：
- 完全依赖 conda-forge 的进度
- 可能根本找不到可用版本
- 就算找到了，版本也可能不是最新的
我试了一下，果然找不到。这个方案 pass。
方案二：手动安装 + Conda 绑定（我开始用的方案）
既然 Conda 源不行，那我就自己装 Python 3.12，然后绑定到 Conda 环境里。
先通过 Homebrew 安装 Python 3.12
1 | brew update |
这里要注意芯片差异：
- Intel 芯片：安装路径是
/usr/local/opt/python@3.12/bin/python3.12 - Apple Silicon：安装路径是
/opt/homebrew/opt/python@3.12/bin/python3.12
创建 Conda 环境并指定 Python 路径
1 | # Intel 芯片 |
激活环境验证
1 | conda activate py312 |
这种方法的优势：
- 可以获取最新版本的 Python 3.12
- 不依赖 conda-forge 的迁移进度
- 相对比较灵活
但踩到的坑也不少：
- 路径管理比较麻烦，不同芯片要记不同的路径
- 有些 Conda 包可能会和手动安装的 Python 有兼容性问题
- 后续升级维护相对复杂
方案三：pyenv + Conda（最终采用的方案）
折腾了一轮后，我发现了一个更优雅的解决方案：pyenv。
pyenv 是一个专门用来管理多个 Python 版本的工具，特别适合我这种需要频繁切换版本的场景。
安装 pyenv
1 | brew install pyenv |
安装 Python 3.12
1 | pyenv install 3.12.0 |
这个过程会编译安装 Python，需要一点时间，但装好后就是纯净的 Python 3.12 环境。
创建 Conda 环境并关联
1 | conda create -n py312 --python=$(pyenv prefix 3.12.0)/bin/python |
这个方案的优点真的很明显：
- 版本管理很清晰：pyenv 负责管理 Python 版本，Conda 负责管理包和环境
- 跨平台兼容：无论是在 Mac、Linux 还是 Windows 上，用法都一致
- 切换灵活：想换 Python 版本只需要改一个参数
常见问题解决
在折腾过程中，我还遇到了几个典型问题，分享一下解决方案：
问题一：Conda 找不到 Python 3.12
现象：执行 conda install python=3.12.8 时提示找不到版本。
解决方法：
1 | # 确认添加了 conda-forge 源 |
问题二：环境激活后版本没变
现象：激活环境后，python --version 还是显示旧版本。
解决方法：
1 | # 检查 Python 路径 |
问题三：依赖冲突
现象：创建环境时出现各种依赖冲突。
解决方法：
1 | # 创建纯净环境 |
最终验证
折腾完这些，终于可以验证 EXO 安装了：
1 | # 激活环境 |
看到安装成功的提示，我真的有种如释重负的感觉。
我的收获和思考
这次折腾虽然花了不少时间，但收获还是很大的：
1. 对 Python 生态有了更深的理解
以前我以为 Conda 就是 Python 环境管理的终点，现在才明白：
- Conda：更像是科学计算生态的环境管理器
- pyenv：才是纯粹的 Python 版本管理器
- Homebrew：macOS 系统级的包管理器
三者各有侧重，结合起来用才是最佳实践。
2. 开源生态的复杂性和脆弱性
通过这次经历，我深刻体会到开源生态的复杂性：
一个简单的 Python 版本要求，背后牵扯到：
- 不同包管理器的兼容性
- 社区维护的进度差异
- 平台适配的复杂性
难怪很多企业选择闭源方案，虽然灵活性差一些，但稳定性和一致性有保障。
3. 解决问题的方法论
这次的经历也让我总结出了一套解决问题的思路：
- 先查文档：确定是操作问题还是环境问题
- 搜源码和 issue：看看别人是否遇到过类似问题
- 理解根本原因：比如这次理解了 conda-forge 的迁移机制
- 多方案并行：不要死磕一个方案，同时尝试几种可能性
- 记录经验：把解决过程写下来，下次遇到类似问题就能快速解决
后续计划
虽然 Python 版本问题解决了，但 EXO 的使用才刚刚开始。我接下来计划：
- 在多台设备上部署 EXO：把家里的 Mac Mini、MacBook 都连起来
- 测试性能表现：看看分布式运行效果如何
- 优化网络配置：确保设备间通信稳定
- 写个管理界面：方便监控各设备状态
如果这些尝试成功了，我会再写文章分享经验。
最后想说的话
折腾技术这事儿就是这样：看起来很简单的问题，背后可能隐藏着一堆坑。
但正是这种踩坑、填坑的过程，让我们对技术的理解越来越深。现在回过头看，如果一开始就顺利装好了，我可能永远都不会知道 conda-forge 的迁移机制，也不会去了解 pyenv 的强大功能。
所以，遇到问题不要慌，把它当作学习的机会。每个坑填平后，你的技术栈就更坚实了一层。
希望这篇文章能帮到那些同样被 Python 版本问题困扰的朋友们。如果你也在尝试 EXO 或者有更好的解决方案，欢迎交流！
