Воспроизведение третьими сторонами: внешний перезапуск и подписанные отчёты

Публичный бенчмарк — это не «картинка с числами», а проверяемое утверждение о коде, данных и окружении.

Единственный надёжный способ проверить такое утверждение — независимый перезапуск на чужом железе.

Канонический протокол публикации и состав артефактов фиксированы и описаны в документации по публичным бенчмаркам. Ниже — конкретный «контракт репликации»: какие файлы обязаны существовать, какие поля в них считаются нормативными и какими seed‑скриптами это собирается.

1.Почему репликация отличается от «ещё бенчмарков»

Мы можем публиковать больше машин, больше suites, больше графиков и всё равно провалить «тест доверия». Репликация качественно отличается тем, что добавляет:

• ›независимое железо
• ›независимые ошибки оператора (реалистичные)
• ›независимую проверку оснастки и допущений

Если бенчмарк не выдерживает внешнего перезапуска, его не следует использовать как доказательство.

2.Что мы понимаем под «репликацией»

Репликация это не «я запустил что-то похожее». Минимально это означает:

• ›то же определение suite и те же входные наборы данных
• ›та же версия харнесса (по baseline_manifest.harness.git_commit)
• ›та же политика детерминизма (флаг baseline_manifest.deterministic)
• ›публикация машиночитаемых артефактов и проверяемых хешей, а не пересказа

Цель — чтобы расхождения стали диагностируемыми:

• ›различия окружения (компилятор, BLAS, драйвер GPU)
• ›дрейф наборов данных
• ›изменения харнесса
• ›или баг

3.Набор артефактов репликации (что публикуется)

Репликация работает только если внешние участники могут идентифицировать точно, что именно сравнивали. Поэтому вместе с сырыми результатами публикуется минимальный «контракт артефактов».

• ›baseline_manifest.json (JSON Schema:benchmarks/nextstat-public-benchmarks/manifests/schema/baseline_manifest_v1.schema.json,schema_version: nextstat.baseline_manifest.v1) — каноническое описание снимка:snapshot_id, deterministic,harness (repo, git_commit),nextstat (обязательная version + опциональныеwheel_sha256/wheel_url),environment (Python + platform, опционально cuda_visible_devices и инвентарь GPU через nvidia-smi), а также списки datasets (id, sha256) и results (по каждому suite: относительный путь path + sha256).
• ›snapshot_index.json (JSON Schema:benchmarks/nextstat-public-benchmarks/manifests/schema/snapshot_index_v1.schema.json,schema_version: nextstat.snapshot_index.v1) — инвентарь всего набора файлов в директории снимка:artifacts[] с полями path, bytes, sha256, плюс метаданные git/workflow для трассируемости.

Для репликации поверх этих двух документов добавляются:

• ›snapshot_comparison.json (seed‑выход replication/compare_snapshots.py,schema_version: nextstat.snapshot_comparison.v1) — структурированное сравнение двух директорий снимков: наборы datasets из baseline_manifest.json, проверка хешей suite‑результатов по списку baseline_manifest.results, а для поддерживаемых suite — дополнительные сравнения (сейчас реализовано для hep; для pharma в отчёт добавляется срез по кейсам (NLL‑время на вызов, статус и время фита), но без жёстких критериев «ok» кроме целостности файлов, наличия кейсов и совпадения dataset‑сета). Формат версионирован полем schema_version, но отдельной JSON Schema для него в seed‑репозитории не публикуется.
• ›replication_report.json (JSON Schema:benchmarks/nextstat-public-benchmarks/manifests/schema/replication_report_v1.schema.json,schema_version: nextstat.replication_report.v1) — компактный машиночитаемый отчёт, который строится из двух snapshot_index.json и фиксирует несовпадения SHA‑256 по пересечению путей (и включает полный replica_snapshot_index для аудита).
• ›signed_report_draft.md → signed_report.md — человекочитаемый отчёт по шаблону, который заполняет репликатор (железо, окружение, вывод, ключевые расхождения) и подписывает выбранным механизмом.

Нормативной частью протокола являются версии schema_version и их JSON Schema там, где она опубликована. Цель — чтобы ключевые проверки выполнялись автоматически, а «человеческий отчёт» был подписываемым слоем поверх уже проверенных данных.

4.Зачем подписанные отчёты

Если отчёты о воспроизведении важны, они должны быть атрибутируемыми и устойчивыми к подмене. Подпись это лёгкий способ гарантировать:

• ›кто произвёл отчёт
• ›на какой снимок он ссылается
• ›что опубликованный артефакт не был изменён

В seed‑инструментах NextStat подпись намеренно не автоматизируется: репликатор сам выбирает механизм (GPG, minisign, корпоративный Sigstore и т.п.) и прикладывает подпись к итоговому signed_report.md. Это делает атрибуцию прозрачной и не привязывает протокол к одной PKI.

Минимальный пример с GPG:

gpg --armor --detach-sign signed_report.md
# результат: signed_report.md.asc

5.Пошагово: минимальная петля воспроизведения

Минимальная петля рассчитана на внешний перезапуск и оформлена как набор файловых операций + валидация JSON по схемам (там, где схемы опубликованы) + сравнение по хешам.

• ›1. Скачать опубликованный снимок и извлечь его в директорию, где есть baseline_manifest.json и snapshot_index.json.
• ›2. Зафиксировать харнесс поbaseline_manifest.harness.git_commit и воспроизвести окружение (минимум: Python версии и платформа изbaseline_manifest.environment; на GPU — также драйвер/модель).
• ›3. Перезапустить suites и собрать новый снимок так, чтобы в нём снова появилисьbaseline_manifest.json и snapshot_index.json.
• ›4. Сравнить снимки машинно: наборы dataset (id+sha256) из baseline‑манифеста, хеши suite‑результатов и (где реализовано) suite‑специфичные сравнения.
• ›5. Сформировать машиночитаемый replication_report.json из двухsnapshot_index.json и человекочитаемый signed_report.md, подписать и опубликовать bundle (опционально — как отдельный Zenodo record с DOI).

Это намеренно спроектировано как преимущественно файловые операции, а не «доверьтесь нашей интерпретации».

Практический runbook (Zenodo → rerun bundle → сравнение) в терминах seed-скриптов:

# 1) Скачать опубликованный snapshot (Zenodo record id) и извлечь.
python3 benchmarks/nextstat-public-benchmarks/replication/fetch_zenodo_snapshot.py \
  --record-id 18542624 \
  --out-dir tmp/zenodo_records

# Скрипт печатает путь к extracted snapshot dir (внутри будет baseline_manifest.json).

# 2) Создать rerun bundle: перезапуск + snapshot_comparison.json + черновик отчёта.
python3 benchmarks/nextstat-public-benchmarks/replication/make_rerun_bundle.py \
  --published /ABS/PATH/TO/extracted/snapshot \
  --published-doi 10.5281/zenodo.18542624 \
  --published-url https://zenodo.org/records/18542624 \
  --rerun-id rerun-yourorg-YYYYMMDD \
  --deterministic \
  --fit

# 3) Сформировать replication_report.json из двух snapshot_index.json.
python3 benchmarks/nextstat-public-benchmarks/scripts/write_replication_report.py \
  --original-index /ABS/PATH/TO/extracted/snapshot/snapshot_index.json \
  --replica-index  /ABS/PATH/TO/bundle/rerun_snapshots/rerun-yourorg-YYYYMMDD/snapshot_index.json \
  --out /ABS/PATH/TO/bundle/replication_report.json \
  --notes "rerun on independent hardware"

Внутри bundle остаются все входы для аудита (пути к снимкам, snapshot_comparison.json, черновик отчёта). Дальше вы решаете, подписывать ли bundle и публиковать ли его как отдельный Zenodo record.

Упаковка bundle в архив + SHA‑256:

python3 benchmarks/nextstat-public-benchmarks/replication/package_replication_bundle.py \
  --bundle-dir /ABS/PATH/TO/bundle \
  --out-dir tmp/replication_bundle_out

Если вы хотите DOI для replication bundle (как отдельной публикации):

python3 benchmarks/nextstat-public-benchmarks/replication/package_replication_for_zenodo.py \
  --bundle-dir /ABS/PATH/TO/bundle \
  --out-dir tmp/replication_bundle_zenodo \
  --published-doi 10.5281/zenodo.18542624 \
  --published-url https://zenodo.org/records/18542624

6.Что мы будем делать с репликациями

Репликации не должны исчезать в ветке комментариев. Мы планируем:

• ›Связывать репликации напрямую с индексом снимков
• ›Использовать воспроизведённые числа в публичных утверждениях
• ›Предпочитать доказательство «перезапусти меня» вместо языка «поверь нам»

7.Просьба к сообществу

Если вам важно воспроизводимое научное вычисление, самый ценный вклад это:

• ›перезапустить опубликованный снимок на своём железе
• ›опубликовать свой манифест и сырые результаты
• ›подписать отчёт

Так утверждения о производительности становятся знанием сообщества.