UE5性能优化实战：不依赖超分，渲染预算分配实现3倍帧率

这次我们来看一个指向性非常明确的 UE5 优化挑战：不用超分辨率，把帧率提到接近 3 倍，并且用可复现的测试数据，正面回应社区里“不开超分就救不了 UE5 性能”的论调。项目标题里提到的“恶意开发者攻击”，在技术社区里通常表现为两种声音：一是宣称 UE5 不开 DLSS/TSR 这类超分功能就必然低帧率，二是丢出大量“优化技巧”却不敢放同一场景的前后对比数据。本文不打算做口舌之争，而是给出一套能在自己项目里跑通的性能优化与验证流程。

这套方案的核心特点是：不依赖任何硬件或渲染层面的超分辨率技术，不做“先降渲染分辨率再用算法放大”的取巧路线，而是从 UE5 渲染管线的预算分配入手，把不合理的 Over-Engineering 开销砍掉。文章会覆盖环境准备、性能基线记录、渲染分辨率策略、Lumen 与阴影降级、反射与后处理预算、GPU/CPU 瓶颈判断、固定路径帧率数据采集，以及面对“恶意开发者”质疑时该如何用截图、帧率曲线和关键设置清单来回应。

适合读者很明确：UE5 开发者、地编、TA、性能优化工程师，以及因为项目卡顿被质疑水平、想用数据说话的团队。如果你是刚接触 UE5 的初学者，这篇文章也能帮你建立起“性能优化不是靠玄学，而是靠 profiling 和预算分配”的底层认知。下面直接进入正题。

1. 核心能力速览

这里必须说明：标题里的“3 倍帧率”不是一个通用承诺，而是一个可验证的优化目标。如果优化前的渲染配置明显不合理，比如全场景开满 Lumen 硬件光追、远景 Nanite 过度细分、阴影距离拉满，优化后达到 3 倍并非夸大其词。如果项目本身已经做过一轮减负，那 3 倍就不现实，可能只有 20% 到 40% 的提升空间。真正重要的是能不能把“目标、手段、测试、数据”闭环跑起来。

2. 适用场景与使用边界

这套方案适合的场景，首先是中低配置 PC 或主机平台的 UE5 项目。很多团队在开发期用高端显卡做效果验证，等到玩家机器上跑就崩溃，原因往往是渲染预算被严重高估。不依赖超分辨率来优化，意味着玩家在不开启 TSR/DLSS 时也能获得可观帧率，这对于性能敏感玩家和主机模式非常重要。

第二类适用场景是画质一致性要求较高的项目。超分辨率在某些动态场景会出现闪烁、细节涂抹、摩尔纹等问题，尤其 TAA 与 TSR 叠加后画面容易出现“涂抹感”。如果项目走的是原生清晰度路线，那先砍掉不必要的渲染特性、做好渲染预算，比直接开超分更能保住画面锐度。

第三类是性能基准测试和版本验收。当团队需要向管理层或外部合作方证明“优化有效”，空口无凭，必须有同一场景、同一相机路径、同一参数下的前后对比数据。这套流程会给出明确的数据采集方法。

使用边界也要说清楚。如果项目已经把所有渲染特性压到很低，帧率瓶颈在 GPU 的绝对算力或 CPU 单线程能力，那不用超分想再翻倍就不现实。另外，场景中含有大量压缩贴图、极端粒子密度、复杂物理模拟时，优化手段要从渲染转向资产和玩法侧，本文的渲染预算逻辑只能解决其中一部分。

安全和合规边界面，业内通用的原则也适用：性能测试数据应如实记录，不夸大不伪造；使用第三方素材、美术资产时确认授权；不要以贬损他人作品为前提宣传自己的优化结果。UE5 项目应通过正规渠道获取引擎版本和插件，避免使用来源不明的整合包或修改二进制。

3. 环境准备与性能基线记录

性能优化最忌讳“凭感觉”。如果不知道优化前帧率到底多少、瓶颈在哪，任何调整都无法评估。这一节先搭建一套可复现的测试环境。

3.1 软硬件与项目状态检查

先确认几件事：

• 引擎版本：UE5.0、UE5.1、UE5.2、UE5.3、UE5.4 的控制台变量与默认值有差异，记录项目实际版本。
• 显卡驱动与 GPU：建议更新到稳定版驱动，关闭第三方覆盖层。
• CPU 与内存：确认 CPU 是否开启高性能电源计划，避免后台进程干扰测试。
• 项目是否在开发期：建议在内容基本冻结的场景上做性能测试，避免频繁改动导致数据不可比。
• 是否开启 Debug/Development 构建：性能数据优先用 Development 或 Shipping 档测试，Editor 数据仅作参考。

检查完成后，建立一个独立分支或配置备份。所有优化调整都必须可回滚，建议把默认的DefaultEngine.ini、DefaultGameUserSettings.ini和关卡配置复制一份，标注_baseline后缀，比如DefaultEngine_Baseline.ini。

3.2 建立固定测试场景与相机路径

性能对比的前提是“同一场景、同一视角、同一运行时间”。剪辑一条固定相机路径，最好覆盖以下 нагрузочных点：

• 近距离细节区域，查看材质复杂度和贴图加载。
• 中距离大场景，查看光照和阴影开销。
• 远景俯视，查看 Lumen、Nanite、HLOD 表现。
• 快速转动视角或镜头运动，查看贴图流送和剔除稳定性。

如果项目支持 Sequencer，可以在 Sequencer 里录制一段相机动画作为固定测试路径。没有 Sequencer 就用手动操作录屏，但每次手动操作路径必须一致，否则帧率数据会失真。

3.3 记录优化前基线

在修改任何参数之前，启动项目至少跑 3 次同样的测试路径，记录每一帧的耗时数据。关键指标包括：

• 平均 FPS。
• 最差 1% Low 帧率，这比平均帧率更能反映卡顿。
• GPU 耗时、DrawCall 数量、三角形数量。
• 显存占用。

采集帧率还不算完整的 baseline，必须在同一路径下保存一张固定帧的画面截图，用于后续画面质量对比。注意不要使用截图软件的压缩图，直接用引擎的高分辨率截图或无损 PNG。

如果项目在启动阶段耗时不稳定，先让场景预缓存运行一遍，再正式记录第二轮数据。这样可以降低贴图流送和着色器编译对首轮测试的影响。采样时间建议不低于 60 秒，时长太短会漏掉大场景切换时的尖峰。

4. 不用超分辨率的帧率优化手段

这一章是核心。所有优化手段都不依赖超分辨率技术，而是从 UE5 渲染管线的预算和特性开关入手。

4.1 渲染分辨率策略：屏幕百分比与画质档位

超分辨率技术的本质，是在低分辨率渲染后通过算法重建高分辨率画面。既然不用超分，那就要在“渲染分辨率”与“输出分辨率”之间找到一个平衡点。UE5 的r.ScreenPercentage控制台变量可以直接控制内部分辨率百分比，100 表示全分辨率渲染，70 到 85 之间通常是比较安全的降载区间。

; 渲染分辨率缩放示例，80 表示内部渲染分辨率降为 80% r.ScreenPercentage=80

这里要注意，降低渲染分辨率会直接影响画面清晰度，和超分辨率的视觉重建不是一回事。所以它只适合作为快速预算调整手段，不应该替代真正必要的特性删减。更好的组合是：先通过对光照、阴影、反射做特性降级，获得性能空间，再把渲染分辨率定在项目可接受的最低值，而不是一开始就粗暴降低分辨率。

同时，把画面的整体质量档位先设置为全局一致性配置。UE5 的Scalability系统允许按Low/Medium/High/Epic分级，但真正能拉开性能差距的，往往不是档位本身，而是档位背后的渲染特性明细。建议在不使用超分的前提下，以 Medium 档为基线逐步回落，观察画面损失和帧率收益。

4.2 光照方案降级：Lumen 的控制与替代

Lumen 是 UE5 标志性的全局光照方案，但也是很多项目卡顿的源头。Lumen 的硬件光线追踪在部分显卡上有明显开销，软件光追虽然对硬件要求低，但在大场景中仍可能占据大量 GPU 时间。

如果项目对间接光照的要求不是特别高，可以先把 Lumen 的漫反射和反射开销降低：

; 关闭 Lumen 漫反射间接光照 r.Lumen.DiffuseIndirect.Allow=0 ; 关闭 Lumen 反射 r.Lumen.Reflections.Allow=0

关闭 Lumen 之后，项目回退到屏幕空间反射和传统间接光照，画面暗部可能会显得“平”，也需要额外处理。更稳妥的做法，是先尝试把 Lumen 控制在更低的分辨率或更粗糙的追踪精度，再决定是否彻底关闭。控制台变量在不同 UE5 版本中名称略有差异，以实际版本的 Console Variables 列表为准。

对大多数场景来说，间接光照的可见收益主要在中远景和封闭空间。如果项目是开放世界或大量室外场景，往往直接光照和天空光照占主导，Lumen 的增益有限。此时把预算从 Lumen 释放出来，常能获得明显帧率收益。

4.3 阴影与距离场优化

阴影在 UE5 中常见的高开销点是级联阴影贴图的距离、级联数量，以及 Nanite 网格体的距离场阴影。项目默认开到高倍数的阴影距离，会直接把 GPU 阴影渲染压力抬上去。

可以按如下方向调整：

; 降低阴影分辨率缩放 r.Shadow.CSM.MaxCascades=2 ; 降低远景阴影距离，这里数值需要按项目实际调整 r.Shadow.DistanceScale=0.5

另一个容易被忽略的选项是距离场阴影。在项目不需要 Nanite 距离场表现远景细节时，可以考虑关闭距离场相关的阴影或减少其用途。Nanite 本身对渲染优化有帮助，但它对三角形密度、网格体细分有要求，远景过度细分依然会带来额外的 GPU 开销。

在 Lumen 关闭的情况下，阴影质量主要由传统 CSM 控制。这里有一个经验性判断：如果场景中大量阴影来自小型静态物体，考虑将部分阴影切换为烘焙光照贴图或预计算的影射线，而不是在运行期实时渲染。烘焙方案会增大构建时间，但运行时开销显著降低。

4.4 反射与后处理预算

Lumen 反射关闭后，项目默认走屏幕空间反射或平面反射。屏幕空间反射在屏幕边缘和低分辨率下容易出现缺失，但它对 GPU 压力相对可控。反射质量维持在中等即可，不建议在这个环节追求极端画质。

后处理体积是另一个容易被低估的开销来源。泛光、色调映射、抗锯齿、景深、动态模糊都会消耗 GPU 时间。在进行帧率优化时，先关闭所有非必要后处理项，只保留颜色校正与基础抗锯齿，再逐步开启并观察性能回落：

; 关闭动态模糊 r.MotionBlur.Max=0 ; 关闭景深 r.DepthOfField.Max=0 ; 降低泛光质量，具体数值按版本调整 r.Bloom.Quality=0

抗锯齿方面，既然不用超分，常见的组合是用 TAA，但 TAA 在低内部分辨率下会有明显的细节涂抹。如果画质要求高，可以先保持全分辨率和更高倍数的采样，在渲染开销与锐度之间找平衡点。TSR 也是 UE5 自带的时域超分辨率，但本文目标是“不用超分”，所以默认不启用。

4.5 遮挡剔除与 HLOD

帧率低不只是 GPU 在渲染，CPU 的剔除和提交开销同样关键。UE5 默认情况下会尽量剔除视锥外和遮挡物体，但在大型场景中，大量对象仍可能进入渲染队列。打开stat scenerendering或stat gpu可以看到 DrawCall 和三角形数量的分布。

HLOD（Hierarchical Level of Detail）是降低远景开销的核心工具。它把远处多个物体合并成简化网格和材质，一次 DrawCall 绘制大量物体，避免每个物体单独提交。对大量静态植被、建筑、道具组成的大场景，HLOD 没有开启和错误配置，是远景帧率差距巨大的重要原因。

实操上，对项目中的大型静态网格体集群，生成 HLOD 并测试远景帧率变化。同时在项目设置中确认 Distance Field 和 Nanite 的可见距离，避免远景出现无意义的精细网格体，白白消耗 GPU 三角形处理和 CPU 剔除时间。

4.6 材质复杂度与 GPU 提交

一个表面的材质如果使用过多纹理采样、多个法线节点、复杂的函数运算，GPU 着色成本会被快速推高。最直接的方法是打开 GPU Visualizer 或profilegpu查看每个渲染通道的耗时，找出最耗时的材质类别。

如果发现某类材质大面积耗时，优先处理以下几类：

• 多层材质混合节点。很多地表材质会叠加多层纹理混合，裁剪成可接受的混合数量能节省大量着色成本。
• 大运算量的 Custom 节点。Custom 节点如果用到了复杂循环或大量纹理读取，会在着色器中展开为高压计算。
• 高分辨率贴图的不合理流送。项目若放入了 8K 贴图但视角根本看不到细节，就会白吃显存和带宽，按需降低 Mip 设置。

材质优化有一个原则：先看数量，再看单个材质成本。很多项目单个材质不复杂，但整个场景有几万次采样，合计起来就非常夸张。用材质编辑器里的成本估算工具，或直接对材质球做耗时排序，先处理重复度最高的材质类型。

4.7 CPU 侧瓶颈与帧率稳定性

GPU 优化做得再多，如果 CPU 侧提交线程过载，帧率依然上不去。UE5 中常见的 CPU 瓶颈来源包括游戏线程的蓝图事件、物理模拟、角色移动组件、可见性查询和渲染线程的 DrawCall 提交。

观察方法很简单：打开stat unit，查看 GameThread、RenderThread、GPU 三个耗时的最大值。如果 GPU 耗时明显低于 RenderThread 或 GameThread，瓶颈就在 CPU 侧。此时重点查以下内容：

• 大量蓝图 tick：每帧都在执行的蓝图节点会消耗大量 CPU 时间。能够用事件驱动代替 Tick 的地方尽量改掉。
• 物理碰撞：复杂碰撞体和大量动态物体的物理模拟，会显著抬高 CPU 耗时。
• 角色动画：大量骨骼网格体同时更新动画时，动画实例数量过多会造成明显的 CPU 压力。
• 导航与寻路：大量 AI 同时做寻路查询，CPU 耗时容易暴涨。

在性能优化中，最容易忽视的就是“原因分层”。如果项目当前 GPU 已经满载，先去降 GPU 特效；如果 GPU 负载明显不高但帧率依旧低，那就要立即把精力转向 CPU 侧。片面的“无脑调低画质”并不能解决 CPU 瓶颈，这也是很多优化帖子翻车的原因。

5. 功能测试与效果验证

优化做完不等于任务完成，关键看能不能用数据证明“优化有效”。这一节给出一套完整的验证流程。

5.1 测试方案设计

每个优化版本必须跑同一路径、同一时长、同一负载环境。测试路径建议控制在 1 到 3 分钟，覆盖前期、中期、后期场景密度变化。记录 3 轮数据取中位数，避免单轮偏差影响结论。

优化的配置切换用项目设置或命令行工具完成。建议使用版本化配置管理，每个变量组对应一个命名配置，例如Performance_Native、Performance_LumenOff、Performance_FinalBudget，方便回退和对比。

5.2 帧率数据采集

最简单的帧率采集方法是游戏内控制台命令。启动项目后执行：

stat fps

此时屏幕左上角会显示当前帧率。如果要生成持久化的日志，可以通过-ExecCmds在启动时自动执行命令：

# Windows 下启动项目并开启帧率与性能统计，日志输出到 Logs 目录 UE5Project.exe -game -WINDOWED -RESX=1920 -RESY=1080 -ExecCmds="stat fps; stat unit; stat scenerendering" -log

# 反复运行三轮，把日志分别保存，便于对比 1..3 | ForEach-Object { $logName = "baseline_run$_.log" & .\UE5Project.exe -game -WINDOWED -RESX=1920 -RESY=1080 -ExecCmds="stat fps; stat unit" -log -LogCmds="LogStats, Log" | Out-Null Copy-Item .\Saved\Logs\UE5Project.log .\PerfLogs\$logName }

UE5 的日志文件保存在项目Saved/Logs目录下，文件名以项目名命名。采集完日志后，可以用脚本解析帧率数据，计算平均帧率和 1% Low 帧率。下面给一个简单的 Python 解析模板：

import re from pathlib import Path def parse_fps_from_log(log_path: Path): """从 UE5 日志中解析 FPS 数值，返回每秒帧率列表。""" fps_values = [] pattern = re.compile(r"FPS:\s*([0-9]+\.?[0-9]*)") with open(log_path, "r", encoding="utf-8", errors="ignore") as f: for line in f: m = pattern.search(line) if m: fps_values.append(float(m.group(1))) return fps_values def percent_low(fps_values, percentile=1.0): """计算 1% Low 帧率，可自定义百分位。""" if not fps_values: return 0.0 sorted_fps = sorted(fps_values) index = max(0, int(len(sorted_fps) * percentile / 100.0)) return sorted_fps[index] if __name__ == "__main__": fps_data = parse_fps_from_log(Path("UE5Project.log")) avg_fps = sum(fps_data) / len(fps_data) low_1 = percent_low(fps_data, 1.0) print(f"样本数: {len(fps_data)}") print(f"平均 FPS: {avg_fps:.2f}") print(f"1% Low FPS: {low_1:.2f}")

如果项目里还没有现成的帧率日志格式，可以让控制台持续输出stat fps并把日志重定向到文件。更专业的做法是接入 Unreal Insights，后面会单独说明。

5.3 画面质量对照

帧率提升了一倍，画面却糊成一团，优化就不能算成功。固定测试路径中，在固定帧位置保存画面截图，分别采集优化前与优化后的画面。判断标准不只看“能否看清远处物体”，还要看暗部层次、植被边缘是否闪烁、反射是否丢失。

建议截图的几个关键点位：

• 近景材质细节区。
• 全景光照对比区。
• 阴影交界处。
• 远景天空轮廓。
• 植被或细小物体密集区域。

如果某些区域出现明显的画质崩坏，需要标记出来，回到对应设置项做微调。性能优化不是“一个开关全部关掉”，而是“保留可见收益、砍掉不可见开销”。

5.4 判断成功标准

判断一次优化是否成功，标准有三条：

1. 平均帧率有可量化提升，最好覆盖到目标路径的多数区域。
2. 1% Low 帧率同步提升或至少不劣化，如果平均帧率提升了但卡顿严重，反而更糟。
3. 画面质量损失在可接受范围内，不出现大面积信息缺失和严重闪烁。

最后用一张对比表展示结果。不要虚空填数字，按自己项目实测结果填写：

6. 自动化测试与批量性能采集

性能优化通常不是一次性的，而是要在多个场景、多个版本间反复验证。手动跑测试路径太慢，数据采集也不统一，这一节讲批量性能采集的做法。

6.1 命令行自动化启动

UE5 支持通过命令行参数直接启动项目并进入指定地图。以下命令示例需要按项目实际包名和地图路径调整：

# 启动 PIE 窗口模式并直接进入测试地图，开启统计 UE5Project.exe Game/StarterContent/Maps/TestMap -game -WINDOWED -RESX=1920 -RESY=1080 -ExecCmds="stat fps; stat unit" -log

如果需要无窗口模式，可以把-WINDOWED去掉，改为全屏方式，同时设置输出分辨率。注意有些命令行参数只在特定构建中可用，Development 和 Shipping 构建的行为也可能不同。

6.2 Unreal Insights 追踪

Unreal Insights 是 UE5 性能分析的核心工具，它可以把游戏运行时的 CPU、GPU、网络、内存等数据记录成.utrace文件，然后在浏览器中打开可视化分析。

启动追踪的方式之一是在启动参数中加入追踪文件路径：

# 启用 Unreal Insights 追踪并输出到指定目录 UE5Project.exe -game -trace=default -tracehost=localhost -tracefile=TestMap_Perf.utrace

追踪文件会记录每一帧的线程耗时、动画耗时、渲染通道耗时、RHI 提交耗时等。相比stat fps的全局数值，Unreal Insights 能精确定位到具体系统和函数，这是应对“恶意开发者质疑”最强有力的证据。但追踪本身也会引入额外开销，所以正式测试时，追踪文件采集要单独跑一轮，与纯帧率数据分开记录。

6.3 批量跑多场景多配置

如果团队有多个场景需要验证，可以用一套脚本按顺序启动多个测试地图，每种配置跑完一轮后自动退出，再切换下一个测试。UE5 支持通过命令行指定地图后自动执行一定数量的帧，但具体的“自动退出”逻辑需要按项目定制的自动化框架来实现。如果没有现成框架，可以先人肉配合脚本记录日志，后续再接入自动化测试系统。

下面是一个通用思路，用于在目录中批量处理日志文件：

from pathlib import Path import csv def summarize_logs_to_csv(log_dir: Path, output_csv: Path): """批量汇总多个日志的帧率统计。""" rows = [] for log_file in sorted(log_dir.glob("*.log")): fps_list = parse_fps_from_log(log_file) if not fps_list: continue avg_fps = sum(fps_list) / len(fps_list) low_1 = percent_low(fps_list, 1.0) rows.append({ "log": log_file.stem, "avg_fps": round(avg_fps, 2), "low_1_fps": round(low_1, 2), "samples": len(fps_list), }) with open(output_csv, "w", newline="", encoding="utf-8-sig") as f: writer = csv.DictWriter(f, fieldnames=["log", "avg_fps", "low_1_fps", "samples"]) writer.writeheader() writer.writerows(rows)

这里对parse_fps_from_log和percent_low函数的复用，依赖第 5 节里给出的解析逻辑。生产使用时要根据项目实际日志格式调整正则表达式。

6.4 失败重试与数据标记

批量跑测试时，偶尔会出现启动失败、场景加载异常、日志没写入等意外。脚本应该记录每次运行的状态，而不是只输出帧率数据。建议在 CSV 格式中额外增加status和notes字段，遇到明显异常的数据直接标记为 invalid，不参与最终统计。

7. 资源占用与性能观察

性能优化不能只看 FPS，资源占用和渲染耗时同样决定了项目的上限。这一节给出观察方法和判断思路。

7.1 GPU 耗时与 GPU Visualizer

打开控制台命令stat gpu，可以看到场景渲染各阶段的耗时分配，包括 BasePass、Shadows、Reflection、PostProcess、Translucency 等。如果某个通道耗时异常突出，针对性处理该通道相关的设置，远比盲目降低整体画质有效。

profilegpu命令可以把 GPU 渲染的详细事件写入日志，配合 GPU Visualizer 可以查看每个渲染事件的耗时。当需要向他人证明某个设置项的收益时，记录优化前和优化后的 GPU 事件耗时即可。

7.2 CD 与 CPU 瓶颈判断

stat unit显示的是 GameThread、RenderThread、GPU 三者的耗时。判断瓶颈的标准非常简单：

• 如果 GPU 耗时最高：瓶颈在 GPU 渲染，优先优化渲染特性。
• 如果 RenderThread 耗时最高：瓶颈在渲染提交，优先减少 DrawCall 和三角形数量。
• 如果 GameThread 耗时最高：瓶颈在游戏逻辑、动画、物理或 AI，调画质没有用。

stat scenerendering可以直接看到 DrawCall 数量和三角形数量。对于 CPU 提交瓶颈，减少 DrawCall 比降低画质更有效。HLOD、实例化、网格体合并、剔除范围调整，都是降低 DrawCall 的手段。

7.3 显存与内存观察

显存占用可以通过任务管理器、GPU-Z 或引擎内置统计查看。纹理流送在开放世界中很容易把显存打爆，尤其当贴图总大小远超显存容量时，画面会频繁出现贴图模糊和加载卡顿。建议在性能测试中统一设置纹理流送池大小，比较不同配置下的显存变化和加载稳定性。

内存方面，大量蓝图对象、关卡流送、物理资产都会占用内存。如果项目频繁遇到 Out of Memory 崩溃，性能优化优先级应该先做资产和关卡流送管理，而不是继续压缩画质配置。

7.4 降低资源占用的优先级

正确顺序是：

1. 先通过 profiling 确定瓶颈，不要盲目调参数。
2. 优先处理特征级开关：Lumen、Nanite、距离场、阴影、反射。
3. 再处理资产级成本：贴图尺寸、材质复杂度、网格体三角数。
4. 最后再调整渲染分辨率百分比和整体画质档位。

这个顺序的核心逻辑是：先解决“不该花却花了”的预算，再解决“需要花但可以更省”的预算。跳过 profiling 直接降低分辨率，往往只能获得短期收益，后续迭代时画面质量很难保证。

8. 常见问题与排查方法

性能优化过程中会遇到各种异常，下面整理一份排查清单，覆盖常见现象、可能原因和解决思路。

9. 面对质疑：怎样用数据回应“恶意开发者攻击”

项目标题里的“恶意开发者攻击”不是指真正的网络攻击，而是技术社区里常见的几种质疑：有人说“不用超分就不可能大幅提升帧率”、有人说“调低 Lumen 和阴影就是阉割画质”、还有人只看结论不看对比数据。面对这些问题，最好的回应不是争论，而是把优化过程和测试数据完整而清晰地展示出来。

9.1 为什么不用超分也能提升帧率

超分辨率解决的是“低分辨率渲染”与“高分辨率输出”之间的画质重建问题，它并不解决渲染特性本身的浪费。如果项目在全局光照、阴影、反射、后处理上配置冗余，那么超分只是掩盖了这些开销，而不是消除它们。一个项目中存在大量不必要的渲染预算时，把这些预算释放出来，帧率自然提升。

这里要特别强调一个原则：渲染预算分配决定了性能表现。每帧 GPU 时间被哪些通道吃掉，是可以用 profiling 工具精确看到的。与其争论“超分有没有用”，不如先回答“这个项目每帧的 GPU 时间花在了哪”。如果优化前 GPU 耗时的大头在阴影距离过大、Lumen 全开但场景几乎没有室内遮挡，那关闭这些特性后的帧率收益就是真实且可计算的。

9.2 超分解决什么、不解决什么

超分技术解决的是低分辨率重建时的清晰度损失，同时通过时域积累获得接近原生分辨率的画面。它适合 GPU 计算能力不足，但画面重建算法能够弥补分辨率损失的场景。

它解决不了三类问题：CPU 侧游戏逻辑耗时过高、渲染特性配置冗余、资产加载和流送管理不当。如果一个项目 CPU 侧已经是瓶颈，超分对帧率的提升微乎其微。这也是很多玩家发现“开了 DLSS 帧率也没涨”的原因之一。

9.3 展示对比的正确姿势

面对质疑，需要准备以下材料：

1. 同一场景、同一路径、同一配置基准下的帧率曲线。
2. 优化前后的截图对比，最好附带局部放大图。
3. 关键设置项的变更清单，不藏着掖着。
4. 1% Low 帧率和平均帧率的同步变化。

把这些数据整理成一张性能报告或博客表格，比空口争论更能说服人。如果质疑者有不同结论，邀请对方在自己的项目里跑相同的测试流程，用数据碰撞而不是用情绪碰撞。对一个小项目来说，这套流程跑下来通常不超过半天，但它能建立起非常牢固的“优化有效”证据链。

9.4 承认边界也是一种专业

不含糊地承认超分在特定场景下的价值，反而增加可信度。如果一个项目已经把所有渲染预算压到极限，GPU 绝对算力仍然不够，那么超分就是合理手段。本文的目标是证明“不借助超分也能做大量优化”，而不是彻底否定超分技术。事实上，混合使用“原生预算优化 + 超分兜底”才是很多商业项目的最终方案。面对“恶意开发者攻击”，更专业的姿态是：给出可复现的数据，定义自己的边界，不贬低其他方案。

10. 总结与下一步

这个优化挑战最值得尝试的点，是把“帧率提升”从口号变成了可测量的工程任务。它不依靠超分辨率技术，而是用渲染预算分配的逻辑重新审视项目，让每一帧 GPU 耗时都有据可查。最先应该验证的功能是第 4 节里的组合拳：先用stat unit确认瓶颈，再依次关闭或调低 Lumen、阴影、反射、后处理，把 GPU 耗时拉下来，最后再根据画面损失微调渲染分辨率。

最容易踩的坑有两个：一是跳过 profiling 直接改参数，导致改完后帧率没变、画质却明显下降；二是只改一个开关，期待它解决所有问题，结果发现 GPU 耗时降了但 CPU 侧波动依旧。性能优化是系统性的预算分配工作，不是某一个 set 就能救命。

下一步可以继续扩展的方向包括：把这套流程接进项目的自动化测试框架，形成每次版本提交后的性能回归测试；对不同硬件档位做配置预设，让低配机器自动使用更保守的渲染设置；结合 Unreal Insights 的追踪数据，深入优化 CPU 侧的游戏逻辑和动画开销。等这一轮做完，你会发现即使最终仍然需要超分来兜底，你的项目也比之前“满配置 + 超分救场”的状态健康得多。这套方法本身，就是回应所有质疑最好的数据源。建议收藏备用，也欢迎在评论区留下你项目的瓶颈表现，一起看看预算到底花在哪里。