Modelo de benchmarks

dispatchatlas.bench define a evidência de benchmarks antes de os solvers ou as campanhas a consumirem. Uma família de benchmarks declara sua taxonomia, perfil de domínio, classe de perfil, suposições, evidência de citação, envelope de escala, espaço de nomes de semente, e esquema de saída. A materialização valida cada problema gerado com dispatchatlas.core, caracteriza a instância, envolve-a em um envelope de proveniência, e registra hashes estáveis.

O catálogo cobre famílias genéricas de escalonamento de otimização-combinatória e escalonamento de distributed-computing como pares co-iguais, de modo que a plataforma não é uma ferramenta apenas-de-distributed-computing.

Exemplo executável: examples/benchmark_continuum.py gera, caracteriza, e cataloga um atlas de benchmarks contínuo em tempo real.

Famílias de escalonamento

Cada família de escalonamento é materializada como um par de catálogo de primeira-classe com ao menos um perfil gerador. A tabela de catálogo abaixo é gerada a partir do registro de geradores de benchmarks e da matriz de citação, de modo que seus totais de família e citações de fonte são contáveis a partir das próprias linhas. Um gráfico de distribuição de famílias acima da tabela mostra como os perfis de família se distribuem entre as categorias de famílias de escalonamento.

O componente acima carrega o inventário gerado completo — as famílias núcleo clássicas e de distributed-computing abaixo mais o contínuo de famílias Edge–Fog–Cloud. Essas famílias núcleo fundacionais em forma de documento:

As famílias de máquina-não-relacionada e job-shop flexível anexam uma matriz de tempo-de-execução CostModel a cada instância, exportada como uma matriz materializada junto ao JSON do problema. A família de flow-shop de setup dependente-de-sequência em vez disso anexa uma matriz de setup CostModel: uma troca entre trabalhos de famílias diferentes em uma máquina custa tempo de setup, de modo que o objetivo de setup recompensa agrupar trabalhos similares. Os corpora padrão nomeados são citados e vinculados apenas e nunca são redistribuídos dentro do repositório.

Várias famílias do contínuo exercitam co-alocação multi-recurso: cada tarefa demanda mais de um recurso ao mesmo tempo e o construtor os mantém juntos por toda a sua duração (ver Contratos de domínio). A família accelerator-coscheduling co-aloca um nó de computação e um acelerador escasso por trabalho; a família distributed-transaction co-aloca um conjunto de bloqueios de cardinalidade-variável de fragmentos de dados por transação; e a família fpga-partitioning co-aloca uma corrida espacialmente contígua de tiles de tecido reconfigurável por kernel de inquilino. As tarefas cujos conjuntos de recursos se intersectam serializam enquanto tarefas disjuntas rodam concorrentemente — o executável examples/inspect_coallocation.py torna a alavanca explícita.

Além da co-alocação, três famílias do contínuo exercitam suas próprias alavancas estruturais. A família elastic-serverless-autoscale exercita execução moldável: cada invocação de função declara mais de um modo de execução — um modo estreito apenas-em-casa e um modo largo que empresta um worker de um pequeno pool de rajada compartilhado para terminar mais cedo — de modo que o escalonamento escolhe um modo por tarefa e a ordem decide quais invocações reclamam o escasso modo largo-e-rápido. A família distributed-training-gang exercita co-escalonamento de gangue: os workers de um trabalho de treinamento data-paralelo síncrono compartilham uma gangue e devem co-iniciar em aceleradores distintos em um lançamento tudo-ou-nada — os workers reutilizam o pool de aceleradores e os trabalhos chegam ao longo do tempo, de modo que um trabalho não pode começar até que aceleradores suficientes se liberem simultaneamente, e a ordem decide qual trabalho adquire seu conjunto completo de workers primeiro. A família multi-tenant-fair-share exercita equidade de recurso-dominante: vários inquilinos de tamanho-assimétrico colocam tarefas flexíveis-em-colocação em um pool de nós compartilhado, e o objetivo de cota-de-recurso-dominante pontua a dispersão entre a cota dominante do inquilino mais- e menos-servido — de modo que a colocação, quais recursos cada inquilino ocupa, é a alavanca que a equilibra ou a enviesa. Os executáveis examples/serverless_autoscale_study.py, examples/distributed_training_gang_study.py, e examples/multi_tenant_fairshare_study.py tornam essas três alavancas explícitas.

Classes de perfil

Rótulos de evidência

Os catálogos de fumaça nunca são evidência de avaliação final. Existem para provar que os geradores, a validação, a caracterização, as verificações de citação, e a persistência funcionam rapidamente. O catálogo do portal e os downloads previsualizam cada família do contínuo nesta pequena escala de fumaça (um pool de três-recursos); uma família de co-alocação não pode exibir paralelismo de recurso-disjunto em um pool tão pequeno, de modo que a estrutura distintiva é uma propriedade de escala-de-pesquisa. build_continuum_full_catalog() materializa cada família em sua escala de pesquisa declarada -- o pool de recursos e a contagem de tarefas maiores onde a estrutura de co-alocação, contenção, e colocação genuinamente se manifesta -- para pacotes de benchmarks de grau-pesquisa.

Taxonomia

A taxonomia cobre estruturas de escalonamento, ambientes, realismo de infraestrutura, características de objetivo, características de restrição, incerteza, e dinamismo. Os exemplos incluem workflows DAG, lotes de tarefas independentes, funções serverless, consolidação de contêineres e VM, ambientes edge e cloud, traços públicos, otimização multi-objetivo, deadlines, localidade de dados, churn, e chegadas dinâmicas.

Matriz de citação

As afirmações de benchmarks são verificadas contra CitationMatrix. As afirmações de grau de evidência candidato e de campanha-completa falham na validação a menos que referenciem fontes respaldadas-por-citações. Material não suportado deve permanecer exploratory até que evidência seja adicionada.

O conjunto de fontes é declarado em default_citation_matrix() com identificadores de fonte estáveis, referências resolúveis, e uma postura de licença registrada. Abrange três níveis: os corpora padrão de otimização-combinatória (citados e vinculados apenas, nunca empacotados), traços de cluster de produção, e um amplo conjunto de datasets contemporâneos do mundo-real do contínuo Edge–Fog–Cloud — traços de cluster de GPU e machine-learning, suites de benchmark de microsserviços e serverless, traços de workflow-científico, traços de trabalhos de supercomputador, datasets de edge-placement e mobilidade, datasets de IoT e demanda-celular, sinais de carbono e energia de rede, cargas de processamento-de-fluxo, benchmarks de participação-de-dispositivos de federated-learning, testbeds de sistemas de realidade-estendida, e traços de rede-satelital de órbita-terrestre-baixa:

Suites de referência canônicas

O registro em default_reference_suites() registra as suites de instâncias publicadas canônicas às quais cada família de escalonamento genérica se ancora: identidade, família, contagem de instâncias, ponteiro de recuperação, e os rastreadores de melhores-soluções-conhecidas que publicam limites para a suite. As suites clássicas são apenas citadas e vinculadas — o DispatchAtlas nunca empacota nem redistribui arquivos de instâncias de terceiros.

As suites com um parser empacotado (texto job-shop padrão, matrizes de flow-shop de Taillard, job-shop flexível .fjs, JSON WfFormat do WfCommons) são ingeridas com load_reference_suite(suite_id, instances_root=...) a partir de arquivos que o operador baixa e coloca sob uma árvore resources/ local. A ingestão executa inteiramente offline, reutiliza o mesmo envelope de validação, caracterização, hashing, e proveniência dos geradores sintéticos, e carimba cada problema com seu suite_id e upstream_instance_id. As suites apenas-de-registro são registradas com suas citações e ponteiros de recuperação sem um parser empacotado.

Registros de melhores-soluções-conhecidas

Os valores de melhor-solução-conhecida por-instância nunca são distribuídos com o DispatchAtlas. O operador os ingere como arquivos JSON sob um diretório privado resources/benchmarks/bks/, um arquivo por suite, cada um carregando schema_version, o suite_id, o source_id do rastreador, a data de recuperação, e as entradas de valor (id da instância, objetivo, valor, tipo ótimo-ou-limite-superior, limite inferior opcional). load_best_known_registry valida cada arquivo contra as suites de referência e a matriz de citação e falha fechando em suites desconhecidas, rastreadores desconhecidos, entradas duplicadas, ou limites inconsistentes. Sem um registro ingerido, as métricas de desvio-relativo estão simplesmente indisponíveis — elas nunca são computadas parcialmente, e nenhum valor de melhor-solução-conhecida aparece em qualquer superfície pública.

Divergências de calibração

As famílias genéricas sintéticas são ancoradas às suites canônicas sem alegar reproduzir seus esquemas de geração. As divergências conhecidas são documentadas em vez de ocultadas:

As comparações contra as convenções publicadas passam pelas instâncias canônicas ingeridas, não pelas famílias sintéticas.

Caracterização

Cada problema materializado recebe descritores normalizados para:

• densidade de oportunidade
• esparsidade de compatibilidade
• contenção e sobrecarga
• profundidade de dependência
• pressão de comunicação
• intensidade de setup
• viés de carga e heterogeneidade
• conflito de objetivo
• incerteza e dinamismo
• sensibilidade do solver

Ponte de distribution-distance

Cada perfil de grau de evidência de campanha-completa declara uma ponte de distribution-distance: seu estado (synthetic, calibrated-synthetic, trace-backed, ou externally-sourced), evidência de calibração, cenário de domínio, cobertura de transferência e disrupção, e risco de distribution-distance residual. A promoção ao grau de evidência de campanha-completa falha fechando a menos que as coberturas de transferência e disrupção sejam declaradas, e um perfil calibrated-synthetic deve nomear a referência trace-backed contra a qual calibra. As famílias calibrated-synthetic nomeiam sua referência de traço explicitamente; as suites canônicas ingeridas carregam uma ponte externally-sourced, e o adaptador WfCommons é a primeira fonte de instâncias trace-backed analisada-externamente, dando ao distribution_distance_score uma perna de referência trace-backed real.

A métrica de calibração nomeada reporta a distância 1-Wasserstein (movedor-de-terra) por-característica entre as distribuições de características de caracterização de um perfil calibrated-synthetic e as de suas instâncias de referência trace-backed. As distâncias por-característica são agregadas a uma única pontuação de distribution-distance; uma pontuação acima do limiar de divergência-máxima (padrão 0.25) significa que o perfil derivou longe demais de sua referência e falha na calibração. A métrica é reproduzível a partir das instâncias materializadas e do traço de referência nomeado.

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

Estratificação e seleção de subconjunto

difficulty_score agrega os descritores de contenção, sobrecarga, profundidade-de-dependência, e sensibilidade-do-solver em uma pontuação de dificuldade normalizada, e stratify_instances agrupa as instâncias materializadas em estratos de dificuldade baixa, média, e alta. select_benchmark_subset escolhe um subconjunto determinístico filtrado por família, classe de perfil, e estrato de dificuldade, ordenado por identificador de problema de modo que a seleção é reproduzível.

Catálogo de fumaça

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

O catálogo de fumaça empacotado inclui as duas famílias de distributed-computing (cloud/edge de tarefa-independente e workflow DAG) junto às quatorze famílias genéricas de escalonamento (escalonamento de máquinas, job-shop, job-shop flexível, flow-shop de permutação, flow-shop de setup dependente-de-sequência, RCPSP, open-shop, flow-shop híbrido, flow-shop de permutação distribuído, flow-shop sem-espera, flow-shop com-bloqueio, flow-shop de montagem distribuído, flow-shop de permutação multi-objetivo, e RCPSP/max) como pares co-iguais. Cada instância é determinística a partir da semente raiz e usa metadados de gerador respaldados-por-citações enquanto permanece rotulada como material de desenvolvimento de fumaça.

Catálogos completos candidatos

Os catálogos de campanha-completa candidatos usam o mesmo caminho de materialização com contagens de problema configuradas maiores e rótulos de evidência mais estritos:

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

Esses catálogos de grau de evidência de campanha-completa são respaldados-por-citações, caracterizados, ligados-por-hash, e ainda marcados como evidência de calibração até que os gates de campanha, divulgação, e publicação promovam afirmações específicas.