如果你看到下面这行字说明你大概率正在装PyTorch或者任何一个依赖比较复杂的包Solving environment: failed with initial frozen solve. Retrying with flexible solve.然后画面就停在这儿CPU风扇开始狂转几分钟过去仍然没有任何新输出。我第一次遇到时以为电脑死机了差点直接按电源键。后来才发现这行英文其实不是最终失败而是conda告诉你它的第一种求解思路失败了正在换一种“更灵活”的思路重试。问题在于这种重试有时候会持续很久甚至最终仍然报错。这篇文章我会先讲清楚这个报错到底在干嘛然后给出我自己实测有效的几个解决方案最后用一次完整安装过程展示从踩坑到上岸的全流程。你在装PyTorch时卡在这一步的话照着往下做大概率能省下一晚上的折腾时间。1. 看懂报错frozen solve与flexible solve到底是怎么回事1.1 conda在遇到这个报错时做了什么要理解这个报错得先搞清楚conda的工作方式。当你执行一条安装命令时conda会面对一个巨大的“依赖拼图”当前环境里已有哪些包、这些包依赖什么、你要装的新包又依赖什么所有依赖约束叠在一起它会尝试找出一个满足所有条件的版本组合。这个过程叫依赖求解solve。conda的求解分两步走第一步先做一个“冻结求解”frozen solve。所谓冻结就是假设当前环境里已经安装的所有包版本都不能动只把新包加进去看看能不能不挪动老包、不改变任何现有版本的情况下找到一组可行的搭配。如果第一步失败也就是现有约束把新包的依赖挤得没位置了conda就会自动进入“灵活求解”flexible solve。这时它会允许对部分已安装包进行升级、降级甚至移除只要最终组合能满足所有包的要求。所以你看到的报错信息翻译过来就是先试了“把所有家具原地不动塞进新沙发”的方案没成功现在改成“可以挪茶几、搬柜子、扔纸箱”的灵活方案重试。conda这么做是为了尽量保留你现有的环境但代价是从“一定有可行解”的假设变成了“可能需要动很多东西”计算量成倍增加。1.2 为什么你的环境会触发失败“冻结求解失败”本身并不可怕它只是说明在完全不改变现状的前提下新包和你环境里的老包没法共存。触发这个现象的原因我总结下来主要有这么几类conda版本太旧。老版本conda的求解器处理不了复杂的依赖树遇到稍微多一点的依赖关系就自动放弃“冻结解”转而进入灵活求解。而灵活求解又因为算法低效跑得极其慢。当前环境里包太多太杂。在base环境里装PyTorch是最典型的场景。base环境里通常已经有了几十上百个包这些包之间早就形成了一堆脆弱的版本默契。你现在突然要加一个“数量大、依赖多、版本卡得死”的PyTorchconda的第一套方案当然很容易碰壁。channel来源太乱。如果你同时用了pytorch、conda-forge、defaults三个channel而且没有设置优先级conda会同时考虑三个来源的同名包版本。不同channel对同一个依赖包的元数据可能有差异这些差异足以让求解器找不出一个“完全不动老包”的组合。目标包版本与当前Python版本不匹配。比如你想在Python 3.12里装一个很久以前的PyTorch版本老版本可能根本还没支持新Python这等于给求解器出了一道无解题。网络源索引不同步。有些镜像源的包索引更新不及时conda读取到的是残缺或过期的依赖信息求解器在错误的原始数据上做计算自然容易失败。这些原因里前两种我遇到过最多后三种在特殊环境下也很折磨人。1.3 怎么判断它到底是卡死了还是在算终端里进度条不动CPU风扇却呼呼吹这种状态最容易让人焦虑。我的经验是打开任务管理器或者用命令查看CPU占用如果进程的CPU占用率很高说明求解器正在满负荷工作它没死就是还在算。如果CPU占用率很低甚至为0那多半不是求解而是卡在了网络请求上比如读取channel索引的时候连接超时。如果你不想等它算完可以按CtrlC中断。中断之前建议先把自己当前的操作记下来在哪个环境、装的什么包、用了哪些channel参数。这样重新尝试时有一份参考不会越试越乱。这一部分的核心结论是这个报错只是“第一方案失败”的提示不是世界末日。真正要解决的问题是让conda从“憋大招式求解”变成“快速给出可行解”甚至干脆换一个工具来解。2. 立竿见影的三个方案按顺序试别上来就重装下面三个方案是我实际使用中跑得通的建议按顺序尝试。如果第一个不行再试第二个大部分情况在第二个就能解决。2.1 方案一升级conda并启用libmamba求解器conda的经典求解器确实太老了。Anaconda官方后来推出了新一代求解器libmamba由C实现比原来的Python求解器快好几倍处理依赖冲突的能力也更强。很多老版本conda之所以动不动进入flexible solve然后卡半天就是因为老求解器对复杂依赖树的优化不足。你可以先升级conda再安装libmamba求解器然后把它设为默认求解器。具体命令如下conda update -n base conda -c defaults conda install -n base conda-libmamba-solver -c conda-forge conda config --set solver libmamba执行完成后再次运行你原来的安装命令。我自己在升级完conda并切换求解器后原来的报错直接消失安装流程很快进入下载阶段。如果你暂时不想升级base环境里的包可以跳过第一条直接装libmamba solver并切换。切换后遇到奇怪问题想回到默认求解器执行conda config --set solver classic切换求解器后如果出现“ResolvePackageNotFound”通常不是逻辑问题而是缓存里的旧索引没刷新。先执行一次清理再重装conda clean -a这个方案背后的逻辑很简单conda的求解器就像一个翻译官旧翻译官遇到复杂谈判很容易死机libmamba是换了翻译策略用更高效的算法把依赖树快速理清。它不一定能解决所有冲突但能极大减少“求解卡住”的概率。2.2 方案二用mamba当外援mamba是社区一个非常流行的包管理器它保持了conda的用法和配置方式但底层求解器换成了libsolv速度和稳定性都远胜经典conda。用它来解决frozen solve失败核心思路就是“别让conda自己算了让mamba来算”。如果你已经有一个conda环境可以直接在base里安装mambaconda install -c conda-forge mamba -n base然后用mamba替代conda安装PyTorchmamba install pytorch torchvision torchaudio cpuonly -c pytorchmamba的求解过程非常快几秒钟就能给出可行解。就算真的无解它也会很快告诉你具体是哪些包、哪些版本之间存在冲突而不是像conda那样闷头算十几分钟再给结果。如果你一开始就不想用Anaconda的完整版环境另一个选择是安装精简发行版。这类发行版自带mamba默认channel是conda-forge对新手很友好而且体积小很多。我自己后来的很多项目都直接用它建环境很少再被conda的求解折磨。2.3 方案三绕开conda直接上pipPyTorch官方对pip的支持已经非常成熟。如果conda这种重量级包管理器在你的环境里确实“带不动”那就别和它较劲直接切到pip。先创建一个干净环境conda create -n torch_env python3.11 -y conda activate torch_env然后执行pip安装。有CUDA需求的话安装时带上官方指定的index URLpip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118不需要GPU的话直接装默认的CPU版本pip install torch torchvision torchaudiopip的依赖解析器同样严谨但对“目标明确”的安装场景更直接。它不会试图扫描你环境里的所有包并重新组合而是按已有约束快速定位一套版本。缺点是pip和conda混用需要特别小心如果你在conda环境里用pip装了一堆包之后再用conda安装其他库conda可能会因为你绕过它安装了一些包而出现“环境状态不一致”的提示。我的习惯是专门用一个独立环境给pip折腾装什么都不影响其他环境。3. 一次完整实操记录从建环境到装好PyTorch说了这么多理论与方案我用一次真实发生过的安装过程带你从头到尾走一遍。3.1 动手前先确认目标这次的目标是建一个独立的Python 3.10环境用来跑PyTorch 2.x并且只做CPU推理实验不涉及GPU。所以不需要安装CUDA相关组件。环境名我取成torch_cpu方便一看就知道用途。为什么不直接用base环境因为base环境里已经有非常多的包直接装PyTorch很容易触发标题里那个报错。独立环境的好处是初始状态干净依赖约束少求解器压力小。这一步看着多敲了几个字符其实能省下后面无数麻烦。3.2 建环境时顺手做铺垫创建环境的命令conda create -n torch_cpu python3.10 -y conda activate torch_cpu创建完之后可以先看一眼当前Python版本和pip版本python --version pip --version如果发现pip版本很旧可以先升级一下避免后面用到pip时出问题pip install --upgrade pip3.3 安装PyTorch时的命令边界接下来执行安装注意“-c pytorch”这个参数。我只指定了pytorch这一个channel没有混入conda-forge。命令如下conda install -n torch_cpu pytorch torchvision torchaudio cpuonly -c pytorch这里的cpuonly是让conda只安装CPU版本不碰CUDA相关依赖。如果你有NVIDIA GPU需要去掉它改成安装GPU版本。关键点是如果你不加-c pytorchconda可能会在默认源里找包默认源的PyTorch版本更新不一定及时依赖匹配也容易出问题。指定官方channel后依赖会优先从官方路径解析冲突概率明显降低。我执行完这条命令后就碰到了本文标题里的报错。当时先是停了几秒然后输出failed with initial frozen solve. Retrying with flexible solve.之后CPU占用飙升卡了大约三分钟。我直接按CtrlC然后切换到libmamba求解器再次执行同样的命令。3.4 切换求解器后的安装结果切换libmamba后再次执行安装命令这次过程明显轻快很多。它不再是“先卡住再看运气”而是快速完成依赖解析然后列出将要安装的包清单并询问确认。我确认后进入下载和解压阶段整个过程下来不到五分钟。安装完成后的验证步骤python -c import torch; print(torch.__version__); print(torch.backends.mps.is_available())在纯CPU机器上MPS输出False是正常的torch.__version__能正确打印说明安装成功。如果你装的是GPU版本验证命令应该是python -c import torch; print(torch.cuda.is_available())返回True才说明CUDA环境也接上了。这里我想多提醒一句安装完成后如果你发现自带的numpy、pillow等基础库版本比预期旧或新不要急着手动降级或升级。PyTorch和它们之间的依赖关系很微妙手一抖改了版本下次再跑代码可能冒出一堆不相关的报错。4. 通用排查技巧与问题速查表如果试了上面的方案还是失败说明问题比较特殊那就需要学会自己“审案”了。4.1 如何快速判断冲突在哪首先可以重试原安装命令但加上--solver classic -v来输出详细日志conda install --solver classic -v pytorch torchvision torchaudio cpuonly -c pytorch日志中凡是带有“Conflict”的行基本都是解题线索。比如日志告诉你某个包要求“numpy1.20”而另一个包要求“numpy1.20”那你立刻就知道问题集中在numpy版本上。还有一种更简单的方式先看当前环境里已经有哪些核心包conda list重点看Python版本、pip版本、gcc相关库版本。PyTorch对底层C库版本很敏感如果环境里某个动态链接库被降到了旧版安装时虽然不一定报错但运行时可能给你一个“undefined symbol”的错这就更痛苦了。4.2 常见问题原因与处置对照表我整理了一张速查表平时遇到这个问题可以直接对照问题特征最可能原因建议动作卡住后最终报UnsatisfiableError版本组合太新或太旧根本无解降低或提高Python版本换一个PyTorch次要版本试试只在base环境里报错base依赖过重建一个干净独立环境别在base里折腾升级conda后仍然报错channel优先级混乱检查conda config --show channel_priority统一channel顺序pip安装后conda环境状态乱了conda和pip的记录不同步回滚到初始环境尽量保持一种包管理器主导网络差导致索引读取不完整缓存中的包索引陈旧执行conda clean -a换个时间段再试4.3 两个容易被忽略的细节缓存与channel优先级第一个细节是缓存。conda的缓存目录里存着大量包索引和下载过的压缩包。时间一长有些文件会损坏或缺失。conda拿这些残缺数据去参与求解时会有一些看起来很玄学的失败。执行conda clean -a虽然会删掉缓存里的所有包但这些包下次用到时再重新下载就好影响不大。我遇到很多“同一命令第一次失败、第二次成功”的情况清理缓存往往是背后的解释变数。第二个细节是channel的先后顺序。conda安装命令里-c参数的顺序会影响优先级。比如-c pytorch -c conda-forge和-c conda-forge -c pytorch解析结果可能完全不同。尤其当两个channel都提供同一个包的不同版本时顺序不同会让求解器偏向不同的版本组合。我的建议是一旦确认用某个channel组合能成功就固定下来不要今天用这个顺序明天换另一个顺序。反复横跳只会让环境状态越来越乱。5. 从更长期的角度避免这类安装问题解决一次报错只是第一步我更希望你在后面的项目中少踩类似的坑。5.1 把环境当一次性项目来管理不要在base环境里做所有事情。base环境应该只负责维护conda本身任何项目相关的依赖都应该单独建环境。项目环境命名最好带上用途关键词比如torch_cpu、nlp_playground。好处有两个第一依赖隔离不同项目之间的包版本互相不影响第二随时可以推倒重来环境折腾坏了删掉再建远比修复要快。我这里特别想说很多人习惯打开一个终端直接conda install也不看自己在哪个环境。等到某个项目跑不起来了才发现环境里的包已经被改得面目全非。5.2 用锁定文件固化版本组合如果你有和别人协作的需求或者过几个月后还要还原今天的实验结果建议在环境稳定后导出锁定文件conda env export -n torch_cpu environment.yml或者精确到每个包的下载地址conda list --explicit spec-file.txt之后重建环境时conda create -n torch_cpu --file spec-file.txt这种方法不再让conda重新做一轮复杂的依赖求解而是直接把之前验证过的状态搬回来理论上可以避免很多版本漂移导致的坑。我在做教学演示时通常会把锁定文件一起归档比只丢一个requirements.txt靠谱得多。5.3 conda与pip各取所长我现在的选择习惯是重量级、涉及二进制依赖的包优先用conda比如CUDA、MKL、OpenMP相关的库轻量级、纯Python、对系统库没需求或者需要最新版的包则倾向于用pip比如一些源码安装的小工具。PyTorch这种“半重不重”的库官方对conda和pip都支持得很好选哪个都能跑通。真正重要的是别在一个环境里频繁混用两个包管理器。如果你已经在conda环境里装了大量依赖就别再用pip装一堆不同版本的同名库。想用pip时独立建环境或者先记录好当前状态都是可以接受的折中。我个人在实际操作中的体会是frozen solve这类报错往往不是代码问题而是工具在替你“扛雷”。理解它的机制比绕开它更重要。我一开始遇到这个报错时只想着“换个源”“重装conda”折腾到半夜。后来耐着性子看了日志才发现每次冲突的原因都很清晰基本都出在我把一个不干净的环境当成了万能试验场。从那以后我坚持先建独立环境、统一channel、再选一个顺手的求解器这套组合拳打下来几乎再也没被这条报错卡住过。最后分享一个小技巧遇到任何conda求解卡顿先新建一个终端执行conda clean -a再重试一次有时候那一行报错只是缓存给惹的祸清理完就安静了。