1. 为什么要专门学 UE5 的 GPU 优化

做场景地编的人都有类似经历：场景里树多了几十棵、石头换成高模扫描资产、灯光从直射光换成 Lumen 全局光照之后，编辑器里操作开始发飘，按一次旋转要卡一下，GPU 占用率直接顶到 99%，而 CPU 只用了 20%。这时候大多数人会下意识去降低整体画质，甚至把分辨率调低，结果画面观感立刻下降，却又说不清到底哪里浪费了性能。

在 UE5 之前，环境美术最怕的是 Draw Call 和三角形数量。到了 UE5，Nanite 和 Lumen 改变了底层逻辑：高密度网格体的渲染成本大幅下降，但 GPU 的总开销并没有消失，只是从“多边形变多”变成了“着色、光照、阴影、后处理变重”。换句话说，现在的地编性能问题，从 CPU 瓶颈大量转移到了 GPU 瓶颈。如果你不理解 GPU 上的开销分布，就只能把所有设置一刀切地降低，或者靠感觉乱改，结果往往是把画面搞砸了，帧率却没救回来。

这篇入门教程会围绕一个非常实际的目标展开：在一小时左右的时间内，用可复现的流程，把 UE5 地编项目的 GPU 瓶颈找出来并压下去。我不会只给你一串命令，而是从地编工作流的角度，把静态网格体、Nanite、Lumen、阴影、材质、后处理和 GPU 崩溃排查这几个方向串起来。读完你能回答三个问题：瓶颈在哪里，为什么在那里，改什么最划算。

2. 先搞清楚地编场景里 GPU 到底在忙什么

很多教程一上来就讲控制台命令，但你不知道 GPU 在忙什么，调参也是盲调。在 UE5 渲染一帧画面时，GPU 大致有几块任务：

第一是几何体处理，包括顶点变换、Nanite 的 Cluster 筛选、LOD 过渡、视锥剔除。现代显卡对三角形数量的承受力很强，但 Nanite 也不是万能的，透明物体、带顶点动画的物体、部分植被依然会走传统路径，这部分开销不能忽略。

第二是光照与阴影。这是地编场景最大的“隐形开销”。Lumen 全局光照依赖软件光追和硬件光追，场景越大、可反射区域越多，计算量越重。动态阴影的渲染分辨率、级联阴影的层数、体积阴影图表的分配，都和场景内容、光源设置直接相关。

第三是着色器执行。每个材质最终要编译成 GPU 指令，法线、粗糙度、金属度、自发光、贴图采样、World Position Offset、半透明混合，每一层都会增加指令数。地编里最常见的性能问题是“同样的材质逻辑几乎一样，但存在几百个材质实例”，导致 GPU 在切换状态上浪费大量时间。

第四是后处理。TAA、景深、Bloom、SSR、环境光遮蔽、色调映射，这些都发生在全屏或者半屏分辨率阶段。后处理叠加越多，GPU 每帧的固定开销就越高，而且它和场景复杂度没有关系，哪怕你只放一个孤零零的球，后处理该花的时间一分不少。

第五是分辨率与像素填充率。最终输出分辨率、渲染分辨率、像素着色器的复杂度，共同决定了 GPU 的压力。这也是为什么很多时候“调低分辨率立刻流畅”的原因：GPU 的像素负载被大砍一截。

对地编来说，理解这五块之后，优化的顺序就清楚了：先看统计数字，再决定从哪一块下手。不要一上来就把 Lumen 关掉，也不要盲目把全部贴图改小。正确做法是先量出 GPU 的耗时结构，再处理最重的那一两项。

3. 定位 GPU 瓶颈：Stat GPU、Stat Unit、ProfileGPU

UE5 自带的性能统计工具已经足够判断大部分地编场景的瓶颈。首先在编辑器里按 ` 打开控制台，输入：

stat unit

这个命令会显示帧时间、游戏线程时间、渲染线程时间和 GPU 时间。如果 GPU 时间明显大于游戏线程和渲染线程，说明压力确实在 GPU 上。反过来，如果游戏线程极高、GPU 不高，那么你优化材质阴影收益也不大，要先去处理 CPU 侧的剔除、物理、蓝图逻辑等问题。

接下来输入：

stat gpu

这个命令会把 GPU 时间按渲染阶段拆开，列出 PrePass、BasePass、Shadow Depths、Lighting、Translucency、PostProcessing 等项目的毫秒耗时。重点看 BasePass、Shadow Depths 和 Lighting 三项。BasePass 耗时高，通常说明材质太复杂、半透明物体太多，或者 Nanite 没有覆盖到本该覆盖的资产；Shadow Depths 高，说明阴影分辨率或动态投影的光源数量有问题；Lighting 高，就要关注 Lumen 和反射相关设置。

另外一个非常实用的命令是：

profilegpu

运行后，UE5 会把当前场景的 GPU 时间保存到日志，并打开 GPU 可视化界面。你能看到每一帧的完整渲染任务序列，包括每个 Draw Event 的耗时。对于地编，最典型的场景是：你看到一个叫“Light Grid”或者“Lumen Scene”的任务占了整整 4ms，这时候就应该去调整全局光照设置，而不是继续压材质。

还有两个配合使用的技巧。输入：

freezerendering

再旋转视角，引擎会冻结渲染状态，但继续实际渲染同一帧。这非常适合切换一个物体或改一个参数后快速对比性能变化。再输入：

stat scenerendering

可以看到 Draw Call、Mesh Draw Call、被剔除物体数量等 CPU 侧数据。如果 GPU 压力不大但整体帧率低，这里的数字能帮你判断是否是场景剔除失效、Draw Call 过多导致的 CPU 瓶颈。

实际操作中，我的建议是：先把 stat unit 和 stat gpu 两个窗口同时打开，记下基线的 GPU 时间，然后逐个调整可疑配置，每次只改一个，改完立刻看数字变化。这个方法虽然朴素，但对地编项目最可靠，比依赖某一个预设快捷键有效得多。

4. 几何体与 Nanite 的正确用法：三角形数量不是唯一焦虑

地编项目里最影响观感的往往是岩石、山体、建筑废墟、木质结构这些高密度物体。UE5 的 Nanite 虚拟化几何体，让这些原本在 UE4 里必须做 LOD、减面的资产，现在可以直接导入高模，甚至导入 ZBrush 级别的高模。

Nanite 的原理是把模型切成 Cluster，GPU 根据像素大小自动选择 Cluster 精度。所以 Nanite 场景下，三角形数量本身不再是主要的 GPU 负担，你的优化重心要转移到别处：

第一，确认哪些物件真的需要 Nanite。Nanite 适合静态网格体，但不适合需要变形、半透明、顶点动画的物体。植被、布料、角色骨骼网格、带 Dissolve 特效的物体，依然要走传统渲染管线。地编里最常见的问题是把树、草、布料全设成 Nanite，结果这些物体反而不支持某些着色功能，性能也没有明显提升。

第二，注意 Nanite 的“像素边边长”设置。控制台输入：

r.Nanite.MaxPixelsPerEdge 2

这里的 2 表示 Nanite 会根据约 2 像素的边长来决定集群细分的程度。数字越小，网格越粗糙。默认值通常是合理的，但如果你在远处发现大量轮廓细节还在计算，可以适当提高这个值。不要把它调得太狠，否则近距离看模型会有明显的 Adaptive LOD 跳变。

第三，普通小物件也尽量合并静态网格体。UE5 的地编场景中，如果一个小桌子由几十个零件组成、每个零件单独一个 Static Mesh，即使 Nanite 能快速处理三角形，也不要让 Draw Call 白白浪费掉。你可以把固定不动的装饰物合并成一个 Static Mesh，或者使用 Instance Static Mesh / HISM 来摆放重复资产，例如树木、石头、栏杆、灌木。

第四，看清楚剔除的情况。地编场景经常因为“被一个巨大包围盒套住”而导致整个网格体无法被视锥剔除。比如一座山的包围盒很大，但实际地形从某个角度完全被另一座山挡住，GPU 依然可能为它做大量计算。解决方案是拆分大的静态网格体，让引擎能更细粒度地剔除，或者在项目设置中开启合适的遮挡剔除裁剪方式。

理解 Nanite 之后，你需要知道另一件事：Nanite 不是地编场景的万能免死金牌。它能帮你把几何体这一层省下来，但阴影、Lumen、材质这些环节，每一个都在 GPU 上继续消耗。接下来要处理的是光源和阴影。

5. 灯光与阴影：地编场景里最大的一块 GPU 隐形开销

环境美术做氛围时，灯光永远不只一盏。主光源、补光、轮廓光、体积雾里的点光源，再加上天光，很容易就把场景堆出七八个动态光源。在 UE5 的 Lumen 体系下，光源数量对 GPU 的影响比 UE4 时代更明显。

Lumen 作为实时全局光照方案，把间接光照和反射的计算纳入了一个统一框架，但它消耗的 GPU 资源也不小。地编工作时，如果不需要看实时 GI，或者场景主打静态光照，可以考虑用一个更便宜的方案，或者阶段性关掉 Lumen。控制台命令：

r.Lumen.DiffuseIndirect.Allow 0

这个命令会关闭 Lumen 的间接漫反射，直接光、天空光等基础光照还在，但全局反弹效果会明显减弱。它适合“只检查灯光造型、暂时不看 GI 效果”的工作阶段。注意，保存项目时不要把临时测试参数带进最终成品。

如果确定要用 Lumen，优化重点就变成场景里哪些物体默认开了“影响全局光照”。在 Lumen 里，自发光材质和强反射物体会被当作光照源处理，数量多、面积大使计算开销迅速上升。地编中要控制发光材质的数量和强度，不要让几十个广告牌式的自发光面同时参与 Lumen 计算。

方向光投射的阴影也有专门参数。动态阴影的分辨率越高，GPU 压力越大。Lumen 开启后，距离场阴影和虚拟阴影贴图会占据不小的运算。你可以先在项目设置里试试 “Virtual Shadow Map” 的相关选项，把范围调小，看阴影边缘质量是否还能接受。如果只想要近距离阴影清晰、远处阴影柔和，可以单独对重要光源提高阴影分辨率，而不是把所有光源都开到最高。

一个更实际的经验：地编场景的阴影卡顿，很多时候不是单盏灯造成的，而是场景里大量光源同时投射动态阴影。主光源开 Shadow 没有问题，但辅助光、轮廓光如果不需要阴影，就把 Cast Shadows 关掉。尤其做室内场景，窗户多、灯光多，隐藏光源、仅可见性、投射阴影，这些设置每盏灯都要亲手检查一遍。

体积雾和体积云也是隐藏的 GPU 压力来源。地编做很大的开放世界时，体积雾常常悄悄把帧率拉低 2 到 4 毫秒。控制台命令：

r.VolumetricFog 0

可以临时关闭体积雾，先确认它是不是拖累帧率的主因。如果确认，再调整体积雾分辨率、Jitter 和距离设置，而不是彻底删除效果。

6. 地形与植被：地编最常踩的阴影和绘制坑

地形（Landscape）是 GPU 优化里的特殊部分。它的材质通常比较复杂：多层材质混合、权重贴图、空间材质噪声，再加上运行时虚拟纹理（RVT）的支持，整个地形会占用很大的显存和着色器带宽。地编中常见的问题是把地形材质做成十几层图层，每一层都用全屏尺寸的重叠贴图，GPU 压力自然就上来了。

优化手段首先是减少图层数量，或者使用 RVT。RVT 能把地形、道路、盖住地面的静态网格体的材质烘焙到虚拟纹理里，大幅降低动态材质采样的开销。如果你的项目允许用 RVT，地形材质层数可以明显减少。RVT 不是简单的开关，它需要在项目设置和材质里配合，但它的收益往往比压缩贴图更直接。

地形阴影方面，地编最容易出现的问题是“远处地形阴影闪烁”或“阴影边缘锯齿”。此时不要盲目提高阴影分辨率，先看是不是加了 Contact Shadow，或者阴影的距离设置太远。地形和植被产生的暗部细节，往往可以通过调整阴影的 DistanceField 精度来解决，而不是把所有阴影层级全开成最高。

植被优化的关键是区分“需要动态响应”和“只是装饰”。大片的草、树叶、灌木，如果能接受风吹动造成的视觉差异不明显，就尽量做成静态。草地的着色器复杂度和实例化数量密切相关，草丛模型如果使用半透明材质，GPU 会按像素做混合排序，几百个透明草片的排序开销会迅速击穿性能。

一个实用思路：大量远处树木改用 Nanite 或普通 LOD 的静态网格体，少用带材质动画、带顶点动画的植被。如果要表现风吹草动，只在镜头可能靠近的区域保留动画植被；远景则直接换成一张可平铺的草卡，配合 Nanite 合并。阴影方面，物件越远，Cast Shadow 越没必要，可以把大范围远景植被的阴影关掉，只保留近景高精度阴影。

植被绘制还有一个容易忽略的点：碰撞体。某些环境物件导入时带了复杂的物理碰撞体，虽然渲染上它是低模，但物理查询和渲染前处理一样占用 CPU 和 GPU 浮点运算。地编中纯装饰的植被，最好把碰撞设成“仅查询”或者干脆关闭碰撞，否则几百棵树的碰撞体同时存在，连编辑器操作都会变卡。

7. 材质与贴图：用一半的 GPU 预算换来同样画面

地编场景里材质数量巨大，而且普遍存在“功能没用但节点很大”的情况。比如一个地面材质里叠加了 World Position Offset、两个像素深度偏移、多个复杂的乘法节点，其实只是为了让地面看起来有点起伏。这些多余运算会直接增加 BasePass 时间，导致 stat gpu 里 BasePass 长期居高不下。

首先看材质的 Shader Complexity。选中材质，打开材质编辑器，在视图模式中选择 Shader Complexity，或者直接在视口使用命令：

viewmode shadercomplexity

模式下画面会以颜色表示像素着色复杂度：绿色表示很轻，红色、白色代表极重。如果你发现大面积的红色区域集中在地形或大型静态网格上，说明要优化材质本身了。

优化材质最有效的一招是把计算从像素里拿出来。常见做法是：涉及随机效果的噪声、变形，先在顶点阶段做一次，再在像素阶段只做简单的采样；使用 Feature Switch 区分高性能平台和低性能平台；把复杂的计算提前烘培到贴图里，比如环境遮蔽、粗糙度变化、轻微色差，都可以烘焙。

地编还有一个通用规则：一个材质实例能搞定的，不要建三个冗余材质。假设项目里有 20 种石头，每种石头只是贴图、颜色、粗糙度参数不同，完全可以共用一个母材质，用参数实例区分。这不仅能减少材质编译数量，还能减少 GPU 切换着色器的开销。

贴图方面，不要拼命追求 4K 贴图。地编普通岩石、地面、墙面，2K 或 1K 已经很够。某些大面积地表甚至 512 足够。贴图的 Mip 处理，以及材质里是否正确使用纹理，会影响显存占用和纹理采样带宽。如果你在场景里大量使用没有 Delta 压缩的 PNG 贴图，显存压力会变大，GPU 采样纹理也变慢。

还有一类隐形成本来自材质里的法线贴图。法线贴图在像素阶段的浮点运算比普通颜色贴图更高，因此不要给离镜头很远的物件全部上 4K 法线。更合理的做法是远景资产使用 1K 法线，或者直接使用平坦法线，配合局部细节纹理做混合，远看效果不会差，GPU 负荷却下降明显。

8. 后处理与可扩展性设置：最后一块“轻拿轻放”的大头

当几何体、光照、材质都已经优化完毕，后处理往往是最后一个 GPU 大头。很多地编项目为了氛围加了很强的 Bloom、SSR、景深、色差、胶片颗粒，这些效果叠加起来，在低端显卡上会直接吃掉 3 到 5 毫秒。

后处理溢出的典型表现：在 stat gpu 中 PostProcessing 时间很高，但你已经确认没有特别复杂的光照。你可以用命令：

r.SSR.Quality 0

临时关闭屏幕空间反射，看看反射对性能的影响。如果场景本身有大量平坦水面或金属表面，SSR 的代价确实不小，可以考虑用平面反射或纯反射捕捉替代。

Bloom 和景深也很容易被滥用。地编中，Bloom 的阈值、强度、半径会明显影响 GPU 开销，尤其是大半径的 Bloom 会使用更多半分辨率采样。一般美术人员习惯把 Bloom 开到很高，其实大部分场景需要的只是非常轻的泛光补偿。景深则尽量使用低分辨率模拟，或者干脆在非剧情场景关闭。每种后处理都可以先在质量设置里逐项降级观察效果，不要一次性把所有后处理都降为零。

项目中比较重要的一点是 Scalability（可扩展性预设）。你是不是经常会遇到这样的开发者：他们在自己的 4K 高配电脑上制作场景，然后打包给普通笔记本用户，效果极其糟糕。原因很简单：他们没有检查过低质量可扩展性下的场景表现。你在项目设置或编辑器里输入：

Scalability

可以快速切换 Low/Medium/High/Epic 四档预设。每一档都对应阴影质量、反射质量、后期处理质量、抗锯齿质量和视距。地编做完一个区域后，至少要用 Medium 档跑一下，确保场景不会在低配机器上直接崩溃或掉帧到无法运行。如果你嫌默认预设不够细，可以在项目设置中自定义 Scalability 组，配置每一档对应的具体参数。

分辨率缩放是另一个被忽视的参数。许多人在项目里直接修改视口分辨率，然后在打包后用固定分辨率运行。更稳妥的做法是让 UE5 的动态分辨率补偿机制介入，也就是设置屏幕百分比上限和下限。控制台：

r.ScreenPercentage 100

把百分比降到 75 或 60，帧率往往立竿见影地提升，同时画面损失可能微乎其微。在地编场景中，如果不是需要逐像素级确认贴图细节，平时完全可以用 75% 的屏幕百分比工作，最后再恢复到 100% 出图。

9. 显卡崩溃与驱动异常排查：地编最常用的“救火”流程

地编工作久了，几乎每个人都会遇到 UE5 引擎突然崩溃并弹出类似于 GPU Crash 的提示。有些崩溃其实是 GPU 过载导致驱动重置，有些则是资源设置异常。常见信息包括：

• “GPU Crash Dump Triggered”：引擎检测到 GPU 异常，生成了 crash dump 文件。
• “Xid 79: GPU has fallen off the bus”：NVIDIA 驱动报告中显卡总线通讯异常，多出现在高负载或过热场景。
• Windows 设备管理器中显卡出现“错误代码 43”：驱动无法正确启动或重置。

这些现象不能一概而论是显卡坏了，但也不能完全忽略。地编项目出现 GPU 崩溃时，建议按以下顺序排查：

第一，检查温度。显卡长期在 85 度以上高负载运行，容易触发驱动保护或运算不稳定。可以使用 GPU-Z 或系统自带任务管理器查看 GPU 温度、显存占用。如果温度过高，清灰、改善机箱风道、降低负载，比改任何引擎参数都更重要。

第二，检查驱动版本。NVIDIA 的 Studio 驱动比 Game Ready 驱动更适合 DCC（数字内容创作）软件。如果你经常开 UE5、Blender、Substance Painter，建议把驱动切到 Studio 分支。同时，驱动不要频繁更新到“最新”版本，引擎对驱动兼容性更敏感；确认你当前的引擎版本匹配的驱动区间后，锁一个稳定版本即可。

第三，检查显存占用。地编场景中比例超高的大贴图、大量 RVT 缓存、Lumen 场景数据，都会压迫显存。如果你的显存是 6GB 或 8GB，运行开放场景时很容易接近满载。可以查看项目中的 Texture Streaming Pool。遇到显存溢出，先缩小贴图尺寸或限制纹理流送池大小：

r.Streaming.PoolSize 512

这里 512 表示纹理流送池大小约为 512MB，实际项目中需要根据显存大小设置，不要盲目设置单位，数值越高占用显存越多。设置后重新加载场景，如果崩溃消失，说明显存压力是主因。

第四，开启日志再复现一次崩溃。UE5 的日志通常保存在项目 Saved/Logs 目录下，崩溃前往往有 GPU 相关的 Error 信息。在崩溃复现前打开日志窗口，你可以看到最后一批渲染指令是什么，进而判断是阴影、材质还是后处理触发了崩溃。如果日志里反复出现某个资源名字，优先替换这个资源测试。

第五，使用命令行参数临时降配运行。如果编辑器反复崩溃，先用打包后的项目配合以下参数跑一遍：

-NoVerifyGC -sm5 -d3ddebug

这里-sm5表示使用 Shader Model 5，-d3ddebug用于输出 DirectX 调试信息。对于排查 GPU 崩溃，更稳妥的方法是先用低画质、低分辨率、关闭 Lumen 跑通场景，再逐步升级画质，找到触发崩溃的那个配置项。

10. 一小时实践流程：一份可以直接照做的优化清单

现在把上面的内容整合成一个可以在 UE5 地编项目中直接执行的“一小时检查流程”。它的目标不是把画质降到最低，而是在相对稳定的视觉水准下，把不必要的 GPU 开销逐一清理干净。

前 10 分钟：定基线。打开控制台，依次执行 stat unit、stat gpu，记录当前 GPU 时间。看是 BasePass、Shadow、Lighting 还是 PostProcessing 占了最大头。同时用viewmode shadercomplexity粗略扫一眼场景中哪些物体材质颜色发红发白。这一步决定了你接下来把时间花在哪里。

第 11 到 25 分钟：处理几何体和阴影。检查主要大型静态网格体是不是 Nanite；植被是否混杂了传统管线和半透明材质；确认主光源外，是否有其他光源开着投影。关闭不必要的动态阴影。用 r.Lumen.DiffuseIndirect.Allow 0 临时关掉 Lumen 后测量一次差异，确定 Lumen 是否为最大开销。如果确认，再延长 Lumen 的屏幕空间追踪距离或降低最终质量，而不是彻底把 GI 阉割掉。

第 26 到 40 分钟：压材质和贴图。找出几个大面积使用的石头、地面、墙面母材质，合并重复材质实例，降低法线贴图分辨率，把像素阶段计算转移到烘焙贴图或顶点阶段。对照 stat gpu 中 BasePass 耗时的变化。

第 41 到 50 分钟：处理后处理与可扩展性。关掉或降级 SSR、Bloom、景深等效果，确认画面观感损失。使用 Scalability 切换中档确认中低配下的表现，再启用较低的 ScreenPercentage 继续工作。如果你想保留高质量出图，设置一个独立的高质量可扩展性档位用于最终截图或影片渲染。

最后 10 分钟：做一轮稳定性验证。从场景各个区域进行快速巡游，超过 5 分钟，观察 GPU Crash 是否出现。如果崩溃，按上一章的驱动、温度、显存、日志顺序排查。

11. 常见问题与排查思路

12. 最佳实践与工程建议

优化并不是一次性的。维护一个 UE5 地编项目，你最好从项目初期就建立一套性能约束。

第一，使用“性能预算表”管理场景。比如定义某区域最大 GPU 时间 6ms、最大非 Nanite 物体数量、最大动态光源数量、最大透明材质数量。美术人员每添加一个资产，就要对照预算表，而不是等场景完全搭完再统一优化。

第二，为不同目标设备配置独立的可扩展性设置。不要默认所有平台共用同一套画质参数。PC 端可以开高分辨率、SSR、后处理；低端笔记本则需要自动降档。UE5 的 Scalability 组与设备配置文件可以配合，在打包时根据硬件等级自动选择设置。

第三，在地编过程中养成“背景草稿加定期验证”的习惯。平时可以在较低分辨率、关闭体积雾的工作模式下创作，每完成一个区块就切到完整画质预览一次。不要全程都在完整画质下操作，那样不仅卡，还会掩盖真正的性能问题。

第四，尽量每天都看一眼日志文件。UE5 的 Saved/Logs 目录会积累大量网络、资源加载、GPU 警告信息，很多问题在出大 Bug 之前就已经有 Warning。花两分钟扫一眼，比崩溃后花两个小时排查要划算得多。

第五，关于备份与版本管理：调整项目设置、可扩展性、材质质量前，先把当前的 Config 文件和材质文件做一次提交。这样改完某个参数发现问题，可以快速回滚对比，不会因为忘记原始状态而找不到恢复路径。

如果你的项目涉及团队协作，建议把整套优化规则写成团队 Wiki，包括使用哪个版本的驱动、哪些材质不允许使用、哪些后处理只留到最终渲染阶段用。地编技术含量并不仅限于会摆资产，能不能稳定地控制性能，才是从入门到进阶的分水岭。

13. 总结与后续学习方向

这篇文章从地编工作流的角度，梳理了 UE5 场景里最常见的 GPU 优化链路：先用 stat unit、stat gpu 定位瓶颈，再从几何体、Nanite、灯光阴影、地形植被、材质贴图、后处理这几个方向逐项压掉开销，最后补充了 GPU 崩溃和驱动异常的排查方式。你要重点记住的核心判断是：不要一开始就整体降低画质，先做量化分析，再针对最大的 GPU 时间块进行调整。

优化没有一劳永逸，渲染技术也在不断变化。UE5 后续版本中 Lumen、Nanite 和相关控制台命令的细节有可能会调整，但定位瓶颈的方法论是稳定的。

实际动手时，建议先拿一个简单的测试关卡跑通整个一小时流程：放一个地形、几块高模岩石、几十棵树、三盏灯，先看你的 GPU 被哪一项吃满，然后根据这篇文章的清单逐项优化。跑完这个流程之后，你再去处理真正的业务场景，会发现自己对 stat gpu 里那些数字的理解完全不同。这个过程，比背下任何一条控制台命令都更有价值。