Model Benchmark

dispatchatlas.bench mendefinisikan bukti benchmark sebelum solver atau kampanye mengonsumsinya. Sebuah famili benchmark mendeklarasikan taksonomi, profil domain, kelas profil, asumsi, bukti sitasi, amplop skala, ruang-nama benih, dan skema keluarannya. Materialisasi memvalidasi setiap masalah yang dihasilkan dengan dispatchatlas.core, mengkarakterisasi instans, membungkusnya dalam amplop provenans, dan mencatat hash stabil.

Katalog mencakup famili penjadwalan optimisasi-kombinatorial generik dan penjadwalan distributed-computing sebagai rekan co-equal, sehingga platform bukan alat hanya-distributed-computing.

Contoh yang dapat dijalankan: examples/benchmark_continuum.py menghasilkan, mengkarakterisasi, dan mengatalogkan atlas benchmark kontinum secara langsung.

Famili Penjadwalan

Setiap famili penjadwalan dimaterialisasi sebagai rekan katalog kelas-satu dengan setidaknya satu profil generator. Tabel katalog di bawah dihasilkan dari registri generator benchmark dan matriks sitasi, sehingga total famili dan sitasi sumbernya dapat dihitung dari baris itu sendiri. Sebuah diagram distribusi-famili di atas tabel menunjukkan bagaimana profil famili tersebar di seluruh kategori famili-penjadwalan.

Komponen di atas membawa inventaris yang dihasilkan lengkap — famili inti klasik dan distributed-computing di bawah ditambah kontinum famili Edge–Fog–Cloud. Famili inti fondasional itu dalam bentuk dokumen:

Famili mesin-tak-terkait dan job-shop fleksibel melampirkan matriks waktu-eksekusi CostModel ke setiap instans, diekspor sebagai matriks termaterialisasi di samping JSON masalah. Famili flow-shop setup bergantung-urutan justru melampirkan matriks setup CostModel: pergantian antara pekerjaan dari famili berbeda pada satu mesin memakan waktu setup, sehingga tujuan setup memberi ganjaran pengelompokan pekerjaan serupa. Korpus standar bernama yang disebutkan hanya disitasi dan ditautkan dan tidak pernah didistribusikan-ulang di dalam repositori.

Beberapa famili kontinum melatih ko-alokasi multi-sumber-daya: setiap tugas menuntut lebih dari satu sumber daya sekaligus dan konstruktor menahannya bersama selama seluruh durasinya (lihat Kontrak Domain). Famili accelerator-coscheduling meng-ko-alokasi sebuah node komputasi dan sebuah akselerator langka per pekerjaan; famili distributed-transaction meng-ko-alokasi sebuah set kunci kardinalitas-variabel dari shard data per transaksi; dan famili fpga-partitioning meng-ko-alokasi sebuah deret ubin fabric-rekonfigurabel yang kontigu secara spasial per kernel penyewa. Tugas yang set sumber dayanya berpotongan terserialisasi sementara tugas yang lepas berjalan bersamaan — yang dapat dijalankan examples/inspect_coallocation.py membuat tuasnya eksplisit.

Di luar ko-alokasi, tiga famili kontinum melatih tuas strukturalnya sendiri. Famili elastic-serverless-autoscale melatih eksekusi dapat-dibentuk: setiap pemanggilan fungsi mendeklarasikan lebih dari satu mode eksekusi — mode sempit hanya-di-rumah dan mode lebar yang meminjam sebuah worker dari kolam burst bersama kecil untuk selesai lebih cepat — sehingga jadwal memilih satu mode per tugas dan urutan memutuskan pemanggilan mana yang mengklaim mode lebar-dan-cepat yang langka. Famili distributed-training-gang melatih ko-penjadwalan geng: para worker dari pekerjaan pelatihan data-paralel sinkron berbagi sebuah geng dan harus ko-mulai pada akselerator berbeda dalam peluncuran semua-atau-tidak — para worker memakai-ulang kolam akselerator dan pekerjaan tiba seiring waktu, sehingga sebuah pekerjaan tak dapat mulai sampai cukup akselerator bebas serentak, dan urutan memutuskan pekerjaan mana yang lebih dulu memperoleh set worker penuhnya. Famili multi-tenant-fair-share melatih keadilan sumber-daya-dominan: beberapa penyewa berukuran-asimetris menempatkan tugas fleksibel-penempatan pada kolam node bersama, dan tujuan bagian-sumber-daya-dominan menilai sebaran antara bagian dominan penyewa yang paling- dan paling-sedikit-dilayani — sehingga penempatan, sumber daya mana yang ditempati tiap penyewa, adalah tuas yang menyeimbangkan atau memiringkannya. Yang dapat dijalankan examples/serverless_autoscale_study.py, examples/distributed_training_gang_study.py, dan examples/multi_tenant_fairshare_study.py membuat ketiga tuas ini eksplisit.

Kelas Profil

Label Bukti

Katalog smoke tidak pernah menjadi bukti evaluasi final. Mereka ada untuk membuktikan bahwa generator, validasi, karakterisasi, pemeriksaan sitasi, dan persistensi bekerja cepat. Katalog portal dan unduhan mempratinjau setiap famili kontinum pada skala smoke kecil ini (kolam tiga-sumber-daya); sebuah famili ko-alokasi tak dapat memamerkan paralelisme sumber-daya-lepas pada kolam sekecil itu, sehingga struktur khasnya adalah properti skala-riset. build_continuum_full_catalog() mematerialisasi setiap famili pada skala riset yang dideklarasikannya -- kolam sumber daya dan jumlah tugas yang lebih besar di mana struktur ko-alokasi, kontensi, dan penempatan sungguh-sungguh terwujud -- untuk bundel benchmark tingkat-riset.

Taksonomi

Taksonomi mencakup struktur penjadwalan, lingkungan, realisme infrastruktur, fitur tujuan, fitur batasan, ketidakpastian, dan dinamisme. Contoh termasuk workflow DAG, batch tugas independen, fungsi serverless, konsolidasi kontainer dan VM, lingkungan edge dan cloud, jejak publik, optimisasi multi-tujuan, deadline, lokalitas data, churn, dan kedatangan dinamis.

Matriks Sitasi

Klaim benchmark diperiksa terhadap CitationMatrix. Klaim tingkat-bukti kandidat dan kampanye-penuh gagal validasi kecuali mereka mereferensikan sumber yang didukung-sitasi. Materi yang tak didukung harus tetap exploratory sampai bukti ditambahkan.

Set sumber dideklarasikan dalam default_citation_matrix() dengan pengidentifikasi sumber stabil, referensi yang dapat-diselesaikan, dan postur lisensi tercatat. Ia merentang tiga tingkat: korpus optimisasi-kombinatorial standar (disitasi dan ditautkan saja, tak pernah dibundel), jejak kluster produksi, dan set luas dataset kontinum Edge–Fog–Cloud dunia-nyata kontemporer — jejak kluster GPU dan machine-learning, suite benchmark microservice dan serverless, jejak workflow-ilmiah, jejak pekerjaan superkomputer, dataset edge-placement dan mobilitas, dataset IoT dan permintaan-seluler, sinyal karbon dan energi grid, beban-kerja pemrosesan-aliran, benchmark partisipasi-perangkat federated-learning, testbed sistem realitas-diperluas, dan jejak jaringan-satelit orbit-bumi-rendah:

Suite Referensi Kanonik

Registri dalam default_reference_suites() merekam suite instans terpublikasi kanonik yang menjadi jangkar setiap famili penjadwalan generik: identitas, famili, jumlah instans, penunjuk pengambilan, dan pelacak best-known-solution yang menerbitkan batas untuk suite tersebut. Suite klasik hanya disitasi dan ditautkan — DispatchAtlas tidak pernah membundel atau mendistribusikan-ulang berkas instans pihak-ketiga.

Suite dengan parser yang dibundel (teks job-shop standar, matriks flow-shop Taillard, job-shop fleksibel .fjs, JSON WfFormat WfCommons) di-ingest dengan load_reference_suite(suite_id, instances_root=...) dari berkas yang diunduh operator dan ditempatkan di bawah pohon resources/ lokal. Ingesti berjalan sepenuhnya luring, memakai-ulang amplop validasi, karakterisasi, hashing, dan provenans yang sama dengan generator sintetik, dan mencap setiap masalah dengan suite_id dan upstream_instance_id-nya. Suite hanya-registri direkam dengan sitasi dan penunjuk pengambilannya tanpa parser yang dibundel.

Registri Best-Known-Solution

Nilai best-known per-instans tidak pernah disertakan bersama DispatchAtlas. Operator meng-ingest-nya sebagai berkas JSON di bawah direktori privat resources/benchmarks/bks/, satu berkas per suite, masing-masing membawa schema_version, suite_id, source_id pelacak, tanggal pengambilan, dan entri nilai (id instans, tujuan, nilai, jenis optimum-atau-batas-atas, batas bawah opsional). load_best_known_registry memvalidasi setiap berkas terhadap suite referensi dan matriks sitasi serta gagal tertutup pada suite tak-dikenal, pelacak tak-dikenal, entri duplikat, atau batas yang tak-konsisten. Tanpa registri yang ter-ingest, metrik deviasi-relatif sama sekali tidak tersedia — metrik itu tidak pernah dihitung sebagian, dan tidak ada nilai best-known yang muncul di permukaan publik mana pun.

Divergensi Kalibrasi

Famili generik sintetik dijangkarkan ke suite kanonik tanpa mengklaim mereproduksi skema pembangkitannya. Divergensi yang diketahui didokumentasikan alih-alih disembunyikan:

Perbandingan terhadap konvensi terpublikasi dirutekan melalui instans kanonik yang ter-ingest, bukan melalui famili sintetik.

Karakterisasi

Setiap masalah termaterialisasi menerima deskriptor ternormalisasi untuk:

• kepadatan peluang
• kelangkaan kompatibilitas
• kontensi dan kelebihan-muatan
• kedalaman dependensi
• tekanan komunikasi
• intensitas setup
• kemiringan beban dan heterogenitas
• konflik tujuan
• ketidakpastian dan dinamisme
• sensitivitas solver

Jembatan Distribution-Distance

Setiap profil tingkat-bukti kampanye-penuh mendeklarasikan jembatan distribution-distance: statusnya (synthetic, calibrated-synthetic, trace-backed, atau externally-sourced), bukti kalibrasi, skenario domain, cakupan transfer dan gangguan, dan risiko distribution-distance residual. Promosi ke tingkat-bukti kampanye-penuh gagal tertutup kecuali cakupan transfer dan gangguan dideklarasikan, dan profil calibrated-synthetic harus menamai referensi trace-backed yang menjadi acuan kalibrasinya. Famili calibrated-synthetic menamai referensi jejaknya secara eksplisit; suite kanonik yang ter-ingest membawa jembatan externally-sourced, dan adapter WfCommons adalah sumber instans trace-backed terurai-eksternal yang pertama, memberi distribution_distance_score sebuah kaki referensi trace-backed yang nyata.

Metrik kalibrasi bernama melaporkan jarak 1-Wasserstein (pemindah-tanah) per-fitur antara distribusi fitur karakterisasi profil calibrated-synthetic dan distribusi instans referensi trace-backed-nya. Jarak per-fitur diagregasi menjadi skor distribution-distance tunggal; skor di atas ambang divergensi-maksimum (default 0.25) berarti profil telah menyimpang terlalu jauh dari referensinya dan gagal kalibrasi. Metrik dapat direproduksi dari instans termaterialisasi dan jejak referensi bernama.

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"
)

Stratifikasi dan Seleksi Subset

difficulty_score mengagregasi deskriptor kontensi, kelebihan-muatan, kedalaman-dependensi, dan sensitivitas-solver menjadi skor kesulitan ternormalisasi, dan stratify_instances membin instans termaterialisasi ke dalam strata kesulitan rendah, sedang, dan tinggi. select_benchmark_subset memilih subset deterministik yang difilter berdasarkan famili, kelas profil, dan strata kesulitan, diurutkan berdasarkan pengidentifikasi masalah sehingga seleksinya dapat direproduksi.

Katalog Smoke

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])

Katalog smoke yang dibundel mencakup dua famili distributed-computing (cloud/edge tugas-independen dan workflow DAG) di samping empat belas famili penjadwalan generik (penjadwalan mesin, job-shop, job-shop fleksibel, flow-shop permutasi, flow-shop setup bergantung-urutan, RCPSP, open-shop, flow-shop hibrida, flow-shop permutasi terdistribusi, flow-shop tanpa-tunggu, flow-shop pemblokiran, flow-shop perakitan terdistribusi, flow-shop permutasi multi-objektif, dan RCPSP/max) sebagai rekan co-equal. Setiap instans deterministik dari benih akar dan menggunakan metadata generator yang didukung-sitasi sambil tetap dilabeli sebagai materi pengembangan smoke.

Katalog Penuh Kandidat

Katalog kampanye-penuh kandidat menggunakan jalur materialisasi yang sama dengan jumlah masalah terkonfigurasi yang lebih besar dan label bukti yang lebih ketat:

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,
)

Katalog tingkat-bukti kampanye-penuh itu didukung-sitasi, dikarakterisasi, ditaut-hash, dan masih dilabeli sebagai bukti kalibrasi sampai gerbang kampanye, pengungkapan, dan publikasi mempromosikan klaim spesifik.