降低了图形设置但帧率没有提升？你很可能调错了瓶颈。
你降低了阴影、纹理、特效甚至分辨率，但帧率几乎没有变化。这并不一定意味着设置坏了。这通常意味着你更改的设置并没有给当前限制性能的组件带来压力。
图形预设不是通用的性能旋钮
图形菜单将许多不同的工作负载分组在一个屏幕下。有些设置主要增加GPU工作。其他设置增加CPU工作、内存流量、资源流送或两者兼有。
降低分辨率就是一个很好的例子。它通常减少GPU必须着色的像素数量。如果GPU是限制组件，帧率可以大幅上升。如果CPU准备每一帧的时间已经比GPU渲染它的时间更长，减少像素工作可能使最终帧率几乎不变。
Intel自己的CPU/GPU瓶颈指南明确指出了这一区别：降低分辨率可以释放GPU资源，而绘制距离等设置可以影响CPU性能。效果取决于场景和工作负载，而不是单一的通用“低预设=更快”规则。
瓶颈响应测试
将设置更改用作诊断实验
为什么降低分辨率是如此有用的测试
分辨率改变GPU执行的像素工作量。这使其成为区分强烈GPU限制情况与其他地方限制情况的最清晰的首批测试之一。
大的分辨率变化可以告诉你什么
| 观察到的结果 | 可能的解释 | 下一步 | |
|---|---|---|---|
| 帧率大幅增加 | FPS rises strongly | GPU rendering load was an important constraint | Tune GPU-heavy settings, resolution, upscaling or image-quality trade-offs |
| 帧率小幅增加 | FPS barely changes | CPU, simulation, frame cap, streaming or another non-pixel workload may be limiting | Inspect CPU/GPU timing and CPU-sensitive settings |
| 混合响应 | Average rises but lows/stutter do not improve | GPU throughput improved but the slow-frame cause remains elsewhere | Inspect frame-time spikes, streaming, CPU scheduling and memory behavior |
| 在固定上限下无响应 | FPS stays exactly at the same ceiling | A frame cap, V-Sync limit or engine cap may be active | Identify the limiter before changing quality settings further |
CPU受限并不意味着“CPU占用100%”
一个常见的错误是查看总CPU利用率，并因为显示40%或60%而得出结论CPU不可能是瓶颈。
游戏不一定将其最重要的帧工作完美地分配到每个核心上。一个或几个关键线程可以决定何时提交下一帧，即使其他核心仍然不那么忙。
Intel建议进行CPU/GPU平衡分析，而不是依赖一个利用率百分比。PresentMon的GPU Busy指标专门设计用于帮助评估GPU在帧间隔中实际执行工作的时间比例。
设置敏感度地图
| 设置类别 | 通常压力点 | 为什么FPS可能响应或不响应 |
|---|---|---|
| 分辨率 / 渲染比例 | 主要是GPU像素工作量 | GPU受限时响应大；CPU受限时响应小 |
| 光线追踪 / 重光照 | GPU | 降低时可大幅减少GPU帧时间 |
| 阴影 | GPU，有时CPU | 取决于阴影距离、对象数量和引擎实现 |
| 绘制距离 / 对象距离 | CPU + GPU | 更多对象会增加提交、模拟和渲染工作 |
| 人群 / NPC密度 | 通常是CPU + GPU | AI、动画和模拟会增加CPU侧开销 |
| 纹理 | 更多是VRAM / 内存带宽而非纯计算 | 可能影响卡顿或内存压力，但平均FPS变化不大 |
| 效果 / 体积效果 | 主要是GPU | 当GPU执行时间高时通常有用 |
| 物理 / 模拟质量 | 通常是CPU | 即使在低分辨率下也可能开销很大 |
| 超分辨率 | GPU工作量和图像管线 | 主要在GPU侧渲染成本显著时有用 |
低GPU利用率可能是症状，而不是病因
如果GPU在等待CPU或管线中的其他上游部分，即使帧率很低，GPU利用率也可能下降。
Intel将这种一般模式描述为瓶颈：一个组件限制了另一个组件发挥其潜力。其开发者指南也展示了CPU受限的场景，即GPU在等待CPU工作时处于空闲状态。
这并不意味着每个70%的GPU读数都证明存在CPU瓶颈。帧率上限、加载、菜单、电源管理、遥测行为和场景切换都可能影响利用率。计时是比单一百分比更强的证据。
为什么更高的GPU利用率并不总是目标
当目标是最大图像质量或吞吐量时，GPU利用率达到99%可能完全正常。当帧率被限制或游戏有意留出余量时，GPU低于99%也可能完全正常。
有用的问题不是“我如何强制GPU达到100%？”而是“是什么阻止了帧更快完成，我真的需要它更快完成吗？”
帧率上限可能让设置看起来无效
如果游戏被限制在120 FPS并且已经达到120 FPS，降低图形设置无法使显示的帧率超过该上限。
额外的余量可能仍然重要：即使FPS计数器保持不变，GPU负载、功耗、风扇噪音或延迟行为也可能发生变化。
在将不变的FPS视为CPU瓶颈的证据之前，请检查游戏限制器、驱动限制器、垂直同步行为或其他呈现限制是否将帧率固定在某个上限。
为什么DLSS、FSR或降低渲染比例有时几乎不起作用
超分辨率技术降低了部分渲染工作量的分辨率，并重建最终图像。当像素渲染开销很大时，这非常有用。
但如果CPU或模拟已经决定了帧间隔，减少GPU像素工作可能不会显著提高基础渲染帧率。
这就是为什么游戏在原生分辨率和低得多的内部渲染分辨率下可能显示几乎相同的FPS。GPU获得了空闲容量，但由于另一个依赖项更慢，下一帧仍然无法更早开始或完成。
帧生成是一种特殊情况
帧生成使通常的 FPS 解读变得复杂，因为生成的帧可以增加显示的帧输出，而无需 CPU 模拟每一个生成的帧。
NVIDIA 明确将此记录为 DLSS 帧生成可以在 CPU 受限场景中提高显示帧率的原因之一。这并不意味着原始的 CPU 瓶颈消失了；这意味着呈现管线可以产生超出 CPU 原生模拟/渲染提交速率的额外帧。
对于诊断，应将基础渲染性能、生成帧输出和输入延迟分开考虑，而不是将单个 FPS 计数器视为整个系统。
响应性和 FPS 不是同一种测量
CPU 或 GPU 瓶颈对延迟的影响也不同。NVIDIA Reflex 文档将延迟管线分为多个阶段，包括输入、模拟、渲染提交、驱动程序、渲染队列和 GPU 渲染。
这很有用，因为图形更改可以改善 GPU 渲染时间，而模拟或 CPU 提交时间几乎不变。
因此，正确的问题可能不是“FPS 上升了吗？”，而是“我关心的管线部分变快了吗？”
错误瓶颈诊断
当低设置和超高设置性能几乎相同时
不要仅从设置菜单进行优化
图形预设是为可用性设计的，而不是为了暴露引擎的性能架构。
“中”预设可能同时更改十个不相关的变量。如果性能提高，你仍然不知道哪个更改起了作用。如果没有提高，一个 CPU 密集型或流式加载密集型选项可能仍然占主导。
对于故障排除，单独更改较慢但信息量大得多。
实用的调优顺序
调优瓶颈而不是标签
什么会改变这个答案？
确切的瓶颈可能因场景而异。室内走廊可能是 GPU 受限，而密集的城市或策略战斗可能变为 CPU 受限。因此，诊断应针对实际导致性能问题的工作负载。
帧生成、动态分辨率、引擎级自适应画质以及未来的调度系统也可能使简单的FPS缩放变得不那么直观。核心方法仍然成立：改变一个工作负载，观察响应，并确定哪个阶段停止了改善。
局限性
本文提供了一个诊断框架，而不是将每个图形设置普遍映射到CPU或GPU成本。引擎架构决定了实际的工作负载。
仅凭利用率百分比无法证明瓶颈。时序追踪、可重复测试以及对受控设置更改的响应提供了更有力的证据。
结论
如果低画质和超高画质提供的FPS几乎相同，不要继续随机降低设置。
将缺乏缩放作为证据。测试分辨率，检查CPU/GPU时序，检查帧率上限，然后针对影响限制性工作负载的设置进行调整。一旦你不再问“哪个设置开销大？”而是开始问“哪个组件阻止了下一帧更快完成？”，性能调优就会变得容易得多。
常见问题
图形设置、CPU瓶颈和低GPU使用率
为什么降低图形设置没有提高我的FPS？
为什么1080p和1440p给我的FPS几乎相同？
低GPU使用率总是意味着CPU瓶颈吗？
当总CPU使用率低于100%时，游戏可能是CPU受限的吗？
哪些图形设置影响CPU？
为什么在某些游戏中升级分辨率没有提高FPS？
术语表
关键瓶颈术语
- CPU受限
- 一种性能状态，其中CPU侧的工作或提交阻止了帧更快地生成，即使GPU有额外的容量。
- GPU受限
- 一种性能状态，其中GPU执行消耗了帧预算的限制部分。
- 缩放响应
- 通过改变工作负载（如分辨率或图形质量）产生的性能变化。
- GPU忙碌
- Intel PresentMon的一个指标，有助于将GPU执行时间与总帧时序进行比较，以评估CPU/GPU平衡。
- 瓶颈响应测试
- Figure Rocks的一种方法，使用受控设置更改和时序测量来确定哪个工作负载限制了性能。
- 设置敏感度图
- Figure Rocks的一种规划模型，根据游戏设置通常影响的CPU、GPU、内存或流式工作类型对它们进行分组。
主要来源
Intel — 定位并解决CPU-GPU瓶颈Intel官方关于CPU/GPU不平衡、场景相关瓶颈以及分辨率和绘制距离设置如何影响不同工作负载的指南。
Intel — PresentMonIntel官方性能监控工具，具有GPU忙碌、CPU/GPU平衡、实时图表、百分位数和遥测功能。
NVIDIA开发者 — Reflex SDKNVIDIA官方文档，分离延迟阶段并描述渲染队列和CPU/GPU时序行为。
NVIDIA技术博客 — CPU线程与游戏性能NVIDIA官方开发者对CPU受限游戏工作负载、线程调度和CPU侧性能约束的分析。
NVIDIA — Ada GPU科学 / DLSS 3NVIDIA官方技术材料，解释CPU受限游戏行为以及为什么帧生成可以在不需要CPU渲染每个生成帧的情况下提高显示的FPS。
Related Articles
为什么PC游戏在编译着色器时会卡顿——以及高级着色器分发如何改变这一现状
着色器卡顿发生在 PC 游戏不得不在错误时机编译 GPU 程序的时候。Microsoft 高级着色器交付通过提前准备硬件专用着色器并随游戏一起交付，将大部分工作从玩家 PC 上移走。
显存使用量不等于显存需求量：为什么显存占用满并不代表全部真相
在8 GB显卡上看到7.8 GB已使用，可能看起来像是游戏显存耗尽的证据。事情并没有那么简单。本指南将解释VRAM容量、驻留预算、工作集、共享内存，以及如何判断内存压力是否真的导致了卡顿。
路由器检查清单 v2：防止延迟尖峰的12项设置
大多数延迟峰值源于负载和不稳定性，而非“高延迟”。在购买新设备前，请使用这份路由器检查清单，以确保在高负载下延迟稳定。
NVIDIA Reflex基础解析：何时有效（何时无效）
当游戏受GPU限制且运行稳定时，Reflex技术能有效减少渲染队列延迟。了解其发挥作用的实际条件，以及可能导致其失效的陷阱。
RTX神经纹理压缩并非超分辨率技术：AI如何以GPU计算换取纹理内存
NVIDIA RTX 神经纹理压缩改变了游戏材质的存储方式。材质不再仅以传统纹素的形式保存每个纹理通道，而是可以压缩为紧凑的潜在数据和一个小型神经解码器，然后在需要时由 GPU 重建。
存储与流式传输：减少加载时间，避免卡顿
快速存储仅在流式行为稳定时才有帮助。本指南将解释输入/输出如何影响卡顿，以及应优先调整哪些设置。
HDR与SDR决策矩阵：何时HDR更优，何时SDR胜出
HDR并非总是更优选择。根据可读性、稳定性及显示器实际表现，使用这个简单的决策矩阵来为每款游戏选择HDR或SDR模式。
游戏路由器设置清单：真正重要的配置项
大多数路由器调整并无助益。真正有效的设置包括：负载下的队列管理、稳定的Wi-Fi表现，以及避免增加延迟或不稳定性的功能。
DirectStorage 1.4 并不会让你的固态硬盘解压游戏：Zstd 和 GPU 解压实际上做了什么
DirectStorage 1.4 新增了 Zstandard 压缩、GPU 解压缩和一个新的游戏资产调理库，但 SSD 本身仍然只是加载管线中的一部分。本指南解释了 SSD、DirectStorage、CPU、GPU 和游戏引擎各自实际负责什么。