前段时间我想在 Windows 上跑 3DGS结果卡在编译上。主要的原因是电脑上软件的版本和文档中的不同。这篇文章讲一下我在编译这两个项目的 CUDA 扩展时遇到的几个问题和相应的解决方法。其中有 2 个可能是 Windows 中文环境特有的。我的环境Windows 11 24H2 (Build 26100) ← 家庭中文版 CUDA 13.0 Visual Studio机器自带 VS2026 BuildToolsMSVC 14.51 后另装 VS2022 BuildToolsMSVC 14.44 / v143← 实际使用这个 Python 3.11 / PyTorch 2.9.1cu130 GPU: RTX 5060 Laptop (8GB, sm_120)这 6 个问题分别来自哪里#问题来自1cudafe段错误LiteGS 构建2C2872: std: ambiguous symbolLiteGS 的依赖simple-knn3.cu文件被交给了cl.exeLiteGS 的依赖构建4CUDA 13 移除了cub::Max★ 原始 3DGS 构建5.1Host compiler targets unsupported OSLiteGS 构建5.2d_w_accum is undefinedLiteGS 构建6 个问题里有 5 个出现在前一个项目1 个出现在后一个。所以这些问题不是某一个项目特有的—— 只要用同一套工具链换个项目也很可能遇到。一、问题 1cudafe段错误报错cudafe died with status 0xC0000005排查0xC0000005是 Windows 的访问违例Access Violation。按常规思路这种崩溃通常是环境损坏所以我试了重装 CUDA、换驱动版本、清编译缓存、换 Python 环境不过全部无效。后来我做了一组对照实验才把范围锁定下来尝试变量结果排除了什么1torch 2.14.1 C20崩溃—2降级 torch 2.9.1 C17同样崩溃排除 C 标准与 torch 版本3极简.cu不含 torch 头同样崩溃排除 torch → 锁定工具链4同上换 MSVC 14.44✅ 通过确认原因第 3 步是关键—— 连一个不引用任何 torch 头的极简.cu都崩溃说明问题根本不在 torch而在编译器工具链本身。原因CUDA 13.0 对 MSVC 编译器版本有硬性白名单只接受 193x / 192x。我的机器上装了 VS2026工具集 14.51 195x版本号超出范围cudafeCUDA 的前端编译器遇到不认识的宿主编译器直接崩了。解法装VS2022 BuildToolsv14314.44.35207用它而不是 VS2026。C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Auxiliary\Build\vcvars64.bat怎么确认自己的工具集版本cl 21|Select-Object-First 1# Microsoft (R) C/C Optimizing Compiler Version 19.44.35229 for x64# ^^^^^# 19.44 → 工具集 v143二、问题 2C2872: std: ambiguous symbol报错error C2872: std: ambiguous symbol could be std or std排查报错信息本身就荒谬 ——“std可能是std或std”。两个候选名字一模一样说明这不是普通的命名冲突。报错位置也很具体compiled_autograd.h(1134)。原因这是 PyTorch 的上游 bug。如果你遇到一样的报错可以直接看这两个问题报告pytorch#173232—— 官方已 triage最初报告者编译的正是 Gaussian Splatting 的simple-knn错误行号1134与本机完全一致官方修复 PRpytorch#188952解法给CL加/permissive-末尾的减号关闭 MSVC 的宽松模式。$env:CL /std:c17 /permissive- /utf-8# ^^^^^^^^^^# 末尾的减号不能少三、问题 3.cu文件被交给了cl.exe报错fatal error C1083: Cannot open include file: cub/cub.cuh error: identifier threadIdx is undefined error: identifier blockIdx is undefined排查threadIdx、blockIdx是CUDA 的内建变量只有 nvcc 认识。它们出现在cl.exeC 编译器的报错里说明.cu文件被 C 编译器处理了而不是 CUDA 编译器。那么问题变成构建系统为什么不用 nvccPyTorch 的构建系统torch.utils.cpp_extension优先用 ninja 构建。我检查了一下python-cfrom torch.utils.cpp_extension import is_ninja_available; print(is_ninja_available())# 输出Falseninja 不可用。而 PyTorch检测不到 ninja 时会静默降级到 distutils——distutils不懂 CUDA于是把.cu当普通 C 文件交给了cl.exe。关键点这个降级是静默的不报任何警告。原因ninja 装了但不在PATH里。它位于 Python 环境的Scripts目录下。解法$env:PATH D:\litegs\env\Scripts;$env:PATH# 必须验证python-cfrom torch.utils.cpp_extension import is_ninja_available; print(is_ninja_available())# 必须输出 True修完后确认is_ninja_available()返回Trueninja 版本 1.13.2。四、问题 4CUDA 13 移除了cub::Max这个问题出现在原始 3DGS 的构建中需要改源码。4.1 报错forward.cu(429): error: namespace cub has no member Max4.2 排查我先去 CUDA 13 的安装目录找 CUBC:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v13.0\include\cccl\cub\ ^^^^^ 注意在 cccl 子目录下在这个目录树里全量搜索struct Max/using Max/class Max一个都找不到。然后我统计了整个扩展里cub::的所有用法用法出现次数CUDA 13 里还在吗cub::BlockReduce1✅ 在cub::DeviceRadixSort2✅ 在cub::DeviceScan5✅ 在cub::Max1❌被删了只有cub::Max这一个没了—— 说明不是路径问题是真的被移除了。4.3 原因CUDA 13 带的是CCCL 3.xCUDA C Core Libraries 第 3 版这个大版本把cub::Max删掉了。官方替代品在 CUB 自己的文档注释里给出了 ——位于cub/block/block_reduce.cuh的示例代码// 来自 CUB 源码的官方注释示例intaggregateBlockReduce(temp_storage).Reduce(thread_data,cuda::maximum{});4.4 解法改1 行调用 加1 行 include#include cub/cub.cuh #include cuda/functional ... - last_contributor BlockReduce(temp_storage).Reduce(last_contributor, cub::Max()); last_contributor BlockReduce(temp_storage).Reduce(last_contributor, cuda::maximum{});改完就编译过了。说明这是本文 6 个问题里唯一需要改源码的一处。位置在原始 3DGS 的光栅化器cuda_rasterizer/forward.cu只改了 1 个文件、2 行其余文件逐字节未动。五、两个原因不明的问题这两个问题可能与中文 Windows 有关具体原因我也不太清楚。#遇到什么问题用了什么方法原因5.1nvcc fatal : Host compiler targets unsupported OS装 Visual Studio 英文语言包不明5.2transform.cu(551): error: identifier d_w_accum is undefined但该变量在第 488 行已声明编译时加/utf-8不明两个方法在我的电脑上都确实解决了问题但为什么会这样我没有查明所以下面只写现象和解法。5.1Host compiler targets unsupported OS报错nvcc fatal : Host compiler targets unsupported OS解法给 Visual Studio 装英文语言包。Visual Studio Installer → 修改 → 「语言包」→ 勾选 English → 安装装英文语言包不需要卸载中文两个可以共存。装完后这个报错消失。5.2d_w_accum is undefined报错transform.cu(551): error: identifier d_w_accum is undefined排查蹊跷之处在于 ——这个变量在第 488 行就声明了中间也没有作用域变化。按 C 规则它绝不该报未定义。之后我发现全文件 65,873 字节里只有 45 个非 ASCII 字节第 487 行的一句中文注释。版本结果原文件❌ 报未定义仅把那 45 个字节替换为 ASCII其余一字不动✅ 编译成功加/utf-8✅ 编译成功解法$env:CL /std:c17 /permissive- /utf-8$env:NVCC_PREPEND_FLAGS -Xcompiler /utf-8六、说明与致谢关于本文本文是环境搭建经验分享不是原创研究。文中涉及的代码归graphdeco-inria原始 3DGS与摩尔线程 Moore ThreadsLiteGS所有。文中的报错信息、环境变量、字节数、命令输出均为真实记录。第五节的两个问题我只写了现象和解法没有写原因——因为我确实没查明。这 6 个问题里只有问题 4 需要改源码原始 3DGS 的forward.cu1 个文件、2 行其余 5 个都是环境层的修复源码未动。文中的调试过程与本文撰写在 AI 辅助下完成我负责目标设定、实验执行、结果判断与错误纠正。这 6 个问题是我在自己的机器环境下遇到的。不同 CUDA / VS / GPU 组合可能不会全部复现。参考PyTorch issue #173232问题 2 的原因https://github.com/pytorch/pytorch/issues/173232PyTorch 修复 PR #188952https://github.com/pytorch/pytorch/pull/188952原始 3DGShttps://github.com/graphdeco-inria/gaussian-splattingdiff-gaussian-rasterizationhttps://github.com/graphdeco-inria/diff-gaussian-rasterizationLiteGShttps://github.com/MooreThreads/LiteGS如果你在别的 CUDA / VS 组合上遇到不同的问题欢迎评论区补充如果你知道第五节那两个问题的原因欢迎分享