AI艺术指导自评9分，逐帧检查仅4分

一个看似完美的闭环

一位开发者构建了自主艺术指导代理：输入一句话需求，规划器生成镜头描述，SDXL（Juggernaut XL v9）渲染图像，视觉模型评估输出并撰写修正指令，循环重跑直到评论模型通过。随后视频模型将获胜帧动画化。硬件是一张RTX 3090（24GB）、5800X和64GB DDR4——这张卡是所有其他环节必须迁就的约束。

第一次端到端运行在凌晨1:30完成，规划、渲染、评论、判定全流程38秒。首个需求（霓虹雨夜抢劫街道）在第一轮就拿到9/10分。这本身就值得警惕：一个首轮就给出9/10的评论者，本质上是带视觉编码器的橡皮图章。循环的通过门槛是8分，且清除条件中有一句or verdict == pass，宽松的模型可以放行任何结果。

视频模型用失败抬高了标准

转向视频环节后，使用MiniMax-H3图生视频在同卡运行。最初几次输出一团糟，随后配方被破解，三次尝试的分数分别为2/10、4/10、9/10。关键修复是将CLIPLoader类型设为minimax而非hidream，并采用官方采样器链：RandomNoise和BasicGuider（无负面提示、无CFG），KSamplerSelect选res_multistep，BasicScheduler simple 8步，通过LoraLoaderModelOnly加载turbo 8步LoRA，latent从MiniMaxH3ImageToVideo节点的slot 1提取。第三次尝试保住了几何结构且无条带。

于是有了一个9/10的片段。拿给负责批准演示的人看，得到的反馈是“假得要命，我的世界雨物理”。这很公平。重度显式雨丝渲染成了粒子精灵，而真实夜雨看起来是雾气、水珠、滴落和水洼涟漪。

MiniMax-H3 与 CLIPLoader 类型

MiniMax-H3 是 MiniMax 推出的图生视频模型，在 ComfyUI 中通过原生节点接入。CLIPLoader 的 type 参数决定文本编码器的权重加载方式与 tokenizer 配置；minimax 与 hidream 对应不同模型的文本编码分支，选错会导致条件信号与视频模型不匹配，表现为画面结构崩坏或运动混乱。文中最初误设为 hidream，正是前两次输出“一团糟”的直接原因。

采样器链与 turbo LoRA

官方推荐链路把采样拆成显式节点：RandomNoise 提供初始噪声，BasicGuider 只接收正向条件（因此无负面提示、无 CFG），KSamplerSelect 选定 res_multistep 求解器，BasicScheduler 以 simple 模式跑 8 步。turbo 8 步 LoRA 通过 LoraLoaderModelOnly 注入，只改权重不改结构，把推理步数压到 8 步以内。latent 必须从 MiniMaxH3ImageToVideo 节点的 slot 1 取出，slot 0 是条件而非潜变量，取错会让采样器从空 latent 起步。

逐帧检查是另一种测量方式

独立QC环节忽略盲评分。每段视频取13个分散帧，加两段连续7帧序列，拼成联系表逐帧阅读。第6次尝试（最高档50步渲染）大多数单元格得分3到6分（满分10），运动仅4/10。伪字形招牌在帧间变形，雨伞人物每帧都被重新合成，仿佛模型从零重绘。地面斑点沸腾，雨要么缺失要么呈精灵状。而那个9/10的第3次尝试，实际得分4到6分，中途有厂商人脸幻觉，蒸汽在帧间瞬移。

在播放分辨率下盲评分曾是准确的：几何锁定、无条带。但它从未检查两个连续帧是否属于同一个世界。

三个根因按重要性排序：源静帧违反了自己钉下的配方，画面中有人物和可读招牌，视频模型每帧重新发明两者；高清阶段太软，lanczos放大加0.42降噪的img2img使拉普拉斯值为29.7（对比片段第0帧的30.9），模型逐帧动画了糊状物并保留了糊状感；通用的图生视频时间噪声完成了剩余部分。

盲评分与联系表 QC 的差异

盲评分是让视觉模型在播放分辨率下看整段视频并给一个总分，它擅长判断构图、几何锁定和条带这类全局属性，但对时间维度几乎不敏感。联系表（contact sheet）QC 则把 13 个分散帧和两段连续 7 帧序列拼成网格逐格打分，强制模型比较相邻帧中同一物体的身份、位置和纹理。两者测的不是同一件事：前者测“这一帧好不好看”，后者测“这些帧是不是同一个世界”。文章的核心方法论教训正来自这里——播放分辨率下的高分可以完全掩盖逐帧重绘。

背后的显存墙

暴力修复的每次尝试都撞上显卡限制。1920x1088因OOM失败，因为CFG路径每步需要两次前向传播，高清档在改善任何东西之前先让内存翻倍。1664x960在24GB中占用21.6GB（基线1.2GB），且只在显卡真正空闲时才能运行。多次并非如此：llama-swap和常驻引擎在渲染中途溜回GPU，主嫌疑是10:30的定时任务遵循了过时的工作日志状态。

最麻烦的失败是1664x960下124帧VAE解码溢出到主机内存。机器进入交换死亡螺旋：ICMP有响应，TCP端口有响应，ssh在banner交换时死亡，ComfyUI返回空HTTP体。一台能响应ping却说不了hello的机器已经内存耗尽，而网络全程正常。

CFG 与 VAE 解码的显存开销

CFG（无分类器引导）每步需要同时跑条件分支和无条件分支两次前向传播，因此显存占用约翻倍，这也是 1920x1088 直接 OOM 的原因。VAE 解码则是另一类峰值：124 帧的 latent 一次性解码时，中间激活张量远超 24GB，驱动会把溢出部分换到主机内存，触发交换死亡螺旋——进程仍在响应 ICMP 和 TCP，但已无法完成 ssh banner 交换。降低分辨率、分块解码或把评论模型挪到第二张卡，都是绕开这一峰值的常见手段。

LUFS 与真峰值

LUFS 是感知响度的度量，流媒体平台通常把目标定在 -14 LUFS 左右；真峰值（true peak）用插值检测采样间峰值，-1 dBTP 是防削波的安全线。文中音频原始母带为 -30.89 LUFS、-17.33 dBTP，远低于投放标准，两遍 loudnorm 后才落到 -14.7 LUFS、-1.8 dBTP。

四道防线

循环中落地了四项更改，提交为c26c82c。

门槛从8提到9，严格清除：分数至少9且判定为pass，or verdict == pass旁路被移除。

规划器和评论者的链式感知品味：无人物或生物、无可读文字或字形、有环境运动潜力、1080p下干净。违规将分数上限压到7，无论画面多漂亮。

修复增量到达规划器：它们此前被计算后丢弃，使循环形同虚设。现在规划器收到问题、提示和负面增量、近期提示，必须进化它们。

高清阶段改为潜空间放大：1.5倍lanczos加30步KSampler、0.42降噪、dpmpp_2m配karras、cfg 5，替代软lanczos加img2img路线。

门槛标准也变了：没有片段可以仅凭播放分辨率下的单帧阅读就发布。每次都要13个分散帧加连续序列。

音频也做了同样处理。生成的雨声通过了独立真实感评分0.91（“真实或专业制作”），但母带测量为-30.89 LUFS、真峰值-17.33。两遍loudnorm到I=-14、TP=-1.5后落在-14.7 LUFS、-1.8 dBTP，零削波样本。该配方现已成为管道常量。

已交付与下一步

强化后的循环已就位。尚无片段通过视频门槛。获胜者必须来自从一开始就遵守链式配方的静帧，由新循环以9分门槛渲染、正确放大、然后以50步CFG 2.0且无LoRA动画化，每段约65分钟。

第二张3090已安装在下方插槽。一张卡同时承载渲染和评论者是常驻引擎中途被驱逐、每个高清档变成内存谈判的原因。两张卡让评论者独占24GB，结束VRAM竞争。机器因电源更换停机，回来后第一个任务是以更高门槛跑相同需求。

一天半的测量教会一个廉价习惯：模型在播放分辨率下给自己的输出打分时会说画面很美。问它第47帧和第48帧，它会告诉你画面是否稳得住。