企业官网建设流程全解析

在本地跑视频生成模型，最让人崩溃的不是出片慢，而是放大那一步。你用 MiniMax H3 生成了一段满意的视频，分辨率只有 720P，想放大到 1080P 甚至 4K，结果一跑就爆显存，显卡直接报 OOM，前面等了半小时的成果卡在最后一步。换 24G 显存的卡？成本太高。于是社区开始流行一种更聪明的做法：不让整段视频一次性进入超分模型，而是把视频的 3D Latent 拆成一个个小块，分块处理，再拼回去。这就是“3D Latent 分块超清”思路。

这个方案的核心价值，不是让超分模型变得更快，而是显著降低单次前向传播时占用的显存峰值。原来需要 24G 显存才能跑的大分辨率视频放大任务，通过合理分块，8G、12G、16G 的显卡也有机会跑完。很多人以为这是通过某个新模型实现的，其实它更多是一种工程优化手段：把“一次处理整段视频”改成“一次处理一小段，循环处理，最后带重叠融合地拼接”。

MiniMax H3 是最近社区热度很高的本地视频生成模型，已经有不少 ComfyUI 整合包、导演台工作流在围绕它构建。生成端大家已经玩得很熟练，真正影响成片质量的瓶颈，往往在视频放大这个后处理环节。本文就不绕弯子，直接讲清楚 3D Latent 分块超清的原理、部署环境、完整工作流和常见坑。

阅读本文后，你至少能理解三个问题：为什么视频放大比图片放大更容易爆显存；为什么把 Latent 分块之后显存占用会降下来；以及在一台低显存显卡上，如何把一条 MiniMax H3 视频放大工作流完整跑通。

1. 这篇文章真正要解决的问题

视频生成模型的默认输出分辨率是有限的。MiniMax H3 生成出来的视频，如果直接用于网络发布或后期剪辑，往往还需要再做一步放大。放大本身并不复杂，用任意一款超分模型跑一遍就能完成。但放到视频场景后，问题就变得棘手了。

第一，视频是三维数据。图片是 H×W 两维，视频多了一个时间轴 T。直接把超分模型套到整段视频上，中间特征图的尺寸会变成 T×H×W 级别。T 一长，显存立刻失控。

第二，视频放大经常要在 Latent 空间做。视频生成模型一般先用 VAE 把像素编码成 Latent，生成器工作完后，再通过 VAE 解码回像素。如果放大模块放在 Latent 和 VAE 解码之间，Latent 本身就带有时间维度，处理起来比单帧图片更吃显存。

第三，用户手里的显卡并不都是旗舰卡。从社区讨论看，围绕 MiniMax H3 本地部署，最常见的问题是 8G 显存整合包、12G 或 16G 显卡能不能跑这类模型。这些显卡能生成视频，但不代表能整段超高分辨率放大。

所以，本文真正要解决的，不是“如何用更好的超分模型”，而是“如何让放大这步在现有显卡上跑得动”。3D Latent 分块方案解决的是显存峰值问题，而不是算法质量问题。它让你在显存有限时，还能完成高清视频放大，只是需要牺牲一点速度和工程复杂度。

什么人最应该读这篇文章？一是准备在本地部署 MiniMax H3 并做完整出片流程的人；二是手里的显卡刚好处于 8G 到 16G 之间、一跑放大就 OOM 的人；三是想在 ComfyUI 里搭建一套视频放大工作流的玩家。如果你手里已经有 24G 以上显存，整段放大通常没有问题，分块方案对你来说意义不大，但了解原理也有利于处理更长视频。

2. 基础概念：MiniMax H3、3D Latent 与分块超分

在进入实操之前，先把几个关键概念讲清楚，后面看工作流时会轻松很多。

2.1 MiniMax H3 是做什么的

从社区实践看，MiniMax H3 是一款支持本地部署的视频生成模型。它能够根据文本、图像或既有视频片段生成新视频，也可以配合导演台、全能工作流等周边工具完成从分镜到成片的完整流程。热词里出现的“minimax h3 本地部署”“minimax h3 一键整合包 8G 底显存”“comfyui minimax h3整合包”，都说明它已经在 ComfyUI 生态里形成了比较完整的使用方式，不只是在云端 API 调用才能用。

对普通用户来说，MiniMax H3 的吸引力在于：模型权重可以放到本地，基于 ComfyUI 的可视化节点来编排工作流，而不是只依赖在线服务。生成完后接放大、接转码、接剪辑，都是本地文件操作，工作流更自由。

但“能本地部署”不等于“任何环节都不吃显存”。视频生成本身对显存有要求，放大环节同样有。MiniMax H3 的视频放大，如果沿用整段处理的老方法，对显存要求依然很高。这也是 3D Latent 分块方案在相关社区里热度上升的原因。

2.2 3D Latent：视频在模型内部的存在形式

“Latent”（潜空间表示）可以这样理解：视频像素被 VAE 编码后，变成一组压缩过的特征，这组特征保留了视频内容的语义信息，但尺寸比原始像素小得多。对于视频，这个特征通常还保留时间维度，所以叫 3D Latent，形状大概是 [B, C, T, H, W]：

• B 是批次大小。
• C 是通道数。
• T 是帧数或时间维度。
• H 和 W 是空间高度和宽度。

相比直接处理像素帧，处理 Latent 的好处是计算量更小。许多视频生成模型和视频超分模型都把核心计算放在 Latent 空间完成，就是因为这个原因。

但 Latent 虽然比像素小，放到视频里仍然会随着分辨率、时长线性增长。一分钟 1080P 的视频，Latent 的体量比一张图大得多，如果整块塞进模型前向传播，显存还是可能不够用。

2.3 分块超分：把大计算拆成小计算

分块超分并不是视频领域首创。在图片超分场景里，有一种经典做法叫 tile：把大图切成若干小图，逐张放大，再拼回大图，这样显卡峰值显存只取决于单个 tile 的大小。3D Latent 分块本质上是把 tile 思路从二维图片扩展到三维视频：既然整段 Latent 一次性处理会爆显存，那就按时间轴或空间轴把它切成多个小块，逐块放大，最后合并。

这样做能降低显存峰值，原因很简单：模型前向传播时，中间激活值和输入大小基本成正比。输入从整段视频变成一个小块，单次前向传播的中间结果就大幅缩小。虽然总的计算量没有减少，甚至因为重叠区会略有增加，但峰值显存从“最大块的尺寸”而不是“整个视频的尺寸”决定，因此低显存显卡也能跑。

3. 视频放大为什么会爆显存

理解了概念，再来分析实际工程中显存爆掉的来源。很多时候，用户看到“CUDA out of memory”就以为显卡不行，实际上是没有分清显存到底被谁吃掉了。

3.1 显存峰值来自哪里

深度学习推理过程中，显存占用主要来自三块。

首先是模型权重。超分模型无论大小，权重都要常驻显存。这部分是固定开销，不会因为你输入的帧数变少而减小。

其次是激活值（activation）。数据在模型每一层前向传播时，会产生中间特征图。对于视频来说，中间特征图的尺寸是批次 × 通道 × 时间 × 高度 × 宽度。这是视频放大显存消耗的大头，而且随着视频分辨率和长度增加呈倍数增长。

最后是临时缓冲区。包括 CUDA context、计算图缓存、图像重排的临时张量等。这些虽然不显眼，但叠加起来可能占掉 1 到 2G 显存。如果你开了别的程序，或者系统桌面还占着一部分显存，实际可用空间会更小。

3.2 直接整段放大的三座大山

把整段视频直接丢进超分模型，会遇到三座大山。

第一座：VAE 解码。Latent 要放大，需要先被解码到像素空间，或者超分模型直接在 Latent 空间处理后再解码。视频越长、分辨率越高，这一步产生的中间张量就越大。

第二座：超分网络前向传播。以常见的超分结构为例，模型会把输入映射到更高维度的特征空间，再做上采样。特征图可能比输入大很多倍。假设输入 Latent 是 T×H×W，中间特征可能是 64 通道、128 通道，每个通道还是 T×H×W，显存占用会瞬间放大。

第三座：后处理。放大完成后要拼接、转码、保存，FFmpeg 和图像处理库也会申请内存。虽然不一定占显存，但在 CPU 内存和显存之间拷贝时，如果处理不当，同样会拖慢流程甚至导致 OOM。

3.3 一个粗略的显存估算思路

我们可以用“分辨率放大，显存需求近似放大”这个粗略尺度来估算。假设 540P 视频整段放大没问题，那么同样时长放大到 1080P，因为长宽各放大 2 倍，像素总量是原来的 4 倍，激活值相关的显存大致也会接近 4 倍。如果再放大到 4K，那就是 540P 的 16 倍。这种情况下，原来 8G 显存刚好能跑的任务，放大两档之后确实会爆。

这里要注意，这个估算只是经验法则，不同模型架构差异很大。有的模型因为使用全局注意力，显存会随序列长度平方级增长，这时分块的意义更大；有的模型以卷积为主，增长更接近线性。实际优化时，以显存监控工具的实测为准，不要凭感觉。

总之，爆显存的本质不是显卡“不够好”，而是单次前向传播的输入过大。3D Latent 分块解决的就是这个问题：把单次输入缩小。

4. 环境准备与前置条件

下面进入可操作环节。因为 MiniMax H3 相关生态更新较快，本文不会写死具体版本号，重点说明通用环境和需要准备什么。以你实际下载的项目要求为准。

4.1 硬件配置建议

按照社区常见的“8G 底显存整合包”说法，8G 显存显卡是低配门槛。但要注意，能跑通 MiniMax H3 生成，和能在放大工作流里跑高清视频，是两个不同要求。分块方案能降低显存峰值，并不意味着完全不需要显存。

最低配置建议：

• 显卡：8G 显存，NVIDIA 优先，支持 CUDA。
• CPU 内存：32G 以上，视频处理时中间帧和临时文件很占内存。
• 硬盘：建议 SSD，至少预留 50G 以上空间。模型权重、视频缓存、分块临时文件都需要空间。

推荐配置建议：

• 显卡：12G 或 16G 显存。
• CPU 内存：64G。
• 硬盘：NVMe SSD，容量越大越省心。

如果是 6G 显存，也不是完全不能跑，但建议把分块开得更小，视频长度和分辨率再降一档。至于热词里出现的“AMD 显卡”“国产显卡”，如果项目本身只支持 CUDA，那么这些显卡需要额外确认是否有对应推理后端，不能默认可用。

4.2 软件栈：ComfyUI、Python、驱动与 CUDA

软件环境大致包括四类。

• 操作系统：Windows 10/11 或 Linux 均可。MiniMax H3 相关的 ComfyUI 整合包，Windows 下用得比较多；但如果追求稳定跑大批量任务，Linux 环境更省心。
• Python：3.10 或 3.11 是当前多数大模型项目的常见选择。具体版本以项目 requirements 为准。
• 显卡驱动与 CUDA：NVIDIA 显卡一般要求较新的驱动。CUDA 版本可以优先看项目要求，比如项目要求 CUDA 11.8 或 12.x，安装对应 PyTorch 版本即可。不要盲目装最新版。
• ComfyUI：本地部署的视频生成和视频放大工作流，很多都以 ComfyUI 作为前端。你可以选择官方 ComfyUI 加自定义节点，也可以使用社区做好的整合包。

建议先把环境隔离好，用虚拟环境管理 Python 依赖。视频生成模型依赖很多，和系统 Python 环境混在一起，很容易出现版本冲突。

4.3 获取模型与工作流资源的通用方式

MiniMax H3 的权重和 ComfyUI 整合包，通常通过开源社区或官方渠道获取。获取时注意两点：

• 从可信任的渠道下载，校验文件完整性，不要随意运行来源不明的脚本。
• 确认授权范围，遵守模型许可协议，不要用于违法违规场景。

下载完成后，一般会把模型目录放入 ComfyUI 的 models 文件夹下，并在工作流里指定对应路径。具体路径因整合包而异，以项目 README 为准。

5. 3D Latent 分块放大的核心流程

环境准备好之后，我们来看 3D Latent 分块放大工作流的完整流程。整条链路可以拆成五步。

5.1 整体流程概览

流程可以概括为：

视频解码 → VAE 编码得到 3D Latent → 按时间或空间分块 → 逐块超分放大 → 重叠区融合 → 合并 Latent → VAE 解码回像素 → 视频编码输出。

从工程上看，中间最关键的是“3D Latent 分块”这一步。它决定了显存峰值有多高，也决定了最后拼接的难度。

5.2 视频切分与 Latent 分块

第一步是把输入视频解成帧序列。不要直接让超分模型去吃一个 mp4 文件，而是先解成帧，再通过 VAE 编码成 Latent。

得到 3D Latent 后，开始分块。分块有两种维度：

• 时间维度分块：把连续 T 帧切成多个小段，比如每 8 帧一块，相邻块之间重叠 2 帧。时间分块对显存友好，因为几乎所有视频生成模型的时间长度都是可以拆的。
• 空间维度分块：如果单段视频的分辨率仍然很高，或者显卡特别有限，可以把每一帧内部再切成多个 tile，即把 H×W 也切小。

实践中我更推荐“时间优先”策略：先按时间切成能放进显存的小段，如果单段还是太大，再在空间上分块。这样单帧连续性更好，也便于后续处理。

分块参数有三个最需要关注：chunk_frames（每块帧数）、overlap_frames（重叠帧数）、chunk_size（空间分块尺寸）。chunk_frames 越小，显存峰值越低，但块数变多，总耗时增加，拼接次数也变多。overlap_frames 越大，时间拼接越平滑，但计算冗余越大。一般从 2 帧重叠开始试。

5.3 重叠区与边缘平滑

分块后再原样拼回去，很可能会在块与块的边界看到接缝，或者视频播放时产生闪烁。原因在于超分模型在独立处理每个块时，看到的上下文不同，输出在边界处会有差异。尤其视频还会伴随时间上的闪烁。

处理办法是重叠与融合。在时间维度上，相邻块保留重叠帧；在空间维度上，相邻 tile 保留重叠像素。合并时，重叠区不是简单取一块的数值，而是做加权平均：越靠近当前块中心，权重越高；越靠近边界，权重越低。这样能有效抹掉硬边界。

此外，可以给超分模型传入一定的全局参考帧。例如让每个分块同时看到视频首帧或前一块的输出，保持同一段视频的色调和纹理一致性。社区工作流里的 3D Latent 放大，通常会把这些细节封装成节点，但理解原理后，即使手动写脚本也知道该在哪里处理。

5.4 合并与视频编码

所有分块放大完成后，把它们按照原来的坐标合并回完整的 3D Latent。然后做 VAE 解码，把 Latent 转回像素帧，再用 FFmpeg 之类的工具把所有帧合成视频。

这一步要注意输出视频长度和输入视频长度保持一致。因为分块时按帧数切，往往存在除不尽的情况，需要在末尾做帧数对齐。如果输出视频比输入多了几帧或少了几帧，播放时就会看到明显卡顿或音画不同步。

6. 完整示例：ComfyUI 工作流与 Python 实现

理论清楚了，下面给出一个可以落地的示例。由于 MiniMax H3 相关整合包和节点更新很快，示例的重点是展示思路和关键代码，而不是照抄节点名称。实际运行以你使用的整合包界面为准。

6.1 在 ComfyUI 中加载工作流

如果你使用 ComfyUI，最简单的方式是加载社区分享的工作流 JSON。一般流程是：

• 打开 ComfyUI 页面。
• 把工作流 JSON 文件拖入页面，或者通过菜单加载。
• 检查所有节点是否标红。标红通常表示缺少自定义节点。
• 在 ComfyUI 的 Custom Nodes 里安装缺失节点，重启生效。
• 配置模型路径和输入视频路径。
• 点击 Queue 运行。

MiniMax H3 周边生态里常用的节点可能包括视频加载、VAE 编解码、Latent 分块、放大模型、视频保存等。不同整合包的节点命名会有差异，不要看到名字不一致就以为工作流坏了。

6.2 关键节点配置示例

下面给出一段简化的工作流 JSON 结构，用于展示 3D Latent 分块放大工作流的节点组织思路。实际使用时，以你 ComfyUI 导出的 JSON 为准。

{ "nodes": [ { "id": 1, "type": "LoadVideo", "title": "加载输入视频", "inputs": { "video": "input.mp4" } }, { "id": 2, "type": "VAEEncodeVideo", "title": "视频编码到 Latent", "inputs": { "frames": [1, 0] } }, { "id": 3, "type": "SplitLatent", "title": "3D Latent 分块", "inputs": { "latent": [2, 0], "chunk_frames": 8, "overlap_frames": 2, "chunk_size": 512 } }, { "id": 4, "type": "VideoUpscaleModel", "title": "分块放大模型", "inputs": { "chunk": [3, 0] } }, { "id": 5, "type": "MergeLatent", "title": "合并放大后的分块", "inputs": { "chunks": [4, 0], "overlap_frames": 2 } }, { "id": 6, "type": "VAEDecodeVideo", "title": "VAE 解码回像素", "inputs": { "latent": [5, 0] } }, { "id": 7, "type": "SaveVideo", "title": "保存放大视频", "inputs": { "frames": [6, 0], "filename": "output_hd.mp4" } } ] }

这段 JSON 不是某个具体整合包的可导入文件，而是逻辑示意。你在真实工作流里看到的节点类型、字段名会改动。手写 ComfyUI JSON 工作流容易出错，更推荐在界面里通过连线拖出来，再保存导出。

6.3 Python 后端处理示例

如果你想脱离 ComfyUI，或者想在公司内部实现批量视频放大，可以使用 Python 脚本。下面是分块与合并的核心逻辑示例。

import torch def split_latent_by_time(latent, chunk_frames, overlap_frames): """ 将 3D Latent 沿时间轴分成小块 latent 形状: [B, C, T, H, W] 返回块列表 """ t_total = latent.shape[2] step = chunk_frames - overlap_frames if step <= 0: raise ValueError("chunk_frames 必须大于 overlap_frames") chunks = [] start = 0 while start < t_total: end = min(start + chunk_frames, t_total) chunks.append(latent[:, :, start:end, :, :]) if end == t_total: break start = start + step return chunks def upscale_chunks(chunks, upscale_model): """ 对每个 Latent 分块调用超分模型 """ outputs = [] for chunk in chunks: with torch.inference_mode(): chunk = chunk.to("cuda") out = upscale_model(chunk) outputs.append(out.cpu()) return outputs def merge_chunks_with_overlap(chunks, overlap_frames): """ 合并时间维带重叠的分块，重叠区做线性融合 为清晰起见，这里只演示单通道张量，实际要按通道广播权重 """ merged = None for i, chunk in enumerate(chunks): if merged is None: merged = chunk continue prev_len = merged.shape[2] overlap = min(overlap_frames, prev_len, chunk.shape[2]) non_overlap = merged.shape[2] - overlap # 保留前一段非重叠部分 result = merged[:, :, :non_overlap] # 记录重叠部分 prev_overlap = merged[:, :, non_overlap:prev_len] curr_overlap = chunk[:, :, :overlap] if overlap > 0: alpha = torch.linspace(0, 1, overlap).view(1, 1, overlap, 1, 1) fused = prev_overlap * (1 - alpha) + curr_overlap * alpha result = torch.cat([result, fused], dim=2) # 当前块剩余部分 if chunk.shape[2] > overlap: result = torch.cat([result, chunk[:, :, overlap:]], dim=2) merged = result return merged

这段代码和真实生产脚本还有距离，但已经把最关键的三个动作展示出来了：切块、逐块放大、重叠融合。你在实际项目里，只需要把upscale_model换成真实的视频超分模型，把latent换成 VAE 编码得到的 3D Latent，就能跑通一个最小版本。

运行脚本时建议加一点日志，输出每个 chunk 的编号、耗时和当前显存占用。这样即使中间崩了，也能明确知道是哪个分块出了问题。

6.4 命令行调用与日志观察

如果项目提供命令行入口，通常长这样：

python run_video_upscale.py \ --input input.mp4 \ --output output_hd.mp4 \ --chunk-frames 8 \ --overlap-frames 2 \ --scale 2 \ --device cuda:0

不同项目的参数名不一样，但核心参数就是输入、输出、块大小、重叠和放大倍数。运行时，重点观察两个日志指标：

• 单个 chunk 的显存峰值：如果峰值已经接近显卡上限，说明 chunk_frames 或 chunk_size 还要调小。
• 单个 chunk 的处理时间：如果时间突然变得很长，大概率是发生了 CPU 与 GPU 频繁拷贝，需要检查数据是否还在 GPU 上。

7. 运行验证与常见问题排查

7.1 判断成功的三个标准

视频放大跑完，不能只看“输出文件存在”就认为成功。建议按三个标准检查：

• 显存是否全程可控。运行过程中没有出现 CUDA OOM 崩溃。
• 视频长度和原视频一致。帧数没有多也没有少，音画同步正常。
• 画面没有明显接缝和闪烁。播放时重点看分块边界、高频纹理区域和运动镜头。

7.2 显存监控方法

Linux 下可以直接在另一终端运行：

nvidia-smi -l 1

Windows 下使用：

nvidia-smi

或者在 PowerShell / CMD 里循环执行。任务管理器也能看显卡总占用，但只看总量，不够精确。跑放大任务时，建议全程盯住显存占用曲线，确认它稳定在某个区间而不是逐渐爬升。如果显存持续爬升，可能是某个节点没有释放缓存，长时间跑多个视频会越来越卡。

7.3 常见问题排查表

这些是视频分块放大里最常见的几类问题。遇到问题时，先确认崩溃发生在哪一个环节，再按表格针对性排查，不要一上来就换显卡或者重装环境。

8. 最佳实践与工程建议

到了实践建议环节。这些内容来自视频超分工程里的通用经验，对 MiniMax H3 放大工作流同样适用。

8.1 分块参数的调优顺序

第一次运行时，不要追求大块。建议先用最小参数跑通：比如 chunk_frames=4，chunk_size=256。确认流程没问题后，再逐步调大。调参时一次只改一个变量：

• 显存还有空余，优先加大 chunk_size。
• 显存已经接近上限，优先减小 chunk_frames。
• 出现接缝，优先增大 overlap。
• 速度太慢，检查重叠是否过大，尝试把重叠从 2 减到 1。

8.2 平衡清晰度、速度与显存

3D Latent 分块不是“无损”的。分块越多，重叠越重，计算冗余越大，速度会下降；分块太小，还会影响模型对全局结构的感知。因此，画质和速度之间需要找平衡。

从实践角度，先做好两件事：开启混合精度，一般 fp16 或 bf16 能显著降低显存占用；合理使用磁盘卸载，热词里提到的“显存不够硬盘来凑”思路，就是把暂时不用的中间结果放到内存或 SSD，用的时候再加载。这个方法能跑通，但要控制好换入换出的频率，否则会变成硬盘瓶颈。

8.3 多显卡与混合显卡的利用

如果你手里有多张显卡，可以把不同视频任务或者不同分块分配到不同显卡上并行处理。因为分块之间没有依赖关系，天然适合并行。但注意：

• 多卡并行前先确认数据拷贝路径，避免跨卡传输成为瓶颈。
• 不同型号的显卡处理速度不同，建议按速度比例分配任务，而不是平均分配。
• 混合显卡场景下，先跑一个小 benchmark，确定哪张卡能支撑多大的分块，再分配任务。
• 如果其中一张卡显存特别小，不要让它处理大块，否则整批任务会被最慢的那张卡拖住。

8.4 缓存复用与工程安全

放大是一个重复性很高的流程。同一个视频可能需要反复调参。建议把中间 Latent、VAE 编码结果缓存下来，调整超分参数时不用重新编码。LLM 推理中有 kv cache，视频工作流中也有类似思路，热词里的 block cache 就是这一类加速思想在 MiniMax H3 视频场景中的体现。

另外，处理原始视频时一定要保留原件。放大后的视频如果出现问题，要能随时回到原始视频重新处理。生产环境里建议使用“先备份、再处理、最后验收”的三步流程，不要在原件上直接覆盖。

8.5 内容合规与版权提醒

使用 MiniMax H3 生成或放大视频时，请确保内容合法合规，不传播违法违规信息，不使用他人的版权素材做未经授权的二次创作。这也是本地部署模型需要特别注意的部分。技术本身没有门禁，使用者的责任边界要清晰。

9. 总结与后续学习方向

回到开头那个问题：视频放大爆显存，到底是因为显卡不行，还是处理方式有问题？看完 3D Latent 分块方案后，答案已经清楚了。它并不改变显卡本身，而是改变数据流经显卡的方式，把一次吃掉整个视频的放大任务，拆成很多次吃小口的子任务。8G 显卡能不能跑高清视频放大，关键不再是“总量够不够”，而是“单块分多小”。

这次跑通后，建议你往三个方向继续深入：一是理解时间一致性，视频放大最难的不是空间清晰度，而是时间维度的稳定；二是学习量化与推理加速，把放大模型的权重做量化，显存占用还能再降一档；三是把分块放大和 MiniMax H3 的导演台工作流整合起来，形成一套从生成到放大再到剪辑的完整出片链路。

第一次实践时，不用急着上 4K。先用 8 帧小片段把工作流完整跑通，再逐步加帧、加分辨率。把每一条参数改动记录成表格，你会发现，显存优化并不神秘，它就是一环一环压峰值、控冗余的工程过程。跑通一次之后，下次再遇到任何“爆显存”的任务，你都会先想一想：能不能分块？怎么分最合适？