在本地跑视频生成模型最让人崩溃的不是出片慢而是放大那一步。你用 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 一次性处理会爆显存那就按时间轴或空间轴把它切成多个小块逐块放大最后合并。这样做能降低显存峰值原因很简单模型前向传播时中间激活值和输入大小基本成正比。输入从整段视频变成一个小块单次前向传播的中间结果就大幅缩小。虽然总的计算量没有减少甚至因为重叠区会略有增加但峰值显存从“最大块的尺寸”而不是“整个视频的尺寸”决定因此低显存显卡也能跑。对比维度整段视频直接放大3D Latent 分块放大显存峰值由整段视频尺寸决定由单个分块尺寸决定8G/12G 显存高分辨率下容易 OOM只要分块够小即可运行实现复杂度简单一步完成需要切片、重叠、融合逻辑拼接瑕疵风险无拼接问题处理不好可能出现接缝或闪烁计算总量基准因重叠区略有增加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 环境更省心。Python3.10 或 3.11 是当前多数大模型项目的常见选择。具体版本以项目 requirements 为准。显卡驱动与 CUDANVIDIA 显卡一般要求较新的驱动。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], dim2) # 当前块剩余部分 if chunk.shape[2] overlap: result torch.cat([result, chunk[:, :, overlap:]], dim2) 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 1Windows 下使用nvidia-smi或者在 PowerShell / CMD 里循环执行。任务管理器也能看显卡总占用但只看总量不够精确。跑放大任务时建议全程盯住显存占用曲线确认它稳定在某个区间而不是逐渐爬升。如果显存持续爬升可能是某个节点没有释放缓存长时间跑多个视频会越来越卡。7.3 常见问题排查表问题现象可能原因排查方式解决方案CUDA OOMchunk_frames 设置过大看日志中崩溃前的 chunk 编号和显存监控调小 chunk_frames 或 chunk_size开启半精度块边界有接缝overlap 太小或缺少融合在拼接位置逐帧检查增大 overlap确认合并逻辑做了加权融合视频播放时闪烁时间一致性未处理对比相邻分块的输出提高时间重叠传递参考帧输出帧数和原视频不一致分块取整问题检查合并后 Latent 的时间长度对齐帧数后再做 VAE 解码显存看似释放了但还是 OOM其他进程占用或显存碎片用 nvidia-smi 看完整进程列表关闭其他程序必要时重启进程释放缓存速度特别慢CPU-GPU 频繁拷贝看日志中是否反复执行 .cpu()/.to(cuda)分块处理完再统一拷贝减少数据搬运画面模糊或色彩偏差放大模型与 Latent 结构不匹配对比同帧原始画面检查模型输入输出通道确认是否在 Latent 域放大更新驱动后 CUDA 不可用驱动版本与 CUDA 不匹配用 DDU 卸载干净后重装匹配驱动安装项目要求的 CUDA 版本这些是视频分块放大里最常见的几类问题。遇到问题时先确认崩溃发生在哪一个环节再按表格针对性排查不要一上来就换显卡或者重装环境。8. 最佳实践与工程建议到了实践建议环节。这些内容来自视频超分工程里的通用经验对 MiniMax H3 放大工作流同样适用。8.1 分块参数的调优顺序第一次运行时不要追求大块。建议先用最小参数跑通比如 chunk_frames4chunk_size256。确认流程没问题后再逐步调大。调参时一次只改一个变量显存还有空余优先加大 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 帧小片段把工作流完整跑通再逐步加帧、加分辨率。把每一条参数改动记录成表格你会发现显存优化并不神秘它就是一环一环压峰值、控冗余的工程过程。跑通一次之后下次再遇到任何“爆显存”的任务你都会先想一想能不能分块怎么分最合适