fVDB: A Deep-Learning Framework for Sparse, Large Scale, and High Performance Spatial Intelligence

一句话总结

fVDB 用一套从 NanoVDB 派生的 IndexGrid 稀疏数据结构，把 3D 深度学习中常用的卷积、池化、注意力、光线步进、采样、溅射、网格化等算子统一在同一个 GPU 加速、可微、与 PyTorch 无缝对接的框架里，在算子性能追平或超越各专用库的同时，能处理比现有框架大得多的空间分辨率与数据规模。

研究背景

深度学习的底层依赖一套可组合的可微算子（卷积、池化、注意力等），主流框架如 PyTorch、JAX、TensorFlow 都围绕稠密张量设计，天然适合文本、图像这类 1D/2D 信号。但 3D 任务里，稠密张量因立方级增长和显存约束而受限。好在 3D 数据本质稀疏——通常只有物体内部或表面附近才需要编码信息，于是催生了一批面向稀疏 3D 张量的框架（Minkowski Engine、TorchSparse、SpConv 等）。

过往稀疏 3D 学习框架主要用哈希表把 3D 整数坐标映射到特征张量。哈希表对卷积、池化这类算子够用，但访问缺乏空间局部性，导致采样、溅射、光线步进等操作在没有额外加速结构时效率低下；而且哈希表不是 BVH，无法高效做光线步进。因此这些框架往往只提供卷积、池化等少数算子。

问题在于，现代 3D 学习任务常需要把多种复杂算子拼在一起。作者举例：图像到 3D 生成的流水线需要把图像特征反投影到体素、经稠密+稀疏卷积网络得到稀疏特征体、再可微地网格化并渲染出带纹理形状——这一条链需要光线步进、溅射、卷积、池化、注意力、网格化、渲染等一系列可微算子协同工作。当前做法是用不同库里的各类加速结构（哈希表、占用位域、网格）拼接定制算子，既笨重又难维护。

fVDB 的目标就是提供一个宽泛、可组合的算子集合，让复杂 3D 学习流水线容易搭建，同时每个算子的性能都不输专用库，并且内存高效、能吃下更大的输入。

核心方法

fVDB 建立在 VDB 数据结构之上。VDB 是计算机图形与仿真领域广泛使用的浅层 3D 树结构：根层用哈希表，往下是固定层级、块尺寸递减的稠密子节点。OpenVDB 与 NanoVDB 的默认配置是三层树，扇出因子分别为 32、16、8，即从根到叶节点分别覆盖 \(4096^3\)、\(128^3\)、\(8^3\) 个体素。浅层结构配合节点缓存，使随机访问在实践中达到 \(O(1)\)。但作者发现，直接把 VDB 用于 GPU 上的 ML 会遇到瓶颈：ML 需要支持任意高维数据类型，而稀疏卷积等计算通常是带宽受限的，随机访问应尽量少、数据应尽量复用（缓存）。

框架的关键创新可以拆成几块。

IndexGrid：拓扑与数值分离

标准 VDB 把数值（如 float、Vec3f）直接编码进树结构，也就是数值和拓扑（稀疏模式）混在一起。这在处理任意类型/维度的 ML 特征时很糟糕：每种特征都要模板特化，代码复杂；当多种特征共享同一稀疏拓扑时又浪费内存。讽刺的是 VDB 本为拓扑和数值都动态变化的场景设计，而 ML 里往往拓扑固定、只有载荷（类型、数值、维度）在变。

作者在 NanoVDB 里新造了一种网格类型 IndexGrid，把拓扑和数值彻底分离。IndexGrid 只编码拓扑，树返回的是指向外部线性数组（称为 “sidecar”）的索引而非数值本身。这样一个 IndexGrid 可被多种特征复用，共享拓扑的编码成本被摊薄。

还有个不那么显然的收益：VDB 所有节点本质是稠密块，一个叶节点固定编码 \(8^3=512\) 个值，无论实际占用多少。朴素实现会索引全部 512 个值，但更省内存的版本只索引稀疏的（激活的）叶值，从而不必为背景值显式存储数据。作者用一段高效的位运算代码（借助 bitmask 前缀和、countOn 内建函数、仅 2 个分支）从坐标算出到外部数组的线性偏移。结果是每个叶节点只需 80 字节即可编码全部索引，相比朴素索引方式（nanovdb::LeafNode<uint64_t> 超过 4KB）实现了超过 50 倍的内存压缩。

GPU 加速的 IndexGrid 构建

构建 LOD 层级、做形态学膨胀时需要动态改变稀疏模式。OpenVDB 靠 CPU 上插入时分配，NanoVDB 则假定拓扑固定，两者都不适合在 GPU 上快速重建不同拓扑的网格。作者设计了一个高度并行的 GPU 构建算法：

1. 输入 \(N\) 个带符号体素坐标 i,j,k；
2. 为每个坐标构造 64 位键（把 i,j,k 各右移 12 位后分段拼进 21+21+21 位）；
3. 对 \(N\) 个键做全量基数排序；
4. 对键做游程编码（RLE）；
5. 为每个游程内的坐标构造唯一 64 位键（分段编码叶/下层/上层节点内偏移与 tile ID）；
6. 局部基数排序； 7-9. 由游程数、唯一键数分别得到上层、下层、叶节点计数； 10-12. 用节点计数分配显存，自顶向下注册各层节点与激活体素的 bitmask，可选地把 ML 特征作为盲数据附加。

由于几乎每一步都能在 GPU 上并行（基数排序与 RLE 都能用 CUDA CUB 库的高性能实现），该算法能在几毫秒内从上百万体素坐标构建出 IndexGrid。

HDDA：层级化的快速光线步进

可微渲染、把图像特征反投影进体、深度计算、最终渲染等任务都离不开高效的光线步进。作者用层级数字微分分析器（HDDA）：给 VDB 树的每一层各配一个 DDA，分别在 \(4096^3\)、\(128^3\)、\(8^3\)、\(1^3\) 四个坐标粒度上光栅化光线。粗粒度的 DDA 负责在空区域上大步”跳跃”，细粒度的才逐体素前进，避免了在体素级做大量冗余随机访问。由于树配置在编译期已知，可用模板元编程把四个 DDA 内联成单个高性能 HDDA，实现 GPU 上体素体的实时光线追踪（每秒可步进数百万条光线）。

面向稀疏卷积的加速算子

fVDB 与高效稀疏卷积算法（如 TorchSparse++ 里的 Sorted Implicit Gemm / SpConv v2）兼容。关键在于 fVDB 本质是”稀疏格点索引到一维线性索引空间的、保局部性的映射”：几何上邻近的激活体素，其线性索引也大概率邻近。这与随机哈希映射相反，因此 SpConv v2 可以直接把每个激活体素的线性索引当作”哈希键”（但自带局部性）无缝接入。作者已把 SpConv v2 纳入算子工具箱，微基准显示其算子级效率至少追平 TorchSparse++。

在此之上，作者针对三类场景设计了性能更优的定制卷积核：

• 场景 1（Leaf，低深度卷积）：输入/输出特征维度都很低（如 8→16）时，卷积严重带宽受限。此时优先”规整性”而非”稀疏性”：在 GPU 共享内存里对 \(8\times8\times8\) 叶节点做局部稠密化（含一圈 halo 的 \(10\times10\times10\) 窗口），用 WMMA tensorcore GEMM 做完全规整的局部稠密卷积。当叶节点占用率 ≥20% 时优于 SpConv v2 默认后端，稠密域可达 2.5x–3x 优势，且无需辅助索引结构。
• 场景 2（Brick，高局部占用）：激活索引局部很密（平均每个激活索引 >70–80% 的邻居也激活，如 2–3 体素宽的窄带或半稠密域），且特征深度中高（≥32）。做法类似局部稠密化，但粒度改为更窄的 \(4\times2\times2\) 输出窗口，用 CuTe 库实现的定制 tensorcore 卷积，在特征深度 32–64 时超 70% 峰值算力、≥128 时超 90%。当窗口平均占用超 60–70% 时优于 SpConv v2。
• 场景 3（LGGS，极稀疏 + 高特征深度）：占用极稀疏（平均每个激活索引不超过 4–5 个激活邻居，如 LiDAR 数据）且特征深度 ≥128。采用共享内存里的局部 Gather-GEMM-Scatter：把操作分块到连续的 64 个输出索引上，用共享内存缓冲区替代对全局内存的散射，为 27 个 stencil 偏移各自打包收集输入/输出索引对（补齐到 16 的倍数以适配 tensorcore GEMM）。在 SemanticKITTI 单帧点云、特征长度 ≥128 时比 SpConv v2 快约 25%。

fVDB 会根据每种情况自动选择最合适的后端（通用的 SpConv v2，或上述新核）。

技术细节

框架层面，fVDB 暴露一批作用于”稀疏体素网格 minibatch”的可微算子，核心是两个类：

• GridBatch：表示一批 NanoVDB IndexGrid（batch 里每项一个），内部就是一块连续存放的 IndexGrid 加少量元数据以便快速访问任意网格。
• JaggedTensor：编码 minibatch 里每个体素的特征。由于各网格体素数不同，需要处理”锯齿数组”。概念上它是张量列表 \([t_1, t_2, \dots, t_B]\)，每个 \(t_i\) 形状为 \([N_i, *]\)（首维不同、其余维相同）。内部由三部分构成：jdata（把所有张量沿首轴拼接的稠密张量）、joffsets（形状 \([B,2]\)，记录每项在 jdata 中的起止）、jidx（记录每个元素属于列表中的哪一项）。

主要算子包括：网格构建（可从点云、体素坐标、三角网格、其他 GridBatch 的填充/粗化/细分、带掩码的稠密网格创建）；采样（三线性或 Bézier 插值，可微）；溅射（把点上数据溅射到网格）；卷积/池化/上采样/注意力（注意力通过调用 Flash Attention 实现）；光线步进（枚举光线经过的体素、求光线与隐式函数水平集的交点、体渲染，均基于 HDDA）。整个框架用 CUDA 与 C++ 编写并与 PyTorch 互操作。

实验结果

微基准：

• IndexGrid 构建：与 TorchSparse++、MinkowskiEngine、SpConv 对比，fVDB 显著快于 MinkowskiEngine 与 SpConv，与 TorchSparse++ 相当；内存上比 TorchSparse++ 更省，而 MinkowskiEngine 和 SpConv 随规模增大会失败（OOM 或非法内存访问）。因此 fVDB 能处理远大于现有框架的输入。
• HDDA 光线步进：在斯坦福兔子 3 体素窄带上从 \(32^3\) 到 \(1024^3\) 各分辨率测试，对比 NerfAcc，fVDB 始终快 1.5x–3x，同时显存最多低 100 倍。

分辨率	\(32^3\)	\(128^3\)	\(512^3\)	\(1024^3\)
NerfAcc 光线/秒 (M)	2.57	2.09	0.82	0.47
fVDB 光线/秒 (M)	3.77	2.81	1.83	1.43
NerfAcc 显存 (MB)	0.24	2.15	129	1028
fVDB 显存 (MB)	0.38	0.40	2.46	8.85

• 稀疏卷积：在低（8→16）、中（32→32）、高（128→128）三种特征深度 × 三种稀疏度（<20%、20–40%、>40% 叶节点占用）下，fVDB 的四种实现（IGEMM、Leaf、Brick、LGGS）能在每种情况选出最有竞争力的算子。用”有效 TFLOPS”（排除空权重 MAC）衡量，需与 RTX 4090 约 73 TFLOPS 的架构上限对比。

宏基准：

• 全网络推理：以 XCube 的生成骨干（编码器-解码器式稀疏 U-Net）为例，在 KartonCity 数据集（256/512/1024 分辨率）上，fVDB 在不同分辨率与通道配置下都稳定优于各 SOTA 基线。
• 神经辐射场：基于 Instant-NGP 参考实现，用 fVDB 网格替换级联二值网格，在 Waymo 场景上训练速度 26.1 vs 26.4 it/s、推理 1.90 vs 1.62 FPS 与 iNGP 相当；因从 LiDAR 点云初始化、采样位置更精确，测试 PSNR 达 27.07（iNGP 为 25.89）。

示例应用：

• 大规模表面重建：用 fVDB 重实现 NKSR（卷积网络、Marching Cubes、批量核岭回归求解器均用 fVDB，扩展仅一个几百行、只依赖 PyTorch 和 fVDB 的文件），从 3.5 亿输入点重建网格，在 8 张 V100 上仅需 2 分钟。
• 3D 生成模型：重实现 XCube，借助 fVDB 可扩展到 100m×100m、10cm 分辨率的场景。
• 大规模 NeRF：如 1 平方公里的 Laguna Seca 赛道；在该场景下光线步进比 NerfAcc 快 1.3x、\(1024^3\) 有效分辨率下显存少 30x。
• 仿真超分辨率：在肌肉/皮肤动力学、流体等稀疏 3D 仿真域上训练 DCSRN、3D-FSRCNN 等全卷积超分网络（进行中的工作）。

贡献与局限

贡献：

• 面向空间智能的综合 API，覆盖广谱高价值 3D 机器学习任务所需的基本算子。
• 新的稀疏数据结构 IndexGrid，源自 NanoVDB 但重构了编程与执行模型，把拓扑与数值分离并激进优化 stencil 型操作。
• 围绕 IndexGrid 构建的一批 GPU 优化快速算子（卷积、注意力、光线追踪等），专门针对空间稀疏数据的高效执行。
• 一个新的稀疏卷积基准，覆盖不同稀疏模式与特征深度。
• 内存高效算法，使规模远超以往工作。
• 在从点云分割、高分辨率 3D 生成、无界 NeRF 到大规模点云重建等多种端到端应用上验证了框架实用性。

局限与未来工作：

• 目前训练默认用 IGEMM 后端以简化梯度计算，Leaf/Brick/LGGS 等更快的核主要用于推理，训练阶段尚未充分利用。
• 论文提出的多后端选择尚未做到”按每个叶节点局部稀疏模式动态分派最优核”，这是提升稀疏卷积性能的一个明确方向。
• 计划扩展更多可微算子（层级对偶 Marching Cubes、粒子/blob 到网格的转换以支持可微物理与高斯溅射等），并提供开箱即用的高层网络架构库。

延伸思考

fVDB 的价值不在某个单点算法，而在于”用一个高度通用的加速结构统一整条 3D 学习流水线”这一系统性选择。它把图形/仿真界成熟的 VDB 结构改造进 ML 生态，抓住了两个关键洞察：ML 场景下拓扑往往固定而载荷多变（催生 IndexGrid 的拓扑-数值分离），以及稀疏卷积的性能瓶颈随稀疏度、特征深度而变（催生按场景切换的多后端卷积）。对于需要把重建、生成、渲染、仿真等异构任务拼进同一流水线的大规模空间智能应用，这种”一套结构打通全链路”的设计能显著降低工程拼接成本，也为数字孪生、物理 AI 等 reality-scale 场景提供了可扩展的底座。