AIベンチの条件を固定する方法――CPU固定が効かない罠と実測の残し方

ガジェット・周辺機器を描いたアイキャッチ画像

AIベンチの差を比べる前に、同時実行、CPU、メモリ上限、実行時の版を固定する必要があります。ここで確認できたのは、固定条件をまとめるラッパのself-testまでです。同条件で2回以上の本番ベンチを流した結果はありません。 そのため、速度や品質の比較結果は示さず、実行前に何を固定し、何を記録するかへ範囲を絞ります。

目次

比較前に固定する4点

揺れ 固定する内容 記録
同時実行 ほかのベンチを並走させない run開始・終了時刻
CPU 同じCPU集合 taskset -pcの実効mask
メモリ 同じHigh/Max systemd scopeのproperty
実行物 同じCLI版・git HEAD・fixture manifest JSON

CPU固定は終了コード0だけで合格にしない

tasksetを付けたコマンドが成功しても、子プロセスが想定したCPU集合で動いた証拠にはなりません。scopeを起動した後、対象PIDの実効affinityを読みます。

taskset -pc <BENCHMARK_PID>

期待するCPU集合と一致しなければ、そのrunは比較対象から外します。記事作成時に実測runのPID記録は残っていないため、実効maskの値は補いません。

固定条件を1行で起動する

公開面のコピー処理で継続行が欠けないよう、実行コマンドは1行にします。<RUNNER>は、読者が実際のベンチコマンドへ置き換える箇所です。

taskset -c 0-7 systemd-run --user --scope -q -p MemoryHigh=8G -p MemoryMax=12G -p CPUQuota=800% -- <RUNNER>

この値は元記事のself-test条件であり、すべてのマシンへの推奨値ではありません。8論理CPU未満、または12GiBを確保できない環境ではそのまま使えません。

runごとにmanifestを残す

{
  "runner": "<exact command or script hash>",
  "cpu_list_requested": "0-7",
  "cpu_list_effective": "<taskset readback>",
  "memory_high": "8G",
  "memory_max": "12G",
  "cpu_quota": "800%",
  "cli_version": "<version output>",
  "git_head": "<commit>",
  "started_at_utc": "<timestamp>",
  "finished_at_utc": "<timestamp>",
  "exit_code": "<integer>"
}

未入力欄を推測で埋めません。比較表へ入れるのは、同じfixture、同じ固定条件、終了コード、出力検証が揃ったrunだけです。

self-testで確認できた範囲

元の再現パックに残っている終端は次の5行です。

fixture_verification=PASS
fixture_exit_code=0
host_exit_code=0
host_output_verification=PASS
overall_verification=PASS

これはfixtureとホスト側の検査が通った記録です。モデルA/Bの性能差、同条件2回のばらつき、長時間runの安定性を示すものではありません。

比較結果として採用する条件

  1. 同じfixtureとrunner hashである。
  2. 実効CPU maskとsystemd propertyをreadbackできる。
  3. 同時実行がない。
  4. 各候補を最低2回流し、runごとの生結果を保存する。
  5. 終了コード0だけでなく、出力の意味検証がPASSになる。

以前掲載していた汎用host-status probeは、AIベンチの固定条件を再現しないため削除しました。現時点の結論は、比較を始められる前提をself-testしたところまでです。

この検証を回している環境

この検証は、自宅の常設ラボ(使い捨てVM/LXCを回す母艦+GPU+VLAN分離ネットワーク)で動かしています。使っている機材と選定理由、全体構成は1本にまとめています。

ラボ構成のまとめを見る →
よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次