一台标着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原始结