1. Qualification cell — единица охвата
Каждый результат принадлежит qualification cell: одной точной комбинации коммерческого устройства, firmware и BIOS, ОС и ядра, драйверного стека GPU, сборки runtime, файла модели с известным хэшем, квантизации, настроек контекста и KV, команды запуска и ревизии workload. Полный system fingerprint фиксируется до измерений.
Изменение любого одного критического слоя создаёт новую cell. Результаты никогда не переносятся молча на другой драйвер, другую сборку runtime, другую ревизию модели или вариант устройства. Публичная карточка конфигурации описывает протестированную cell — а не все версии устройства.
2. Предрегистрация до headline-прогонов
До любых headline-прогонов в документе предрегистрации фиксируются:
- основной вопрос и системы с их критическими версиями;
- ревизия workload и правило выбора модели;
- cells, число повторов и headline-метрики;
- quality gates и правила исключения/инвалидации;
- запланированные сравнения и условия расширения scope.
После предрегистрации headline-метрику, правила исключения и configuration cells нельзя менять без новой ревизии. Exploratory-прогоны разрешены, но маркируются отдельно и никогда не подменяют предрегистрированный результат.
3. Жизненный цикл run и инвалидация
Каждый run проходит фиксированный жизненный цикл:
draft → preregistered → environment-captured → warmup → measured → derived → reviewed → published | private-delivered → superseded | retracted
Run становится invalid — сохраняется в журнале, но исключается из headline-заявлений — в частности, если:
- хэш runtime или модели неизвестен или не совпадает с предрегистрированной ревизией;
- произошёл незаметный device fallback — например, workload, предназначенный для GPU, тихо выполнился на CPU;
- warmup-трафик попал в измеряемый интервал, или холодный старт смешан с warm serving latency;
- оператор изменил конфигурацию системы во время run;
- не соблюдена целевая геометрия вывода, дрейф часов телеметрии сделал временные ряды несопоставимыми, или benchmark-клиент исчерпал собственные ресурсы;
- число failed requests невозможно определить.
Failed requests никогда не исчезают из знаменателя. Запрос, завершившийся таймаутом или ошибкой, засчитывается против run, даже если у него нет данных о таймингах. Вместе с результатом публикуется учёт запросов по каждой cell: scheduled, started, completed valid, functional failures, timeouts, transport errors, server errors, invalid outputs, cancelled. После OOM или падения run не продолжается как валидный; восстановление требует нового идентификатора run.
4. Повторы и разброс
Headline cell требует не менее трёх независимых измеренных прогонов. Индивидуальные значения прогонов публикуются, а headline-число — медиана, если методика workload не задаёт иное.
Если разброс между прогонами шире внутреннего порога контроля качества, выполняются дополнительные прогоны или устанавливается причина до публикации числа. Этот порог — внутреннее QC-правило AGmind, а не отраслевой стандарт.
Хвостовые перцентили публикуются только тогда, когда число валидных наблюдений достигает внутренних минимумов, и размер выборки показывается рядом со значением. При меньшей выборке вместо перцентилей показываются сырое распределение, медиана и диапазон с явной пометкой о недостаточной выборке. Таймауты и ошибки остаются видимыми в каждом распределении.
5. Типы claims: controlled, system, diagnostic
- Controlled — между условиями меняется ровно один фактор. Разрешены относительные утверждения об этом факторе.
- System — сравниваются готовые конфигурации в том виде, в каком они поставляются. Разрешены только параллельные observed values с раскрытием всех известных различий; результат не приписывается какому-либо одному компоненту.
- Diagnostic — микробенчмарки и пробы. Их результаты никогда не экстраполируются на пользовательскую ёмкость.
6. Порог качества
Любая performance-рекомендация требует заранее заданных quality или functional gates — например: server/API contract, валидность JSON и схемы, язык вывода, обнаружение повторов и collapse, корректность задачи, retrieval и поддержка цитирования, выполнение функций, воздержание на unanswerable-входах. Если ни один gate не проверялся, результат несёт явную пометку:
Performance-only; quality not qualified.
7. Длинный контекст: пять различных уровней
«Поддерживает длинный контекст» — это не одно свойство. Методология различает:
- Configured context — то, что runtime настроен принимать.
- Loadable context — то, что реально загружается без сбоя.
- Successfully completed context — то, на чём запросы завершаются от начала до конца.
- Quality-preserving context — то, где качество вывода держится относительно короткоконтекстного контроля.
- Recommended context — то, что AGmind рекомендует под конкретный workload и SLO.
Минимальный набор long-context тестов включает короткоконтекстный контроль, позиционно-сбалансированные задачи, multi-hop и агрегирующие задачи, unanswerable-контроль, обнаружение повторов/collapse и кривую latency/памяти по длинам контекста.
8. Минимум endurance
Публичный endurance-результат требует сессии непрерывной активной нагрузки не короче фиксированной минимальной длительности, заданной методикой, с отдельной фазой drain, на фиксированных workload и cell. Пропускная способность, задержки и ошибки публикуются по временным интервалам вместе с температурой, частотами, утилизацией и источником питания. События троттлинга, рост памяти и любые перезапуски, падения и восстановления фиксируются в журнале run.
9. Репликация между экземплярами
Когда в лаборатории есть два одинаковых коммерческих экземпляра, headline anchor points повторяются на втором устройстве. Это не делает выборку репрезентативной для всей производственной партии, но отделяет повторяемость между прогонами от возможности одного аномального экземпляра.
10. Словарь вердиктов
Вердикты берутся из фиксированного словаря. Вердикт всегда относится к конкретной версии, workload и acceptance criteria — и никогда к устройству в целом.
| Вердикт | Значение |
|---|---|
| PASS | Acceptance criteria выполнены при протестированных условиях. |
| PASS WITH LIMITS | Критерии выполнены только в рамках задокументированных ограничений — конкретных настроек, суженного scope или явных оговорок. |
| PARTIAL | Часть acceptance criteria выполнена, часть — нет; разбивка перечисляется. |
| FAIL | Acceptance criteria не выполнены при протестированных условиях. |
| NOT REPRODUCED UNDER TESTED CONDITIONS | Внешнее заявление проверялось и не воспроизвелось в данной cell. Это не утверждение, что исходный результат ложен везде. |
| INDETERMINATE | Собранных свидетельств недостаточно, чтобы вынести вердикт в любую сторону. |
| BLOCKED BY UPSTREAM | Тестирование не смогло продолжиться из-за upstream-дефекта или зависимости вне контроля тестируемой системы. |
| NOT TESTED | Вне протестированного scope. Никакие выводы — ни положительные, ни отрицательные — не допускаются. |
11. Исправления, superseded и retracted
Исправления публикуются, а не скрываются. Каждое исправление получает дату, причину и список затронутых claims. Затронутый claim маркируется superseded или retracted; старый отчёт остаётся доступным или архивируется с явным redirect. Исправленные цифры пересчитываются из исходных данных и никогда не правятся вручную. Материальные ошибки перечисляются на странице errata, а headline-страницы обновляются из реестра claims.
12. Чего эта методология не утверждает
- соответствия MLPerf или любой другой внешней бенчмарк-программе;
- статистической репрезентативности всего рынка устройств или производственной партии;
- пригодности для любого workload, который не тестировался;
- безопасности продукта или каких-либо выводов о regulatory compliance;
- долговременной поддержки будущих версий firmware, драйверов, runtime или моделей;
- причинности, если между условиями менялся более чем один фактор.