UE5大作DLSS 4超分、帧生成与光追配置及性能测试指南

《黎明行者之血》（The Blood of Dawnwalker）是 Rebel Wolves 工作室的首款作品，位于波兰华沙，核心成员来自《巫师 3》和《赛博朋克 2077》团队。公开资料显示，该作基于虚幻引擎 5 开发，由 Bandai Namco Entertainment 发行，官方此前给出的发行窗口是 2026 年，登陆 PC、PS5 和 Xbox Series X|S。

这篇文章标题里的信息需要先对齐：截至整理时，NVIDIA 官方公开的最新一代图形增强技术是 DLSS 4（含 Transformer 模型的超分、光线重建和多帧生成），目前没有任何官方渠道发布过“DLSS 5”；《黎明行者之血》也还没有正式发售。因此，本文重点转向可落地的问题：游戏上线前后，这台机器上的超分、帧生成、光追应该怎么配，社区工具怎么用，效果怎么验证，出问题怎么排查；所谓“一键部署神器”并非重点。

如果你关心以下内容，这篇文章会比较对口：虚幻引擎 5 大作在 8GB、12GB、16GB 显存显卡上的实际帧数差别；DLSS 超分档位、帧生成、光线重建分别该在什么顺序开启；社区常见的 DLSS 运行时替换工具怎么安全使用又怎么还原；以及如何用脚本批量采集帧时间数据，把“感觉变流畅了”变成可对比的数字。

1. 事实对齐：游戏状态与 DLSS 版本

1.1 《黎明行者之血》的公开信息

先把能确认的东西列清楚。Rebel Wolves 由前 CD Projekt RED 成员创立，2022 年公开成立消息，2024 年公布首款作品《黎明行者之血》。游戏设定在 14 世纪的喀尔巴阡山区，主角 Coen 因为某种诅咒，白天是人类、夜晚获得吸血鬼的力量，设定上有一条明确的“白天与黑夜”机制——白天做调查、夜晚用非人能力战斗，这个设计贯穿叙事和玩法。

技术层面，Unreal Engine 5 是公开确认的。这一点很关键：UE5 项目的画质增强插件体系是固定框架，NVIDIA 为 UE5 提供官方的 DLSS Super Resolution、Frame Generation、Ray Reconstruction 插件，游戏发行商只要在打包时挂上插件并放置运行时 DLL，玩家端就能在设置菜单里看到对应的开关。因此你不需要等某个“专属部署包”，绝大部分 UE5 游戏的画质增强，都是在游戏自己的图形设置里完成的。

需要明确的是：发行窗口和最终发售日期请以官方公告为准，本文不基于“已发售”的假设展开操作，所有流程都是通用的、可在游戏到位后直接套用的。

1.2 关于“DLSS 5”的说法

这是本文要重点更正的一点。NVIDIA 的 DLSS 版本演进是有明确公开节奏的：DLSS 2 引入通用超分模型，DLSS 3 引入帧生成和 Reflex 配合，DLSS 3.5 引入光线重建，DLSS 4 在 RTX 50 系发布时带来多帧生成（Multi Frame Generation），同时把超分模型升级为 Transformer 架构并下放到 RTX 20/30/40 系显卡。截至目前，官方口径仍停在 DLSS 4 这一代以及其后续小版本迭代。

网上流传的“DLSS 5 一键部署工具”，从命名方式看就属于典型的标题党拼装：把真实存在的游戏名、真实存在的技术名词，加上一个不存在的版本号，再配一个“一键”前缀，凑成点击诱饵。识别方法很简单——去 NVIDIA 官方开发者博客或 GeForce 官方页面查一下版本号，如果连一条官方新闻都搜不到，那基本可以判定为虚构。

这篇文章的价值在于，把真正有效的那部分技术操作拆开讲清楚：DLSS 运行时的版本差异确实会影响画面和帧数，社区也确实有成熟的版本管理工具，这些是实打实能用的。

2. 画质增强技术栈速览

在动手之前，先把这个生态里的几个概念分清楚。很多玩家把“开 DLSS”当成一个开关，实际上它至少包含三层独立的能力，每一层的资源开销和适用场景完全不同。

表格里最容易被误读的是帧生成。它的本质是在两张真实渲染帧之间插入 AI 生成的帧，所以它不会降低单帧渲染耗时——如果你的基础帧率只有 30 帧，插帧后显示 60 帧，但输入延迟仍然是 30 帧的水平，手感会明显发飘。稳妥的开启条件是：关闭帧生成时能稳定跑到 60 帧以上，再考虑打开。

另一个常被忽略的点是显存。UE5 的 Nanite 和 Lumen 组合本身就很吃显存，1440p 高材质预设下，显存占用突破 10GB 是常态；再叠加帧生成需要保存的额外帧缓冲，8GB 显卡很容易触发显存溢出，表现就是帧数突然掉到个位数、画面卡死几秒。所以显存容量往往比核心型号更早成为瓶颈。

3. 硬件门槛与环境准备

3.1 显卡与驱动版本

DLSS 超分对 RTX 20 系及以上开放，帧生成需要 RTX 40 系及以上，多帧生成官方限定 RTX 50 系，光线重建需要 RTX 20 系及以上且游戏侧集成。这个矩阵是硬性的，认卡不认人。

驱动版本比很多人想的更重要。DLSS 运行时 DLL 是随驱动和游戏一起分发的，新驱动通常捆绑更新的运行时，对新增游戏有更好的兼容性。装驱动的原则是：优先使用 NVIDIA App 或官网提供的 Game Ready 驱动，不要用第三方“优化大师”打包的版本；如果某个游戏出现闪退，先回退一个版本做对照测试。

下面这段 PowerShell 用来快速确认显卡型号、驱动版本和显存容量，比翻控制面板快：

# 查询显卡基础信息，路径按实际安装位置兜底 $candidates = @( "C:\Windows\System32\nvidia-smi.exe", "C:\Program Files\NVIDIA Corporation\NVSMI\nvidia-smi.exe" ) $smi = $candidates | Where-Object { Test-Path $_ } | Select-Object -First 1 if ($smi) { & $smi --query-gpu=name,driver_version,memory.total --format=csv } else { Write-Host "未找到 nvidia-smi，可在 NVIDIA 控制面板 -> 系统信息 中查看驱动版本" }

输出里重点看三列：显卡名称、驱动版本号（形如 5xx.xx 的五位数字）、显存总量。显存这一项要特别注意，nvidia-smi 报的是物理容量，实际可用会略低。

3.2 系统与运行库

虚幻引擎 5 项目的运行库依赖是固定的：Visual C++ 2015-2022 运行库、DirectX 运行时、.NET 桌面运行时。这些在游戏启动器首次运行时会自动补齐，但如果你的系统是精简版或者长期没更新，建议手动装一遍完整包，能避免大量“启动即闪退”的问题。

Windows 版本建议保持在较新的正式版分支。HDR、自动 HDR、窗口化优化这些特性在不同系统版本上的行为差异不小，做画质对比测试时，最好把系统版本记录下来，否则换台机器复现不了。

另外，测试前务必确认三件事：关闭所有覆盖层（Discord、Steam 覆盖、录屏软件、显卡厂商的录制功能），因为覆盖层会干扰帧生成；关闭 Windows 的游戏模式和硬件加速 GPU 计划做一次对照，这两项在不同配置上收益方向相反；确认显示器刷新率在系统设置里已经调到最高，很多人测了半天发现一直跑在 60Hz。

3.3 监控与对比工具

一套够用的观测工具组合：

• GPU-Z 或 HWiNFO64：看显存占用、核心温度、功耗墙是否触发。
• CapFrameX 或 PresentMon：采集帧时间，输出 CSV，能做 1% Low 统计。
• NVIDIA App 的性能覆盖层：快速看帧数和延迟，适合随手验证。
• 截图工具：固定机位截图，用于画质对比。

这里强调一个方法论：画质对比必须在同一机位、同一时间点（游戏内时间）、同一天气条件下截图。UE5 的动态全局光照会随时间变化，随便截两张图对比，得出的结论基本无效。

4. 部署路径一：游戏内官方设置的正确顺序

绝大多数情况下，你不需要任何第三方工具。游戏自带的图形菜单已经把该给的能力都给全了，问题只是很多人开启顺序不对，导致测出来的数据自相矛盾。

4.1 第一步：建立无增强基线

关掉 DLSS、关掉 FSR/XeSS、关掉帧生成、关掉光追和路径追踪，分辨率设为显示器原生分辨率，画质预设设为“高”，然后进游戏跑一段固定路线。

这一段路线的选择有讲究：要包含开阔场景（考验几何和阴影）、包含大量植被（考验 alpha 测试和 Lumen）、包含水面或反射表面（考验光追）、包含快速转身（考验流式加载）。建议录一段 3 到 5 分钟的固定操作，后面每次测试都重复同一段，这样数据才有可比性。

基线数据要记录三项：平均帧率、1% Low 帧率、显存峰值。这三项决定了你后面能开多少东西。

4.2 第二步：只开超分，找质量档位

在基线基础上只开 DLSS 超分，画质档位从“质量”开始往下试。质量档的渲染分辨率大约是输出的 66%，平衡档约 58%，性能档约 50%，超高性能档更低。每一档都跑同一段路线，记录帧数和截图。

判断标准不是帧数越高越好，而是找到“画面开始出现明显瑕疵”的那个临界点。UE5 游戏在性能档下，细密的植被和铁丝网这类高频细节容易出现涂抹感，远景的粒子效果可能闪烁。如果你的显示器是 1080p，性能档的实际渲染分辨率会低到 960×540 左右，瑕疵会非常明显；如果是 4K 屏，性能档的渲染分辨率仍有 1920×1080，观感会好很多。分辨率越高，低档位越可用，这是超分的基本规律。

4.3 第三步：叠加帧生成

确认超分档位后，再打开帧生成。这里要看两个数：帧数涨了多少，以及延迟感受是否可接受。

帧生成生效的前提是基础帧率足够。如果关掉帧生成时只有 45 帧，打开后显示 85 帧，但操作会有明显的滞后感，尤其是快速转视角和近战闪避时。这时候更合理的做法是降一档画质预设，把基础帧率提到 60 以上，再开帧生成。

另外注意，帧生成开启后，游戏内的帧数显示可能是“生成后帧数”，而监控工具报的是“呈现帧数”，两者可能不一致。做数据记录时，统一用 CapFrameX 或 PresentMon 的口径，别混着看。

4.4 第四步：最后再动光追

光线追踪和路径追踪放在最后开。原因是它们会显著改变性能基线，如果先开光追再调超分，你很难判断帧数变化到底来自哪一项。

路径追踪（如果游戏提供）对显卡的要求是断崖式的，中端卡开启后即使叠加超分性能档也未必能稳住 60 帧。这时候的取舍是：优先保帧数，用高预设 + 超分质量档，放弃路径追踪；或者接受 40 帧左右，靠帧生成补到手感尚可的区间。这个没有标准答案，取决于你玩的是战斗密集的动作 RPG 还是剧情探索。

5. 部署路径二：社区工具管理 DLSS 运行时（可选）

5.1 什么情况下才需要它

社区工具解决的是一个具体问题：游戏打包时附带的 DLSS 运行时 DLL 版本可能比较旧，而新版本运行时在画质和稳定性上有改进。典型场景是游戏发售较早、后续没再更新 DLSS 插件，但驱动里已经有更新的运行时。

这类工具的代表是 DLSS Swapper（图形化管理，从官方 CDN 拉取运行时）和 DLSSTweaks（通过配置调整 DLSS 的内部参数，比如强制某个预设、调整锐化）。两者定位不同，前者换文件，后者改参数。

风险必须说清楚：修改游戏目录下的 DLL 属于修改游戏文件，可能违反游戏的用户许可协议；带反作弊的多人游戏绝对不要动，会触发完整性校验甚至封号；单机游戏相对安全，但也建议只在离线状态下操作，并且做好备份。不要用来源不明的“整合包”替换文件，那是最容易被植入东西的环节。

5.2 备份与替换的通用模板

下面这套脚本是通用模板，路径和版本号必须按你的实际情况替换。核心思路是：先在游戏目录里递归找到所有 nvngx_dlss.dll，全部备份到一个独立文件夹并记录原始路径，再统一替换。

# 第一步：定位并备份游戏目录下所有 DLSS 运行时 DLL $gameDir = "D:\Games\YourGame" # 替换为实际游戏根目录 $dllName = "nvngx_dlss.dll" $backupDir = Join-Path $gameDir "_dlss_backup" New-Item -ItemType Directory -Force -Path $backupDir | Out-Null $targets = Get-ChildItem -Path $gameDir -Recurse -Filter $dllName -ErrorAction SilentlyContinue if ($targets.Count -eq 0) { Write-Host "未找到 $dllName，可能该游戏未集成 DLSS 或使用了其他目录结构" } else { foreach ($f in $targets) { $stamp = $f.Directory.FullName.Replace($gameDir, "").Trim("\").Replace("\", "_") $dest = Join-Path $backupDir ("{0}_{1}" -f $stamp, $f.Name) Copy-Item $f.FullName -Destination $dest -Force Write-Host "已备份 -> $dest" } $targets | ForEach-Object { $_.FullName } | Set-Content (Join-Path $backupDir "paths.txt") }

备份完成后再执行替换。替换前先确认新 DLL 的签名和来源，替换后立刻进游戏做一次 10 分钟的稳定性测试，看有没有崩溃、黑屏、闪退。

# 第二步：用新版本运行时覆盖（确认备份已完成再执行） $newDll = "D:\Tools\dlss_runtime\nvngx_dlss.dll" # 替换为实际下载的新版本文件 $backupDir = "D:\Games\YourGame\_dlss_backup" $pathsFile = Join-Path $backupDir "paths.txt" if (-not (Test-Path $newDll)) { throw "新版本 DLL 不存在，请检查路径" } Get-Content $pathsFile | ForEach-Object { Copy-Item $newDll -Destination $_ -Force Write-Host "已替换 -> $_" }

还原就是反过来：把备份目录里的文件按 paths.txt 记录的路径覆盖回去。所以 paths.txt 这一步不能省，它是你唯一的还原依据。

5.3 参数调整型工具的配置模板

DLSSTweaks 这类工具通过 ini 或 JSON 配置调整 DLSS 的内部行为。下面是一个配置模板，字段名以实际工具的说明文档为准，这里只演示结构：

{ "dlss": { "force_preset": "preset_k", "sharpness": 0.0, "override_render_scale": false, "render_scale": 0.66 }, "frame_generation": { "enabled": true, "reflex_mode": "on" }, "logging": { "enabled": true, "log_path": "./dlss_log.txt" } }

force_preset对应 DLSS 内部的不同网络预设，不同预设在不同场景下的表现有差异，比如运动场景的拖影、静态细节的清晰度。这个参数没有普适最优值，必须自己截图对比。override_render_scale手动指定渲染比例，用来做极端测试，正常游玩不建议开。

配置改完一定要看日志文件，确认配置真的被加载了。很多“改了没效果”的情况，其实是配置文件放错目录或者格式写错，工具静默忽略了。

6. 功能测试与效果验证

6.1 超分档位对比测试

测试目的：找出在你的显示器分辨率下，画质和帧数的最佳平衡点。

操作步骤：固定机位站在一个包含远景建筑、中景植被、近景材质细节的位置，分别截取原生、DLAA、质量、平衡、性能五张图，然后在图片查看器里 100% 放大逐一切换对比。

判断标准：看三个位置。远景建筑的边缘有没有锯齿或糊成一片；植被的叶片轮廓是否还清晰；地面材质的细节纹理有没有被抹平。如果性能档在这三处都能接受，那就用性能档，帧数收益最大。

常见失败原因：截图时机不同导致光照变化；开了动态分辨率但没关掉，导致每次截图的渲染分辨率都不一样；显卡驱动里的“图像缩放”功能没关，二次缩放污染了结果。

6.2 帧生成开关对比测试

测试目的：确认帧生成带来的收益是否值得那份延迟。

操作步骤：先在关闭帧生成的状态下跑固定路线，记录平均帧和 1% Low；再打开帧生成跑同一段，记录同样指标。然后用快速转身、连续闪避这类操作主观感受输入延迟。

判断标准：如果关闭时平均帧低于 50，打开后的延迟大概率不可接受；如果关闭时能到 70 以上，打开后的手感通常是正向的。另外要看 1% Low 的变化，帧生成有时会拉高平均帧但恶化 1% Low，表现为偶发的顿挫。

常见失败原因：显示器没开可变刷新率，导致生成帧和显示刷新不同步；后台有录制软件占用 GPU 编码器；游戏内垂直同步和驱动的垂直同步同时开启，产生额外延迟。

6.3 光追与路径追踪压力测试

测试目的：判断当前显卡能不能扛住光追，以及光追和超分应该怎么配比。

操作步骤：在超分质量档固定的前提下，分别测试光追关闭、光追中等、光追高、路径追踪四档（如果游戏提供），每档跑固定路线并记录帧数和显存峰值。

判断标准：显存峰值是第一道门槛，超过物理显存容量就会触发溢出，表现为帧数断崖下跌。第二道是 1% Low，光追开启后如果 1% Low 掉到 30 以下，即使平均帧有 60，实际体验也会很难受。

常见失败原因：光追开启后首次进入新场景会有编译卡顿，前几十秒的数据不能算数，要等编译完成后再开始计时。

6.4 长时间稳定性测试

测试目的：排除显存泄漏和过热降频。

操作步骤：连续运行 40 分钟以上，中途多次切换场景、进出菜单、切换分辨率。全程用 HWiNFO64 记录显存占用曲线和核心温度曲线。

判断标准：显存占用应该在一个区间内波动，如果曲线是持续单向上升且不回落，那就是泄漏，只能等官方修复或者降低材质预设。核心温度如果撞到温度墙并伴随频率下降，说明散热不足，帧数波动是散热问题不是软件问题。

7. 性能数据采集与批量测试脚本

手动测一两次还行，要做参数矩阵对比就必须脚本化。思路是：用 PresentMon 或 CapFrameX 的 CLI 采集每次运行的 CSV，然后写脚本批量统计。

先定义一套测试用例配置，把每次要测的参数组合列清楚：

{ "game_exe": "D:\\Games\\YourGame\\Binaries\\Win64\\YourGame.exe", "output_dir": "./bench", "route_seconds": 180, "cases": [ { "name": "01_baseline", "upscale": "off", "fg": "off", "raytracing": "off" }, { "name": "02_dlss_quality", "upscale": "quality", "fg": "off", "raytracing": "off" }, { "name": "03_dlss_balanced", "upscale": "balanced", "fg": "off", "raytracing": "off" }, { "name": "04_dlss_perf", "upscale": "perf", "fg": "off", "raytracing": "off" }, { "name": "05_dlss_perf_fg", "upscale": "perf", "fg": "on", "raytracing": "off" }, { "name": "06_dlss_perf_fg_rt", "upscale": "perf", "fg": "on", "raytracing": "high" } ] }

这个配置本身不执行任何操作，它是你手动测试时的对照清单——每测完一组，把采集到的 CSV 按 name 命名存进 output_dir。这样后面统计脚本可以直接按文件名分组。

统计脚本如下，核心是算平均帧、中位帧和 1% Low：

import csv import os from statistics import median FRAME_TIME_COL = "MsBetweenPresents" def summarize(csv_path: str) -> dict: """从帧时间 CSV 中计算平均帧率、中位帧率和 1% Low 帧率。""" with open(csv_path, newline="", encoding="utf-8") as f: rows = list(csv.DictReader(f)) frame_times = [] for r in rows: raw = r.get(FRAME_TIME_COL) if raw in (None, "", "NA"): continue try: ms = float(raw) except ValueError: continue if ms > 0: frame_times.append(ms) if not frame_times: return {"file": os.path.basename(csv_path), "error": "无有效帧时间数据"} fps = [1000.0 / ms for ms in frame_times] fps_sorted = sorted(fps) n = len(fps_sorted) p1_index = max(0, int(n * 0.01) - 1) return { "file": os.path.basename(csv_path), "frames": n, "avg_fps": round(sum(fps) / n, 2), "median_fps": round(median(fps), 2), "p1_low_fps": round(fps_sorted[p1_index], 2), "max_ms": round(max(frame_times), 2), } def walk(folder: str): for name in sorted(os.listdir(folder)): if name.lower().endswith(".csv"): yield summarize(os.path.join(folder, name)) if __name__ == "__main__": folder = "./bench" results = list(walk(folder)) for r in results: print(r)

脚本跑完你会得到一张表，直接拿这张表做纵向对比。判断重点在p1_low_fps和max_ms两列：前者代表最差 1% 帧的表现，后者是单帧最长耗时，这一列最能暴露卡顿尖峰。平均帧好看但 max_ms 出现 300ms 以上，说明有加载卡顿或者显存溢出。

如果 PresentMon 的版本较新，列名可能不是MsBetweenPresents而是别的字段名，把常量改成实际列名即可。跑之前先用 Excel 打开一个 CSV 看一眼表头，比猜省事。

8. 资源占用与性能观察

8.1 显存是首要观察项

UE5 的虚拟化几何和全局光照体系，让显存占用变得不太可预测——同一个场景，站原地不动和跑动起来，显存占用能差 1 到 2GB。所以观察显存不能只看一个瞬时值，要看整段测试的峰值和曲线形态。

具体做法：用 HWiNFO64 开日志记录，把 GPU 显存已用、GPU 显存分配、核心频率三列勾上，跑完测试后打开日志看曲线。健康的表现是有升有降、在某个区间波动；不健康的表现是一路上升不回头，或者频繁在某个点突然掉一大块（这是驱动在回收显存，通常伴随画面卡顿）。

降低显存占用的顺序应该是：先降材质质量（影响最大），再降阴影分辨率，最后才是降超分档位。很多人反过来操作，先降超分档位，结果画质糊了显存也没降多少。

8.2 CPU 瓶颈的判断

高帧率场景下，瓶颈经常不在显卡。判断方法很简单：把分辨率降到 720p，所有画质选项拉到最低，再测一次帧数。如果帧数没有明显提升，说明是 CPU 限制；如果帧数大幅上涨，说明是 GPU 限制。

UE5 游戏的 CPU 压力主要来自场景流式加载和绘制调用。表现是快速移动时帧时间出现规律性尖峰，站着不动很流畅。这类问题的解法是降低绘制距离和植被密度，而不是调显卡设置。

8.3 延迟的主观与客观测量

客观测量可以用 NVIDIA 的延迟监控（支持 Reflex 的游戏会显示 PC Latency），也可以用一个支持 1000fps 拍摄的手机对着屏幕拍慢动作，数一下从点击到画面响应的帧数。主观感受则是打开帧生成后，连续做快速转向和闪避，看有没有“操作比画面慢半拍”的感觉。

经验判断：60 帧无帧生成的手感，通常优于 40 帧 + 帧生成。如果非要二选一，优先保基础帧率。

9. 常见问题与排查方法

这张表覆盖了绝大多数实际会遇到的情况。排错的核心原则是“一次只改一个变量”——同时换驱动、换 DLL、改配置，出了问题你根本不知道该回退哪一步。

10. 最佳实践与合规边界

第一条，先建立基线再谈优化。任何“这个设置能让帧数提升 40%”的说法，都必须在你自己的机器、你自己的分辨率、你自己的画质预设下验证过才算数。别人的数据只能作为参考区间，不能当结论。

第二条，测试环境要可复现。把显卡型号、驱动版本、系统版本、游戏版本、测试路线、画质预设这六项记录下来，附在截图旁边。过一周你回头看自己的测试数据，没有这些上下文就是一堆废数字。

第三条，文件操作必须有回滚路径。改游戏目录之前先备份，备份目录里放一个路径清单，改完立刻做稳定性验证。这是最低要求，不是可选项。

第四条，关于社区工具的合规性。修改本地游戏文件用于单人离线体验，在多数地区的法律框架下属于个人使用范畴，但仍可能违反游戏的用户许可协议，风险自负。带反作弊的联机游戏一律不要碰，这是硬红线。不要下载来源不明的“整合包”和“绿色版”，这类东西是恶意程序的高发载体。

第五条，涉及版权和素材的内容要注意边界。本文所有截图和测试素材都应该来自你合法拥有的游戏副本，不要传播他人录制的游戏画面用于商业用途。

第六条，本文不提供任何游戏本体的获取途径，也不讨论绕过授权的方案。游戏上线后请通过官方渠道购买，这既是合规要求，也是让开发团队能持续更新优化的前提。

最后给一个实操建议：等游戏真正发售之后，先花半小时做基线测试，别急着开一堆增强选项。很多人玩了一周才发现自己的帧数一直卡在 45，原因是最开始随手开了路径追踪加超高性能档，根本没建立过对照基线。把这半小时花下去，后面每一分钟的体验都会更稳。