同じML結果に最も安く済むGPUはどれか？

許容される結果の定義を決める

テストの前に判断基準を書きましょう：「どの構成がすべてのドキュメントを処理し、最低品質を満たし、締め切り前に完了し、かつ最も低い予算で済むか？」シナリオを設定します：ここではオフラインで処理されるコーパスです。インタラクティブなアプリケーションでは、リクエストの到着、同時実行、許容されるレイテンシも定義する必要があります。そのランキングはこのテストだけから導き出せるものではありません。

検証済みコーパスとは、すべてのチェックを通過した完全な出力セットのことです。作成されたファイルは、まだ受け入れられた結果ではありません。識別子、形式、カバレッジ、および用途に関連する指標を確認してください。時間を見る前に、参照に対する閾値と許容範囲を記録しておきましょう。こうすることで、2つの構成が決定において等価でありながら、ビット単位で同一の数値を生み出さない場合もあり得ます。

データセット、品質目標、シナリオを分離する考え方は、MLPerf Inferenceの原則にも存在します。以下のプロトコルはあなたのプロジェクトに合わせて調整するための当社の作業方法であり、MLPerfの実行や認証を構成するものではありません。

技術的な出典: MLCommons — シナリオ、指標、品質目標

入力、参照、マニフェストを準備する

使用する権利のあるコーパス、参照回答または評価手順、推論コード、選択したモデルを実行できる環境が必要です。最終比較コーパスの構成を調整するために使うデータは分離してください。後者を見た後に閾値を調整する場合は、結論を裏付けるための新しい独立した評価を用意してください。

各入力に安定した識別子を付けてください。コーパスのフィンガープリント、通過順序、モデルとトークナイザーのリビジョン、コードと依存関係のバージョンを保持しましょう。マニフェストには使用したGPU、精度、量子化、コンパイル、アテンションバックエンド、パディングポリシー、最大長も記載します。切り詰め方が異なれば、比較する作業も変わってしまいます。

実際に導入されているドライバーとバックエンドを記録します。AMD のバリアントでは、公式マトリクスでシステム、GPU、ROCm、フレームワークの組み合わせを確認します。ドキュメントを参照したことやカード名は、その環境がインストールされている証拠にはなりません。2つの試行でソフトウェアスタックが異なる場合、結論はテストした構成全体に関するものになります。

技術的な出典: AMD — ROCm 互換性マトリクス

例：同じ 1,000 件のテキストを分類する

以下は、性能結果を仮定せずにご自身のデータで構築する実験です。1,000 件のテキストをプロジェクトのカテゴリに分類したいとします。短いエントリを 600 件、中間を 300 件、長いものを 100 件確保し、採用する tokenizer で境界を定義し、クラスの分布が代表的なものになるようにしてください。この分割はプロトコルの一例であり、提供されたコーパスでも、普遍的な比率の推奨でもありません。

同じモデル、同じ精度、同じ順序、同じ padding ルールで、バッチ 1、4、8 を比較してください。この最初のシリーズで唯一の変数はバッチです。2 番目のシリーズでは、他の選択を明示的に固定したまま、精度やハードウェアを変更できます。長さによるグループ化は、作業の構成を変えるため、宣言すべき新しいバリアントです。

各実行について、1,000 件の予測を識別子とともにエクスポートしてください。検証では、期待される識別子が重複も欠落もなく正確に見つかる必要があります。誤った予測は保持してください。品質の計算に役立ちます。難しい例を除外すると、スコアが人為的に良くなり、実際に処理されたコーパスが減ってしまいます。

起動、ウォームアップ、測定対象の実行を分離する

必要なダウンロード、インストール、ロード、コンパイルを、安定した処理とは別に記録してください。これらは 1 回の実行の計測から除外できますが、レンタル時間の一部は消費します。すべてのバリアントで同一のウォームアップルールを定めてください：対象となる入力、実行回数、再コンパイルの扱いです。どのバリアントが有利になるかを見た後に、このルールを調整しないでください。

主要な時間の境界を定義してください。このオフラインの例では、コーパスの読み込み、tokenization、転送、推論、ホスト上での予測の実体化を測定します。次に、評価と成果物の書き込みを別途計測し、キャンペーン全体を確定します。GPU 計算のみに限定した時間は、この処理時間と直接比較できません。

CUDA の操作は非同期です。ホスト側のタイマーは、開始前に先行する操作の完了を、停止前に測定対象の作業の完了を待つ必要があります。CUDA イベントは、適切に定義された GPU の範囲に適しています。単一の操作には、torch.utils.benchmark.Timer がウォームアップと同期を処理します。バリアント間で同じ測定境界を維持してください。

技術的な出典: PyTorch 2.14 — CUDA の非同期実行 · PyTorch — torch.utils.benchmark で測定する

繰り返して失敗も保持する

この最初の比較では、バリアントごとに 5 回の完全な実行を計画します。順序を入れ替え、例えば 1–4–8、次に 4–8–1、次に 8–1–4 とし、特定のバリアントが常に最初にならないようにします。プロセス、キャッシュ、ウォームアップの方針は維持します。この 5 回の実行は小規模な系列を記述するものであり、それだけで長期間にわたる安定性を証明するものではありません。

生の表の1行は、中断も含め、試行された1回のパスを表します。これはバリアントとコーパスを、パラメータ、所要時間、品質判定に結び付けます。expected_ids フィールドと observed_ids フィールドにはエントリ数が記録され、ids_match は集合の一致を確認するもので、別途保存された予測ファイル内で検査されます。corpus_accepted にはそのパスの判定が入ります。エラーと出力のパスは notes に記載してください。測定値が欠けている場合は、そのセルを空のままにし、理由を示します。GPU が存在しないことは、ゼロ秒やゼロバイトの測定値ではありません。

バッチ8が長い入力でメモリを超える場合は、失敗した行と完了したエントリ数を残してください。このパスを、より小さいバッチで暗黙のうちに置き換えないでください。再開の設定は別個のバリアントとなり、その時間と試行回数は集計に含まれます。中断や形式エラーは、たとえ速く終わったとしても、コスト上の成功になることは決してありません。

5 回の試行を過度に解釈せずに実行時間を読む

5 回の生の実行時間、その中央値、最小値、最大値を、成功数と失敗数とともに示します。中央値はこれらの観測の中心を表すものであり、インシデントを消し去るものではありません。文書化された外的要因により実行を除外する場合は、その記録を残し、すべてのバリアントに同じ除外ルールを適用します。

5 回の実行から計算した p95 を、遅いケースの頑健な推定値として示してはいけません。リクエストのレイテンシを調べるには、到着シナリオと同時実行数を伴う、適切な個々の時間の集合を収集します。5 回のコーパス実行時間と 1,000 リクエストのレイテンシは同じ母集団ではありません。

観測されたばらつきが中央値間の差と同程度である場合、その系列ではまだ選択肢を判別できません。共通のプロトコルで反復を追加するか、読み込み、入力形状、コンパイル、競合するアクティビティといった具体的な原因を調べてください。各カードの最良のパスだけを採用することは避けてください。

精度変更後の品質を検証する

FP32、BF16、または量子化を比較するには、同じ入力と同じ参照から出発してください。形式、主要な指標、および予定されたサブグループを評価します。許容範囲を超えるバリアントは、別の目的には興味深いかもしれませんが、後からしきい値を下げることで、同等品質の比較に加わることはありません。

使用したシードと決定論的オプションを記録してください。PyTorch は、同じシードであっても、バージョン、プラットフォーム、または CPU と GPU の実行間で完全な再現性を保証しません。したがって、何を再現しようとしているのかを明確にしてください。同一の出力、限定的な数値誤差、または許容可能な業務品質です。確率的なプロトコルでは、複数の共通シードを用意し、それらの結果を別々に保持してください。

技術的な出典: PyTorch 2.14 — 再現性の範囲と限界

メモリを実現可能性の基準として使う

ある選択肢のコストを比較する前に、その選択肢が長い入力も含めてコーパスを完了できる必要があります。デバイスごとのメモリピークとカウンタの範囲を記録してください。PyTorch では、memory_allocated はテンソルを追跡し、memory_reserved はアロケータが管理するメモリを追跡します。これらの値は合算されません。対応するピークは異なる時点で発生する可能性があります。

メモリのフォルダにあるノートブックは、推定と実測を区別するのに役立ちます。その演習は、あなたのモデルの測定に代わるものではありません。自分の環境を読み込み、パラメータを保持し、自分のワークロードを再実行してください。カードごとに公表された容量とロット価格から、スループット、相互接続、または複数 GPU へのモデルの自動分散を推測することはできません。

技術的な出典: PyTorch 2.14 — メモリカウンタとアロケータ

完全なカレンダーで期間を選ぶ

必要な期間は、GPU カーネルの合計だけではありません。レンタルの準備から成果物の回収までのアクセスウィンドウを構築してください。インストール、チェック、ウォームアップ、比較、予定された再開、評価、エクスポートです。レンタルを保持しておく必要がある待機期間も加えてください。タスクが重複する場合は、それぞれの期間を二重に足し合わせるのではなく、実際のカレンダーで考えてください。

スケジュールの例です。速度の仮定は置きません。月曜9時から金曜9時まで同じタイムゾーンで、夏時間の切り替えをまたがずにアクセスを確保したいとします。この期間は96時間です。3日間プランの72時間を超え、7日間プランの168時間内に収まります。ただし、処理が期限内に終わることを証明するものではありません。所要時間はあくまで測定が必要です。

計算ツールでは、総期間を入力でき、3日間・7日間・30日間のプランが表示されます。そのカレンダーをカバーするプランが候補になります。キャンペーンが対象期間を超える場合は、スケジュールを変更するか、必要な追加期間を明示的に見積もってください。自動延長は前提にしないでください。

プランで発生するコストを計算する

レンタルの予算は、1ロットあたりのプラン料金にロット数を掛けたものです。検証済みコーパスあたりのコストは、この総額を、提示した範囲で実際に承認された有効なコーパス数で割って算出します。承認されたコーパスが1つもなければ、この比率は未定義です。一方、発生した支出は収支に残ります。

以下の価格は当社カタログ（2026年9月24日版）によるものです。計算ルールを示すものであり、どのGPUが最も速く処理を終えるかを示すものではありません。B200の1ロットにはすでに2枚のカードが含まれます。その価格をもう一度2倍すると、カードを二重に数えることになります。例えば、RTX 4090を7日間2ロット借りると220 USD、B200 2枚を7日間1ロット借りると2,071 USDです。

短時間の実行でも、プランが時間単位の請求になるわけではありません。期間の一部が未使用でも、計算ツールはプランの総額を使用します。プロジェクト全体の予算については、他に実際に該当する支出とその根拠を別途記録してください。一方の構成で測定したコストと、もう一方で計上し忘れた項目を混ぜないでください。

技術的な出典: IteraGPU — カタログのプラン

測定の繰り返しではなく、有効な成果物を数える

同じベンチマークを5回繰り返すのは、ばらつきを観察するためです。5つのファイルが書き出されたからといって、それがそのまま5つの有用な本番コーパスになるわけではありません。キャンペーン前に期待される成果物を定義し、承認された成果物はそれぞれ一度だけ数えてください。実際の作業が複数のコーパスに及ぶ場合、各構成は同じコーパスを処理し、同じ品質ルールを適用する必要があります。

計算ツールでは、有効な成果物が実際に完成し検証されるまで、コーパス数の欄は空欄にしておいてください。品質チェックボックスはご自身の確認を確定するもので、ツールが予測やメトリクスを読み取ることはありません。確認できた数量のみを入力してください。キャンペーン期間は計画上の仮定でも構いませんが、キャパシティの予測は承認された結果の代わりにはなりません。

最終的な評価では、許容可能な各構成について、品質の判定、生の所要時間、キャンペーン期間、契約した定額プラン、および受け入れられた成果物の数をまとめます。締め切りの厳しい案件では高速な選択肢が役立つことがありますが、最も安価であるとは限りません。同じスケジュールに収まる2つの選択肢は、契約したコスト、失敗、または残存する不確実性によって優劣をつけられます。

プロトコルをダウンロードし、再利用できる証拠を残す

IteraGPU Lab v1フォルダには、この比較とメモリ測定の資料がまとまっています。まずREADMEと品質プロトコルから始め、次に生の表にご自身の実行を追加してください。パフォーマンスのセルは実行前は空欄のままです。料金はカタログデータであり、測定値とは分離されています。

RTX 4090を2基、7日間分見積もるには、calcul_forfaits.py と tarifs-forfaits.csv を同じフォルダに置き、そのフォルダでターミナルを開き、Python 3.10以上で以下のコマンドを実行します。GPU 2基に対して220.00 USDの定額プランが表示されます。任意オプションの --accepted-results には、実際に完了して検証済みの、重複のない有用なコーパスの整数を受け取ります。この実績がまだ存在しない場合は省略してください。その場合スクリプトは定額プランのみを計算し、結果あたりのコストをでっち上げることはありません。

マニフェスト、入力のハッシュ、予測、判定、試行の一覧表はまとめて保管してください。判断メモには、採用した設定、対象となる負荷、その選択理由を記載します。これはIteraGPUの台帳にあるレンタル内容と突き合わせることができ、モデルやバージョンを変更する際に同じ実験上の問いを正確に再実行できます。

このオフラインプロトコルは、それ自体で対話型サービス、収束までの学習、その他のデータセットを評価するものではありません。これらの用途では、比較する前に対象となる有効単位と検証項目を再定義してください。提供されているファイルは、試行を準備し記録するためのものです。このフォルダには、カタログ上の構成間で測定された比較や、観測された削減額は一切掲載されていません。

python calcul_forfaits.py --gpu rtx-4090 --days 7 --lots 2

• IteraGPU Lab v1 — 完全版パッケージ ↓

  スクリプト、ノートブック、表、手順書をまとめたアーカイブ。

• 品質プロトコル ↓

  試行前に定める入力、受け入れ基準、比較ルール。

• 生データ結果表 ↓

  パラメータ、測定値、判定、失敗を記録するための白紙シート。

• パッケージ料金の計算 ↓

  ロット単位の価格、3日・7日・30日の期間、検証済みコーパスを用いた予算計算。

• パッケージ料金表 ↓

  提示された計算で使用する当社カタログ価格のスナップショット。

• メモリ測定ノートブック ↓

  メモリ資料と合わせて解釈する計算と測定演習。

• メモリ計測スクリプト ↓

  演習のPython版。環境チェック付き。

• 手順と前提条件 ↓

  ツールの範囲と、それらを実行して出力を保存する手順。

• リソースのライセンス ↓

  フォルダ内のオリジナルリソースの再利用条件。