Benchmark-Modell

dispatchatlas.bench definiert Benchmark-Belege, bevor Solver oder Kampagnen sie konsumieren. Eine Benchmark-Familie deklariert ihre Taxonomie, ihr Domänenprofil, ihre Profilklasse, ihre Annahmen, ihren Zitationsbeleg, ihre Skalenhülle, ihren Seed-Namensraum, und ihr Ausgabeschema. Die Materialisierung validiert jedes generierte Problem mit dispatchatlas.core, charakterisiert die Instanz, hüllt sie in einen Provenienz-Umschlag, und zeichnet stabile Hashes auf.

Der Katalog deckt generische kombinatorisch-optimierungs Planungsfamilien und Distributed-Computing-Planung als co-gleiche Peers ab, sodass die Plattform kein nur-Distributed-Computing-Werkzeug ist.

Ausführbares Beispiel: examples/benchmark_continuum.py generiert, charakterisiert, und katalogisiert einen Kontinuum-Benchmark-Atlas im Flug.

Planungsfamilien

Jede Planungsfamilie wird als erstklassiger Katalog-Peer mit mindestens einem Generatorprofil materialisiert. Die Katalogtabelle unten wird aus der Benchmark-Generator-Registry und der Zitationsmatrix generiert, sodass ihre Familien-Summen und Quellzitationen aus den Zeilen selbst zählbar sind. Ein Familien-Verteilungs-Diagramm über der Tabelle zeigt, wie sich die Familienprofile über die Planungsfamilien-Kategorien verteilen.

Die Komponente oben trägt das vollständige generierte Inventar — die klassischen und Distributed-Computing-Kernfamilien unten plus das Kontinuum der Edge–Fog–Cloud-Familien. Diese grundlegenden Kernfamilien in Dokumentform:

Die unverwandte-Maschine- und flexible-Job-Shop-Familien hängen eine CostModel-Ausführungszeit-Matrix an jede Instanz, exportiert als materialisierte Matrix neben dem Problem-JSON. Die sequenzabhängige-Setup-Flow-Shop-Familie hängt stattdessen eine CostModel-Setup-Matrix an: ein Wechsel zwischen Jobs verschiedener Familien auf einer Maschine kostet Setup-Zeit, sodass das Setup-Ziel das Gruppieren ähnlicher Jobs belohnt. Die genannten Standardkorpora werden nur zitiert und verlinkt und werden niemals innerhalb des Repositorys weiterverteilt.

Mehrere Kontinuum-Familien üben Multi-Ressourcen-Co-Allokation: jede Aufgabe fordert mehr als eine Ressource gleichzeitig und der Konstruktor hält sie für ihre ganze Dauer zusammen (siehe Domänenverträge). Die Familie accelerator-coscheduling co-allokiert einen Rechenknoten und einen knappen Beschleuniger pro Job; die Familie distributed-transaction co-allokiert eine variabel-kardinale Sperr-Menge von Daten-Shards pro Transaktion; und die Familie fpga-partitioning co-allokiert einen räumlich zusammenhängenden Lauf von rekonfigurierbaren Gewebe-Kacheln pro Mandanten-Kernel. Aufgaben, deren Ressourcen-Mengen sich schneiden, serialisieren, während disjunkte Aufgaben gleichzeitig laufen — das ausführbare examples/inspect_coallocation.py macht den Hebel explizit.

Über die Co-Allokation hinaus üben drei Kontinuum-Familien ihre eigenen strukturellen Hebel. Die Familie elastic-serverless-autoscale übt formbare Ausführung: jede Funktionsaufrufung deklariert mehr als einen Ausführungsmodus — einen schmalen Nur-Zuhause-Modus und einen weiten Modus, der einen Worker von einem kleinen geteilten Burst-Pool leiht, um früher fertig zu werden — sodass der Plan einen Modus pro Aufgabe wählt und die Reihenfolge entscheidet, welche Aufrufungen den knappen weit-und-schnellen Modus beanspruchen. Die Familie distributed-training-gang übt Gang-Co-Scheduling: die Worker eines synchronen daten-parallelen Trainingsjobs teilen einen Gang und müssen auf distinkten Beschleunigern in einem Alles-oder-Nichts-Start co-starten — die Worker wiederverwenden den Beschleunigerpool und Jobs treffen über die Zeit ein, sodass ein Job nicht beginnen kann, bis genug Beschleuniger gleichzeitig frei werden, und die Reihenfolge entscheidet, welcher Job zuerst seine volle Worker-Menge erwirbt. Die Familie multi-tenant-fair-share übt Dominant-Ressourcen-Fairness: mehrere asymmetrisch-große Mandanten platzieren platzierungs-flexible Aufgaben auf einem geteilten Knotenpool, und das Dominant-Ressourcen-Anteil-Ziel bewertet die Spreizung zwischen dem dominanten Anteil des meist- und am wenigsten-bedienten Mandanten — sodass die Platzierung, welche Ressourcen jeder Mandant belegt, der Hebel ist, der sie ausbalanciert oder verzerrt. Die ausführbaren examples/serverless_autoscale_study.py, examples/distributed_training_gang_study.py, und examples/multi_tenant_fairshare_study.py machen diese drei Hebel explizit.

Profilklassen

Beleglabels

Smoke-Kataloge sind niemals finale Evaluationsbelege. Sie existieren, um zu beweisen, dass Generatoren, Validierung, Charakterisierung, Zitationsprüfungen, und Persistenz schnell funktionieren. Der Portal-Katalog und die Downloads zeigen jede Kontinuum-Familie in dieser kleinen Smoke-Skala (einem Drei-Ressourcen-Pool) als Vorschau; eine Co-Allokations-Familie kann disjunkt-Ressourcen-Parallelismus auf einem so kleinen Pool nicht zeigen, sodass die distinktive Struktur eine Forschungs-Skala-Eigenschaft ist. build_continuum_full_catalog() materialisiert jede Familie in ihrer deklarierten Forschungsskala -- dem größeren Ressourcenpool und der Aufgabenanzahl, wo sich die Co-Allokations-, Contention-, und Platzierungsstruktur wahrhaft manifestiert -- für Forschungs-Grade-Benchmark-Pakete.

Taxonomie

Die Taxonomie deckt Planungsstrukturen, Umgebungen, Infrastruktur-Realismus, Zielmerkmale, Constraint-Merkmale, Ungewissheit, und Dynamik ab. Beispiele umfassen DAG-Workflows, unabhängige Aufgaben-Batches, serverlose Funktionen, Container- und VM-Konsolidierung, Edge- und Cloud-Umgebungen, öffentliche Traces, Mehrziel-Optimierung, Deadlines, Datenlokalität, Churn, und dynamische Ankünfte.

Zitationsmatrix

Benchmark-Aussagen werden gegen CitationMatrix geprüft. Kandidaten- und Vollkampagnen-Belegstufe-Aussagen bestehen die Validierung nicht, sofern sie nicht zitations-gestützte Quellen referenzieren. Nicht-gestütztes Material muss exploratory bleiben, bis Beleg hinzugefügt wird.

Die Quellmenge wird in default_citation_matrix() mit stabilen Quell-Identifiern, auflösbaren Referenzen, und einer aufgezeichneten Lizenzhaltung deklariert. Sie umspannt drei Stufen: die standard kombinatorisch-optimierungs Korpora (nur zitiert und verlinkt, nie gebündelt), Produktions-Cluster-Traces, und eine breite Menge zeitgenössischer Real-World-Edge–Fog–Cloud-Kontinuum-Datensätze — GPU- und Machine-Learning-Cluster-Traces, Microservice- und Serverless-Benchmark-Suiten, Wissenschafts-Workflow-Traces, Supercomputer-Job-Traces, Edge-Placement- und Mobilitäts-Datensätze, IoT- und Mobilfunk-Nachfrage-Datensätze, Netz-Carbon- und -Energie-Signale, Stream-Verarbeitungs-Workloads, Federated-Learning-Geräte-Teilnahme-Benchmarks, Extended-Reality-Systeme-Testbeds, und Low-Earth-Orbit-Satelliten-Netz-Traces:

Kanonische Referenz-Suiten

Die Registry in default_reference_suites() zeichnet die kanonischen publizierten Instanz-Suiten auf, an denen jede generische Planungsfamilie verankert ist: Identität, Familie, Instanzanzahl, Abruf-Verweis, und die Best-Known-Solution-Tracker, die Schranken für die Suite publizieren. Klassische Suiten werden nur zitiert und verlinkt — DispatchAtlas bündelt oder verteilt niemals Instanzdateien Dritter weiter.

Suiten mit einem gebündelten Parser (Standard-Job-Shop-Text, Taillard-Flow-Shop-Matrizen, flexibler .fjs-Job-Shop, WfCommons-WfFormat-JSON) werden mit load_reference_suite(suite_id, instances_root=...) aus Dateien ingestiert, die der Operator herunterlädt und unter einem lokalen resources/-Baum ablegt. Die Ingestion läuft vollständig offline, nutzt dieselbe Validierung, Charakterisierung, dasselbe Hashing, und denselben Provenienz-Umschlag wie die synthetischen Generatoren, und stempelt jedes Problem mit seiner suite_id und upstream_instance_id. Nur-Registry-Suiten werden mit ihren Zitationen und Abruf-Verweisen ohne gebündelten Parser aufgezeichnet.

Best-Known-Solution-Registries

Best-Known-Werte pro Instanz werden niemals mit DispatchAtlas ausgeliefert. Der Operator ingestiert sie als JSON-Dateien unter einem privaten Verzeichnis resources/benchmarks/bks/, eine Datei pro Suite, jede mit schema_version, der suite_id, der Tracker-source_id, dem Abrufdatum, und den Wert-Einträgen (Instanz-Id, Ziel, Wert, Optimum-oder-Oberschranke-Art, optionale Unterschranke). load_best_known_registry validiert jede Datei gegen die Referenz-Suiten und die Zitationsmatrix und schlägt bei unbekannten Suiten, unbekannten Trackern, doppelten Einträgen, oder inkonsistenten Schranken schließend fehl. Ohne eine ingestierte Registry sind Relativ-Abweichungs-Metriken schlicht nicht verfügbar — sie werden niemals teilweise berechnet, und kein Best-Known-Wert erscheint auf irgendeiner öffentlichen Oberfläche.

Kalibrierungs-Divergenzen

Die synthetischen generischen Familien sind an den kanonischen Suiten verankert, ohne zu beanspruchen, deren Generierungsschemata zu reproduzieren. Die bekannten Divergenzen werden dokumentiert statt versteckt:

Vergleiche gegen die publizierten Konventionen laufen über die ingestierten kanonischen Instanzen, nicht über die synthetischen Familien.

Charakterisierung

Jedes materialisierte Problem erhält normalisierte Deskriptoren für:

• Gelegenheitsdichte
• Kompatibilitäts-Sparsity
• Contention und Überlast
• Abhängigkeitstiefe
• Kommunikationsdruck
• Setup-Intensität
• Lastschiefe und Heterogenität
• Zielkonflikt
• Ungewissheit und Dynamik
• Solver-Sensitivität

Distribution-Distance-Brücke

Jedes Vollkampagnen-Belegstufe-Profil deklariert eine Distribution-Distance-Brücke: ihren Status (synthetic, calibrated-synthetic, trace-backed, oder externally-sourced), ihren Kalibrierungsbeleg, ihr Domänenszenario, ihre Transfer- und Disruptionsabdeckung, und ihr verbleibendes Distribution-Distance-Risiko. Die Beförderung zur Vollkampagnen-Belegstufe schlägt schließend fehl, sofern Transfer- und Disruptionsabdeckungen nicht deklariert sind, und ein calibrated-synthetic-Profil muss die trace-backed-Referenz nennen, gegen die es kalibriert. Calibrated-synthetic-Familien nennen ihre Trace-Referenz explizit; ingestierte kanonische Suiten tragen eine externally-sourced-Brücke, und der WfCommons-Adapter ist die erste extern-geparste trace-backed-Instanzquelle, wodurch distribution_distance_score ein echtes trace-backed-Referenz-Standbein erhält.

Die benannte Kalibrierungsmetrik berichtet die 1-Wasserstein-(Erdbeweger-)Distanz pro-Merkmal zwischen den Charakterisierungs-Merkmals-Verteilungen eines calibrated-synthetic-Profils und denen seiner trace-backed-Referenzinstanzen. Die pro-Merkmal-Distanzen werden zu einer einzigen Distribution-Distance-Bewertung aggregiert; eine Bewertung über dem Maximal-Divergenz-Schwellenwert (Standard 0.25) bedeutet, dass das Profil zu weit von seiner Referenz abgedriftet ist und die Kalibrierung nicht besteht. Die Metrik ist aus den materialisierten Instanzen und der benannten Referenz-Trace reproduzierbar.

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

Stratifizierung und Teilmengenauswahl

difficulty_score aggregiert die Contention-, Überlast-, Abhängigkeitstiefe-, und Solver-Sensitivitäts-Deskriptoren in eine normalisierte Schwierigkeitsbewertung, und stratify_instances teilt materialisierte Instanzen in niedrige, mittlere, und hohe Schwierigkeitsstrata. select_benchmark_subset wählt eine deterministische Teilmenge, gefiltert nach Familie, Profilklasse, und Schwierigkeitsstratum, geordnet nach Problem-Identifier, sodass die Auswahl reproduzierbar ist.

Smoke-Katalog

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

Der gebündelte Smoke-Katalog umfasst die zwei Distributed-Computing-Familien (cloud/edge unabhängige-Aufgabe und workflow DAG) neben den vierzehn generischen Planungsfamilien (Maschinenplanung, Job-Shop, flexibler Job-Shop, Permutations-Flow-Shop, sequenzabhängiger-Setup-Flow-Shop, RCPSP, Open-Shop, hybrider Flow-Shop, verteilter Permutations-Flow-Shop, No-Wait-Flow-Shop, Blocking-Flow-Shop, verteilter Montage-Flow-Shop, Mehrziel-Permutations-Flow-Shop, und RCPSP/max) als co-gleiche Peers. Jede Instanz ist vom Wurzel-Seed deterministisch und nutzt zitations-gestützte Generator-Metadaten, während sie als Smoke-Entwicklungsmaterial gekennzeichnet bleibt.

Kandidaten-Vollkataloge

Kandidaten-Vollkampagnen-Kataloge nutzen denselben Materialisierungspfad mit größeren konfigurierten Problemanzahlen und strengeren Beleglabels:

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

Diese Vollkampagnen-Belegstufe-Kataloge sind zitations-gestützt, charakterisiert, hash-verknüpft, und weiterhin als Kalibrierungsbeleg gekennzeichnet, bis Kampagnen-, Offenlegungs-, und Publikations-Gates spezifische Aussagen befördern.