# プロトコル：コストを比較する前に、受理されたコーパスを用意する

バージョン1 — 2026年9月24日。この資料は記入用のプロトコルを提案するものであり、測定結果やデータセットは一切含みません。付属のノートブックは、合成された小さなMLPを使ってメモリの計測方法を学ぶためのものです。以下の業務プロトコルは実行しません。

## 1. 試行の前に、有用な作業を定義する

作業の例：**1,000件のテキスト**からなるコーパスを分類する。利用が許可された、自分の用途を代表するデータセットを自分で用意し、各テキストに一意の識別子と検証済みの参照を付ける。コーパス、モデル、tokenizer、コードのリビジョンとシードを固定する。監査を可能にするため、期待されるIDのリストと個々の出力を別々に保管する。

測定の前に定義する：クラス、出力形式、主要な指標（例えばmacro-F1）、その合格しきい値、参照に対する許容される最大の劣化。自分のアプリケーションに適した許容範囲を選ぶこと。ここでは普遍的な値は提供しない。訓練、調整、評価のデータは分離したままにする。

コーパスが受理されるのは、期待される1,000件のIDがちょうど1回ずつ存在し、出力に余分な回答が含まれず、形式が有効で、あらかじめ定めた品質ルールが満たされている場合のみである。それぞれ1,000行を含む2つのファイルだけでは、IDの一致を証明できない。集合と重複のチェックを保存する。

## 2. 告知した変種のみを変更する

batchを調べるには、例えば1、4、8の変種を用意する。同じコーパス、入力順序、モデル、tokenizer、精度、コンテキスト上限を維持する。次に精度を調べる場合は、別の実験を作成し、品質チェックをやり直す。切り詰めについて記述する：テキストを短くすると実行される作業が変わる。

実際のGPU、実際に使用されたGPU数、device、ドライバー、Python、PyTorch、CUDAまたはROCmのruntimeを記録する。コードのバージョン、該当する場合は生成オプション、マシン上のあらゆる競合も`notes`に記載する。2基のGPUの商用プランは、プログラムが両方を使用することを意味しない。

## 3. 比較可能なパスを測定する

タイマーが何を含むかを告知する：処理のみか、読み込み・トークン化・書き込みを含む完全なチェーンか。ロード、最初のパス、ウォームアップ済みパスを分離する。メモリのスクリプトは自分のMLPのみを測定し、完全な分類チェーンを計時しない。

告知したウォームアップを実行した後、交互または事前に抽選した順序で、変種ごとに5回の測定パスを行う。各生の所要時間を保持する。中央値と最小–最大の範囲を報告すると、ばらつきが見える。5件の観測ではp95のロバストな推定は正当化されない。エラーや遅いパスを黙って除外しない：その行を保持し、インシデントを説明する。最初のパスを同様の条件で比較したい場合は、新しいプロセスで再実行する。

PyTorchのGPU測定では、初期の記録の前と操作の後に、選択したdeviceを同期する。`allocated`と`reserved`のベースラインを記録し、ピーク統計をリセットしてから、フェーズの絶対ピークを保持する。`allocated`は`reserved`に含まれる：両者を足すとメモリの一部を二重に数えることになる。2つの最大値は異なる時点で到達しうる：その差はある時点でのキャッシュの測定値ではない。他のプロセスの割り当てや、PyTorchアロケーター外の割り当ては対象外である。

## 4. resultats-bruts.csvを記入する

配布されるCSVにはヘッダーのみが含まれる。1パスにつき1行を書き、時間には小数点と秒、メモリにはバイト、プランにはUSドルのセントを用いる。空のセルは「未記録」を意味し、ゼロは実際にゼロを意味する。ノートに含まれるカンマは、通常のCSV規則で保護しなければならない。

| フィールド | 意味と入力 |
| --- | --- |
| `experiment_id`, `variant_id` | 実験とバリアントの安定した識別子。 |
| `corpus_revision`, `model_revision`, `tokenizer_revision`, `seed` | 不変のバージョンまたはハッシュ、および公表されたシード。 |
| `gpu_model`, `gpu_count`, `device`, `driver_version`, `python_version`, `torch_version`, `runtime_version` | 実際に使用されたハードウェアと観測された環境。オファーの約束事をそのまま転記しないこと。 |
| `precision`, `batch`, `context` | 実際に適用された構成。 |
| `phase`, `run_index`, `warmup_iterations` | 分離されたフェーズ（例えば `cold` または `warm`）、実行番号、ウォームアップ回数。所要時間を混在させないこと。 |
| `expected_ids`, `observed_ids` | 期待される ID 数と観測された ID 数。詳細なリストは出力とともに保持します。 |
| `ids_match`, `format_valid` | 実際の検証後の `true`/`false`。重複や余分な回答も含みます。 |
| `quality_metric`, `quality_threshold`, `quality_tolerance`, `quality_value` | 事前に定めた名前、閾値、許容範囲、そして測定値。許容範囲の意味と基準を `notes` に明記してください。 |
| `corpus_accepted` | すべての検証条件を満たす場合のみ `true`、そうでなければ `false`。 |
| `elapsed_seconds` | 公表された範囲の生の所要時間。決して期待値ではありません。 |
| `baseline_allocated_bytes`, `baseline_reserved_bytes`, `peak_allocated_bytes`, `peak_reserved_bytes` | 測定対象の device のみに対する個別の測定値。測定していない場合は空欄のままにしてください。 |
| `duration_days`, `lots`, `package_total_usd_minor` | 選択した完全なパッケージ、請求されるロット、および USD セント単位の合計価格。一つの支出を五回加算してはいけません。 |
| `accepted_unique_corpora` | 経済分析のために受け入れられた、重複のない有用なコーパスの数。このフィールドは繰り返し間で合計してはいけません。 |
| `notes` | 範囲、インシデント、品質に関する決定、コードのリビジョン、および保存された証拠の参照。 |

## 5. 成果をでっち上げずに計算する

比較すべき価格は、3日、7日、または30日のパッケージ全体にロット数を掛けたものです。B200 の場合、1ロットには2つの GPU が含まれ、料金はすでにそのロットをカバーしています。`calcul_forfaits.py` はこのルールを提供された料金に適用します。

選択した有用な作業が受け入れられた完全なコーパスである場合、`--accepted-results` にはその期間に実際に検証された重複のないコーパスの数を受け取る必要があります。同じコーパスの5回の繰り返しは変動性を測定するためのものであり、5つの有用な成果物を生み出すものではありません。比較の前に単位を定め、すべてのバリアントでそれを維持してください。測定され受け入れられた数量がない場合は、このパラメータを省略してください。その場合、パッケージのコストのみが計算されます。3日、7日、または30日にわたるペースを自動的に外挿しないでください。

記入済みのプロトコル、個別の出力、品質チェック、生の CSV、および経済計算を一緒に保管してください。より高速でも受け入れられない構成は、同じ目的を満たしません。メモリを超える構成は失敗の観測のままであり、ゼロに置き換えるべき時間ではありません。