ベンチマークモデル

dispatchatlas.bench は、ソルバーやキャンペーンが消費する前にベンチマーク証拠を定義します。 ベンチマークファミリは、その分類法、ドメインプロファイル、プロファイルクラス、前提、引用 証拠、スケールエンベロープ、シード名前空間、および出力スキーマを宣言します。具現化は生成 された各問題を dispatchatlas.core で検証し、インスタンスを特徴づけ、来歴エンベロープで 包み、安定ハッシュを記録します。

カタログは、汎用の組合せ-最適化スケジューリングファミリと distributed-computing スケジ ューリングをco-equalな同位として網羅するため、プラットフォームは distributed-computing 専用ツールではありません。

実行可能な例： examples/benchmark_continuum.py は連続体ベンチマークアトラスをその場で生成・特徴づけ・カタログ化します。

スケジューリングファミリ

各スケジューリングファミリは、少なくとも1つの生成器プロファイルを持つ一級カタログ同位と して具現化されます。下のカタログ表はベンチマーク生成器レジストリと引用マトリクスから生成 されるため、そのファミリ合計とソース引用は行そのものから数えられます。表の上にあるファミリ分布グラフは、ファミリプロファイルがスケジューリングファミリのカテゴリにどのように分布しているかを示します。

上のコンポーネントは完全な生成インベントリを担います——下の古典および distributed-computing コアファミリに加え、Edge–Fog–Cloud ファミリの連続体です。それらの基礎的コアファミリを ドキュメント形式で：

非関連機械および柔軟 job-shop ファミリは各インスタンスに CostModel 実行時間マトリクスを 付加し、問題 JSON と共に具現化マトリクスとしてエクスポートします。順序依存セットアップ フローショップファミリは代わりに CostModel セットアップマトリクスを付加します：機械上で 異なるファミリのジョブ間の切替はセットアップ時間を要するため、セットアップ目的は類似ジョブ のグループ化を報います。挙げられた具名の標準コーパスは引用とリンクのみで、リポジトリ内で 再配布されることは決してありません。

いくつかの連続体ファミリはマルチ-資源協調割当を行使します：各タスクは同時に複数の資源を 要求し、コンストラクタはその全期間それらを一緒に保持します（ドメイン契約 を参照）。accelerator-coscheduling ファミリはジョブごとに計算ノードと希少アクセラレータ を協調割当します；distributed-transaction ファミリはトランザクションごとにデータシャード の可変-基数ロックセットを協調割当します；そして fpga-partitioning ファミリはテナント カーネルごとに再構成可能ファブリックタイルの空間的に連続した連なりを協調割当します。資源 集合が交差するタスクは直列化し、互いに素なタスクは並行して走ります——実行可能な examples/inspect_coallocation.py がそのレバーを明示します。

協調割当を超えて、3つの連続体ファミリがそれぞれ独自の構造的レバーを行使します。 elastic-serverless-autoscale ファミリは成形可能実行を行使します：各関数呼出は複数の 実行モードを宣言します——狭い在宅のみモードと、より早く終えるために小さな共有バースト プールから worker を借りる広いモード——そのためスケジュールはタスクごとに1モードを選び、 順序がどの呼出が希少な広-かつ-速モードを獲得するかを決めます。distributed-training-gang ファミリはギャング協調スケジューリングを行使します：同期データ-並列訓練ジョブの workers はギャングを共有し、オール・オア・ナッシングの起動で異なるアクセラレータ上で共起動せねば なりません——workers はアクセラレータプールを再利用しジョブは時間とともに到着するため、 十分なアクセラレータが同時に空くまでジョブは開始できず、順序がどのジョブが最初にその完全な worker 集合を獲得するかを決めます。multi-tenant-fair-share ファミリは支配-資源公平性を 行使します：複数の非対称-規模のテナントが共有ノードプール上に配置-柔軟なタスクを置き、 支配-資源-シェア目的が最も多く-および最も少なく-供給されたテナントの支配シェア間の広がりを 採点します——そのため配置、すなわち各テナントがどの資源を占めるかが、それを均衡させるか歪め るレバーです。実行可能な examples/serverless_autoscale_study.py、 examples/distributed_training_gang_study.py、 および examples/multi_tenant_fairshare_study.py がこれら3つのレバーを明示します。

プロファイルクラス

証拠ラベル

スモークカタログは決して最終評価証拠ではありません。それらは生成器、検証、特徴づけ、引用 チェック、永続化が素早く機能することを証明するために存在します。ポータルカタログとダウン ロードはこの小さなスモークスケール（三-資源プール）で各連続体ファミリをプレビューします； 協調割当ファミリはこれほど小さなプールでは互いに素-資源並列性を示せないため、その特徴的構造 は研究-スケール特性です。build_continuum_full_catalog() は各ファミリをその宣言された研究 スケールで具現化します——協調割当、競合、配置構造が真に現れる、より大きな資源プールとタスク 数で——研究-グレードのベンチマークバンドルのために。

分類法

分類法はスケジューリング構造、環境、インフラ現実性、目的特徴、制約特徴、不確実性、および 動性を網羅します。例には DAG ワークフロー、独立タスクバッチ、serverless 関数、コンテナ および VM 統合、edge および cloud 環境、公開トレース、多-目的最適化、deadline、データ 局所性、churn、動的到着が含まれます。

引用マトリクス

ベンチマーク主張は CitationMatrix に対してチェックされます。候補および完全キャンペーン 証拠-グレード主張は、引用-裏付けソースを参照しない限り検証に失敗します。裏付けのない素材は 証拠が追加されるまで exploratory のままでなければなりません。

ソース集合は default_citation_matrix() で、安定したソース識別子、解決可能な参照、記録 されたライセンス姿勢とともに宣言されます。3つの層にまたがります：標準的な組合せ-最適化 コーパス（引用とリンクのみ、決してバンドルされない）、本番クラスタトレース、そして広範な 当代の実世界 Edge–Fog–Cloud-連続体データセット——GPU および machine-learning クラスタ トレース、マイクロサービスおよび serverless ベンチマークスイート、科学-ワークフロー トレース、スーパーコンピュータジョブトレース、edge-placement およびモビリティデータセット、 IoT およびセルラー-需要データセット、グリッド炭素およびエネルギー信号、ストリーム-処理 ワークロード、federated-learning デバイス-参加ベンチマーク、拡張-現実システムテストベッド、 および低-地球-軌道衛星-ネットワークトレース：

正準参照スイート

default_reference_suites() のレジストリは、各汎用スケジューリングファミリが係留する 正準の公刊インスタンススイートを記録します：識別子、ファミリ、インスタンス数、取得 ポインタ、およびそのスイートの境界を公表する最良-既知-解トラッカー。古典スイートは 引用とリンクのみです——DispatchAtlas がサードパーティのインスタンスファイルをバンドル または再配布することは決してありません。

バンドルされたパーサを持つスイート（標準 job-shop テキスト、Taillard フローショップ 行列、.fjs 柔軟 job-shop、WfCommons WfFormat JSON）は、オペレーターがダウンロード してローカルの resources/ ツリー下に配置したファイルから load_reference_suite(suite_id, instances_root=...) で取り込まれます。取り込みは完全に オフラインで走り、合成生成器と同じ検証、特徴づけ、ハッシュ化、来歴エンベロープを再利用 し、各問題にその suite_id と upstream_instance_id を刻印します。レジストリ-のみの スイートは、バンドルされたパーサなしに、その引用と取得ポインタとともに記録されます。

最良-既知-解レジストリ

インスタンス-毎の最良-既知値が DispatchAtlas とともに出荷されることは決してありません。 オペレーターはそれらを、プライベートな resources/benchmarks/bks/ ディレクトリ下の JSON ファイルとして、スイートごとに1ファイルで取り込みます。各ファイルは schema_version、suite_id、トラッカーの source_id、取得日、および値エントリ （インスタンス識別子、目的、値、最適-または-上界の種別、任意の下界）を運びます。 load_best_known_registry はすべてのファイルを参照スイートと引用マトリクスに対して 検証し、未知のスイート、未知のトラッカー、重複エントリ、または不整合な境界に対して 閉じて失敗します。取り込まれたレジストリなしでは、相対-乖離メトリックは単に利用不能 です——それらが部分的に計算されることは決してなく、いかなる公開面にも最良-既知値は 現れません。

較正乖離

合成の汎用ファミリは、その生成スキームを再現すると主張することなく、正準スイートに 係留されます。既知の乖離は隠されるのではなく文書化されます：

公刊慣行に対する比較は、合成ファミリを通じてではなく、取り込まれた正準インスタンスを 経由します。

特徴づけ

各具現化問題は以下についての正規化記述子を受け取ります：

• 機会密度
• 互換性疎性
• 競合と過負荷
• 依存深度
• 通信圧力
• セットアップ強度
• 負荷偏りと異質性
• 目的衝突
• 不確実性と動性
• ソルバー感度

現実-ギャップ橋渡し

各完全キャンペーン証拠-グレードプロファイルは現実-ギャップ橋渡しを宣言します：その状態 （synthetic、calibrated-synthetic、trace-backed、または externally-sourced）、 較正証拠、ドメインシナリオ、移行と擾乱カバレッジ、および残余現実-ギャップリスク。完全 キャンペーン証拠グレードへの昇格は、移行と擾乱カバレッジが宣言されない限り閉じて失敗し、 calibrated-synthetic プロファイルは較正対象の trace-backed 参照を命名せねばなりません。 Calibrated-synthetic ファミリはそのトレース参照を明示的に命名します；取り込まれた正準 スイートは externally-sourced 橋渡しを運び、WfCommons アダプタは最初の外部-解析 trace-backed インスタンスソースであり、distribution_distance_score に実 trace-backed 参照の 脚を与えます。

具名の較正メトリックは、calibrated-synthetic プロファイルの特徴づけ特徴分布とその trace-backed 参照インスタンスのそれとの間の特徴-毎の 1-Wasserstein（土運び）距離を報告 します。特徴-毎の距離は単一の現実-ギャップスコアに集約されます；最大-乖離しきい値（既定 0.25）を超えるスコアは、プロファイルがその参照から離れすぎて漂流し較正に失敗したことを 意味します。メトリックは具現化インスタンスと具名の参照トレースから再現可能です。

from dispatchatlas.bench import (
    build_smoke_catalog,
    metrics_from_instance_set,
    distribution_distance_score,
)
 
catalogs = {c.config.profile_id: c for c in build_smoke_catalog()}
synthetic = metrics_from_instance_set(catalogs["cloud-edge-capacity"])
reference = metrics_from_instance_set(catalogs["workflow-dag"])
score = distribution_distance_score(
    synthetic, reference, reference_trace_id="google-cluster-data"
)

層別化とサブセット選択

difficulty_score は競合、過負荷、依存-深度、ソルバー-感度記述子を正規化難易度スコアに 集約し、stratify_instances は具現化インスタンスを低、中、高難易度層にビン分けします。 select_benchmark_subset はファミリ、プロファイルクラス、難易度層でフィルタした決定論的 サブセットを、問題識別子順に選び、選択を再現可能にします。

スモークカタログ

from dispatchatlas.bench import build_smoke_catalog, smoke_benchmark_provider
 
catalogs = build_smoke_catalog(root_seed=20260527)
provider = smoke_benchmark_provider(root_seed=20260527)
 
first_problem = provider.get_problem(provider.list_problem_ids()[0])

バンドルされたスモークカタログは、2つの distributed-computing ファミリ（cloud/edge 独立-タスクと workflow DAG）を、14の汎用スケジューリングファミリ（機械スケジューリング、 job-shop、柔軟 job-shop、順列フローショップ、順序依存セットアップフローショップ、RCPSP、オープンショップ、ハイブリッドフローショップ、分散順列フローショップ、ノーウェイトフローショップ、ブロッキングフローショップ、分散組立フローショップ、多目的順列フローショップ、RCPSP/max） とco-equalな同位として含みます。各インスタンスはルートシードから決定論的であり、引用-裏付け 生成器メタデータを用いつつ、スモーク開発素材としてラベル付けされたままです。

候補完全カタログ

候補完全キャンペーンカタログは、より大きな設定問題数とより厳格な証拠ラベルで同じ具現化 パスを用います：

from dispatchatlas.bench import build_full_catalog, full_benchmark_provider
 
catalogs = build_full_catalog(root_seed=2026052713, problem_count_per_profile=30)
provider = full_benchmark_provider(
    root_seed=2026052713,
    problem_count_per_profile=30,
)

それらの完全キャンペーン証拠-グレードカタログは引用-裏付け、特徴づけ済み、ハッシュ-リンク 済みであり、キャンペーン、開示、公開ゲートが特定の主張を昇格させるまでは較正証拠として ラベル付けされたままです。