2023年，斯坦福和三星联合发布了一个叫VecSet的3D生成方法，它用512个全局token就能表示一个完整的3D物体，效果相当不错。两年后，韩国团队的COD-VAE把这个数字压到了32个token，而且质量还提升了。听起来压缩之路一片光明，对吧？
但真相是，这条路走到32个token附近突然就撞墙了。
COD-VAE的论文里藏着一个不太起眼的数字：如果把token数量从32砍到2，ShapeNet数据集上的IoU（一种衡量重建准确度的指标，数值越接近100表示重建的形状和真实形状重合度越高）直接从97.1掉到了77.7，掉了将近20个百分点。TRELLIS数据集上更惨，从75.25掉到45.85，几乎腰斩。这不是缓慢的性能衰减，是断崖式的崩溃。
这就是ZipTok3D这篇论文要解决的问题：能不能只用一两个token，就把整个3D物体的几何形状撑起来？
为什么压缩到极限就会崩溃
先说清楚这里的"token"是什么。
*Token*：在3D生成里，token是编码器把一个物体的表面几何信息压缩成的一小段数字向量，生成模型后续就靠操作这些向量来"画"出3D形状。token数量越少，存储和计算的成本就越低，但每个token要扛的信息量也越大。
现有的3D tokenizer（把3D物体转成token序列的编码器）分成两条路子。一条是像TRELLIS那样把特征绑定在空间格子上，物体的每个局部区域都有对应的token，这样空间关系清晰，但想压缩就得把格子变粗，一旦格子太粗，细节就没地方放了。另一条是VecSet和COD-VAE走的路，用一组"全局token"来概括整个物体，不再对应具体空间位置，理论上可以压得更狠。
问题出在训练方式上。这些全局token方法在训练时,是把所有token一起塞进去,统一优化一个固定长度的重建目标。也就是说,32个token作为一个整体去学怎么重建物体,但没有人告诉网络"如果只能保留前两个token,应该优先保住什么"。
这就好比你让十个人一起搬一件大家具,分工全凭默契,没有明确的责任划分。搬得动的时候一切正常,可一旦临时只剩两个人,谁都不知道自己该扛哪一头,家具很可能直接散架。如果不做任何干预,单纯依赖"整体重建效果好"这个终极目标去反推每个token该存什么信息,网络学到的往往是一种脆弱的、互相依赖的编码方式,前几个token和后面的token绑得很紧,一旦砍掉后面的,前面的也跟着失效。
这正是COD-VAE在32个token时表现优异,却在2个token时直接失灵的根本原因。它从没被要求过"仅用前两个token也要撑起整个物体"。
把token排出优先级：nested dropout
ZipTok3D的第一个核心设计,是让token序列自带一种"重要性排序"。
具体做法是这样的：编码器最多生成128个token,构成一个完整的序列。训练时,每次随机截取这个序列的一段前缀，长度从1、2、4一直到128，按2的幂次跳着采样。无论截到多短，都要求这段前缀独立完成对整个物体的重建，被截掉的后半段（论文里叫"suffix"，也就是尾部）在这一轮训练里完全不参与运算。
*Nested dropout*：一种训练技巧，随机截断向量序列的长度，并要求每个被保留下来的前缀都能独立完成任务，从而让序列前部的元素自动承担更重要的信息。
这个机制逼着网络做一件事：既然第一个token有相当概率会被单独拿出来重建整个物体，它就必须尽可能装下最核心的几何信息，比如物体的整体轮廓、主要部件的位置关系。第二个token知道自己可能和第一个token搭档去完成同样的任务，于是它学的是"补充"第一个token没说清楚的东西，而不是重复劳动。以此类推,越往后的token,越是负责边角料式的细节修正。
这就像写一封只能发一句话的电报和一封可以随意展开的长信。电报作者必须把最重要的信息压进那一句话里，绝对不会浪费字数去描述无关紧要的细节；而长信作者可能想到哪写到哪，把重点和细节混在一起写。如果没有nested dropout这道约束，网络生成的128个token更像是那封长信，重点和细节杂糅在一起，一旦你只截取开头几句，很可能抓不住整体意思。而经过nested dropout训练之后,前几个token被迫变成电报式的表达，信息密度极高。
实验结果验证了这个想法。论文的消融实验表明,只是给原来COD-VAE的12层解码器加上nested dropout训练（论文里叫"Prefix only"这个变体），在K=2（也就是只用2个token）的情况下，IoU就从77.7跳到92.3，CD（Chamfer Distance，衡量重建表面和真实表面之间距离的指标，越小越好）从0.032降到0.015。这还只是排序机制单独起作用的效果，网络结构完全没变。
解码器要多想几遍：参数共享的迭代精细化
排好优先级只是解决了一半问题。剩下的问题是：当你真的只拿到一两个高度浓缩的token时，解码器怎么把它们"翻译"成一个完整的、有细节的3D形状？
原来的COD-VAE用的是单次前馈解码，输入进去，走一遍网络，直接出结果。这对32个token来说没问题，因为信息本来就分散在32个向量里，网络只需要做一次"拼图"就够了。但如果只有1个token,这一个向量携带了物体几乎全部的几何信息，指望解码器一次性把它完整地铺展成一个128×128分辨率的三平面（triplane，一种用三个正交平面存储3D特征的表示方法）表示,难度陡增。
*Triplane*：一种3D特征存储格式，用三个互相垂直的2D平面网格保存空间信息，查询3D空间中任意一点的属性时，只需要从三个平面上分别采样再融合，兼顾了存储效率和表达能力。
ZipTok3D的解法是让解码器"多想几遍"，但不增加参数量。具体来说，论文用一个六层的Transformer模块（一种基于注意力机制的神经网络结构），让它反复处理同一份triplane状态，每次处理都会重新参考那个被保留下来的token前缀，逐步把状态修正得更精细。默认设置是5轮迭代，每一轮用的都是同一套参数，不会因为多做几轮就多学一套权重。
*参数共享的迭代精细化*：用同一个神经网络模块反复处理数据，每次迭代都在前一次结果的基础上继续修正，从而在不增加参数数量的前提下增加有效计算深度。
这个思路让我想起素描的过程。画家第一遍下笔，通常是打个大概轮廓，人物的比例位置先定下来；第二遍开始加阴影、调整线条的粗细；第三遍才会去抠睫毛、衣服褶皱这类细节。如果只画一遍就想要完整的成品，那画出来的东西必然是粗糙的，因为大脑没法在一次动作里同时处理"整体布局"和"局部细节"这两种截然不同的任务。而如果每一遍都要重新学一整套新的绘画技巧（对应"每一层都用不同参数"），那学习成本会指数级上升。参数共享的巧妙之处就在于，画家用的是同一套技法，只是反复应用，让画面在同一套规则下不断收敛到清晰。
论文里的消融实验清楚地展示了这个效果的分层来源。在K=2的设置下，把COD-VAE的12层单次解码换成6层单次解码（也就是只砍参数量，不加迭代），IoU反而从92.3降到91.9，说明单纯缩小解码器是要付出代价的。但如果把这个6层解码器改成"跑5轮"而不是1轮，IoU一下子跳到96.6，几乎追平甚至超过了参数量翻倍的12层单次解码器。这说明关键不在解码器有多少层，而在于它有没有机会反复咀嚼那份浓缩信息。
图4和图5这两张图（论文中展示refinement过程的可视化）能看出这个过程的具体样貌：只跑1轮的时候，解码出的物体经常缺胳膊少腿，或者表面破碎不连续；跑到3轮，主体结构基本成型；跑到5轮，主要是在收尾，把细支撑结构、边界轮廓这些精细部分打磨清楚。这个由粗到细的收敛过程，跟人手绘素描的节奏惊人地一致。
光有反复迭代还不够，中间过程也要被"教"
如果只在最后一轮的输出上加监督（也就是只告诉网络"第5轮的结果要接近真实答案"），前面几轮的中间状态其实是没有约束的，网络完全可能在中间几轮乱来，只要最后收得回来就行。
论文对此的解决方案是给中间状态也加上监督。具体做法是随机挑一个中间轮次（比如第3轮），同时用两种方式约束它：一是直接拿真实的物体形状去要求这个中间结果接近正确答案，二是让这个中间结果去模仿最终第5轮的输出（论文里叫作"intra-loop self-distillation"，即循环内部的自蒸馏）。第二种约束用的是"stop gradient"的技巧，也就是最终输出被当作一个固定的参考目标，不会反过来被中间状态的梯度影响。
*自蒸馏*：让模型自己较早阶段的输出去模仿自己较晚阶段的输出，相当于用"更成熟的自己"去指导"还不成熟的自己"，从而让中间过程也保持在合理的轨道上。
这有点像跑步教练的训练方式。教练不会只在终点线卡秒表，只关心最终成绩，他会在半程也设个检查点，看看你是不是按照正确的节奏在跑，配速是不是稳定。如果没有这个中间检查点，运动员可能前半程乱跑，靠后半程猛冲来凑成绩，这种跑法长期来看是不稳定的，换个赛道就崩了。给中间轮次加监督，本质上就是确保解码器的每一步迭代都走在正确的路径上，而不是靠最后一步硬拗回来。
消融表里能看到这一点带来的增量确实存在但相对温和：在同样5轮迭代的设置下，加上中间监督后IoU从96.6提升到96.9，CD从0.013降到0.012。增量不大，但方向是正确的，而且这个改动完全不增加推理阶段的计算成本，纯粹是训练时候的"良心工程"。
实测效果：一个token能打平32个token吗
来看看这套组合拳打出来的实际数字。
在ShapeNet数据集上，ZipTok3D用1个token，IoU达到96.8，CD是0.012，F1是97.8。作为对比，COD-VAE用32个token的成绩是IoU 97.1，CD 0.012，F1 97.8。CD和F1两个指标打平，IoU只差0.3个百分点，但token数量从32压到了1，缩短了32倍。
在更复杂多样的TRELLIS数据集上，ZipTok3D用4个token，IoU 75.31，CD 0.0166，F1 95.92，对比COD-VAE-32的IoU 75.25，CD 0.0172，F1 95.67，ZipTok3D不仅token数量少了8倍，CD和F1还略微反超了。论文还专门做了统计学上的置信区间验证（用了两万次的bootstrap重采样），确认CD和F1的提升是有统计学意义的，而IoU的差异在误差范围内，可以视为基本持平。
| 方法 | Token数 | ShapeNet IoU | ShapeNet CD | TRELLIS IoU | TRELLIS CD |
| COD-VAE | 32 | 97.1 | 0.012 | 75.25 | 0.0172 |
| COD-VAE | 2 | 77.7 | 0.032 | 45.85 | 0.0674 |
| ZipTok3D | 1 | **96.8** | **0.012** | 75.18 | 0.0168 |
| ZipTok3D | 4 | 96.9 | 0.012 | **75.31** | **0.0166** |
这组数字放在一起看，最刺眼的对比其实是COD-VAE-2和ZipTok3D-1。前者是COD-VAE原本的架构，硬压到2个token的惨状；后者是ZipTok3D用1个token（还比COD-VAE少一个）达到的效果。同样是极限压缩，一个崩了，一个几乎没掉分，这中间的差距全部来自前面提到的两个设计：排好序的前缀训练，以及反复咀嚼的迭代解码。
生成任务上也不掉链子
光会重建还不够，3D tokenizer最终是要服务于生成任务的，也就是从随机噪声开始，用扩散模型这类生成技术凑出一个新的3D物体。
论文额外搭建了一个两阶段的架构：先用一个额外的VAE（变分自编码器）把ZipTok3D的K×512维前缀压缩成更小的K×32维隐向量，再用EDM（一种扩散模型的训练框架）在这个更小的隐空间上做生成。测试时选用了2个token的设置，也就是生成阶段只需要处理一个2×32的极小张量。
在ShapeNet的五个类别（飞机、汽车、椅子、桌子、步枪）上做类别条件生成，ZipTok3D-2的三个分布相似度指标（MMD、COV、1-NNA，都是衡量生成样本和真实样本分布接近程度的统计指标）都和COD-VAE-32相差不大，但采样速度达到每秒50.62个样本，比COD-VAE-32的46.02更快，完整流程（包括解码和体渲染查询）的速度是36.64样本/秒，和COD-VAE-32的36.14基本持平，同时用的隐序列长度只有COD-VAE-32的十六分之一。
这说明压缩下来的这份"精华token"不是只能用来重建已有的物体，它同样可以作为生成模型操纵的对象，支撑起从无到有地造出新形状。
写在后面
读这篇论文的过程中，最让我意外的一点，是那个"token数量和解码深度是两个独立旋钮"的框架。
一般直觉里，压缩率和重建质量应该是一条曲线上的两个点，你要更短的序列，就必然要接受更差的质量，这是一种此消彼长的关系。但ZipTok3D把这件事拆成了两个维度：一个是"信息装了多少"（token数量K），另一个是"解码器花了多少功夫去解读这些信息"（迭代轮次L）。论文的消融实验显示，这两个维度在不同区间里起作用的方式完全不同：token数量的边际效益在浅层解码时最大，而迭代轮次的边际效益在极短token时最大。这意味着当你手上的信息量本来就很少的时候，砸算力去反复琢磨，比强行多塞几个token更划算。
这个发现其实有点反直觉，因为工程直觉通常会觉得"信息不够就加信息"，但这篇论文告诉你,有时候"信息不够就多想几遍"同样管用,甚至更管用。
论文附录里那个"事后诊断"实验也挺值得琢磨。研究者事后去看，对于ShapeNet测试集里的1283个物体，有76.31%的物体其实用不到2.43个token（平均值）加上3.41轮迭代就能追平COD-VAE-32的效果，但剩下的304个物体，无论怎么调整K和L的组合，都够不上那个门槛。这说明极限压缩这件事本身是有"物体依赖性"的，有些形状天生复杂，硬凑几个token是不够的。论文诚实地把这部分失败案例列出来了，而不是藏起来，这种态度值得认可。这也留下一个没解决的问题：能不能让模型自己判断"这个物体需要几个token"，而不是靠固定预算硬撑？论文最后也提到这是未来的方向，但目前还没有答案。
Q&A
Q1：ZipTok3D是什么？
A：ZipTok3D是一种3D物体的tokenizer，能用极少数量的token（最少1个）就重建出高质量的3D几何形状，核心方法是nested dropout和参数共享的迭代解码。
Q2：ZipTok3D和COD-VAE相比有什么优势？
A：在ShapeNet数据集上，ZipTok3D只用1个token就能达到COD-VAE用32个token的重建质量，序列长度缩短32倍；在TRELLIS数据集上用4个token甚至超过COD-VAE-32，缩短8倍。
Q3：ZipTok3D的推理速度会不会因为迭代解码而变慢？
A：会有一定影响，因为多轮迭代解码增加了计算量，实测全流程吞吐量略低于单次解码的COD-VAE，但压缩后的隐序列在下游生成任务中反而带来了更快的采样速度。
