论文页面 - 奖励模型评分能有多快？C++ 与 PyTorch 推理运行时在 RLHF 中的系统研究

来源: https://huggingface.co/papers/2607.19712

摘要

在 RLHF 流程中，奖励评分环节会阻塞策略更新。由于所有 rollout 必须获得评分后才能进行更新，缓慢的评分过程会拖慢整个循环。然而，大多数方案直接默认使用 PyTorch eager 模式或 torch.compile，没有人去检查这是否真的是最快的方案。评分任务本身很小，rollout 生成在典型的 RLHF 步骤中消耗的资源远多于评分。但评分和生成会争夺相同的 CPU 和 GPU 资源，因此更快的评分引擎本身并不能缩短步骤时间，主要作用是释放出生成任务可以利用的容量。我们基于 ONNX Runtime 构建了一个原生 C++ 推理引擎。第一步：确认正确性。输出与 PyTorch 参考结果的差异在 CPU 上为 5.7×10⁻⁶，在 GPU 上为 4.2×10⁻³，精度足够可信。接着，我们在 CPU 和 GPU 上分别对 PyTorch eager 模式、torch.compile 和 FastAPI 进行了对比测试。CPU 上的结果具有决定性：我们的引擎击败了所有基线，置信区间完全没有重叠。GPU 上情况不同：我们优于 PyTorch 和 FastAPI，但 torch.compile 更胜一筹。进一步测试表明，加速来自 ONNX Runtime 本身，而非 C++ 语言。而且，批处理策略的影响比语言或运行时选择更大，远超我们的预期。由于单次运行结果不可靠，所有结果均来自重复的独立运行。

查看 arXiv 页面 (https://arxiv.org/abs/2607.19712)
查看 PDF (https://arxiv.org/pdf/2607.19712)
项目页面 (https://arxiv.org/abs/2607.19712)
GitHub (https://github.com/vishnup22/reward-model-benchmarks)
添加到收藏 (https://huggingface.co/login?next=%2Fpapers%2F2607.19712)

在您的代理中获取此论文：

hf papers read 2607.19712

没有最新的 CLI？curl -LsSf https://hf.co/cli/install.sh | bash

引用此论文的模型 0

没有模型链接此论文

在模型 README.md 中引用 arxiv.org/abs/2607.19712 以从此页面链接。

引用此论文的数据集 0

没有数据集链接此论文

在数据集 README.md 中引用 arxiv.org/abs/2607.19712 以从此页面链接。

引用此论文的 Space 0

没有 Space 链接此论文

在 Space README.md 中引用 arxiv.org/abs/2607.19712 以从此页面链接。

包含此论文的收藏集 1