Наступление доверия: публичные бенчмарки

Бенчмарки легко сделать неправильно даже без злого умысла:

• ›разные входы
• ›разные настройки
• ›разная политика прогрева
• ›разные режимы компиляции
• ›разные предположения о «эталонной корректности»

В научном софте это создает разрыв доверия: пользователь не может понять, является ли заявление о производительности осмысленным, стабильным и воспроизводимым.

Если нужен не нарратив, а спецификация (что меряем, как публикуем, что закрепляем), начните отсюда: спецификация публичных бенчмарков.

0.Термины и контракты (что именно означает «воспроизводимо»)

В этой серии мы используем несколько терминов как строгие контрактные слова, а не как метафоры.

• ›Снимок (snapshot) — неизменяемая директория артефактов, которая включает исходные JSON-результаты, инвентарь файлов и манифест окружения. Минимальный набор: baseline_manifest.json + snapshot_index.json + suite JSON (например, HEP: hep/hep_suite.json и per-case файлы).
• ›Валидация (validation) — не «проверили глазами», а машина-гейт, который должен пройти каждый кейс до того, как измерения времени считаются допустимыми. В HEP это, например, паритет NLL/градиентов в пределах явного допуска (эталон: pyhf/ROOT в зависимости от кейса).
• ›Репликация (replication) — воспроизведение опубликованного снимка сторонней командой с автоматическим сравнением артефактов: формируется rerun-снимок, затем строится машинный diff в snapshot_comparison.json (schema nextstat.snapshot_comparison.v1).

Канонические JSON-схемы (которые использует харнесс публикации) живут в репозитории NextStat: benchmarks/nextstat-public-benchmarks/manifests/schema/. Генерация снимка делается seed-скриптом scripts/publish_snapshot.py, а репликация — парой replication/make_rerun_bundle.py и replication/compare_snapshots.py.

Серия (рекомендуемый порядок чтения)

1. ›Наступление доверия: публичные бенчмарки (этот пост) — словарь, модель доверия и критерии «воспроизводимо».
2. ›Конец эры скриптов — что такое «перезапускаемое свидетельство» и почему нарратив без артефактов не является доказательством.
3. ›Снапшоты бенчмарков как продукт — точный состав snapshot-директории, роль манифестов и инвентаря файлов.
4. ›Репликация третьими сторонами: подписанные отчёты — как делается rerun + машинный diff + человекочитаемый отчёт.
5. ›Надежный HEP-бенчмарк-харнесс — протокол измерений + гейты корректности (паритет NLL до секундомера).
6. ›Численная корректность — ROOT/pyhf/NextStat и типовые режимы расхождений с воспроизводимыми артефактами.
7. ›Дифференцируемый HistFactory в PyTorch — дифференцируемость как контракт (FD-гейты, envelope градиенты).
8. ›Байесовские бенчмарки: ESS/сек — метрики качества вывода + протокол (warmup/seed/accept/divergences).
9. ›Фарма-бенчмарки: PK/NLME — стабильные синтетические наборы данных + контроль корректности фитов.
10. ›JAX: компиляция против выполнения — честное разделение latency (compile) и throughput (execute).

Сопроводительная документация (канонические руководства по перезапуску)

Посты в блоге объясняют почему и что это означает. Документация объясняет как это перезапустить.

Начните здесь:

• ›Спецификация публичных бенчмарков — что измеряем, что публикуем, что закрепляем.
• ›Результаты бенчмарков — воспроизводимые снимки производительности по вертикалям.

1.Что мы бенчмаркаем (и что нет)

Мы бенчмаркаем сквозные (end-to-end) рабочие процессы, которые реально запускают пользователи, а не только микрокернелы:

• ›ФВЭ / HistFactory: оценка NLL, градиенты, MLE-фиты, профильные сканы, ансамбли тоев
• ›Фарма: правдоподобие PK/NLME и циклы фита
• ›Байесовский вывод: ESS/сек при полностью заданных настройках вывода
• ›ML-инфраструктура: задержка компиляции против пропускной способности выполнения (например, JAX)
• ›Временные ряды: пропускная способность фильтра/сглаживателя Калмана, стоимость сходимости EM
• ›Эконометрика: Panel FE, DiD, IV/2SLS, масштабирование по числу кластеров

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

Не цели: разовые «герой-цифры», непубликуемые скрипты оснастки, производительность без гейтов корректности.

2.Самое сложное: сделать бенчмарки заслуживающими доверия

A. «Быстро», потому что делает не то же самое

Для конвейеров на бинированном правдоподобии бенчмарк бессмысленен, если реализация не является численно согласованной с эталоном. Наше правило: до измерения времени оснастка проверяет корректность в рамках явного допуска.

система отчетов валидации (validation report) формализует это: каждый опубликованный снимок включает validation_report.json с SHA-256 хешами наборов данных, спецификациями моделей и гейтами по каждому набору: «прошёл/не прошёл».

B. «Быстро», потому что прогрев устроен иначе

JIT-компиляция, кеширование, загрузка GPU-ядер, аллокаторы памяти и стоимость импортов Python могут доминировать в наивных измерениях. Каждый бенчмарк обязан задавать политику прогрева, окно измерения в стационарном режиме (steady-state) и то, что включено/исключено (время компиляции и время выполнения).

C. Окружение не закреплено

Научные вычисления очень чувствительны к версиям компилятора, бэкендам BLAS, GPU-драйверам и ограничениям зависимостей Python. Каждый опубликованный снимок включает манифест окружения.

D. Публикуется только одна «удобная» статистика

Одна цифра скрывает дисперсию. Наше правило: публиковать сырые измерения по тестам и явную политику агрегации (например, медиана или min-of-N).

3.Что мы публикуем

• ›Сырые результаты по кейсам и повторам (suite JSON + per-case JSON).
• ›Baseline manifest — манифест окружения и входов: baseline_manifest.json (хеши датасетов, commit SHA харнесса, версия NextStat, детерминизм/флаги).
• ›Snapshot index — инвентарь всех файлов с SHA-256: snapshot_index.json.
• ›Валидация как формальный гейт (паритет/корректность), который либо проходит, либо останавливает публикацию.
• ›validation_report.json + опциональный PDF через nextstat validation-report

4.Производительность как научное утверждение

В исследованиях мы не принимаем «у меня на машине работало» как доказательство результата. Производительность нужно трактовать так же, особенно когда она меняет границы возможного:

• ›ансамбли тоев становятся практичными в масштабе 10³–10⁵
• ›профильные сканы становятся интерактивными
• ›ML-обучение может оптимизировать метрики вывода напрямую, а не суррогаты

Если бенчмарк нельзя воспроизвести — это не доказательство. Это анекдот.

5.Наборы (suites)

6.Просьба: перезапустите

Публичные бенчмарки работают только если другие команды их перезапускают. Самый ценный вклад:

• ›перезапустить опубликованный снимок на своем железе и получить rerun-снимок (тот же контракт артефактов)
• ›приложить машинное сравнение snapshot_comparison.json и указать, какие гейты прошли/не прошли
• ›сообщить, что расходится (цифры, настройки, входы, режимы детерминизма)

Так «быстро» становится «заслуживающим доверия».