硬件测量纪律：什么让一个数字可信

核验于 2026-10-292 分钟阅读

比较之前先固定 build、驱动、电源计划与温度，报告分位数而不是均值，并保留原始数据。

测试环境Pro (26H2) / Server · 版本号 26300.9457 / 26100.33650 · x64

版本号: 26300.9457 / 26100.33650
版本: Pro (26H2) / Server
架构: x64
支持: 文档（E1）
证据: E1官方文档
核验日期: 2026-10-29
页面类型: 方法

一句话结论

硬件数字只有在固定五件事、报告三件事时才有意义：

固定：build、驱动版本、电源计划、环境/温度状态、负载。

报告：分布（不是均值）、方法（怎么采的）、环境（什么机器、什么设置）。

多数“这个更快”的说法至少在三项上不成立。

最容易被忘的五个变量

变量	为什么改变结果
Windows build	调度器、电源行为、驱动模型在版本间会变
驱动版本	显卡驱动会改频率与帧节奏
电源计划/模式	最小处理器状态与加速影响持续频率
温度	冷的机器比热的机器加速更高
后台负载	Windows Update、索引、同步客户端

两次运行只要有一项不同，你测的就是两台不同的机器。

报告分布，不是均值

对交互型负载（游戏、UI、音频），均值会掩盖问题：

报告 1% low / 99 分位帧时间，不只是平均 FPS；
报告最差帧时间，因为一次 200ms 卡顿才是用户感知到的；
吞吐型负载报告多轮的中位数与离散度，不是最好那次。

“平均 120 帧”和“中位 120 帧但 1% low 只有 40 帧”，均值相同，体验完全不同。

最小可复现协议

固定环境：build（winver）、驱动版本、电源计划、室温、关闭后台应用。
按固定时长预热，让频率与温度稳定。
同一负载跑 3 次，保留每一次，不是最好那次。
用真正的工具采集——WPT（wpr/wpa）、性能计数器，或负载自带的帧时间日志。任务管理器是指示器，不是测量。
报告多次运行的中位数与离散度，以及最差情况。
只改一个变量，整套协议重跑。

Get-Counter '\Processor Information(_Total)\% Processor Performance',
            '\Processor Information(_Total)\% of Maximum Frequency',
            '\Memory\Available MBytes' -MaxSamples 60 -SampleInterval 1 |
  Export-Counter -Path "$env:TEMP\run1.blg" -Force

Export-Counter 产出可重新打开的 .blg——这是“数据”和“我记得是个什么数”的区别。

测量常错在哪

失败	报告里的症状
跨驱动版本比较	“新驱动快 15%”，但没固定版本
冷机比热机	第一轮最快，之后变慢，被叫作“降频”
只报最好一次	没人能复现的数字
场景/关卡不同	无法解释的巨大方差
虚拟机结果当裸机	数字看似合理，结论错误
不留原始数据	无法复核方法

本站怎么做

E1 页面引用文档，不做性能声明。
E2 页面报告固定 PVE 模板中的观察，并写明宿主/来宾配置。
任何帧率、温度、功耗数字都在硬件进了实验室之后才发布。

证据等级（E1/E2/E3、M-V/M-P）与快照保留方式见实验方法。

实验室边界

E1。工具与计数器行为有微软文档依据。本文只讲方法，本身不含任何测量。