UE5不靠超分实现3倍帧率：渲染管线优化实战指南

UE5 的功能越来越强，但“强”背后是巨大的渲染开销。很多人遇到的问题是：项目里开了 Lumen、虚拟阴影、高精度后处理，帧率掉到 30 甚至更低，于是第一反应是开 DLSS/FSR/TSR 这类超分辨率方案把帧率拉回来。那如果禁掉超分呢？还能不能把帧率做到 3 倍？

这篇文章正面回应这个争议：在 UE5 中不依赖超分辨率，通过系统化的性能分析和渲染管线优化，完全可以获得非常明显的帧率提升。注意，这不是“无脑降低画质换帧率”，而是先定位瓶颈，再按收益排序裁剪不必要的渲染开销，尽量保住画面观感和原生分辨率。

文章会按“工具准备 -> 瓶颈判断 -> 项目设置优化 -> 场景与材质优化 -> CPU优化 -> 数据验证”的顺序展开。无论你用的是 UE5.0 还是 UE5.4，这套流程都适用。

1. 核心能力速览

这套流程的核心是“用数据说话”。优化前先用 Profiling 工具明确瓶颈，再逐项调整。不靠猜，不靠玄学。

2. 适用场景与使用边界

这套优化思路适合以下场景：

• PC 或主机平台的 3D 游戏项目，目标帧率是 60 FPS 或 120 FPS。
• 建筑可视化、虚拟展厅、数字孪生等实时大屏漫游项目。
• 场景中大范围使用动态光源、体积雾、Lumen 全局光照导致帧率偏低的项目。
• CPU 瓶颈明显、Draw Call 高、蓝图每帧计算过重的项目。
• 不想依赖超分辨率重建，担心画质变糊、动态细节丢失的团队。

也有明确不合适的场景：

• 项目本来跑得很流畅，只是某几个镜头短暂掉帧，不需要全项目大改。
• 项目必须开启 Lumen 和碰撞、破坏、物理模拟等动态效果，且美术标准不接受任何妥协。
• 显卡过老，连引擎最低 DX11 要求都达不到，那再优化也很难“3倍”。
• 代码和资源处于快速迭代期，每天都有大量临时 Actor，这时候优化数据没有参考价值。

关于“3倍帧率”的边界，必须说得清楚一点。30 FPS 提升到 90 FPS 是 3 倍，45 FPS 提升到 135 FPS 也是 3 倍。能不能做到，取决于原始帧率卡在哪个瓶颈上。如果瓶颈是 GPU 后处理全开，优化空间可能非常大；如果瓶颈是一个不可绕过的循环逻辑，那要先解决代码问题。因此本文的验证流程特别重要，它帮你确认“这个 3 倍是不是真的可以通过某项优化达成”。

还有一层边界是“心态”上的：标题里提到“正面回应恶意开发者的攻击”，最好的回应不是争辩，而是把可复现的优化步骤和前后帧率数据贴出来。别人说不可能是别人的事，你把自己项目里的帧时间曲线摆出来，结论自然清楚。

3. 环境准备与前置条件

做性能优化前，先确认基础环境。

3.1 引擎版本

推荐使用 UE5.3 或 UE5.4，这两个版本对性能工具支持比较完整。UE5.0 和 UE5.1 也能用，但部分渲染设置名称可能不同。建议在开始之前锁定项目使用的引擎版本，避免升级引擎给优化数据带来干扰。

3.2 系统与硬件

• 操作系统：Windows 10/11 64 位，Linux 也可以，但 Windows 下工具链最顺手。
• 内存：16GB 起步，32GB 更稳。烘焙光照、捕获 Trace、跑编辑器同时开着，内存占用会比较高。
• 显卡：支持 DX12 的显卡优先。优化过程中需要切换到 DX12 来做 GPU 性能分析。
• 硬盘：UE5 安装本身占用几十 GB，项目再大一点更需要 SSD。
• 编译器：一般来说，用引擎自带的二进制版本就可以了，不需要装 Visual Studio。如果要从源码编译，才需要 VS 2022 和对应的 Windows SDK。

3.3 软件工具

• Epic Games Launcher，安装对应版本的 UE5。
• 一个测试工程，新建第三人称或第一人称模板就能用来验证。
• Unreal Insights 是引擎自带的性能追踪工具，通常位于：

Epic Games/UE_5.4/Engine/Binaries/Win64/UnrealInsights.exe

3.4 环境检查清单

在开始优化前，按下面清单过一遍：

• 项目能正常打开展示场景。
• 能使用 PIE（Play In Editor）运行关卡。
• 能通过命令行参数启动游戏窗口。
• 能看到stat unit的输出。
• 能打开 GPU Visualizer。

如果以上任意一步失败，先解决环境问题，再谈优化。

4. 启动方式与性能观察工具

优化 UE5 性能，不能只靠“目测”。下面这套启动和记录方式，是整个流程的基础。

4.1 使用命令行启动独立游戏进程

在编辑器里按 Play 很方便，但性能数据会和编辑器 UI 混在一起，不够干净。建议用 Standalone Game 或直接通过命令行运行项目。

命令行启动示例：

"UE5安装目录/Engine/Binaries/Win64/UnrealEditor.exe" "项目路径/你的项目.uproject" -game -log -ExecCmds="stat unit" -windowed -ResX=1920 -ResY=1080

在 Windows 上，路径写实际路径。-game表示以游戏模式启动，-log会在窗口和日志中输出信息，-ExecCmds用于启动时自动执行控制台命令，-ResX和-ResY指定窗口分辨率。

这样启动后，屏幕上可以直接看到stat unit的实时帧时间信息。

4.2 核心性能命令

优化过程中最常用的命令：

每次打开项目，顺手输入stat unit，就可以判断当前帧率卡在 CPU 还是 GPU。

4.3 使用 Unreal Insights 录制 Trace

Unreal Insights 能提供更完整的帧率、耗时、线程分布数据。使用命令行启动时增加 Trace 参数：

UnrealEditor.exe "项目路径/你的项目.uproject" -game -trace=cpu,gpu,frame -tracefile="路径/性能数据.utrace"

启动后跑一段固定路线，退出后打开 UnrealInsights，加载这个trace文件查看。

这种方式的好处是数据可回溯，别人质疑你的帧率结论时，直接发 Trace 文件比吵架有用得多。

4.4 固定测试路线

性能对比最怕测试不一致。打开项目后，先确定一条固定“跑图路线”，例如：

• 固定相机位置和旋转角度。
• 固定从 A 点走到 B 点，时间固定。
• 固定视角是否开启动态模糊。
• 固定天气、时间、光照条件。

后续每次修改配置，都用同一路线重新跑，结果才有可比性。

5. 不用超分：先确定瓶颈在哪

很多项目卡帧，不是 UE5 默认设置不行，而是开发者不知道到底卡在哪。超分辨率方案之所以有效，是因为它直接砍掉像素渲染压力，让 GPU 负担大幅下降。但如果不打算用超分，就必须做到“哪里贵，优化哪里”。

5.1 看懂stat unit

启动项目后运行stat unit，输出类似：

Frame: 28.0ms Game: 12.0ms Draw: 8.0ms GPU: 18.0ms

这四项的含义：

• Frame：整帧所花时间，FPS = 1000 / Frame。
• Game：游戏线程耗时，包含蓝图、物理、AI、动画等。
• Draw：渲染线程提交耗时，Draw Call 主要在这里体现。
• GPU：GPU 实际渲染耗时，包括所有 Pass。

判断瓶颈的方法很简单：

• 如果Game时间接近Frame，说明 CPU 游戏线程是瓶颈。
• 如果Draw时间高，说明 Draw Call 或渲染线程提交压力大。
• 如果GPU时间高，说明 GPU 渲染负载重。
• 如果Frame时间远大于三者，可能存在线程等待同步问题。

5.2 看懂stat gpu

GPU 瓶颈时，需要用stat gpu看具体是哪类 Pass 贵：

Total GPU Time: 18.0ms BasePass: 8.0ms Translucency: 2.0ms ShadowDepths: 3.0ms PostProcessing: 2.5ms ReflectionPass: 1.5ms

常见的高开销来源：

• BasePass高：材质复杂、顶点数多、Overdraw 大。
• ShadowDepths高：动态阴影太多，阴影分辨率太高。
• ReflectionPass高：Lumen Reflections 或 Screen Space Reflections 消耗大。
• PostProcessing高：抗锯齿、泛光、景深、色调映射叠加。

5.3 禁用超分前要先做的记录

在动手改设置前，先保存一组基准数据：

Frame: 28.0ms => 约 35 FPS Game: 12.0ms Draw: 8.0ms GPU: 18.0ms

然后把这一行数据记录到表格里。后面每改一项优化，都单独记录一次，不要连续改五六个设置然后再测，那样你根本不知道是谁带来的提升。

6. 项目级渲染设置优化

UE5 默认开着非常重度的渲染特性。这里给出的是一套“保画面、压开销”的项目级调整顺序，按收益从高到低排列。

6.1 关闭 Lumen 或改用混合方案

Lumen 是 UE5 的招牌动态全局光照，但它的 GPU 开销在低中端设备上非常高。如果项目不需要动态日夜循环、动态光线反弹，最简单的做法是：

• 将Project Settings -> Global Illumination Method从Lumen改为None或使用光照烘焙贴图。
• 在场景中放置Lightmass Importance Volume并烘焙光照。

烘焙光照之后，静态场景中依然可以得到不错的光照效果，但 GPU 不再需要为实时 GI 计算买单，帧率提升非常明显。

如果美术场景必须保留 Lumen，可以调节它的质量参数：

r.Lumen.Reflections.Allow=1 r.Lumen.DynamicGlobalIllumination.Speed=1 r.Lumen.ScreenProbeGather.RadianceCache=1

这些参数不可能让 Lumen 免费，但可以降低部分开销。注意，需要根据项目实际效果微调，不要无脑照抄。

6.2 降低阴影质量与阴影距离

UE5 的动态阴影也很费 GPU。在项目设置中，把Shadow Map Resolution和Dynamic Shadow Distance调低，是最直接的手段。

常用的控制台命令：

r.Shadow.MaxResolution=1024 r.Shadow.DistanceScale=0.6 r.Shadow.CSM.MaxCascades=4

MaxResolution从 2048 降到 1024，远距离阴影锐度受影响，但视角中近距离通常感知不强。DistanceScale决定动态阴影的生效距离，调低后远处物体不再投射实时阴影，这在大场景中能省下大量 Shader 复杂度。

如果场景有很多小型植物围墙、碎石等物体，强烈建议给它们关闭 Shadows：

r.Shadow.CSM.TransitionScale=0.5

更好的做法是：在静态网格体资产中，把不需要投射阴影的物体设为Movable时关闭CastShadow，或者使用Per-Object阴影控制。

6.3 减少反射计算

Lumen Reflections 和 Screen Space Reflections 都是资源大户。如果项目中有大量水面、玻璃和金属材质，反射效果确实重要；但如果反射只在少量材质上出现，可以全局降低反射质量：

r.SSR.Quality=0 r.SSR.HalfResSceneColor=1 r.Lumen.Reflections.Allow=0

如果场景大量使用平坦地面和墙面，改用静态Reflection Capture是比较划算的方案。在场景中放置数量合适的反射捕获球，把反射烘焙进场景，远看观感损失不大，但 GPU 压力会小很多。

很多项目反射开销高是因为“整个场景到处都在用镜面材质”，而不是因为某个反射方案本身贵。先减少反射材质的面积，再考虑方案切换。

6.4 调整抗锯齿方案

UE5 默认抗锯齿是 TAA，效果不错，但会引入模糊和拖影，并且有额外 GPU 开销。如果不想用超分辨率重建，但也不想用 TAA 的模糊，可以考虑：

• 在项目设置里将抗锯齿方法改为TAA但配合更高分辨率？这没必要。
• 也可以改用FXAA或MSAA（只适合部分场景）。
• 关闭 TAA 后，画面边缘会闪烁，需要靠材质和资源设计配合。

常见控制台：

r.AntiAliasingMethod=1

1对应 FXAA，2对应 TAA。改成 FXAA 后，GPU 压力降低，画面变锐利，但远处细节会有些噪点。如果项目的美术风格偏卡通、风格化，FXAA 通常足够。

6.5 精简后处理堆

场景中如果放了一个很大范围的Post Process Volume，里面 Bloom、Motion Blur、Depth of Field、Vignette、AO 全部开启，GPU 开销会成倍增加。

建议：

• 关闭Motion Blur，帧率提升非常明显，动态画面更清晰。
• 将Bloom从标准降到低，或者关闭。
• 关闭Ambient Occlusion或换用浅层 AO。
• Depth of Field只保留在 UI 需要的镜头中，不要在全局开启。

不要小看这些后处理，逐项关掉后，PostProcessing时间能从 4ms 降到 1ms 以内，在很多 GPU 上就是 10% 到 20% 的帧时间提升。

6.6 体积雾与体积云

如果场景没有特殊的云层、雾效需求，直接关闭体积雾和体积云：

r.VolumetricFog=0 r.VolumetricCloud=0

这两个特性对 GPU 的消耗非常夸张。去掉后，天空和雾效退回到廉价模式，低中端显卡会立刻轻松不少。对于大多数室内场景和半封闭地图，关闭它们几乎不影响观感。

7. 场景与资源优化

项目级设置只是第一步，很多帧率卡在场景资产本身。UE5 的“默认画面强”不代表“资产越多越好”。

7.1 开启 Nanite（如果适合的话）

Nanite 是 UE5 的虚拟化几何系统，能有效降低大量静态网格体的顶点处理压力。如果你的目标是减少三角形开销，Nanite 可以直接把极高面数的资产压到可控范围。

使用条件：

• 静态网格体需要开启Support Nanite。
• 材质需要满足 Nanite 的材质限制，不能使用部分复杂效果。
• 不适合变形、蒙皮骨骼网格体。

在可用的地方开启 Nanite，BasePass的负载会降低，尤其是大量高模物体密集的场景。

7.2 使用 LOD 让远处物体“变简单”

如果某个物体不适合 Nanite，那必须设置 LOD。UE5 会自动生成 LOD 吗？不一定，很多外包资源只有 Lod0。建议在静态网格体编辑器中，使用自动生成 LOD 工具：

Mesh Settings -> LOD Settings -> Number of LODs

设置合理的屏幕尺寸阈值，让物体在远处切换到低模。这样 GPU 基 Pass 和 Draw Call 都会减少。

7.3 减少 Draw Call

Draw Call 过多会让渲染线程和 CPU 提交时间暴涨。减少 Draw Call 的方法：

• 将多个静态网格体合并为单一 Actor。
• 使用 Hierarchical Instanced Static Mesh（HISM）或 Instanced Static Mesh（ISM），大量相同物体时优先考虑。
• 减少不同材质的数量，同一种材质合并成一张图集。
• 使用 Merge Actors 工具，把多个小型物体合并。

你可以用下面的命令查看 Draw Call：

stat RHI

如果DrawCall数量高到几千上万，那即使 GPU 渲染再快，帧率也上不去。优化完场景后，DrawCall 明显下降，帧率一般会有直观改善。

7.4 调整剔除距离

UE5 默认的可见性剔除已经不错，但对于大场景，手动设置更合理的剔除距离能省大量开销。

对静态网格体资源，设置Distance Culling；对体积、粒子、阴影，设置单独的剔除距离。远处不可见的物体越早剔除，GPU 和 CPU 的负担越低。

如果项目场景很大，还可以使用Level Streaming，把地图切成多个子关卡，按玩家位置动态加载。配合预计算可见性，可以让渲染内容尽量接近“当前真是可见范围”。

7.5 减少 Overdraw

Overdraw 对 GPU 来说就是“同一个像素被画了多次”。多出现在半透明材质、粒子特效、大量植被叠加的场景。

排查方式：

• 启用 Viewport 的Overdraw显示模式，颜色越亮越严重。
• 粒子数量过多时，用 GPU Spawn 替代 CPU 发射。
• 半透明排序复杂时，考虑用不透明材质替代。

Overdraw 高的项目，GPU 时间会高到离谱，哪怕场景面数很低也卡。这是很隐蔽的瓶颈。

8. 材质与着色器优化

UE5 的材质系统很灵活，但灵活不等于免费。同一个材质，不同写法性能差距可以很大。

8.1 查看 Shader Complexity

在 UE5 的材质编辑器中，点击材质球的预览视口，把 View Mode 切到Shader Complexity。颜色从绿到红，红色说明该材质极贵。

把画面中大面积出现的材质改到绿色，是最直接的优化。尤其注意地面、墙面这类“填满屏幕”的材质，它们的一点点开销都会被放大。

8.2 减少纹理采样和数学运算

材质蓝图中的Texture Sample数量、noise计算、Custom节点、复杂的Normal混合，都会增加 GPU 负担。常见的省钱写法：

• 将多张纹理通道打包进 RGBA，减少采样次数。
• 把高频波函数换成简单的参数贴图。
• 避免每帧在材质中做开方、倒数、多层嵌套运算。

对于大面积基础材质，目标是让 Shader Complexity 显示为绿色或浅绿。

8.3 慎用 Masked 材质

Masked混合模式会导致 GPU 多渲染一次，用于裁剪透明区域。大量 Masked 材质叠加，性能会明显下降。

替代方案：

• 效果要求不高时使用Dithered Opacity。
• 需要裁剪边缘很好看时，尽量限制 Masked 材质的使用面积。

8.4 合并材质参数和材质实例

使用大量材质实例本身不一定会拖慢 GPU，但如果每棵树、每块石头都单独搞材质实例，管理成本高，Draw Call 也可能分裂。尽量让同类模型共用一个材质实例，只在实例里调整参数。

材质优化的原则很简单：越接近纯颜色/纯贴图越好，越接近数学运算的“实时复杂效果”越贵。

9. CPU / GameThread 优化

很多项目 GPU 优化了一大轮，帧率依然上不去。这时候要看Game时间。

9.1 Tick 优化

蓝图中最常见的坑是“每个 Actor 每帧 Tick 都做一堆事”。优化思路：

• 不需要每帧检测的事件，使用Timer或事件触发。
• 将 AI 检测、导航寻路改为低频检测。
• 禁用不需要运行的 Tick。在 Actor 属性中关闭Start with Tick Enabled。
• 使用Actor Set Tick Interval把高频 Tick 改成 0.1 秒甚至更低。

大量 Actor 同时 Tick 是 CPU 杀手。可以用命令行看看：

stat Game

如果Game时间高，再用 Unreal Insights 查看 Game Thread 上具体是哪些函数消耗大。

9.2 减少蓝图节点开销

蓝图节点越多，性能越差。常见的高消耗节点：

• Get Actor Location / Rotation每帧调用多次。
• Line Trace每帧都跑。
• Spawn Actor高频执行。
• For Each Loop遍历大量 Actor。

优化方法是缓存数据、减少循环、合并事件。更彻底的做法是把高频逻辑从蓝图搬到 C++，但那是后话。先改掉蓝图中的明显冗余。

9.3 AI 与角色动画

大量 AI 角色同时对玩家做视线检测，CPU 会爆炸。建议：

• 增加 AI 感知帧间隔。
• 降低 NavMesh 更新频率。
• 减少同时更新的 Character Movement 数量。
• 动画蓝图尽量简化状态机，骨骼网格体数量多时使用动画 LOD。

9.4 多线程与异步

UE5 支持通过AsyncTask把耗时计算丢到后台线程。如果某些数据生成、物理查询、IO 不是必须由 GameThread 同步等待，可以改成异步。

不过这是一个相对进阶的操作，通常在普通项目里不做。优先保证蓝图、Tick、AI 没有冗余，然后才考虑多线程。

10. 验证 3 倍帧率的实操流程

前面优化做了一堆，到底提升了多少？这里给出一套可复现的验证流程。

10.1 保存优化前基准

优化前，用固定路线跑 60 秒，记录平均帧时间和关键耗时。

如果希望用一个脚本从 UE5 日志里提取帧时间，可以打开日志输出，然后保存为trace_test.log。

日志中stat unit会输出类似：

Frame: 28.0ms Game: 12.0ms Draw: 8.0ms GPU: 18.0ms

写一个简单的 Python 脚本，提取 Frame 并计算平均 FPS：

import re frame_times = [] pattern = re.compile(r"Frame:\s+([\d.]+)ms") with open("trace_test.log", "r", encoding="utf-8") as f: for line in f: match = pattern.search(line) if match: frame_times.append(float(match.group(1))) if frame_times: avg_frame_ms = sum(frame_times) / len(frame_times) avg_fps = 1000.0 / avg_frame_ms print(f"平均帧时间: {avg_frame_ms:.2f} ms") print(f"平均FPS: {avg_fps:.2f}") else: print("没有提取到Frame数据，请确认日志格式")

这个脚本比较粗糙，但能快速给你一张“平均帧时间变化表”。要注意：日志帧率数据如果用编辑器运行，可能含编辑器 UI 开销，建议使用命令行游戏模式。

10.2 分阶段对比

不要一次改完全部设置再测。建议这样操作：

如果基准 Frame 是 28ms，优化到 9ms，确实接近 3 倍帧率。这就是数据回应的方式。

10.3 观察 1% Low

平均 FPS 高不代表体验流畅。最好同时记录 1% Low 帧率。Unreal Insights 里可以直接看帧率分布，也可以从日志中取所有 Frame 时间，排序后取最低 1%。

在 Python 脚本里加一点排序逻辑：

sorted_frames = sorted(frame_times) percentile = sorted_frames[max(0, int(len(sorted_frames) * 0.01) - 1)] print(f"1% Low 帧时间: {percentile:.2f} ms") print(f"1% Low 帧率: {1000.0 / percentile:.2f} FPS")

如果优化后平均帧率提升，但 1% Low 依然很差，说明存在卡顿尖峰，可能是加载、GC、或者某个瞬间很贵的特效触发。需要继续排查突然的峰值。

10.4 判断优化是否成功

判断标准不是“画面看起来流畅了”，而是：

• Frame平均时间明显下降。
• Game、Draw、GPU中关键瓶颈项下降。
• 同一场景、同一路线，视觉质量没有出现大面积不可接受的降低。
• 1% Low 帧率没有明显恶化。

如果满足这些条件，那“不用超分实现 3 倍帧率”就不是口号，而是可复现的结果。

11. 资源占用与性能观察

优化帧率的过程中，显卡显存、CPU 占用、内存占用也要一并观察。

11.1 观察显存和 GPU 占用

• 使用 GPU-Z 或任务管理器查看显卡占用率、显存占用。
• 如果 GPU 占用率 99%，说明 GPU 是瓶颈，继续优化渲染相关设置。
• 如果 GPU 占用率只有 60%，但 FPS 低，说明 CPU 或内存带宽有瓶颈。
• 显存不够时，纹理可能被频繁换入换出，造成卡顿。

11.2 CPU 占用

在任务管理器里看 CPU 主线程核心占用。UE5 是并行化的，但游戏线程瓶颈会导致很多核心空闲。此时优化蓝图和 Tick 比继续压 GPU 更有效。

11.3 降低显存占用的手段

• 纹理流送距离：控制r.Streaming.PoolSize。
• 降低阴影贴图分辨率。
• 减少渲染目标尺寸，避免超大Render Target。
• 用Texture Streaming后，注意观察纹理池是否爆掉。

11.4 避免端口冲突和进程残留

UE5 性能分析时，不要开太多后台进程。UnrealInsights 本身也会占资源。测试结束后一定要关闭游戏进程，否则下一次启动端口、文件锁都会有隐患。

12. 常见问题与排查方法

13. 最佳实践与建议

• 每一步改动都单独记录，不要一次改多个变量。性能优化最怕无法复现。
• 固定一条测试路线和测试时间，不要随手乱跑。
• 性能目标写清楚：GPU 成本预算多少、Game 线程预算多少、DrawCall 上限多少。
• 场景和资源迭代很快，优化完后的数据要经常重新跑一遍，防止回归。
• 不要盲目照搬网上参数，每个项目的画面标准、场景复杂度、目标平台都不一样。
• 保留一套“最小可运行配置”，当项目被改废时能快速回退。
• 使用版本管理工具记录项目设置文件的变更历史，方便对比。
• 如果有 C++ 能力，优先将高频逻辑从蓝图移到 C++，收益比调渲染参数更稳定。

14. 总结与下一步

UE5 里不用超分辨率，确实可以把帧率推到 3 倍，前提是系统优化而不是“关几个勾选项”就完事。核心思路是先通过stat unit、Unreal Insights 定位瓶颈，再按 GPU、场景、材质、CPU 分类逐项优化，最后用固定路线数据验证结果。

这篇文章最值得你尝试的就是第 6 章和第 7 章：项目级渲染设置 + 场景资源控制。多数项目的帧率瓶颈就藏在 Lumen、动态阴影、体积雾、Draw Call 和过度后处理里。

最容易踩的坑是一口气把所有画质降到最低，然后发现画面已经没法看，帧率也没翻倍。正确做法是一步步调，每步都保留对比数据。

下一步你可以做几件事：

• 打开自己的项目，跑一次stat unit，先确认瓶颈类型。
• 用 10 分钟按第 6 章的设置选项过一轮，看 GPU 时间下降多少。
• 再用 Python 脚本提取帧时间，建立自己项目的性能基线。

帧率优化不是一次性工作，应该成为项目迭代中的常规环节。等你把基础渲染开销压下来之后，再考虑未来项目是否引入超分方案作为锦上添花，那时心态会完全不一样。