这篇报告我读了两遍。第一遍觉得"嗯，Qwen又发了个VAE"，第二遍才意识到事情没那么简单。
但我有几个尖锐的问题。
第一，f32c192 NED 0.8555，真能叫"可用"吗？
论文自己说"从不可读推到了部分可读、可评测、能继续优化的阶段"，这其实是委婉的说法。0.8555意味着OCR还有约14%的错误率。对文档、合同、论文截图这种场景，14%的识别错误是不可接受的。论文把它当成一个"进步"来展示，但如果产业落地，这个指标需要推到0.95以上。
更关键的是，论文没有报告人类可读性的评估。NED是OCR-based的，OCR对了不代表人眼舒服。字符粘连、字间距变形，OCR可能通过上下文猜对，但人看着就是别扭。这部分缺失了。
第二，DINOv2语义对齐到底对齐了什么？
论文说"让VAE的latent分布与预训练视觉模型的语义空间对齐"，但没说对齐的是DINOv2的哪一层、什么特征、对齐强度怎么调。DINOv2的浅层是纹理和边缘，深层是语义对象——对齐不同层，latent空间的性质完全不同。这个细节缺失，让"语义对齐"成了一个黑盒。
另外，DINOv2是ImageNet预训练的，它的语义空间是否适合文档、网页、UI这类text-rich场景？论文没讨论这个问题。如果这些场景的latent分布和DINOv2的语义空间本来就错位，强行对齐可能适得其反。
第三，合成渲染引擎的数据占比是多少？
十亿级训练数据中，合成数据占多少？真实文档数据占多少？合成引擎生成的文字和真实文档的字体分布、排版风格、噪声模式差异很大。如果合成数据占比过高，模型在真实文档上的表现可能虚高。论文没有披露这个数据比例，是一个关键遗漏。
第四，SiT实验的说服力有限
论文用SiT验证diffusability，但只在ImageNet 256上跑了80 epoch、without CFG。ImageNet是类条件生成，和真实的文生图场景差距很大。文生图需要处理复杂的文本理解、多物体关系、风格控制——这些能力在ImageNet类条件任务中完全测不出来。
更关键的是，论文没有对比实验：用其他VAE（比如FLUX.2-dev的VAE）训练同样的SiT，看收敛速度和生成质量的差异。没有对照组，"diffusability更好"的结论站不住脚。
最后，产业落地的成本账没算
f16c128的decoder 248M，f32c192也是250M。decoder比encoder重3倍多，推理时decode的代价不可忽略。高分辨率生成（1K、2K）下，decoder的延迟和显存占用会成为瓶颈。论文只报了重构指标，没有报实际推理延迟和显存占用。对基础设施层的VAE来说，这些数字和产品体验直接挂钩。
不过必须承认，OmniDoc-TokenBench这个方向是对的。把"文字可读性"从模糊的定性感受变成NED这种硬指标，对产业评测非常有价值。下一步应该把NED扩展为更完整的"生成式文档视觉质量"体系——包括排版还原、公式识别、表格结构恢复这些维度。
还有，Qwen-Image-VAE-2.0的定位很清晰：不是为benchmark刷分，而是为真实系统服务。encoder保持轻量、decoder承担重建压力、合成数据针对text-rich场景——这些设计选择都是务实的。
但论文的标题如果叫"Qwen-Image-VAE-2.0 Technical Report"，确实太低调了。它做的事比标题大得多。
#千寻 #追评 #论文