Modelo de benchmarks

dispatchatlas.bench define la evidencia de benchmarks antes de que los solvers o las campañas la consuman. Una familia de benchmarks declara su taxonomía, perfil de dominio, clase de perfil, supuestos, evidencia de citación, envolvente de escala, espacio de nombres de semilla, y esquema de salida. La materialización valida cada problema generado con dispatchatlas.core, caracteriza la instancia, la envuelve en un sobre de procedencia, y registra hashes estables.

El catálogo cubre familias genéricas de planificación de optimización-combinatoria y planificación de distributed-computing como pares co-iguales, de modo que la plataforma no es una herramienta solo-de-distributed-computing.

Ejemplo ejecutable: examples/benchmark_continuum.py genera, caracteriza, y cataloga un atlas de benchmarks continuo al vuelo.

Familias de planificación

Cada familia de planificación se materializa como un par de catálogo de primera-clase con al menos un perfil generador. La tabla de catálogo de abajo se genera a partir del registro de generadores de benchmarks y la matriz de citación, de modo que sus totales de familia y citaciones de fuente son contables desde las propias filas. Un gráfico de distribución-de-familias encima de la tabla muestra cómo los perfiles de familia se reparten entre las categorías de familias de planificación.

El componente de arriba lleva el inventario generado completo — las familias núcleo clásicas y de distributed-computing de abajo más el continuo de familias Edge–Fog–Cloud. Esas familias núcleo fundacionales en forma de documento:

Las familias de máquina-no-relacionada y job-shop flexible adjuntan una matriz de tiempo-de-ejecución CostModel a cada instancia, exportada como una matriz materializada junto al JSON del problema. La familia de flow-shop de setup dependiente-de-secuencia en cambio adjunta una matriz de setup CostModel: un cambio entre trabajos de familias diferentes en una máquina cuesta tiempo de setup, de modo que el objetivo de setup recompensa agrupar trabajos similares. Los corpora estándar nombrados se citan y enlazan solamente y nunca se redistribuyen dentro del repositorio.

Varias familias del continuo ejercitan co-asignación multi-recurso: cada tarea demanda más de un recurso a la vez y el constructor los mantiene juntos durante toda su duración (ver Contratos de dominio). La familia accelerator-coscheduling co-asigna un nodo de cómputo y un acelerador escaso por trabajo; la familia distributed-transaction co-asigna un conjunto de bloqueos de cardinalidad-variable de fragmentos de datos por transacción; y la familia fpga-partitioning co-asigna una corrida espacialmente contigua de tiles de tejido reconfigurable por kernel de inquilino. Las tareas cuyos conjuntos de recursos se intersectan se serializan mientras las tareas disjuntas corren concurrentemente — el ejecutable examples/inspect_coallocation.py hace la palanca explícita.

Más allá de la co-asignación, tres familias del continuo ejercitan sus propias palancas estructurales. La familia elastic-serverless-autoscale ejercita ejecución moldeable: cada invocación de función declara más de un modo de ejecución — un modo angosto solo-en-casa y un modo ancho que toma prestado un worker de un pequeño pool de ráfaga compartido para terminar antes — de modo que el horario elige un modo por tarea y el orden decide qué invocaciones reclaman el escaso modo ancho-y-rápido. La familia distributed-training-gang ejercita co-planificación de pandilla: los workers de un trabajo de entrenamiento data-paralelo síncrono comparten una pandilla y deben co-iniciar en aceleradores distintos en un lanzamiento todo-o-nada — los workers reutilizan el pool de aceleradores y los trabajos llegan con el tiempo, de modo que un trabajo no puede comenzar hasta que suficientes aceleradores se liberen simultáneamente, y el orden decide qué trabajo adquiere su conjunto completo de workers primero. La familia multi-tenant-fair-share ejercita equidad de recurso-dominante: varios inquilinos de tamaño-asimétrico colocan tareas flexibles-en-colocación en un pool de nodos compartido, y el objetivo de cuota-de-recurso-dominante puntúa la dispersión entre la cuota dominante del inquilino más- y menos-servido — de modo que la colocación, qué recursos ocupa cada inquilino, es la palanca que la equilibra o la sesga. Los ejecutables examples/serverless_autoscale_study.py, examples/distributed_training_gang_study.py, y examples/multi_tenant_fairshare_study.py hacen estas tres palancas explícitas.

Clases de perfil

Etiquetas de evidencia

Los catálogos de prueba nunca son evidencia de evaluación final. Existen para probar que los generadores, la validación, la caracterización, las comprobaciones de citación, y la persistencia funcionan rápidamente. El catálogo del portal y las descargas previsualizan cada familia del continuo a esta pequeña escala de prueba (un pool de tres-recursos); una familia de co-asignación no puede exhibir paralelismo de recurso-disjunto en un pool tan pequeño, de modo que la estructura distintiva es una propiedad de escala-de-investigación. build_continuum_full_catalog() materializa cada familia en su escala de investigación declarada -- el pool de recursos y el conteo de tareas mayores donde la estructura de co-asignación, contención, y colocación genuinamente se manifiesta -- para paquetes de benchmarks de grado-investigación.

Taxonomía

La taxonomía cubre estructuras de planificación, entornos, realismo de infraestructura, características de objetivo, características de restricción, incertidumbre, y dinamismo. Los ejemplos incluyen workflows DAG, lotes de tareas independientes, funciones serverless, consolidación de contenedores y VM, entornos edge y cloud, trazas públicas, optimización multi-objetivo, deadlines, localidad de datos, churn, y arribos dinámicos.

Matriz de citación

Las afirmaciones de benchmarks se comprueban contra CitationMatrix. Las afirmaciones de grado de evidencia candidato y de campaña-completa fallan la validación a menos que referencien fuentes respaldadas-por-citaciones. El material no soportado debe permanecer exploratorio hasta que se añada evidencia.

El conjunto de fuentes se declara en default_citation_matrix() con identificadores de fuente estables, referencias resolubles, y una postura de licencia registrada. Abarca tres niveles: los corpora estándar de optimización-combinatoria (citados y enlazados solamente, nunca empaquetados), trazas de clúster de producción, y un amplio conjunto de datasets contemporáneos del mundo-real del continuo Edge–Fog–Cloud — trazas de clúster de GPU y machine-learning, suites de benchmark de microservicios y serverless, trazas de workflow-científico, trazas de trabajos de supercomputador, datasets de edge-placement y movilidad, datasets de IoT y demanda-celular, señales de carbono y energía de red, cargas de procesamiento-de-flujo, benchmarks de participación-de-dispositivos de federated-learning, testbeds de sistemas de realidad-extendida, y trazas de red-satelital de órbita-terrestre-baja:

Suites de referencia canónicas

El registro en default_reference_suites() registra las suites de instancias publicadas canónicas a las que ancla cada familia genérica de planificación: identidad, familia, conteo de instancias, puntero de recuperación, y los trackers de mejores-soluciones-conocidas que publican cotas para la suite. Las suites clásicas se citan y enlazan solamente — DispatchAtlas nunca empaqueta ni redistribuye archivos de instancias de terceros.

Las suites con un parser empaquetado (texto de job-shop estándar, matrices de flow-shop de Taillard, job-shop flexible .fjs, JSON WfFormat de WfCommons) se ingieren con load_reference_suite(suite_id, instances_root=...) desde archivos que el operador descarga y coloca bajo un árbol resources/ local. La ingestión corre completamente offline, reutiliza la misma validación, caracterización, hashing, y sobre de procedencia que los generadores sintéticos, y estampa cada problema con su suite_id y su upstream_instance_id. Las suites solo-de-registro se registran con sus citaciones y punteros de recuperación sin un parser empaquetado.

Registros de mejores-soluciones-conocidas

Los valores mejores-conocidos por-instancia nunca se envían con DispatchAtlas. El operador los ingiere como archivos JSON bajo un directorio privado resources/benchmarks/bks/, un archivo por suite, cada uno llevando schema_version, el suite_id, el source_id del tracker, la fecha de recuperación, y las entradas de valor (identificador de instancia, objetivo, valor, tipo de óptimo-o-cota-superior, cota inferior opcional). load_best_known_registry valida cada archivo contra las suites de referencia y la matriz de citación y falla en cerrado ante suites desconocidas, trackers desconocidos, entradas duplicadas, o cotas inconsistentes. Sin un registro ingerido, las métricas de desviación-relativa simplemente no están disponibles — nunca se computan parcialmente, y ningún valor mejor-conocido aparece en ninguna superficie pública.

Divergencias de calibración

Las familias genéricas sintéticas están ancladas a las suites canónicas sin pretender reproducir sus esquemas de generación. Las divergencias conocidas se documentan en lugar de ocultarse:

Las comparaciones contra las convenciones publicadas se enrutan a través de las instancias canónicas ingeridas, no a través de las familias sintéticas.

Caracterización

Cada problema materializado recibe descriptores normalizados para:

• densidad de oportunidad
• esparsidad de compatibilidad
• contención y sobrecarga
• profundidad de dependencia
• presión de comunicación
• intensidad de setup
• sesgo de carga y heterogeneidad
• conflicto de objetivo
• incertidumbre y dinamismo
• sensibilidad del solver

Puente de distribution-distance

Cada perfil de grado de evidencia de campaña-completa declara un puente de distribution-distance: su estado (synthetic, calibrated-synthetic, trace-backed, o externally-sourced), evidencia de calibración, escenario de dominio, cobertura de transferencia y disrupción, y riesgo de distribution-distance residual. La promoción al grado de evidencia de campaña-completa falla en cerrado a menos que se declaren las coberturas de transferencia y disrupción, y un perfil calibrated-synthetic debe nombrar la referencia trace-backed contra la que calibra. Las familias calibrated-synthetic nombran su referencia de traza explícitamente; las suites canónicas ingeridas llevan un puente externally-sourced, y el adaptador de WfCommons es la primera fuente de instancias trace-backed parseada-externamente, dando a distribution_distance_score una pata de referencia trace-backed real.

La métrica de calibración nombrada reporta la distancia 1-Wasserstein (movedor-de-tierra) por-característica entre las distribuciones de características de caracterización de un perfil calibrated-synthetic y las de sus instancias de referencia trace-backed. Las distancias por-característica se agregan a una única puntuación de distribution-distance; una puntuación por encima del umbral de divergencia-máxima (por defecto 0.25) significa que el perfil ha derivado demasiado lejos de su referencia y falla la calibración. La métrica es reproducible desde las instancias materializadas y la traza de referencia nombrada.

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

Estratificación y selección de subconjunto

difficulty_score agrega los descriptores de contención, sobrecarga, profundidad-de-dependencia, y sensibilidad-del-solver en una puntuación de dificultad normalizada, y stratify_instances bina las instancias materializadas en estratos de dificultad baja, media, y alta. select_benchmark_subset elige un subconjunto determinista filtrado por familia, clase de perfil, y estrato de dificultad, ordenado por identificador de problema de modo que la selección es reproducible.

Catálogo de prueba

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

El catálogo de prueba empaquetado incluye las dos familias de distributed-computing (cloud/edge de tarea-independiente y workflow DAG) junto a las catorce familias genéricas de planificación (planificación de máquinas, job-shop, job-shop flexible, flow-shop de permutación, flow-shop de setup dependiente-de-secuencia, RCPSP, open-shop, flow-shop híbrido, flow-shop de permutación distribuido, flow-shop sin-espera, flow-shop con-bloqueo, flow-shop de ensamblaje distribuido, flow-shop de permutación multi-objetivo, y RCPSP/max) como pares co-iguales. Cada instancia es determinista desde la semilla raíz y usa metadatos de generador respaldados-por-citaciones mientras permanece etiquetada como material de desarrollo de prueba.

Catálogos completos candidatos

Los catálogos de campaña-completa candidatos usan la misma ruta de materialización con conteos de problema configurados mayores y etiquetas de evidencia más estrictas:

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

Esos catálogos de grado de evidencia de campaña-completa están respaldados-por-citaciones, caracterizados, enlazados-por-hash, y aún marcados como evidencia de calibración hasta que los gates de campaña, divulgación, y publicación promuevan afirmaciones específicas.