六十六分之一的价格打平，便宜模型交付的视频62%是黑帧

Anthropic 的旗舰推理模型 Fable 5.2 昨天在 Cold Iron 测试里拿到 141-145 分。同一天，Meta 新出的小模型 Muse Ember 用六十六分之一的价格拿了同样的分数。

Nemo 没把这个平局当成结论。他换了一道更接近真实工作的题：让两个模型用 Blender 搭意大利渔村 Portofino，要有马蹄形港口、彩色房屋、游艇、山上的城堡、黄金时刻的光，还有一段平滑的无人机式运镜。

两个模型都跑在 OpenRouter 上，都只能出文本，写不了视频，只能写 Blender Python 脚本。温度、token 预算、渲染设置全部一致，取每段相机路径的前 12 秒，720p，Cycles 跑 16 个 CPU 核心，64 样本。渲染预算也一样：Blender 4.5.3 LTS headless，Cycles CPU，16 线程，1280x720。288 帧，24 帧每秒，64 样本加降噪，H.264 编码。提示词 2,376 字节，生成之前用哈希确认了两份副本字节相同。

Fable 5.2 交了 32,000 字符的脚本，第一次运行零错误，零编辑。场景文件 24 兆字节。渲染出来是发光的港口村庄、赤陶屋顶、停在反光水面上的游艇、森林覆盖的山丘，山顶一座带城垛和圆塔的城堡。响应里还附了一张逐镜头的相机表，像导演的分镜。

Muse Ember 写了 8,700 字符，对象清单是对的：676 个对象，城堡、教堂、双松树、四十多座房屋都在。问题出在执行。一个 Blender 命令的参数被改了名，会抛 TypeError；相机从第一帧起就待在一座山内部。Nemo 按规则机械地应用了两处修复并记录在案，其中一处是把相机起始 y 从 -280 挪到 -298。规则是测模型写出来的东西，不是测他希望模型写出来的东西。除此之外，两个模型的输出没有别的改动。

修复没解决根子上的问题。Muse Ember 的相机在 12 秒路径里飞过自己的山丘，几何验证显示相机坐标大部分时间落在山体网格内部。像素审计给出结果：最终视频 62% 的帧是纯黑。从山里面看不到任何东西。

有一件事两个模型一样：都明说自己跑不了 Blender，也附不了文件，然后各交出一段能跑的脚本。

成本方向相反。Fable 的脚本 1.80 美元，Muse Ember 约七分之一美分，差 1200 倍。渲染时间也倒挂：Fable 的 288 帧 720p 花了 3 小时 7 分钟，Muse Ember 花了 1 小时 35 分钟。Muse 的场景每帧快一倍，因为画面里几乎什么都没有；Fable 的场景满是值得看的东西，所以慢。评分标准在查看最终渲染之前就写好，30 分制：Fable 26 分，Muse 11 分。

Nemo 划了一条界：昨天 Cold Iron 的那个平局，在代理工作上不成立。便宜模型赢测验；需要交付结果的任务里，贵的那个把 1.80 美元赚了回来。他也标了边界——两边各一个样本，是设计好的比较，不是稳定性研究。成本记的是每次生成实际用掉的用量数据，跟标价是两回事。Cold Iron 的三轮运行、Muse Ember 那次五美分运行、AETHER 一次性测试，都是不同的测试，该分开看。

复现材料分开放在两处。冻结的提示词、生成收据、修复日志、修复差异在 NemoKnowledgebase 的 benchmarks/portofino-blender 下；两个脚本和两个 .blend 文件在 Nemo 的帖子里。Fable 的场景文件 24 兆字节，Muse Ember 的 6 兆字节。生成 ID 是 Fable 的 gen-1794315824-v9iFni1nMdsRL9Nvf1N0，和 Muse Ember 的 gen-1794315831-pVJzhX0j9p3nOpCLf7hW。