벤치마크 모델
dispatchatlas.bench는 솔버나 캠페인이 소비하기 전에 벤치마크 증거를 정의합니다. 벤치마크
패밀리는 그 분류법, 도메인 프로파일, 프로파일 클래스, 가정, 인용 증거, 규모 외피, 시드
네임스페이스, 그리고 출력 스키마를 선언합니다. 물질화는 생성된 각 문제를
dispatchatlas.core로 검증하고, 인스턴스를 특성화하며, 출처 봉투로 감싸고, 안정적 해시를
기록합니다.
카탈로그는 범용 조합-최적화 스케줄링 패밀리와 distributed-computing 스케줄링을 co-equal한 동급으로 포괄하므로, 플랫폼은 distributed-computing-전용 도구가 아닙니다.
실행 가능한 예제: examples/benchmark_continuum.py는 연속체 벤치마크 아틀라스를 즉석에서 생성·특성화·카탈로그화합니다.
스케줄링 패밀리
각 스케줄링 패밀리는 최소 하나의 생성기 프로파일을 가진 일급 카탈로그 동급으로 물질화됩니다. 아래 카탈로그 표는 벤치마크 생성기 레지스트리와 인용 매트릭스에서 생성되므로, 그 패밀리 합계와 출처 인용은 행 자체에서 셀 수 있습니다. 표 위의 패밀리-분포 차트는 패밀리 프로파일이 스케줄링-패밀리 범주에 걸쳐 어떻게 퍼져 있는지 보여줍니다.
Generated from the benchmark generator registry and the citation matrix: 69 family profiles across 8 scheduling families — distributed-computing (47), flow-shop (7), job-shop (6), machine-scheduling (3), open-shop (1), rcpsp (3), rcpsp-max (1), setup-flow-shop (1).
Showing 69 of 69 family profiles.
| Distinctive against | Evidence | Citation status | Source citations | |||
|---|---|---|---|---|---|---|
accelerator-coschedulingaccelerator-coscheduling a heterogeneous datacenter job needs a compute resource and a scarce accelerator at the same time, so every job co-allocates two simultaneous resource demands held together for its whole run; the accelerator pool is scarce, so jobs sharing an accelerator serialize on it while jobs on disjoint resources run in parallel, and the scheduler reasons over a multi-resource co-allocation problem rather than a single-unit-demand one | distributed-computing | ioe-complete | published single-resource continuum schedulers (one unit resource demand per task, not the simultaneous co-allocation of a compute resource and a scarce accelerator held together under a Pareto contract) | smoke | citation-backed |
|
aerial-edgeaerial-edge a loitering UAV is a flying fog node that serves the ground region beneath it for a fixed loiter window before moving to the next pass, so sorties group into successive loiter passes pinned to the fog tier the platform embodies while overhead | distributed-computing | ioe-complete | aerial-edge MEC simulators (no flying-fog loiter placement) | smoke | citation-backed |
|
anytime-inferenceanytime-inference an edge accelerator serves deep-learning inference requests that each complete a mandatory minimal-accuracy early-exit branch and may run an optional refinement to full accuracy when their latency deadline allows; every request declares a mandatory duration below its full duration and a tight latency deadline, and arrivals are spaced shorter than a full inference so requests queue and contend, so the scheduler decides which requests refine and which deliver the early-exit result -- an imprecise-computation quality-versus-timeliness trade-off | distributed-computing | ioe-complete | published edge-cloud split inference and datacenter inference serving (a fixed full-accuracy computation per request), neither of which lets a request drop an optional refinement to meet its deadline so the schedule order trades accuracy for timeliness | smoke | citation-backed |
|
blocking-flow-shopblocking-flow-shop | flow-shop | classical | — | smoke | citation-backed |
|
bulk-synchronous-graphbulk-synchronous-graph an iterative graph computation runs as a sequence of supersteps separated by global barriers, so each superstep's vertex partitions compute and exchange messages and every partition of the next superstep waits on all partitions of the prior one; the slowest partition therefore gates each superstep, and the scheduler reasons over a barrier-synchronized partition-balancing problem rather than an overlap-friendly pipeline or an independent-task one | distributed-computing | ioe-complete | published pipeline or independent-task schedulers (an overlap-friendly wavefront or unsynchronized tasks, not supersteps separated by global barriers where the slowest partition gates each round under a Pareto contract) | smoke | citation-backed |
|
carbon-awarecarbon-aware flexible jobs defer to low-carbon-intensity windows under a time-varying grid carbon signal while honoring their SLA deadlines | distributed-computing | ioe-complete | Electricity-Maps grid carbon-intensity and CityLearn carbon-aware community signals | smoke | citation-backed |
|
cloud-independentcloud-edge-independent | distributed-computing | domain-specific | — | smoke | citation-backed |
|
coflow-schedulingcoflow-scheduling a distributed-computing stage completes only when the last network transfer of its coflow lands, not the first, so a coflow's completion time is the maximum over its member flows; every coflow emits data-heavy flow tasks that place freely across the fabric plus a barrier task that depends on all of them, so the barrier gates the group and the coflow-completion-time is an all-or-nothing footprint | distributed-computing | ioe-complete | datacenter coflow schedulers (no continuum tier-placement barrier) | smoke | citation-backed |
|
compact-job-shopcompact-job-shop | job-shop | classical | — | smoke | citation-backed |
|
confidential-edgeconfidential-edge tasks are classified by data sensitivity -- a confidential task that touches protected data must execute inside the enclave-capable trusted tier so its data never leaves the trusted boundary, while a public task draws a free placement affinity across the fabric | distributed-computing | ioe-complete | edge enclave runtimes (no security-classified Pareto placement) | smoke | citation-backed |
|
cyber-physicalcyber-physical control cycles arrive periodically under a time-varying tariff | distributed-computing | ioe-complete | periodic hard-real-time task models and smart-grid demand-side scheduling formulations (no edge-fog-cloud tier placement under a Pareto contract) | smoke | citation-backed |
|
data-localitydata-locality a query over a large dataset is cheaper to run where the data already resides than to ship the data across the WAN fabric; each task's input lives on one tier (edge sensor logs, fog warm aggregates, or cloud cold archives) and the task pins to that tier so its heavy input never crosses the fabric, with the data tiers cycled so placement spans the whole edge-fog-cloud continuum | distributed-computing | ioe-complete | cluster locality schedulers (no continuum data-residency placement) | smoke | citation-backed |
|
datacenter-colocationdatacenter-colocation latency-sensitive service jobs and deferrable batch jobs share multi-tenant cells, so high-priority-band jobs claim capacity ahead of low-band jobs under contention | distributed-computing | ioe-complete | Google Borg ClusterData2019 priority-tiered cell traces | smoke | citation-backed |
|
digital-twin-syncdigital-twin-sync each physical asset periodically syncs its state to its fog/cloud twin and must finish within a freshness (Age-of-Information) window before the twin's state goes stale | distributed-computing | ioe-complete | digital-twin edge frameworks (no joint Pareto placement) | smoke | citation-backed |
|
disaggregated-memorydisaggregated-memory a CXL-pooled cloud platform backs each socket with a small local DRAM tier and a shared far-memory pool, and every VM draws a long-tailed memory working set, so a few memory-hungry tenants dominate a socket's local budget while far-memory access inflates a VM's runtime in proportion to the working set it spills to the pool; the scheduler reasons over local-versus-pool placement rather than core-count placement | distributed-computing | ioe-complete | published CXL memory-pooling and tiered-memory systems (socket-local page placement, no edge-fog-cloud tier scheduling under a Pareto contract) | smoke | citation-backed |
|
distributed-assembly-flow-shopdistributed-assembly-flow-shop | flow-shop | classical | — | smoke | citation-backed |
|
distributed-flexible-job-shopdistributed-flexible-job-shop | job-shop | structurally-complex | — | smoke | citation-backed |
|
distributed-permutation-flow-shopdistributed-permutation-flow-shop | flow-shop | classical | — | smoke | citation-backed |
|
distributed-training-gangdistributed-training-gang a GPU cluster runs synchronous data-parallel training jobs; each job is a gang of workers that must START TOGETHER on distinct accelerators (every all-reduce step synchronizes the workers), so a job cannot begin until enough accelerators are free simultaneously; the workers reuse the accelerator pool and jobs arrive over time, so jobs queue and the scheduler decides which job acquires a full simultaneously-free worker set first -- an all-or-nothing gang co-start, not an independent placement of each worker | distributed-computing | ioe-complete | published GPU-cluster and inference-serving families that place each task independently; none requires a whole job's worker set to co-start simultaneously on distinct accelerators, so no other family forbids a partial start -- the gang-scheduling all-or-nothing constraint under a Pareto contract | smoke | citation-backed |
|
distributed-transactiondistributed-transaction a partitioned database runs transactions that each acquire exclusive locks on a variable read/write set of data shards, so every transaction co-allocates a randomly drawn subset of shards held together for its whole run; two transactions whose shard sets intersect serialize while disjoint transactions commit in parallel, so the scheduler reasons over a variable-cardinality lock-conflict graph rather than a fixed two-resource hold | distributed-computing | ioe-complete | published replica-placement schedulers (a single shard pinned per task for locality, not a variable-cardinality exclusive lock set co-allocated per transaction forming a conflict graph under a Pareto contract) | smoke | citation-backed |
|
edge-offloadingedge-offloading-mec each task chooses between local edge execution and remote offload | distributed-computing | ioe-complete | iFogSim MEC offloading scenarios | smoke | citation-backed |
|
edge-placementedge-placement services place on edge servers near their user population and migrate as demand shifts across base-station coverage cells | distributed-computing | ioe-complete | EUA edge-user-allocation and Shanghai-Telecom base-station placement traces | smoke | citation-backed |
|
elastic-serverless-autoscaleelastic-serverless-autoscale a serverless platform serves function invocations on a shared worker pool, and every invocation is moldable: it may run on one, two, or four concurrent workers, where a wider allocation runs shorter by a sublinear speedup but spends more total worker-seconds; each request declares its execution modes and arrivals are spaced shorter than a base invocation so the pool is contended, so the scheduler picks each invocation's worker width -- a moldable latency-versus-cost choice rather than a fixed resource hold | distributed-computing | ioe-complete | published serverless cold-start and fixed-width co-allocation families (accelerator co-scheduling, fpga partitioning), each of which holds one fixed resource set per task; none lets a request choose among several worker-count modes so the schedule order trades latency for resource cost under a Pareto contract | smoke | citation-backed |
|
facility-assignmentfacility-assignment | machine-scheduling | classical | — | smoke | citation-backed |
|
failure-recoveryfailure-recovery a failed task re-places its checkpoint state to a surviving tier | distributed-computing | ioe-complete | Borg cluster failure-event traces | smoke | citation-backed |
|
federated-learningfederated-learning each training round selects a subset of heterogeneous, straggler-prone edge clients that train on non-IID local data, then a fog or cloud aggregator combines their updates | distributed-computing | ioe-complete | FedScale and Oort federated-learning device-participation benchmarks | smoke | citation-backed |
|
flexible-job-shopflexible-job-shop | job-shop | classical | — | smoke | citation-backed |
|
flow-shoppermutation-flow-shop | flow-shop | classical | — | smoke | citation-backed |
|
fpga-partitioningfpga-partitioning a multi-tenant reconfigurable FPGA hosts tenant kernels that each occupy a contiguous region of fabric tiles, so every kernel co-allocates a contiguous run of tiles held together for its whole residency; two kernels whose tile intervals overlap cannot be co-resident and serialize while kernels on disjoint tile spans run in parallel, so the scheduler reasons over an interval-overlap conflict graph rather than a fixed two-resource hold or a random-subset lock set | distributed-computing | ioe-complete | published accelerator co-scheduling (a fixed compute-plus-accelerator pair) and shard-lock transactions (a random subset of resources), neither of which constrains the co-allocated set to a spatially contiguous tile interval whose overlaps form an interval conflict graph under a Pareto contract | smoke | citation-backed |
|
frontierco-fjspfrontierco-fjsp | job-shop | classical | — | smoke | citation-backed |
|
generative-inference-servinggenerative-inference-serving a transformer inference replica batches autoregressive requests that each hold key-value-cache memory proportional to their token count for the whole decode, so a long-tailed sequence mix fragments a fixed cache budget and the scheduler reasons over memory-bound admission rather than GPU-count placement; every request's decode duration and KV-cache demand scale with its drawn token count | distributed-computing | ioe-complete | published single-replica generative-model serving systems (no edge-fog-cloud tier placement under a Pareto contract) | smoke | citation-backed |
|
gpu-mlgpu-ml training and inference jobs claim accelerators and gang-schedule replicas | distributed-computing | ioe-complete | Alibaba PAI, Philly, and Helios GPU-cluster traces | smoke | citation-backed |
|
hybrid-flow-shophybrid-flow-shop | flow-shop | classical | — | smoke | citation-backed |
|
immersive-xrimmersive-xr each extended-reality frame runs a latency-critical perception, render, and display pipeline placed across the device, edge, and cloud within a hard motion-to-photon deadline | distributed-computing | ioe-complete | ILLIXR extended-reality systems testbed | smoke | citation-backed |
|
intermittent-edgeintermittent-edge a batteryless sensor harvests ambient energy into a small buffer, runs until the buffer depletes, then sleeps to recharge; a job too large for one duty-cycle window is checkpointed at power loss and resumed in the next, so it is a precedence chain of edge-pinned per-window segments each bounded by the constant energy window | distributed-computing | ioe-complete | intermittent-computing runtimes (no continuum energy-window placement) | smoke | citation-backed |
|
iot-edgeiot-edge many small sensor readings arrive periodically and aggregate at the edge | distributed-computing | ioe-complete | published wireless-sensor-network telemetry datasets and in-network aggregation deployments (raw sensor readings, not edge-fog-cloud tier scheduling under a Pareto contract) | smoke | citation-backed |
|
job-shopjob-shop | job-shop | classical | — | smoke | citation-backed |
|
kv-cache-placementkv-cache-placement a distributed key-value cache tier serves a catalog of cache objects whose request rate follows a heavy Zipfian popularity skew, so a few hot objects absorb most of the traffic; each object is placement-flexible, carrying one single-node mode per cache-tier node, so the scheduler chooses which tier node hosts it, and an object's working set -- the transfer volume staged onto its host tier -- scales with its popularity rank, so the hottest object carries the largest working set and a cold-tail object the smallest; a naive uniform placement strands a hot, large-working-set object on a far tier and pays its transfer across the fabric, while a locality-aware placement pins the hottest objects to near tiers to shrink makespan and cost | distributed-computing | ioe-complete | published cache and content-placement families (consistent-hashing replica placement, CDN content distribution) that place each object uniformly or by a hash; none scales each object's working set with a Zipfian popularity rank so the hot objects carry a strictly larger transfer volume, making popularity-skewed near-tier pinning the lever a locality-aware placement pulls under the Pareto contract | smoke | citation-backed |
|
machine-schedulingmachine-scheduling-unrelated | machine-scheduling | classical | — | smoke | citation-backed |
|
microservice-dagmicroservice-dag services form an acyclic call graph pinned by role to a tier | distributed-computing | ioe-complete | Alibaba v2021 microservice-trace call graphs | smoke | citation-backed |
|
mixed-criticalitymixed-criticality a safety-critical real-time mix runs tasks of differing criticality, and a high-criticality task is budgeted with a conservative high-assurance worst-case execution time and a tight deadline while a low-criticality task carries a smaller best-effort budget and a loose deadline, so the criticality tiering lives in the duration and deadline structure; the scheduler reasons over which assured-criticality tasks to guarantee under contention rather than a uniform-assurance deadline-scheduling one | distributed-computing | ioe-complete | published uniform-assurance real-time deadline schedulers (one worst-case execution time and deadline class per task, not criticality-tiered WCET budgets with tighter high-assurance deadlines under a Pareto contract) | smoke | citation-backed |
|
moe-expert-parallelmoe-expert-parallel a sparsely-activated mixture-of-experts model routes each token batch to one expert and the experts are spread across devices, and expert popularity is long-tailed, so a few hot experts receive most token batches while many stay cold and the all-to-all routing exchange dominates fabric traffic; the scheduler reasons over an expert-placement and load-balancing problem rather than a dense uniform-replica serving one | distributed-computing | ioe-complete | published dense generative-model serving systems (uniform per-replica KV-cache admission, not sparse token-to-expert routing under load imbalance and a Pareto contract) | smoke | citation-backed |
|
multi-objective-pfspmulti-objective-pfsp | flow-shop | classical | — | smoke | citation-backed |
|
multi-project-rcpspmulti-project-rcpsp | rcpsp | structurally-complex | — | smoke | citation-backed |
|
multi-tenant-fair-sharemulti-tenant-fair-share a shared cluster serves several tenants whose workloads compete for one node pool; each task is placement-flexible, carrying one single-node mode per pool node, so the scheduler chooses which node it occupies; tenants are sized asymmetrically, so even a load-balanced placement leaves the heavy tenants holding a larger fraction of their busiest node -- a higher dominant resource share -- than the light ones, and a fairness-aware scheduler rebalances placement to shrink the dominant-share spread | distributed-computing | ioe-complete | published multi-tenant colocation families (Borg-style priority colocation, vm allocation) that fix each task's resource and score makespan or cost; none lets the scheduler choose each tenant task's node and scores the dominant-resource-share spread between tenants as a fairness objective | smoke | citation-backed |
|
network-slicingnetwork-slicing isolated slice classes (latency-critical, broadband, massive-IoT) each carry their own service-level deadline and placement, and same-class slices spread across tiers for resilience | distributed-computing | ioe-complete | 5G slicing orchestration (no joint Pareto placement) | smoke | citation-backed |
|
no-wait-flow-shopno-wait-flow-shop | flow-shop | classical | — | smoke | citation-backed |
|
open-shopopen-shop | open-shop | classical | — | smoke | citation-backed |
|
orbital-edgeorbital-edge tasks schedule across ground terminals, moving low-earth-orbit satellites, and cloud backhaul under time-varying connectivity as satellites enter and leave coverage and hand work over | distributed-computing | ioe-complete | LENS real-measurement LEO satellite-network traces | smoke | citation-backed |
|
pipeline-parallel-trainingpipeline-parallel-training a deep network is split into successive pipeline stages pinned across edge-to-cloud tiers and the training mini-batch is divided into micro-batches, so each micro-batch flows forward stage by stage while each stage runs its micro-batches in issue order; the two precedence families form a diagonal wavefront whose warm-up and cool-down idle slots are the pipeline bubbles, and deeper stages carry rising compute, so the scheduler reasons over a stage-partition and bubble-minimizing problem rather than a synchronous data-parallel all-reduce one | distributed-computing | ioe-complete | published data-parallel / gang-scheduled training systems (synchronous all-reduce over co-located replicas, not a stage-by-micro-batch pipeline wavefront with warm-up and cool-down bubbles under a Pareto contract) | smoke | citation-backed |
|
rcpsprcpsp-renewable | rcpsp | structurally-complex | — | smoke | citation-backed |
|
rcpsp-maxrcpsp-max | rcpsp-max | structurally-complex | — | smoke | citation-backed |
|
rcpsp-multi-modercpsp-multi-mode | rcpsp | structurally-complex | — | smoke | citation-backed |
|
reentrant-fabreentrant-fab | job-shop | structurally-complex | — | smoke | citation-backed |
|
replica-placementreplica-placement a replica runs where its data shard already lives | distributed-computing | ioe-complete | CRUSH replicated-data placement | smoke | citation-backed |
|
serverless-cold-startserverless-cold-start a cold invocation pays a container provisioning penalty | distributed-computing | ioe-complete | Azure Functions serverless-in-the-wild traces | smoke | citation-backed |
|
service-function-chainservice-function-chain an NFV packet flow traverses a linear ordered chain of typed virtual network functions -- firewall, intrusion detection, deep packet inspection, address translation -- each pinned to a tier that hosts its function type, so the chain is a strict total order and the flow crosses the edge-fog-cloud fabric in a fixed sequence; the scheduler reasons over a chain-placement problem under an end-to-end latency budget rather than the branching role-pinned call graph of a microservice | distributed-computing | ioe-complete | published microservice call-graph schedulers (a branching role-pinned acyclic call graph, not a strict linear chain of function-typed network functions under an end-to-end latency budget and a Pareto contract) | smoke | citation-backed |
|
setup-flow-shopsetup-flow-shop | setup-flow-shop | classical | — | smoke | citation-backed |
|
smartnic-offloadsmartnic-offload a SmartNIC-accelerated server pairs a fast host CPU with a low-power on-NIC processor, and every microservice draws a long-tailed compute intensity, so most are light enough to offload onto the energy-frugal NIC cores while a few compute-heavy services must stay host-bound; a service's runtime scales with its intensity, so the scheduler reasons over an energy-versus-latency offload-placement problem rather than a uniform host placement one | distributed-computing | ioe-complete | published mobile-edge computation-offloading models (device-to-edge latency offload, not in-server host-to-NIC energy offload under a Pareto contract) | smoke | citation-backed |
|
split-inference-servingsplit-inference-serving each inference request partitions a deep model at a layer cut -- a light head runs the early layers on the edge near the sensor and a heavy tail runs the later layers in the cloud, consuming the head's intermediate feature map under a per-request end-to-end latency SLO | distributed-computing | ioe-complete | datacenter inference serving (no edge-cloud partition placement) | smoke | citation-backed |
|
spot-preemptiblespot-preemptible a cloud provider rents idle capacity at a discount as revocable spot instances reclaimed after a short lease; eviction-tolerant batch work pins to the cloud spot tier under a hard lease deadline (the eviction horizon), while latency-critical interactive work pins to the stable edge on-demand tier with no eviction deadline | distributed-computing | ioe-complete | cloud spot schedulers (no continuum eviction-deadline placement) | smoke | citation-backed |
|
storage-io-tieringstorage-io-tiering a tiered storage pool serves I/O-bound jobs whose runtime is dominated by moving a job's I/O volume through the storage node it lands on; each job is placement-flexible, carrying one single-node mode per tier node, and the mode duration is tier-dependent -- a seek floor plus the I/O volume divided by that tier's I/O bandwidth, which differs by tier (a fast cloud array sustains far more bytes/second than a slow edge disk); a job's I/O volume follows a heavy-tailed falloff over its I/O-demand rank, so a few I/O-heavy jobs carry most of the bytes and have a large cross-tier duration spread, while the light tail barely varies; a naive placement strands an I/O-heavy job on a low-bandwidth tier and pays its volume slowly, while a bandwidth-aware placement pins the heavy jobs to fast tiers to shrink makespan and cost | distributed-computing | ioe-complete | published storage-tiering and hierarchical-storage-management families that migrate blocks between fast and slow tiers by access frequency; none models the heterogeneous-tier I/O bandwidth as a placement-flexible per-tier mode whose duration is the I/O volume divided by that tier's bandwidth, so an I/O-heavy job's cross-tier duration spread is the bottleneck-relief lever a bandwidth-aware placement pulls under the Pareto contract | smoke | citation-backed |
|
streaming-windowstreaming-window events arrive online in bounded windows and must close within one | distributed-computing | ioe-complete | Parallel Workloads Archive online arrivals | smoke | citation-backed |
|
time-sensitive-networkingtime-sensitive-networking each time-triggered flow releases on a fixed period and must finish within one cycle under a hard, jitter-free deadline | distributed-computing | ioe-complete | EdgeCloudSim best-effort scenarios (no gating) | smoke | citation-backed |
|
unrelated-parallel-setupunrelated-parallel-setup | machine-scheduling | structurally-complex | — | smoke | citation-backed |
|
vehicular-offloadingvehicular-offloading a vehicle's tasks share an arrival time and a roadside-unit dwell deadline, and hand over from the roadside unit to the fog tier as the vehicle drives on | distributed-computing | ioe-complete | EdgeCloudSim / SUMO vehicular-edge mobility scenarios | smoke | citation-backed |
|
video-analyticsvideo-analytics each camera streams frames that must be analyzed within a tight real-time latency bound, placed hierarchically with edge inference near the camera and cloud aggregation | distributed-computing | ioe-complete | edge video-analytics clusters (no joint Pareto placement) | smoke | citation-backed |
|
vm-allocationvm-allocation size-heterogeneous virtual-machine deployments pack onto hosts while each deployment's members spread across distinct failure domains for availability | distributed-computing | ioe-complete | Azure Public Dataset Resource Central VM-allocation traces | smoke | citation-backed |
|
workflow-dagworkflow-dag | distributed-computing | structurally-complex | — | smoke | citation-backed |
|
Per-instance characterization and download eligibility live in the benchmark catalog; this table is the family-and-citation inventory.
위 컴포넌트는 완전한 생성 인벤토리를 담습니다 — 아래의 고전 및 distributed-computing 코어 패밀리에 더해 Edge–Fog–Cloud 패밀리의 연속체입니다. 그 기초적 코어 패밀리를 문서 형식으로:
| 패밀리 | 프로파일 | 프로파일 클래스 | 주요 코퍼스 |
|---|---|---|---|
| 기계 스케줄링 (R||Cmax, 비관련 기계) | machine-scheduling-unrelated | classical | OR-Library |
| Job-shop | job-shop-classical | classical | OR-Library, Taillard |
| 유연 job-shop (FJSP) | flexible-job-shop | classical | Brandimarte; Hurink-Jurisch-Thole |
| 순열 플로우샵 | permutation-flow-shop | classical | Taillard |
| 순서-의존 셋업 플로우샵 (SDST) | setup-flow-shop | classical | Allahverdi et al. (2008); Allahverdi (2015) |
| 자원-제약 프로젝트 스케줄링 (RCPSP) | rcpsp-renewable | structurally-complex | PSPLIB |
| Distributed-computing (cloud/edge) | cloud-edge-capacity | domain-specific | CloudSim; DynamicCloudSim; Edge vision |
| Distributed-computing (workflow DAG) | workflow-dag | structurally-complex | Standard Task Graph Set |
비관련-기계 및 유연 job-shop 패밀리는 각 인스턴스에 CostModel 실행-시간 매트릭스를
부착하여, 문제 JSON과 함께 물질화 매트릭스로 내보냅니다. 순서-의존 셋업 플로우샵 패밀리는
대신 CostModel 셋업 매트릭스를 부착합니다: 한 기계에서 다른 패밀리의 작업 간 전환은
셋업 시간을 들이므로, 셋업 목적은 유사 작업의 그룹화를 보상합니다. 명명된 표준 코퍼스는
인용 및 링크만 되고 저장소 내에서 결코 재배포되지 않습니다.
여러 연속체 패밀리는 다중-자원 공동-할당을 행사합니다: 각 태스크는 한 번에 둘 이상의
자원을 요구하고 생성자는 그 전체 지속 동안 그것들을 함께 유지합니다(도메인 계약
참조). accelerator-coscheduling 패밀리는 작업당 컴퓨트 노드와 희소 가속기를 공동-할당합니다;
distributed-transaction 패밀리는 트랜잭션당 데이터 샤드의 가변-기수 잠금 집합을
공동-할당합니다; 그리고 fpga-partitioning 패밀리는 테넌트 커널당 재구성 가능 패브릭 타일의
공간적으로 연속된 연속을 공동-할당합니다. 자원 집합이 교차하는 태스크는 직렬화되고, 서로소
태스크는 동시에 실행됩니다 — 실행 가능한
examples/inspect_coallocation.py가
그 레버를 명시화합니다.
공동-할당을 넘어, 세 연속체 패밀리는 각자의 구조적 레버를 행사합니다.
elastic-serverless-autoscale 패밀리는 성형 가능 실행을 행사합니다: 각 함수 호출은
둘 이상의 실행 모드를 선언합니다 — 좁은 자택-전용 모드와, 더 일찍 끝내기 위해 작은 공유
버스트 풀에서 worker를 빌리는 넓은 모드 — 그래서 스케줄은 태스크당 한 모드를 고르고 순서가
어떤 호출이 희소한 넓고-빠른 모드를 차지하는지 결정합니다. 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가
이 세 레버를 명시화합니다.
프로파일 클래스
| 프로파일 클래스 | 의미 |
|---|---|
classical | 표준 조합-최적화 코퍼스에서 파생됨. |
structurally-complex | 우선순위, DAG, 또는 자원-네트워크 구조를 가짐. |
ioe-complete | 만물인터넷-완전 분산 시나리오. |
trace-backed | 명명된 실세계 워크로드 트레이스에 기반함. |
domain-specific | 단일 운영 도메인에 맞춤됨. |
증거 레이블
| 레이블 | 용도 |
|---|---|
smoke | 테스트, 예제, 문서, 미리보기용 작은 결정론적 인스턴스. |
exploratory | 아직 인용-뒷받침되거나 완전히 특성화되지 않은 그럴듯한 자료. |
| 후보 증거 등급 | 파일럿, 통계, 캠페인 게이트를 기다리는 인용-뒷받침 자료. |
| 완전-캠페인 증거 등급 | 인용, 특성화, 통계, 공개, 품질 게이트를 통과한 증거. |
스모크 카탈로그는 결코 최종 평가 증거가 아닙니다. 그것들은 생성기, 검증, 특성화, 인용 검사,
영속성이 빠르게 작동함을 증명하기 위해 존재합니다. 포털 카탈로그와 다운로드는 이 작은 스모크
규모(삼-자원 풀)에서 각 연속체 패밀리를 미리봅니다; 공동-할당 패밀리는 그토록 작은 풀에서
서로소-자원 병렬성을 보일 수 없으므로, 그 독특한 구조는 연구-규모 속성입니다.
build_continuum_full_catalog()는 각 패밀리를 그 선언된 연구 규모로 물질화합니다 —
공동-할당, 경합, 배치 구조가 진정으로 발현되는 더 큰 자원 풀과 태스크 수에서 — 연구-등급
벤치마크 번들을 위해.
분류법
분류법은 스케줄링 구조, 환경, 인프라 현실성, 목적 특징, 제약 특징, 불확실성, 그리고 동적성을 포괄합니다. 예시에는 DAG 워크플로우, 독립 태스크 배치, serverless 함수, 컨테이너 및 VM 통합, edge 및 cloud 환경, 공개 트레이스, 다중-목적 최적화, deadline, 데이터 지역성, churn, 그리고 동적 도착이 포함됩니다.
인용 매트릭스
벤치마크 주장은 CitationMatrix에 대해 검사됩니다. 후보 및 완전-캠페인 증거-등급 주장은
인용-뒷받침 출처를 참조하지 않는 한 검증에 실패합니다. 뒷받침되지 않은 자료는 증거가
추가될 때까지 exploratory로 남아야 합니다.
출처 집합은 default_citation_matrix()에서 안정적 출처 식별자, 해결 가능한 참조, 기록된
라이선스 태세와 함께 선언됩니다. 그것은 세 계층에 걸칩니다: 표준 조합-최적화 코퍼스(인용 및
링크만, 결코 번들되지 않음), 프로덕션 클러스터 트레이스, 그리고 광범위한 당대 실세계
Edge–Fog–Cloud-연속체 데이터셋 — GPU 및 machine-learning 클러스터 트레이스, 마이크로서비스
및 serverless 벤치마크 스위트, 과학-워크플로우 트레이스, 슈퍼컴퓨터 작업 트레이스,
edge-placement 및 이동성 데이터셋, IoT 및 셀룰러-수요 데이터셋, 그리드 탄소 및 에너지
신호, 스트림-처리 워크로드, federated-learning 디바이스-참여 벤치마크, 확장-현실 시스템
테스트베드, 그리고 저-지구-궤도 위성-네트워크 트레이스:
정준 참조 스위트
default_reference_suites()의 레지스트리는 각 범용 스케줄링 패밀리가 앵커하는 정준 발행
인스턴스 스위트를 기록합니다: 정체성, 패밀리, 인스턴스 수, 검색 포인터, 그리고 그 스위트의
경계를 발행하는 최선-기지-해 트래커. 고전 스위트는 인용 및 링크만 됩니다 — DispatchAtlas는
제3자 인스턴스 파일을 결코 번들하거나 재배포하지 않습니다.
| 스위트 | 패밀리 | 인스턴스 | 다운로드 | BKS 트래커 |
|---|---|---|---|---|
fisher-thompson | job-shop | 3 | OR-Library | van-hoorn-2018, scheduleopt-benchmarks |
lawrence | job-shop | 40 | JSPLIB 미러 | van-hoorn-2018, scheduleopt-benchmarks |
adams-balas-zawack | job-shop | 5 | JSPLIB 미러 | van-hoorn-2018, scheduleopt-benchmarks |
applegate-cook-orb | job-shop | 10 | JSPLIB 미러 | van-hoorn-2018, scheduleopt-benchmarks |
storer-wu-vaccari | job-shop | 20 | JSPLIB 미러 | van-hoorn-2018, scheduleopt-benchmarks |
yamada-nakano | job-shop | 4 | JSPLIB 미러 | van-hoorn-2018, scheduleopt-benchmarks |
taillard-jsp | job-shop | 80 | JSPLIB 미러 | van-hoorn-2018, scheduleopt-benchmarks |
demirkol-dmu | job-shop | 80 | JSPLIB 미러 | scheduleopt-benchmarks |
brandimarte-mk | 유연 job-shop | 15 | SchedulingLab 미러 | scheduleopt-benchmarks |
hurink-fjsp | 유연 job-shop | 198 | SchedulingLab 미러 | scheduleopt-benchmarks |
dauzere-peres-paulli | 유연 job-shop | 18 | SchedulingLab 미러 | scheduleopt-benchmarks |
taillard-pfsp | 플로우샵 | 120 | OR-Library | zenodo-pfsp-bks-2021 |
vrf-pfsp | 플로우샵 | 480 | SOA 그룹 사이트 | zenodo-pfsp-bks-2021 |
sdst-taillard-ruiz | 셋업 플로우샵 | 480 | SOA 그룹 사이트 | 최선해가 인스턴스와 함께 제공됨 |
cicirello-wt-sds | 기계 스케줄링 | 120 | Harvard Dataverse | cicirello-wtsds-benchmark |
or-library-smtwt | 기계 스케줄링 | 375 | OR-Library | crauwels-potts-vanwassenhove-1998 |
vallada-ruiz-upmsp | 기계 스케줄링 | 1640 (보고됨) | SOA 그룹 사이트 | — |
psplib | RCPSP | 2040 | PSPLIB 사이트 | psplib-1997 |
mmlib | RCPSP | 4320 (보고됨) | OR&S 랜딩 페이지 | solutionsupdate-ugent-rcpsp |
rg300 | RCPSP | 480 | OR&S 랜딩 페이지 | solutionsupdate-ugent-rcpsp |
번들된 파서가 있는 스위트(표준 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 파일로 수집합니다 — 스위트당 한 파일,
각각 schema_version, suite_id, 트래커 source_id, 검색 날짜, 그리고 값 엔트리(인스턴스
id, 목적, 값, 최적-또는-상한 종류, 선택적 하한)를 지닙니다. load_best_known_registry는
모든 파일을 참조 스위트와 인용 매트릭스에 대해 검증하고 미지의 스위트, 미지의 트래커, 중복
엔트리, 또는 비일관 경계에서 닫혀 실패합니다. 수집된 레지스트리 없이 상대-편차 메트릭은
그저 사용 불가입니다 — 결코 부분적으로 계산되지 않으며, 어떤 최선-기지 값도 어떤 공개
표면에도 나타나지 않습니다.
보정 발산
합성 범용 패밀리는 그 생성 방식을 재현한다고 주장하지 않으면서 정준 스위트에 앵커됩니다. 알려진 발산은 숨겨지지 않고 문서화됩니다:
| 패밀리 | 발행 관례 | 합성 관례 |
|---|---|---|
| 셋업 플로우샵 | 처리 시간의 10/50/100/125%인 SDST-Taillard 셋업 | 세 셋업 패밀리, 비용 = 패밀리 + 1 |
| 기계 스케줄링 (R||Cmax) | U[1,100] 지속시간 클래스와 상관-기계 변형 | 쌍-별 속도 계수 0.5–2.0 |
발행 관례에 대한 비교는 합성 패밀리가 아니라 수집된 정준 인스턴스를 경유합니다.
특성화
각 물질화된 문제는 다음에 대한 정규화된 기술자를 받습니다:
- 기회 밀도
- 호환성 희소성
- 경합 및 과부하
- 의존 깊이
- 통신 압력
- 셋업 강도
- 부하 편향 및 이질성
- 목적 충돌
- 불확실성 및 동적성
- 솔버 민감도
현실-격차 브리지
각 완전-캠페인 증거-등급 프로파일은 현실-격차 브리지를 선언합니다: 그 상태(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])번들된 스모크 카탈로그는 두 distributed-computing 패밀리(cloud/edge 독립-태스크 및 workflow DAG)를 열네 범용 스케줄링 패밀리(기계 스케줄링, 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,
)그 완전-캠페인 증거-등급 카탈로그는 인용-뒷받침되고, 특성화되고, 해시-연결되며, 캠페인, 공개, 발행 게이트가 특정 주장을 승격할 때까지 여전히 보정 증거로 레이블됩니다.