CMGS(@CMGS1988):记录下回去再写，infra 铁饭碗的本质是 trade-off 和背锅…这些恰好是 AI 做不到的…数据过拟合导致贪心算法过于贪心。但凡事都是有代价的，举个简单例子，你去翻 E2B 或者 Fly 的实现里面为了进程快速启动都用上了 Uffd 和 FUSE 懒载入，当然 Composefs 应该是这个名字也是同样的套路，看上去设备层启动是快了，那么代价是什么呢？我们就观察到 OS 重载尤其是接 DHCP 的前提下 UFFD 性能极差。简单的来说即便是 snapshots clone vm，你用 UFFD 看上去进程启动快了 1 倍(省掉了内存载入)，但 OS 恢复到可用耗时可能慢了 2 倍，这就要 trade 了，每个系统的表现都不一样，资源配额大小也有影响，这些 AI 就跟人一样，需要调教，不管啥样的模型…这一点上 Fable 也做得不太好，一样需要外部输入。当然了也得承认端到端的优化本身就是个难题，过去靠人也只能一点点磨，现在只不过更方便了而已，像镜像层数优化，initrd 的重写，AI 执行我觉得没问题了，策略层面还是差很多…

CMGS@CMGS1988

2026.07.07 09:36

记录下回去再写，infra 铁饭碗的本质是 trade-off 和背锅…这些恰好是 AI 做不到的…数据过拟合导致贪心算法过于贪心。但凡事都是有代价的，举个简单例子，你去翻 E2B 或者 Fly 的实现里面为了进程快速启动都用上了 Uffd 和 FUSE 懒载入，当然 Composefs 应该是这个名字也是同样的套路，看上去设备层启动是快了，那么代价是什么呢？我们就观察到 OS 重载尤其是接 DHCP 的前提下 UFFD 性能极差。简单的来说即便是 snapshots clone vm，你用 UFFD 看上去进程启动快了 1 倍(省掉了内存载入)，但 OS 恢复到可用耗时可能慢了 2 倍，这就要 trade 了，每个系统的表现都不一样，资源配额大小也有影响，这些 AI 就跟人一样，需要调教，不管啥样的模型…这一点上 Fable 也做得不太好，一样需要外部输入。当然了也得承认端到端的优化本身就是个难题，过去靠人也只能一点点磨，现在只不过更方便了而已，像镜像层数优化，initrd 的重写，AI 执行我觉得没问题了，策略层面还是差很多…

Forward to community