重画一遍脸就变了、招牌上的字也糊了：英伟达给 H3 开源的高清重绘出了第二版，专门修这个
3分钟看懂
11 月 8 日傍晚（太平洋时间），英伟达 NVlabs 的 Sana 团队放出了 Open-H3-Regenerate-2K-IC。名字很长，但事情很简单：它不是一个新的视频生成模型，而是给 MiniMax H3 那条流水线补上的最后一段——把 H3 先吐出来的 768P 草稿，重画成 1080P、2K 甚至 4K。
一句话结论：这是同一件事的第二版，专门修第一版最要命的毛病——重画的时候把人脸、嘴型、招牌上的字一起改掉了。
需要先说清口径：这篇的核心事实（发布物、训练与推理方式、采样参数、许可证条款）来自英伟达的官方模型卡、NVlabs 项目页和 NVlabs/Sana 仓库的提交记录；硬件门槛、社区转换版本、ComfyUI 节点这些细节，基于多家媒体转述整理，厂商没有发布技术报告。
还要先把一件事分清楚。今年 10 月底，同一支团队已经开源过一版 Open-H3-Regenerate-2K，我们当时也写过实测：清楚是真清楚，但脸会变，高动态画面还会拖影。这次不是那个项目的重新曝光，是换了技术路线的新版本，权重、代码、项目页都是这一两天才出现的。判断标准很简单：上一版的结论是"能用但会改脸"，这一版的全部卖点就是"不改脸"。
它修的是上一版的哪个毛病
先理解 H3 是怎么出片的。它分两段：第一段用低分辨率把内容、动作、构图定下来——便宜、快、但糊；第二段把这条草稿重画到高分辨率——贵，但决定了成片能不能交付。
第一段是开源的，第二段一直是 MiniMax 的托管 API，权重不放。10 月 26 日 NVlabs 补上了这个空缺，做法是：把草稿重新加噪，再让它擦一遍。
问题就出在"擦"这个动作上。一旦草稿被噪声糊掉再重画，模型就得靠自己去猜"这张脸长什么样""招牌上写的是什么"。猜得越用力，细节越漂亮，但猜错的地方也越多：眼睛位置偏一点、嘴型对不上音、招牌上的"PRIVATE CAR PARK"变成一串看不懂的笔画。对做广告、口播、产品特写的人来说，这一条就够判死刑了——画面再清楚，脸不是那个人，片子也不能用。
IC 版怎么绕开的：把草稿留在旁边，不许动
IC 是 in-context 的缩写。这一版的做法是：草稿一帧都不改，原封不动地放在参考位上，高清画面从纯噪声在旁边重新长出来，每一步都回头看它。
具体一点：H3 自带一个叫 Ref2VA 的"参考转视频"Transformer，它本来就能把参考视频当成额外的 token 读进去。团队把这个 Transformer 冻住，只训了一个 rank 384 的 LoRA（约 312 个线性层，FP32）。训练时每一对样本都来自一条真实的 768P 到 4K 的片子：把高清片缩小（有时再加模糊）当作"草稿"放前面，高清片当目标放后面，噪声强度从纯噪声一路抽到干净，损失只算在目标那一段。
于是就出现了这样一条链路：草稿始终干净地摆在上下文里，高清画面从 σ=1 的纯噪声起步，每走一步都 attend 回草稿。项目页的说法是"人脸、口型、文字和布局跟着草稿走，细节在 2K/4K 上重新画"。
这话听着像营销，但有一个很硬的旁证：上一版靠 RefinerBench-150 和 200 次盲测刷出了 87% 的偏好率，这一版一个 benchmark 都没发。 官方给的对比全是自选样片——停车场招牌、翠鸟、玻璃蘑菇，以及和官方 API 的并排。自选样片能说明方向，不能说明分布。这是我给这件事打的第一个折扣。
三种跑法，和那张"几步"的表
推理参数不复杂，官方给了三个采样器，区别只在 2K/4K 的潜变量从哪里起步：
up3（默认）：草稿潜变量先用一个 3D 卷积的 latent upscaler 直接放大到目标网格（不解码、不重编码），加噪到 σ=0.835，然后三次 Transformer 调用收尾。up4：同样从放大后的潜变量起步，起点 σ=0.923，四次调用。hf8：从纯噪声开始，走完 HyperFlow 的八步。
三个都是 CFG 1，也就是每一步只花一次前向。加载时会把 HyperFlow 八步 LoRA、社区的 LMS Sharp 1.0，和 IC LoRA 合并进同一个 Transformer。2K 结果用快解 VAE 解码，4K 用标准 VAE。草稿的音轨原样复制过去，不重新生成——静音素材也要求带一条静音音轨，权重包里就附了一份。
输入输出这里有个小坑值得记：模型卡写的是 4K = 3840×2160，项目页的 4K 演示标的是 4096×2304。这处不一致官方没解释，按保守的那个理解就行。另外 384P、512P、576P 的草稿进去，出来是 768P，不是直接跳 4K。
硬件：能跑，但门槛写在没说的地方
模型卡的示例命令是 torchrun --nproc_per_node 8，Transformer 可以切在 1、2、4、7 或 8 张卡上（FSDP + Ulysses 上下文并行）。官方没有公布 IC 版的最低显存。
这里必须把两件事分开：上一版在单张 B200 上，5 秒 2K 片段"潜变量放大 + 三步重绘 + VAE 解码"是 22.45 秒（不开优化是 87.26 秒）；我们 10 月底那篇实测里，2K 直接吃满 48G 显存，只跑 3 秒的话 16G 也能起来。这些数字都属于上一版，不能顺延到 IC——IC 多了"草稿常驻上下文"，显存只会更紧，不会更松。
社区已经动起来了：Kijai 把那份 8.3 GB 的 FP32 LoRA 压成了 200 MB 的 rank-21 bf16 版本；另有一个 ComfyUI 节点包（Prepare Draft / Official Prompt / Sigma Grid / Compose Target Latent），配了三个工作流——文生草稿到 2K、参考图到草稿到 2K、草稿直接到 2K。这些都是第三方产物，官方没有出节点。
许可证：这条比技术门槛更硬
权重挂在 Efficient-Large-Model 账号下，走的是 MiniMax H3 社区许可，而这份许可写得很清楚：适用地域是全球除去欧盟、英国、韩国和美国。
也就是说，对住在这些地方的开发者和公司，这份权重在法律上就没被授权使用，不是"要申请"，是"不在范围内"。许可里还有两条：年收入超过 2000 万美元的商业产品要单独拿 MiniMax 的书面授权；用了 H3 的商业产品要在界面上标出 "MiniMax H3"。
模型卡自己也写了——"这不是 MiniMax 的官方产品"。所以它解决的是"开源社区拿不到 2K 那一段"，没解决"你能不能合法用"。
适用场景
- 本地跑 H3、需要把草稿交付成 2K/4K，但人在许可允许的地域内；
- 画面里有必须保住的元素：人脸、口型、字幕、招牌、包装上的文字；
- 已经有一条满意的草稿，只想把清晰度提上去，不想重新抽一次；
- 想做 5 秒级短片验证，或者接在"一采 → 二采 → 重绘"的流水线尾巴上。
不适用场景
- 在美/英/欧盟/韩——许可不允许，先解决合规再谈技术；
- 需要第三方 benchmark 或第三方实测才能决策的采购流程——IC 版目前一个公开评测都没有；
- 高动态、快速动作、打斗镜头——这是 H3 底子的问题，重绘那一段修不了，只能外挂 LoRA 硬压；
- 想拿它当"通用视频超分"处理老素材——它吃的是 H3 的草稿和原始 caption，不是任意成品片；
- 只有 16G 显存还想批量出 2K 长片。
避坑提醒
- 别把上一版的数字搬过来。 22.45 秒、87% 盲测、RefinerBench-150，全是第一版的成绩，IC 版官方一个字都没给。任何"快了 X 倍""赢了官方 API"的说法，在这版上目前没有依据。
- 别只看官方对比样片。 挑的是最能体现"保住文字"的停车场招牌。真正会翻车的是运动模糊、半透明材质、多人交叠——这三类官方没放对比。
- caption 要用原样的。 官方明确说把生成草稿时那条 H3 prompt 原封不动传回去，不做额外提示词工程，也可以留空。自己重写一遍反而可能让它偏离草稿。
- 4K 的尺寸定义有冲突（3840×2160 vs 4096×2304），排期做交付规格前先自己跑一条确认。
- 分清"开源"和"可商用"。 权重能下载，不等于你能在所在地区商用。
成本与时间
钱这件事要说实话：权重免费，算力不免费。 官方没给 IC 版的耗时，也没给显存下限，能参考的只有上一版在单张 B200 上的 22.45 秒（5 秒 2K，不含草稿生成、模型加载和文本编码）。租一张 B200 按小时计价，跑几十条测试就是几百到上千美元量级——具体数字取决于你拿到的卡价，这里不做推算。
时间上倒是有明确坐标：HF 仓库 11 月 8 日 17:50（太平洋时间）建好，代码 11 月 9 日凌晨进主干，项目页同批上线。换句话说，这东西到现在为止存在不到两天，任何"实测结论"都还没沉淀出来。
怎么用（参考路径）
官方没有 GUI，教程里给的路径就是命令行，大致四步：
- 按模型卡拉权重：
python infer/download.py --out weights（加--base-from-minimax则从官方 H3 仓库取基础组件）。 - 把草稿和它原来的 caption 一起喂进去：
--input draft.mp4 --caption "..."，caption 原样不改。 - 选分辨率与采样器：
--resolution 2k（默认，2560×1440）、--sampler up3（默认三连）、up4或hf8。 - 多张卡按 FSDP 切：
torchrun --nproc_per_node 8，卡数可选 1/2/4/7/8。
在 ComfyUI 里目前只有社区节点，官方没出；要用就得装第三方节点包，稳定性自己掂量。
第一步怎么做
如果你只是想判断值不值得跟：先把项目页那三组并排看完，重点不是看清晰度，是看没被改的地方有没有漂——瞳孔位置、牙齿数量、招牌笔画的连通性。这三处是重绘类方案最容易露馅的地方。
如果你确定要试：先确认自己不在排除地域内，再按模型卡把 base_model/ 拉下来（infer/download.py 支持从官方 H3 仓库取），拿一条 5 秒、带人正脸和一处屏幕文字的草稿，只跑 up3 默认档，把输出和草稿逐帧对齐看口型。这一步能省掉后面所有的猜测。
值得注意的取舍
这条新闻真正值得记的不是"又开源了一个模型"，而是它暴露了这条技术路线的分水岭。
过去一年，视频模型的钱几乎都花在"把画面做得更像真的"上。但真正卡住交付的，往往是最后那一公里：草稿很清楚，重画一遍就散了。上一版选择"擦得更用力"，代价是改脸；这一版选择"把草稿供起来不许动"，代价是新增的纹理更少、显存更紧、还得每一步都 attend 一份完整参考。
这是一个很典型的工程取舍：保真度和锐度，你只能选一个当主目标。 IC 版把保真度放在了前面，这在广告、口播、电商这类"人不能变、字不能错"的场景里是对的；但在风景、氛围、纯视觉冲击的素材上，它可能不如上一版好看。
至于它能不能成为默认选项，取决于两件官方还没给的东西：一份第三方 benchmark，和一个说得清的显存下限。在那之前，它是一个方向正确的补丁，不是一个可以排进生产线的成品。
参考来源
- https://huggingface.co/Efficient-Large-Model/Open-H3-Regenerate-2K-IC
- https://nvlabs.github.io/Sana/Open-H3-Regenerate-2K/
- https://github.com/NVlabs/Sana/tree/sol-engine/models/Open-H3-Regenerate-2K/IC
- https://www.llms.blog/posts/nvidia-open-h3-regenerate-2k-ic-video-refiner
- https://comfyui-wiki.com/en/news/2026-11-09-open-h3-regenerate-2k-ic
- https://aifilmhq.com/entry/open-h3-regenerate-2k-ic-minimax-h3-drafts-to-2k-or-4k/
参考来源
- https://huggingface.co/Efficient-Large-Model/Open-H3-Regenerate-2K-IC
- https://nvlabs.github.io/Sana/Open-H3-Regenerate-2K/
- https://github.com/NVlabs/Sana/tree/sol-engine/models/Open-H3-Regenerate-2K/IC
- https://www.llms.blog/posts/nvidia-open-h3-regenerate-2k-ic-video-refiner
- https://comfyui-wiki.com/en/news/2026-11-09-open-h3-regenerate-2k-ic
- https://aifilmhq.com/entry/open-h3-regenerate-2k-ic-minimax-h3-drafts-to-2k-or-4k/