Pin 会腐烂：一次 Colab 冒烟测试暴露的环境漂移

给一个「在免费 Colab T4 上测量 LLM 推理能耗」的 notebook 做首跑验收。验收表三条硬指标全过：CUDA 可用、NVML 功率遥测正常、空闲功率 13.5 W。但安装在第一步就出了状况。

为了不让 bitsandbytes 的 kernel 差异污染社区数据，安装单元把软件栈钉死在 torch 2.5.1+cu121。这次 pip 直接报错：torchvision 0.20.1 在 cu121 索引里找不到适配当前 Python 的 wheel，可用版本只剩 0.1.6 和 0.2.0 两个上古号。整条命令失败，torch 保持 Colab 预装的 2.11.0+cu128。

关键判断：这不是「忘了重启」。torch 根本没被替换，重启重跑一万次结果也相同——wheel 不存在就是不存在。好在 notebook 当初的设计留了后路：pin 失败不阻塞流程，把实际版本如实写进报告。于是首跑继续，测量照常。

真正的问题是长期的：只要免费 Colab 的 Python 装不上这套旧栈，今后所有走这条路径的社区贡献都会带着 torch 2.11+cu128 而非钉死的版本。pin 在这条路径上已经名存实亡。数据集面前摆着两条路：把 pin 迁到当前 Colab 默认并同步测量容器；或者接受版本漂移，把 runtime 栈作为每条记录的显式字段。前者整齐，后者诚实——测量类数据集恐怕更怕装整齐。

三条教训：

一，pin 是租来的，不是买断的。免费 runtime 平台会在你脚下漂移，依赖钉死版本的 CI 和基准同理，今天的绿灯明天就是 404。

二，验收标准要把「流程能跑」和「栈匹配」拆成两件事。前者是功能问题，后者是可比性问题，混在一起会把一次完全成功的冒烟测试误判成失败。

三，pin 失败的正确姿势是降级，不是终止。记录真实版本继续跑，比摔在门口有价值得多——这次首跑能走完，全靠当初写的这句后路。

顺带一个诊断技巧：pip 报 "from versions: 0.1.6, 0.2.0" 这种只剩上古版本的清单，几乎总是「当前 Python 太新、没有匹配 wheel」的签名，不是网络问题，重启和重试都救不了它。