主题
输入延迟：构成、测量与判据
输入延迟问的是"我操作之后，画面多久才动"；响应时间问的是"像素切换有多快"。这两个问题经常被混成一个"1ms"，但它们的来源与降低手段都不同。
📌 本页在"时序层"上的位置：本页负责操作到画面的总延迟（分段构成与测法）。 哪些处理环节在增加延迟见 图像处理与画质引擎； 总链与症状定位见 动态表现。
本页按三段式走：先把延迟分段（概念）→ 再学会测与降（会用）→ 最后弄清延迟为什么"降不干净"（原理）。
一、延迟是分段构成的
| 环节 | 贡献 | 能否降低 |
|---|---|---|
| 信号处理 | 缩放、降噪、画质增强、HDR 映射等 | ✅ 主要可调项：切换游戏/低延迟模式、关闭增强 |
| 链路 | 线材、接口、中间设备（KVM、延长器）、无线 | ✅ 直连、缩短链路、换接口 |
| 扫描与显示 | 帧被逐行写入面板的过程 | ⚠️ 与刷新率相关，刷新率越高这一段越短 |
| 帧率不足带来的等待 | 内容帧率低时，新帧要等下一次输出 | ⚠️ 与内容帧率相关，不完全是显示器的问题 |
✅ 判断口径：同一台显示器在不同分辨率、刷新率、模式与链路下的延迟不同 —— 报一个"延迟 X ms"而不写条件，与不报没区别。
二、与响应时间、MPRT 的区别
| 指标 | 它描述的时间区间 |
|---|---|
| 输入延迟 | 从信号进入到画面出现变化 |
| 响应时间（GtG） | 像素从一个灰阶切到另一个所需时间 |
| MPRT | 人眼追踪运动物体时的等效模糊时间 |
⚠️ 库内已立结论：三者不能互相替代（见 响应时间测量）。 低延迟 + 慢响应 = 操作跟手但仍有拖影；高延迟 + 快响应 = 画面干净但手感迟滞。
三、测量方法
| 方法 | 做法 | 适用与局限 |
|---|---|---|
| 高速相机法 | 同时拍"输入动作"与"屏幕画面变化" | 通用；需要高帧率相机与同步手段 |
| 光电探头 + 信号注入 | 用专用设备注入信号，同时记录光输出变化 | 精度较好；需要设备支持 |
| 软件 / 系统法 | 借助测试工具或系统计时 | 便于比较相对差异，绝对精度有限 |
必须记录：分辨率、刷新率、模式（是否低延迟/游戏模式）、增强功能开关、VRR 状态、 链路与中间设备、内容帧率、测量方法。
⚠️ 中间设备会直接改变结论：KVM、延长器、无线方案都会引入额外延迟 （见 KVM 与多机切换）。测延迟必须直连。
四、VRR 与处理对延迟的影响
| 因素 | 对延迟的作用 |
|---|---|
| 帧率越高 | 新帧等待时间越短，端到端延迟下降 |
| VRR | 减少因固定刷新率同步带来的等待；不会让处理变快 |
| 画质增强 / 缩放 | 通常增加延迟 |
| 超高刷新率模式 | 缩短扫描与写入段时间（见 双模与超高刷新率） |
✅ 实用顺序：先换低延迟模式与直连，再看刷新率与帧率 —— 处理与链路这两段的收益通常最快见效。
五、判据怎么写
① 度量 端到端延迟（ms），写清是"信号进到画面出现"
② 统计口径 平均还是最大？是否含最差帧
③ 条件 分辨率、刷新率、模式、VRR、链路、内容帧率、测量方法与环境
④ 抽样 抽检还是逐台
⑤ 例外 仅在某种模式下达标时如何判定⚠️ 不要在判据里只写一个数字 —— 延迟与"模式 + 刷新率 + 链路"强绑定， 条件写不全的判据会在验收时无法复核。
六、会用（一）：降延迟的动手顺序（收益从快到慢）
① 切模式：游戏 / 低延迟模式（关掉大部分处理链）
② 关增强：动态对比、降噪、锐化、局部调光"演示档"、任何图像增强
③ 改链路：直连（去掉 KVM / 延长器 / 坞站 / 无线），换更短的线
④ 查刷新率：确认系统与显示器都跑在目标刷新率（并确认协商值）
⑤ 提帧率：降低画质设置让帧率进入目标区间（同时开 VRR 可减少同步等待）
⑥ 复核：改完后重测一次，并把条件一起记录⚠️ 顺序反了会白折腾：先去调刷新率，而增强项还开着 —— 处理链的耗时可能比刷新率带来的收益更大（见 图像处理与画质引擎）。
七、会用（二）：测一次可比的延迟（七步）
① 定口径：说明测的是"信号进 → 画面出现变化"的哪一段（端到端还是链路内）
② 固定条件：分辨率、刷新率、模式、增强项、VRR 状态、内容帧率
③ 直连排干扰：先直连测一次基准，再把中间设备逐个加回
④ 选方法并记录：高速相机 / 光电探头 + 信号注入 / 软件法（各注明局限）
⑤ 重复与统计：测多次，给平均与最差（不要只报最好的一次）
⑥ 与响应时间分开测：延迟与拖影是两个问题，混着测无法定位
⑦ 留证：环境、温度、预热、方法参数、原始记录✅ 一条纪律：延迟数据必须带"模式 + 刷新率 + 链路"三件套， 否则两组数据不可比（见 测量标准索引）。
原理（一）：为什么延迟一定"分段"，而且下限不为零
从操作到画面出现，信号必须走完：
输入设备采样 → 系统/驱动 → 帧生成 → 扫描输出 → 链路传输
→ 显示端处理 → 面板写入与翻转 → 光输出
每一段都有自己的固有耗时，其中"面板写入 + 翻转"与"帧生成间隔"是大头
→ 所以延迟有下限，且任何一段变慢都会叠加到总延迟上推论："降低延迟"本质是"减少经过的段数与每段的耗时" —— 这也是"直连 + 低延迟模式"最有效的机制来源。
原理（二）：为什么提高刷新率能降延迟，但不是万能的
刷新率越高 → 扫描与写入一段的时间越短，且新帧最多等待的时间越短
但帧生成的间隔由 GPU 决定：
帧率 60fps 时，一帧的产生间隔本身就有十几毫秒量级
→ 只提高刷新率而不提高帧率，收益有限（等待仍发生在帧生成侧）
→ 这也解释了"VRR 不减少处理耗时，只减少同步等待"⚠️ 所以"高刷屏延迟一定低"是过度简化：要看帧率、处理链与链路是否同步优化。
原理（三）：为什么"低延迟模式"往往要牺牲画质
低延迟的做法通常有两类：
① 跳过或简化处理（不缩放、不做复杂降噪/映射）
② 减少缓冲与队列（少等几帧再输出）
→ 代价是画质与稳定性：可能出现缩放质量下降、闪烁（帧输出不匀）、
或者在 HDR 映射上出现可见妥协
→ 所以"低延迟"与"最好的画质"通常是两条路线，按用途选八、常见误区
| 误区 | 说明 |
|---|---|
| "响应时间 1ms 就是低延迟" | 两者描述不同区间，不可互推 |
| "刷新率一样延迟就一样" | 处理与链路差异仍会造成差别 |
| "开 VRR 延迟一定最低" | VRR 改善同步等待，不改变处理耗时 |
| "软件测法可以当验收依据" | 相对比较可用，绝对值需与方法口径一致 |
| "接不接中间设备无所谓" | KVM、延长器、无线都会叠加延迟与掉档 |
| "看标称延迟就够了" | 标称值通常缺少条件说明 |
判据与可比性（本节只给接口）
✅ 延迟与"模式 + 刷新率 + 链路"强绑定，所以两组延迟数据比较前要对齐条件； 对齐清单见 测量标准索引。
📋 判据接口：本页属器件与材料类 —— 依此页结论做判定时，除通用条件外还必须附带 判据字段集 · 器件与材料类 所列字段（共 6 项）：这个结论能代表"这一批"还是只代表"这一台"？ 缺任一项，结论不可复核，只能作降级表述。
关键概念速查
通用术语见 统一速查（由统计生成，只在一处维护）。
| 术语 | 英文 | 含义 |
|---|---|---|
| 端到端延迟 | End-to-End Latency | 含链路与显示的完整链路时间 |
| 低延迟模式 | Game / Low-latency Mode | 关闭增强处理以缩短延迟 |
| 帧率上限等待 | Queue Latency | 帧率不足导致的排队时间 |
相关文档
数据来源：本页为方法论整理，不含具体延迟数值与门槛；产品数值以厂商官方资料与实测口径为准。