一台标着16GB显存的RTX 5070 Ti，把TRELLIS.2要求的24次生成全部跑完了，连1536分辨率的网格也没落下。但真正值得看的不是“跑完了”，而是跑完的方式：在一次成功的官方1536导出过程中，Windows快照报出了10.30 GiB的共享GPU内存占用。
换句话说，这张卡名义上是16GB本地显存，实际干活时却动用了系统内存兜底。完成，不等于整条流水线塞进了16GB。
测试环境是Windows 11 Pro工作站，RTX 5070 Ti 16GB、驱动617.42、锐龙9 9950X，系统内存约61.65 GiB；WSL2下的Ubuntu 24.04.2给了30.18 GiB内存上限和8 GiB交换空间。隔离环境用Python 3.12.3、PyTorch 2.8.0+cu128、CUDA编译器12.8.93、FlashAttention 2.8.3.post2和Transformers 4.57.1。
(资料图片仅供参考)
需要说明的是，微软固定版本的TRELLIS.2说明文档要求Linux和至少24GB显存，这套Windows/WSL实验并没有改写这条要求。
生成、导出、验证，三个环节三个答案
输入是三个768×768的透明Blender渲染图：洒水壶、盆栽和长椅。两条代码路径共用同一套权重、种子42、12步采样默认值、低显存卸载和49152 token上限。所有返回的网格分辨率都与请求的512、1024、1536档位一致，没有出现悄悄降档换来的成功。
主测试矩阵包含18个全新Python进程：三个输入×三个档位×两条源码路径。另有六个洒水壶进程复测默认分配器，它们是独立对照组，不是六个新物体，也不是分配器的因果基准测试。
官方源码是提交75fbf018，社区对照用的是Espalier旧版MIT许可修订13344be6，包含256体素核心、边距8的分块解码。它不执行当前分支，也不跑完整的Espalier封装。两条路径用的是同一套编译好的原生扩展基线。
结果分成两层。生成环节完成得更频繁，原生导出则掉了链子：24次请求全部生成了输出，原生GLB导出写出23个文件。其中一次官方路径导出报出CUDA驱动错误“设备未就绪”——这是观察到的导出失败，不是确认的显存溢出异常。
导出设置没有因为失败而下调：沿用官方示例的100万三角面目标、4096贴图、重网格化、band 1、projection 0和WebP输出。保存私有原始张量、套用示例的16777216面安全上限，都发生在计时的to_glb加写文件阶段之前；整进程墙钟时间包含这部分工作。
生成中位数用三个不同输入计算，导出中位数只用写出的文件，所以官方1536导出只有n=2。写出的文件，不一定就是格式合法的文件。
只有官方512试点事先预热过。新路径、新张量形状和新分辨率可能在之后才编译内核，磁盘缓存则一直保留。打过补丁的1024生成中位数反而更慢，这也是这批观察不能当成稳态速度排名的原因之一。后来默认分配器的1024洒水壶运行，官方路径43.96秒、补丁路径45.10秒，此时缓存已经更热，所以这点差异不能单独归因于分配器配置。
六次默认分配器复测全部生成并写出了文件。官方1536复测的生成耗时121.20秒，导出加写文件475.52秒，试验运行器内697.85秒，算上外层进程编排约700秒。导出前，安全上限内的网格有15538939个面，重网格化一度把它撑到36114868个面。约100万三角面的交付目标，约束不了中间网格的体量。
显存计数器为什么必须分开看
每个格子都是同一测量口径下三个输入的观测最大值，它们不是可以互换的“纯进程显存”读数。PyTorch分配器统计会区分已分配张量和预留块，它的内存工具也看不到每一次直接的CUDA分配。
单个NVIDIA采样器在正式试验中记录了56381行有效数据，包含桌面占用。预期采样间隔100毫秒，实测中位数101毫秒，最大间隔2032毫秒。短促的峰值可能被漏掉，变化的全局基线也无法归到某个具体应用头上。
Windows适配器级计数器是后来才加的。正式试验第23次在16:27:30的单次快照报出15.57 GiB专用占用和10.30 GiB共享占用。这是补充证据，不是该进程全程的峰值。默认1536生成还通过PyTorch报出18.78 GiB预留，已经超过物理卡容量。
成功的那次补丁默认复测有110条较晚的Windows观测，在这个不完整窗口里共享占用最高0.094 GiB。早期主试验没有这些计数器。驱动系统内存回退设置没有被检查或改动，这些数据也无法指认具体的回退机制。但它们足以排除一种说法：把成功完成当成“纯本地16GB显存就能跑通”的证明。
失败的输出不用重新生成就能救回来
失败的那次官方洒水壶运行，其实已经存下了真实的1536原始结果：9103700个顶点、18252884个面。三个全新的纯导出对照复用了这份结果，没有加载生成模型。这三个对照不计入24次全流程的分母。
没有任何正式试验抛出字面意义上的OOM异常。Windows系统日志查询在检查窗口内没有找到匹配的显示或NVIDIA事件，这既不能诊断那个CUDA错误，也不能排除驱动故障。
验证环节暴露了第二个问题。23个原生文件里，17个无错通过，6个包含零长度法线；两个写出的恢复文件同样带零法线。原始文件全部保留，另外生成了八份修正副本，用相邻几何或相邻有效法线替换了21个精确为零的法线向量。位置、索引、UV、所有非零法线和编码后的贴图字节保持不变。八份衍生文件全部以零glTF验证错误通过。
这次小修不碰拓扑和退化三角面，也不构成流形、动画或生产级质量认证。加上恢复并修正的文件，每次生成试验现在都有一个明确映射的、格式合法的本地交付选择；但这不改写最初23/24的导出结果。
六个原生导入的Blender场景被保存、重新打开、解码打包贴图并再次渲染。它们展示的是不同光照下可辨认的形状，不是真值重建评分。Blender导入时可能丢弃退化三角面：代表性的洒水壶从源文件989733个三角面变成导入后的989723个。重新打开只能证明Blender场景持久化了，不是逐位一致的glTF往返。
九对官方/补丁原始结果在体素坐标对齐后也做了比较。三个512案例的对齐属性完全一致，其他配对有时存在差异，最大对齐属性差为0.0016203。每个方向两万个顶点的确定性最近顶点探测，最大采样距离为5.54×10⁻⁶归一化场景单位。这既不是全表面豪斯多夫距离，也不能证明差异只来自补丁的数值误差：同路径内的随机重复对照没有跑。
浏览器版本是另一笔主动取舍
浏览器测试用的是补丁路径下完成的最高分辨率洒水壶。它的原生GLB为35546480字节，989733个三角面，两张4096 WebP贴图。网页基线做了焊接、简化比例0.1、误差上限0.001，贴图换成两张2048 WebP、质量95。实际输出保留了154568个三角面，而不是假设的10万个。
Meshopt和Draco从同一份网页基线出发，声明14位位置、10位法线和12位UV。原生到网页的转换改变了几何和贴图，这四个文件不是同一份资产的四种无损编码。
计时口径是本地资产拉取到首次GPU完成，每个文件/后端三个全新配置文件。渲染器和程序化环境初始化发生在计时之前，导航计时仍保留它们的开销。完成栅栏不测量屏幕呈现。
24次正式启动和2880个就绪后RAF间隔全部通过：物理NVIDIA WebGPU/ANGLE WebGL2适配器、非空白截图、无JavaScript页面错误。Chrome 156无头模式，Three.js 0.186.1，1280×720，DPR 1。单独的预检和十二次替代视角截图不计入这些计时中位数。浏览器配置文件是全新的，驱动缓存则保留着。帧间隔集中在约60Hz上限下的16.7毫秒附近，它们无法给未限帧的GPU吞吐量排名。
序列化和独立解码的压缩分支都通过了glTF验证。两张RGBA8贴图配理想mip链，在4096下约合170.67 MiB，2048下约42.67 MiB。这些是逻辑贴图估算，不是实测驱动显存；一个体积很小的WebP下载本身，证明不了低驻留。
对这台工作站来说，分块解码降低了观察到的高档位生成分配，补丁导出救回了一份原本失败的原始结果。下一个有用的关卡，是一份经过检查、通过验证、并带有实测网页预算的资产。生成完成本身回答不了这个问题，一张16GB显卡的名字，也描述不了整条内存路径。
营业执照公示信息