Fugu-MT 論文翻訳(概要): How Fast Can Reward Models Score? A Systems Study of C++ and PyTorch Inference Runtimes for RLHF

論文の概要: How Fast Can Reward Models Score? A Systems Study of C++ and PyTorch Inference Runtimes for RLHF

arxiv url: http://arxiv.org/abs/2607.19712v1
Date: Wed, 22 Jul 2026 03:27:21 GMT
ステータス: 翻訳完了
システム内更新日: 2026-07-23 18:51:37.966927
Title: How Fast Can Reward Models Score? A Systems Study of C++ and PyTorch Inference Runtimes for RLHF
Title（参考訳）: RLHFのためのC++とPyTorch推論ランタイムのシステム研究
Abstract要約: RLHFパイプラインでは、報酬スコアリングがポリシー更新をブロックする。ほとんどのセットアップはデフォルトではPyTorch eager mode または torch.compile である。我々のエンジンは全てのベースラインを破り、信頼区間も違ってはいなかった。
参考スコア（独自算出の注目度）: 0.0
License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/
Abstract: In RLHF pipelines, reward scoring blocks policy updates. Slow scoring bottlenecks the entire loop, since no update runs until every rollout gets a score. And yet most setups just default to PyTorch eager mode or torch.compile, no one checks if that's actually fastest. Scoring itself is small. Rollout generation eats far more of a typical RLHF step. But scoring and generation fight over the same CPU and GPU resources, so a faster scoring engine doesn't shrink step time on its own. It mainly frees up capacity generation can use instead. We built a native C++ inference engine on ONNX Runtime. First step: confirm correctness. Output matched the PyTorch reference to 5.7 x 10^-6 on CPU and 4.2 x 10^-3 on GPU, close enough to trust. Then we tested it against PyTorch eager mode, torch.compile, and FastAPI, on both CPU and GPU. CPU was decisive. Our engine beat every baseline, confidence intervals didn't even overlap. GPU gave a different view: we beat PyTorch and FastAPI, but torch.compile came out ahead. Further testing traced the speedup to ONNX Runtime itself, not C++ as a language. And batching strategy mattered more than either the language or the runtime choice, more than we expected. The results are from repeated, independent runs, since single runs just aren't reliable enough to trust.
Abstract（参考訳）: RLHFパイプラインでは、報酬スコアリングがポリシー更新をブロックする。ロールアウト毎にスコアが取得されるまで更新が実行されないため、スロースコアはループ全体のボトルネックとなる。しかし、ほとんどのセットアップはPyTorchのアグレッシブモードや torch.compileにデフォルトで設定されています。装飾自体は小さい。ロールアウト生成は、典型的なRLHFステップよりもはるかに多くを食べる。しかし、スコアリングと生成は同じCPUとGPUリソースを争うため、より高速なスコアリングエンジンは独自のステップタイムを縮めません。主に、代わりに使用可能なキャパシティ生成を解放する。私たちはONNX Runtime上にネイティブなC++推論エンジンを構築しました。最初のステップは、正確性を確認することです。出力はCPUでは5.7 x 10^-6、GPUでは4.2 x 10^-3とPyTorchの基準と一致した。次に、CPUとGPUの両方でPyTorchのアグレッシブモード、 torch.compile、FastAPIに対してテストしました。 CPUは決定的だった。我々のエンジンは全てのベースラインを打ち負かしたが、信頼区間は重なり合わなかった。 GPUはPyTorchとFastAPIに勝ったが、Torch.compileは先駆けて登場した。さらなるテストでは、言語としてのC++ではなく、ONNX Runtime自体にスピードアップした。そしてバッチ戦略は、言語かランタイムの選択よりも、予想以上に重要でした。単一の実行は信頼できないだけなので、結果は繰り返し、独立した実行によるものです。

関連論文リスト

KernelBench-Verified: Do LLM-Generated Kernels Actually Beat PyTorch? [13.026983194416168]
大きな言語モデル(LLM)は、KernelBenchのようなベンチマークでPyTorchを上回っているように見えるカスタムカーネルを生成することができる。 We demonstrate that frontier models often involved in reward hacking to artificially inflate performance。
論文参考訳（メタデータ） (2026-06-26T03:22:50Z)
BurTorch: Revisiting Training from First Principles by Coupling Autodiff, Math Optimization, and Systems [56.16884466478886]
BurTorchは、単一ノードワークステーション上でのディープラーニング(DL)トレーニングを最適化するために設計された、コンパクトな高性能フレームワークである。 BurTorchは最小限の設計を採用し、これらの状況下では、古典的なコンパイルされたプログラミング言語がDL研究において重要な役割を果たすことを証明している。
論文参考訳（メタデータ） (2025-03-18T00:52:12Z)
KernelBench: Can LLMs Write Efficient GPU Kernels? [36.4117525096377]
KernelBenchは、高速で正確なカーネルを記述する言語モデルの能力を評価するためのオープンソースのフレームワークである。本稿では,関数的に正しい生成カーネルの割合を計測する,新しい評価基準であるfast_pを紹介する。実験の結果,フロンティア推論モデルが最も優れているが,全体としては不足していることがわかった。
論文参考訳（メタデータ） (2025-02-14T19:30:53Z)
No Saved Kaleidosope: an 100% Jitted Neural Network Coding Language with Pythonic Syntax [0.8408735228878615]
我々は,C++,LLVM,Cudaを用いてニューラルネットワークを学習するためのjittedコンパイラを開発した。オブジェクト指向の特徴、強い型付け、データ前処理のための並列ワーカー、式のためのピソニック構文、PyTorchのようなモデル宣言、自動微分などが特徴である。
論文参考訳（メタデータ） (2024-09-17T23:15:39Z)
Green AI: A Preliminary Empirical Study on Energy Consumption in DL Models Across Different Runtime Infrastructures [56.200335252600354]
トレーニング済みのモデルを、ネイティブな開発環境とは異なる環境にデプロイするのは、一般的なプラクティスです。これにより、インフラを含むONNXや標準フォーマットとして機能するONNXなどの交換フォーマットが導入された。
論文参考訳（メタデータ） (2024-02-21T09:18:44Z)
PockEngine: Sparse and Efficient Fine-tuning in a Pocket [62.955793932377524]
さまざまなエッジデバイスで微調整が可能な,小型でスパースで効率的なエンジンであるPockEngineを紹介します。 PockEngineはスパースバックプロパゲーションをサポートし、測定メモリの節約とレイテンシの削減でモデルをスパース更新する。注目すべきなのは、PockEngineはNVIDIA Jetson AGX OrinのLLaMav2-7Bを550トークン/秒で微調整できることだ。
論文参考訳（メタデータ） (2023-10-26T19:46:11Z)
Comparative Analysis of CPU and GPU Profiling for Deep Learning Models [0.0]
本稿では、Pytorchを用いて深層ニューラルネットワークをトレーニングしながら、CPUとGPUの時間とメモリ割り当てを示す。単純なネットワークでは、CPUよりもGPUが大幅に改善されることはない。
論文参考訳（メタデータ） (2023-09-05T18:22:11Z)
TorchBench: Benchmarking PyTorch with High API Surface Coverage [9.68698340637426]
我々は、PyTorchソフトウェアスタックの性能を研究するための新しいベンチマークスイートであるTorchBenchを提案する。 TorchBenchは、PyTorchソフトウェアスタックのパフォーマンスを包括的に特徴付けることができる。本稿では,TorchBenchの実用例を2つ紹介する。
論文参考訳（メタデータ） (2023-04-27T14:37:05Z)
Enabling Multi-threading in Heterogeneous Quantum-Classical Programming Models [53.937052213390736]
量子カーネルの並列実行を可能にするために,C++ベースの並列コンストラクトを導入する。予備的な性能の結果は、カーネル毎に12スレッドのベルカーネルを2回実行し、カーネルを次々に実行する並列性能が向上したことを示している。
論文参考訳（メタデータ） (2023-01-27T06:48:37Z)
Data-Efficient Instance Segmentation with a Single GPU [88.31338435907304]
我々は2021年のVIPriors Instance Challengeで使用したデータ効率のセグメンテーション手法を紹介した。私たちのソリューションは、強力なツールボックスであるmmdetectionをベースにした、Swin Transformerの修正版です。本手法は,全競技者の2位である0.592のAP@0.50:0.95(medium)を達成した。
論文参考訳（メタデータ） (2021-10-01T07:36:20Z)
Hybrid Models for Learning to Branch [81.93868699246214]
我々はCPUマシン上で効率的な分岐を行うための新しいハイブリッドアーキテクチャを提案する。提案アーキテクチャは,GNNの表現力と分岐処理のための計算コストの低い多層パーセプトロン(MLP)を組み合わせる。
論文参考訳（メタデータ） (2020-06-26T21:03:45Z)

関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。

指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。