在 Windows 上把 TRELLIS 2 装进 ComfyUI：RTX 50 系列从驱动到第一个网格的完整路径

在 Windows 上装 TRELLIS 2，与其说是安装，不如说是一个小型的工具链工程。节点包只是普通的 Python 代码，成本全在模型需要的三个 CUDA 扩展上，它们都要在最终运行的那台机器上从源码编译。而在 RTX 50 系列显卡上，这些构建必须针对一个 CUDA 生态直到最近才认识的算力等级，照着 RTX 4090 的教程走到这里就会卡住。

下面这个顺序最省时间：先驱动与工具链，再定解释器，然后装 torch，接着编译扩展，最后下载权重。每一步都有可以立刻验证的检查点；后面几节把报错信息和它们真正的原因对应起来。

为什么 RTX 50 系列显卡会让 TRELLIS 2 的默认安装失效

TRELLIS 2 并不是一个装完就能用的轮子。节点包是普通的 Python 代码，但真正吃算力的部分要走三个在安装时于本机编译的 CUDA 扩展：cumesh 负责解码后曲面上的网格运算，o_voxel 负责模型预测出的稀疏体素结构，flexgemm 则撑起前两者底下的稀疏矩阵算子。

Linux 把这三个构建藏在一条安装脚本里，Windows 没有对应脚本。RTX 50 系列报告的计算能力是 12.0，每个内核都必须为 sm_120 生成。基于 CUDA 12.1、12.4、12.6 构建的 PyTorch 轮子里不含 sm_120 代码，所以一块跑游戏毫无问题的显卡，会在 TRELLIS 节点开始采样的那一刻停在 CUDA error: no kernel image is available for execution on the device。早于 CUDA 12.8 的工具链则会回一句 nvcc fatal: Unsupported gpu architecture compute_120。两条报错，同一个原因：工具链比显卡先出厂。

装 ComfyUI 之前要先准备什么

• 较新版本的 64 位 Windows 11，开启长路径支持，并执行 git config --system core.longpaths true：这些扩展的源码目录层级远超 260 字符的默认上限。
• 与运行时匹配的 NVIDIA 驱动：CUDA 12.8 大致对应 570 分支，CUDA 13.0 对应 580 分支。nvidia-smi 会打印该驱动支持的最高 CUDA 版本。
• CUDA 工具链本体，12.8 或 13.0。12.8 是第一个接受 sm_120 的版本。装完确认 nvcc --version，PATH 里残留一个 CUDA 11.8 是很常见的情况。
• Visual Studio 2022 生成工具，勾选 C++ 桌面工作负载、Windows 11 SDK 和 ninja，再在无空格、且不在 OneDrive 同步范围内的路径上留出 60–100 GB 空间。

真正可行的安装顺序

1. 先装驱动、工具链和生成工具，然后重启。工具链还没就位就开始编译，是构建半路失败并留下一堆脏目录的最常见原因。
2. 先确定 ComfyUI 装在哪里。便携版使用 python_embeded 里的解释器，虚拟环境则用自己的，后面每条命令都必须走这同一个解释器。
3. 用 PyTorch 官方源装 cu128 或 cu130 版 torch，然后确认 torch.cuda.get_device_capability() 返回 (12, 0) 这个组合。
4. 安装 ComfyUI Manager 和 TRELLIS 2 节点包，但先拒绝自动安装依赖，接着依次编译 cumesh、o_voxel、flexgemm，每次失败后清掉 build 与 egg-info 目录。
5. 处理登录与授权，下载权重，从同一个启动脚本重启 ComfyUI，然后看控制台输出，而不是浏览器页面。

你的显卡该配哪一套 CUDA 与 PyTorch

从源码构建 cumesh、o_voxel 与 flexgemm

这三个扩展都没有面向 sm_120 的 Windows 预编译轮子，而为旧架构构建的轮子比没有更麻烦：它能导入，然后退回到很慢的路径，或者在第一次启动内核时失败，报错还指向模型。请用 ComfyUI 实际运行的解释器编译。要读日志里的第一条错误，而不是最后一条：编译器不可用会连锁产生上百行「无法打开包含文件」，而 cl.exe 一旦能被找到，这些报错会一起消失。

决定构建成败的几个环境变量

• CUDA_HOME 指向工具链根目录，也就是 NVIDIA GPU Computing Toolkit 下的 v12.8 或 v13.0 文件夹；构建辅助脚本读的是它，不是驱动。
• TORCH_CUDA_ARCH_LIST 设为 12.0，让 nvcc 生成 sm_120 代码而不是靠猜；猜成 8.6 的模块能正常加载，然后在第一个内核上失败。
• 执行 vcvars64.bat 之后把 DISTUTILS_USE_SDK 和 MSSdk 设为 1，否则 setuptools 会坚称缺少 Visual C++ 14.0，而它其实已经装好。
• MAX_JOBS 设为 4 或更低，构建目录不要带空格：16 GB 内存上同时跑三个 nvcc，很容易得到一个看起来像源码 bug 的崩溃。

构建期与运行期报错分别意味着什么

• nvcc fatal: Unsupported gpu architecture compute_120 说明 PATH 上的 nvcc 早于 12.8；装了两套 CUDA 时通常是旧的那套抢先，先改 PATH 顺序。
• 构建报告成功之后仍出现 no kernel image is available for execution on the device，说明扩展编译成了别的架构；用 cuobjdump 看一下，再重新构建。
• LINK : fatal error LNK1181: cannot open input file cudart.lib 说明 CUDA_HOME 设了，但 x64 库目录不在 LIB 里。
• 打印出 Successfully installed 之后仍然 ModuleNotFoundError，说明你装进了另一个解释器；而 ImportError: DLL load failed 多半是缺少 Visual C++ 运行库。

HuggingFace 的 404、需要授权的仓库与镜像延迟

1. 在 ComfyUI 用的那个解释器里登录，而不是在系统终端里登录：只读令牌按环境缓存，换一个地方登录，下载器看不到。
2. 用同一个账号在浏览器里接受许可。这类权重很多都带授权门槛，账号从没点过同意时，令牌再有效也过不去。
3. 固定一个版本号。仓库会被改名，文件会在子目录之间移动，而文件被移动给你看到的只是一个普通的 404。
4. 使用 hf-mirror.com 这类镜像时要记住，镜像比上游晚几小时到几天；另外在 Windows 上，使用符号链接的缓存下载需要开发者模式或管理员终端。

xformers 与注意力后端的版本错配

xformers 的轮子与某一个 torch 版本、某一个 CUDA 运行时严格绑定。为 Blackwell 换到 cu128 或 cu130 之后，匹配的构建可能还没发布：导入时会提示它是为另一个 PyTorch 版本编译的，然后自行禁用或直接报错。flash-attn 的情况相同，而 sm_120 的预编译轮子往往比它对应的 torch 版本晚出现。把这两者当成可选的加速层；启动 ComfyUI 时禁用 xformers，或改用 PyTorch 的交叉注意力后端，损失的是速度，不是结果。

如何验证安装，以及什么时候不该装本地环境

验证要分层做，而不是一上来就跑工作流。torch.cuda.get_device_capability() 应当返回 (12, 0)；导入 cumesh、o_voxel、flexgemm 不应当抛出任何报错；控制台在启动时应当列出 TRELLIS 节点，且上方没有导入警告。这些都对之后，再让一张图走最小的预设，盯住控制台里的第一条错误。请预期这套环境在升级面前很脆弱：它有四层编译组件，一次 torch 升级就会让它们全部失效，所以要么锁定版本，要么留一份能用的便携版用来回滚。

如果真正要的是网格而不是一套本地环境，同样的图生 3D 任务可以放到浏览器里做。Open3DAI 运行一个本地的程序化生成引擎，也可以用自己的 API 密钥接入第三方引擎接口。它支持图生 3D 与文生 3D，接受多视图输入，可以给模型做 AI 贴图，能导出 GLB、glTF、OBJ、STL、PLY、3MF，另有 48 个格式转换器、12 个浏览器工具和一套 REST API，同一张图还能在可用引擎之间并排跑一遍再导出。它不会给你节点图，不托管任何第三方模型，也不做重拓扑、UV 展开、绑定，更不承诺输出一定封闭。网格该清理的部分一样要清理；当你需要自定义节点逻辑、批量控制或自己的模型权重时，ComfyUI 这条路线依然是正确答案。

常见问题

在 Open3DAI 中试一下

把同一份提示词或图片交给多个引擎，并排对比网格，然后导出 GLB、glTF、OBJ、STL、PLY 或 3MF。注册即赠免费积分，无需信用卡。