FAIRChem Benchmark 模块从 fp64 基线到指标报告的推理校验链路【免费下载链接】ocpFAIR Chemistrys library of machine learning methods for chemistry项目地址: https://gitcode.com/GitHub_Trending/oc/ocp你给模型换了 fp16 推理配置、打开了activation_checkpointingqps确实上去了——但没人告诉你能量误差是不是悄悄漂了 0.05 eV。FAIR Chemistry 的fairchem库包名fairchem-core里components/benchmark模块就是干这件事的它把推理性能基准测试拆成「fp64 高精度基线 候选配置对比」两步自动算出force_mae、energy_abs_error、qps这类精度与速度指标再落盘成 JSON 报告。本文带你从一条fairchem命令跑通推理基准测试看懂数据怎么从基线流到最终指标再挑对 runner 和 reducer。这里有个边界它不覆盖训练配方调参、也不接 LAMMPS 动力学循环只回答这套推理/训练配置精度掉没掉、快了多少。从一条命令拿到 force_mae 与 qps最短路径是装好包、指向现成配置直接跑# 安装核心包自带 fairchem CLI pip install fairchem-core # 跑一次推理基准测试fp64 基线 vs 默认候选配置 fairchem -c configs/uma/benchmark/perf_check/benchmark.yaml要验证某个具体改动比如开tf32torch.compile直接用命令行覆盖inference_settings字段不用改任何 YAMLfairchem -c configs/uma/benchmark/perf_check/benchmark.yaml \ runner.inference_settings.tf32True \ runner.inference_settings.compileTrue这两段代码里benchmark.yaml只负责声明用哪个 runner、哪套推理设置fairchemCLI 通过 Hydra 的_target_把这些键实例化成PerfCheckRunner。warmup_iters默认 10是预热轮数、不计入计时timed_iters默认 50才真正计时算qps。新手最容易踩的坑fp64 基线是缓存在磁盘上的run_dir/baseline_cache.json换配置时它会被静默复用——如果你怀疑基线不对得确认缓存的cache_key是否匹配而不是重新算。一次基准测试的完整数据流整条链路实现在 perf_check.py按数据流动顺序看是四步建系统 → 算基线 → 跑候选 → 出报告。fp64 基线怎么被算出来并缓存PerfCheckRunner启动时用get_default_benchmark_systems()生成四个内置测试系统水盒子、200/1000 原子 FCC 晶体、slab 吸附不需要任何真实数据集。随后用一套写死的高精度设置BASELINE_SETTINGSbase_precision_dtypetorch.float64、关闭所有优化对每个系统跑一遍run_inference。结果按checkpoint 系统 device seed哈希成cache_key首次落盘、后续命中即复用。这么做的原因fp64 前向很慢而它只是金标准没必要每次重算。候选配置怎么跑、误差怎么对齐接着对同一批系统用你在inference_settings里给的候选设置再跑一遍这次带上warmup_iters和timed_iters于是run_inference会额外返回qps和峰值显存。compare_results(baseline, candidate)把两份InferenceResult逐字段相减得到能量绝对误差、力的 MAE 与 max error、应力误差候选侧的性能指标直接透传。# compare_results(baseline, candidate) 返回的单个系统指标 { energy_abs_error: 3.2e-04, # eV force_mae: 0.0021, # eV/Å force_max_error: 0.014, # eV/Å qps: 47.3, # 查询/秒 peak_gpu_memory_mb: 8122.0, }这里有个细节候选跑挂 OOM 时不会整体崩溃而是给该系统写{error: OOM}继续下一个方便一次跑出到多大量级会 OOM的边界。指标怎么从预测落盘成报告最后format_report_table把各系统指标拼成一张人类可读的表打到日志完整结果连同inference_settings序列化进results_dir/benchmark_report.json。如果你要的是下游属性弹性张量、吸附能、热导率而不是推理本身换用CalculateRunnerBenchmarkReducer的组合reducer 的join_results用 glob 把分片结果拼回 DataFramecompute_metrics对公共列算 MAElog_metrics再推到 WB这一套在 benchmark reducer 里JsonDFReducer已把大部分样板代码写好了。三种 Runner 与 Reducer 怎么选benchmark子模块里可实例化的入口分两类测推理/训练过程的 Runner和测下游属性的 Reducer。组件适用场景输入要求关键限制一句话总结PerfCheckRunner单配置推理精度速度校验预训练 checkpoint只用 4 个内置系统最轻量的改配置有没有劣化检查MixedPerfCheckRunner混合 batch 大小的真实吞吐预训练 checkpoint依赖SystemPool池化、较慢测真实负载下的samples/sTrainingBenchmarkRunner训练保真 吞吐bf16 vs fp32内层训练配置 自动假数据需指定training_config一条命令对比混合精度训练JsonDFReducer及各专用 Reducer下游属性 leaderboard 指标真实 target 数据文件必须下载对应目标数据算 MAE 等可提交榜单的指标对号入座只想确认我开的优化没让精度崩选PerfCheckRunner几分钟跑完要评估生产环境多种结构、多 batch 混跑的吞吐曲线选MixedPerfCheckRunner注意它的oom_policy默认是skip要量化训练侧 bf16 的 loss/梯度相对误差用TrainingBenchmarkRunner并runner.bf16True。硬限制要记牢前两者都不吃你的真实数据集指标只反映数值保真与速度而所有 Reducer 都强依赖target_data_path指向的参考数据没下载就跳过算分日志会提示evaluation labels not available。接入训练闭环与高频排坑衔接点有三处。接 CLIfairchem入口在 src/fairchem/core/_cli.py任何带_target_的 YAML 都能直接跑benchmark 配置遵循job/runner/reducer三段式。接日志job.logger指向WandBSingletonLoggerlog_metrics会把指标 DataFrame 推到 WB 面板和训练指标放同一 project 便于对比。接结果读run_dir下的benchmark_report.json或{benchmark_name}_metrics.json.gz即可拿到结构化数值。# 接 WB把基准指标和训练放同一 project 便于横向对比 job: logger: _target_: fairchem.core.common.logger.WandBSingletonLogger.init_wandb _partial_: true project: uma-benchmarks高频排坑现象换候选配置后误差为 0、怀疑没生效 →原因命中了 fp64 基线缓存cache_key没变 →解法确认inference_settings确实变了必要时检查run_dir里的baseline_cache.json时间戳。现象fairchem报Found unused keys in the config→原因YAML 里有没被任何${}引用的顶层键 →解法删掉多余键或确保它是被引用的变量。现象Reducer 阶段日志提示跳过指标计算 →原因target_data_path没指向有效文件 →解法下载对应 benchmark 的目标数据后重跑或先只用 Runner 看精度。现象MixedPerfCheckRunner某些 batch 直接消失 →原因oom_policyskip记下了 OOM 的 batch size →解法看报告里的oom_batch_sizes定位显存上限或调小pool_size_buckets。现象qps数值比预期低一个量级 →原因timed_iters太短、单次计时被初始化主导 →解法把runner.timed_iters提到 50 以上让预热充分。【免费下载链接】ocpFAIR Chemistrys library of machine learning methods for chemistry项目地址: https://gitcode.com/GitHub_Trending/oc/ocp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考