ComfyUI迁移Arm踩坑：依赖版本不等于兼容

同一份 requirements.txt、同一个 ComfyUI 提交，搬到另一台机器，装出来的依赖和生成的图片仍然可能不同。作者把 SDXL 工作流从 Intel Arc 笔记本迁到 Arm Windows 的 WSL2，成功用官方 PyTorch CUDA 构建跑通 GPU，缓存模型后的重绘约快了 2.4 倍。

更有用的是迁移中的排查过程：包能安装不等于能运行，版本号不必相同，CUDA 构建却要兼容；固定 seed，也不能保证跨 GPU 生成同一张图。这些经验适合正在本地部署图像工作流的程序员参考。

固定代码提交，为什么还原不了运行环境

作者迁移的是已有工作流：SDXL img2img，配合线稿和 tile ControlNet。ComfyUI 提交、自定义节点和 4 个模型文件保持一致，CPU 架构与 GPU 厂商同时更换，从 Intel Arc 140V 的 XPU 环境，迁到 Surface Laptop Ultra 的 Windows 11 Arm64、NVIDIA RTX Spark N1X 和 WSL2。

代码固定，依赖却没固定。requirements 大多只写包名，部分只有下限，例如 numpy>=1.25.0。迁移时 numpy 从 1.26.4 变成 2.5.2，opencv-python 从 4.10 变成 5.0。

固定仓库提交，只固定了依赖声明，没有固定解析出来的环境。

作者保存了完整的 pip freeze，方便以后追查差异。但它也不是跨平台安装保证：记录版本之外，还得看目标平台有没有对应 wheel，以及 wheel 使用什么 CUDA 构建。

安装前，作者检查两份 requirements 是否包含 git+、URL、-e、--index-url、--extra-index-url、--find-links，确认没有额外来源。约 9.5GiB 的 4 个模型则在复制后核对 SHA256 和字节数，放入 WSL2 后再用 sha256sum -c 检查，全部一致。

内存设置也有一个容易误读的地方。WSL2 默认拿 Windows 总内存的 50%；机器给 GPU 分配了 95.5GB，Windows 侧约剩 31GB，WSL2 因而只看到约 15GB。作者通过 %USERPROFILE%.wslconfig 设置 memory=24GB，执行 wsl --shutdown 后重启，free -g 显示总量 23GB。

不过，首轮生成实测内存峰值只有 5.5GiB。24GB 是为后续更大模型留空间，不能据此认定这个工作流必须调大内存。

torchaudio 的坑，为什么不能靠对齐版本号解决

官方 Linux Arm 构建 torch 2.14.1+cu132 直接跑通了 GPU，cuda.is_available() 返回 True。GPU 的计算能力是 12.1，get_arch_list() 虽然最高只有 sm_120，生成仍然成功；按原文引用的兼容规则，同一主版本下，较低次版本的 cubin 可以在较高次版本 GPU 上运行。

卡住的是 torchaudio。作者最初想找与 torch 同号的 2.14.1，这是错误前提：从 torchaudio 2.11 起，它不再绑定某个 torch 版本。METADATA 中，2.10.0 还声明 torch==2.10.0，2.11.0 已没有这项依赖。

但解除版本绑定，不等于二进制随便搭配。PyPI 的 aarch64 torchaudio 2.11.0 可以安装，导入时却报错：

RuntimeError: Detected that PyTorch and TorchAudio were compiled with different CUDA versions. PyTorch has CUDA version 13.2 whereas TorchAudio has CUDA version 13.0. Please install the TorchAudio version that matches your PyTorch version.

要看的是报错中的 CUDA 13.2 和 CUDA 13.0，而不是最后一句笼统的「匹配版本」。

图像流程用不到音频，作者先去掉 torchaudio，并用 constraints 防止已装好的 torch、torchvision 被依赖解析替换。原文给出的示意命令如下，并非当时逐字执行的命令：

pip freeze | grep -E '^(torch|torchvision)==' > constraints.txt
grep -v '^torchaudio' requirements.txt > requirements-noaudio.txt
pip install -r requirements-noaudio.txt -c constraints.txt

关键是最后一行的 -c constraints.txt，它约束安装结果。作者没有实际观察到 torch 被替换；这一步是在保护已有 CUDA 13.2 环境。

随后，作者在复制的 venv 中，用 --no-deps 从 https://download.pytorch.org/whl/test/cu132 安装 torchaudio==2.11.0+cu132。导入检查通过，MelSpectrogram 和 resample 能在 GPU 运行，节点从 706 增至 732，音频节点从 20 增至 45。但其 version 仍显示 2.11.0+cu130，进一步说明显示字符串不能代替运行验证。

这里必须带上时间边界：上述是 2026 年 10 月记录。11 月更新说明，稳定源已加入 Linux aarch64 的 torchaudio 2.11.1+cu132，作者尚未安装测试。因此，「稳定源没有对应构建」已不再成立。ComfyUI 从 v0.38.0 起也已移除 torchaudio 依赖，更新时的 v0.45.0 仍未包含它。

快了 2.4 倍，为什么同一个 seed 却画不一样

性能测试比较的是热运行。两台机器都重启 ComfyUI，先生成一次预热，再比较第 2–5 次运行；这些运行只改变 seed，模型、线稿预处理和 VAEEncode 已缓存，计时只覆盖采样、解码、保存。

日志时间从旧机器的 50.87 秒降到新机器的 21.60 秒，约快 2.4 倍。

这个数字描述的是缓存后的重绘速度，不能当作完整出图耗时。

输出比较则使用相同工作流、输入和 seed，并额外保存 AnimeLineArt 预处理结果。预处理有 96% 像素完全一致，其余差值最多为 4，最终图像的 SSIM 却只有 0.45。按 4×4 网格拆分后，各区域平均像素差都在 19–34，变化遍布整张图。

作者据此把差异定位到生成阶段，并从 euler_ancestral 的实现提出解释：comfy/sample.py 在 CPU 上按 seed 生成初始噪声，comfy/k_diffusion/sampling.py 中每一步新增的噪声则来自 latent 所在设备的随机数生成器。CUDA 与 Intel GPU 的随机数序列可能不同，采样过程就逐渐分开。

这是有代码依据的推断，但作者没有提取两台机器的随机序列验证，不能写成已经证实的唯一原因。

跨机器结果的 PSNR 为 15.3dB；Surface 不同日期之间为 37.3dB，旧机器升级版本前后为 25.5dB。数值越高，通常越接近。作者观察到构图、人物和文字位置相近，颜色、字形和背景小物件不同，没有主观认定哪张质量更差。

比较也留有缺口：旧机器后来已升级到 Python 3.14、numpy 2.5.4、opencv-python 4.14，所以没有单独验证 numpy 1.26.4 到 2.5 的影响。

我的判断

这次迁移最值得借鉴的是验证方法：分别检查依赖安装、模块导入、GPU 算子和实际工作流，再把预处理与生成结果拆开比较。只看到 pip 成功或页面能打开，都不足以确认环境可用。

裁掉不用的依赖也合理，但前提是明确工作流边界。作者跳过 mediapipe，因为没有使用人脸、姿态、手部节点；mediapipe 0.10.33 没有 Linux aarch64 wheel，1.1.1 虽有，节点包是否兼容 1.x 尚未验证。缺少 onnxruntime 触发的 DWPose CPU 回退，也恰好不影响这条流程。不能把这份删减方案推广到所有工作流。

2.4 倍提速是两台整机、两套运行栈的结果，不能归因成 Arm 优于 Intel，或 NVIDIA 普遍快多少。作者没有控制这些变量。图像质量相当也是主观观察，没有盲测数据支撑。

保留旧环境、另建新目录和 venv 试新版，则是清楚的取舍：牺牲一点维护便利，换来结果可追溯。它比原地升级更适合已有稳定出图需求的项目。

能拿来做什么

• 迁移本地图像工作流时，同时记录代码提交、pip freeze、Python 与 CUDA 构建，并校验模型文件；不要只复制 requirements.txt 就认定环境已经复原。
• 排查 GPU 扩展包时，先读 METADATA 和导入错误，再运行实际算子；用复制的 venv 验证试验构建，避免直接改动正在使用的环境。
• 给生成结果做回归检查时，分别保存预处理与最终图片，并区分冷启动和缓存后的耗时；跨 GPU 的同 seed 图片不宜作为逐像素一致的验收基准。
• 为视频模型试新版 ComfyUI 时另建环境，并检查 tags 中的修复记录。原文中 MiniMax H3 要求 0.36.0 或更高，LoRA 修复在 v0.42.3，而 Releases 的 Latest 当时仍停在 v0.42.1。