Приемка сервера с ускорителями требует полной нагрузки

Сервер с ускорителями нельзя принимать по перечню компонентов и одному короткому тесту. Приемка должна доказать, что все карты одновременно выполняют расчетную нагрузку, память передает данные с ожидаемой скоростью, межкарточные маршруты соответствуют проекту, а охлаждение и питание удерживают результат после прогрева. Главная ошибка приемочной комиссии проста: она считает высокий разовый показатель подтверждением исправности. На практике сервер может выдать красивую цифру в первую минуту, затем снизить частоты из-за температуры или лимита мощности. Одна карта может работать быстро, пока остальные простаивают. Тест может пройти через медленный маршрут PCIe, хотя проект предполагал прямую связь ускорителей. Поэтому результатом приемки должна быть не отметка «тест пройден», а воспроизводимый пакет исходных данных, временных рядов, порогов и выводов.

Критерии надо согласовать до включения сервера

Приемку начинают с матрицы требований, а не с запуска случайного бенчмарка. В ней связывают каждое требование спецификации с методом проверки, измеряемой величиной, длительностью нагрузки, допустимым отклонением и артефактом, который попадет в протокол. Без этой матрицы стороны почти неизбежно спорят уже после теста: поставщик показывает результат одной карты, заказчик ожидает сумму по восьми, а документация на закупку не уточняет режим.

Зафиксируйте состав сервера: модели и количество ускорителей, объем памяти каждой карты, процессоры, оперативную память, накопители, сетевые адаптеры, блоки питания, версии BIOS и прошивок. Для программной части нужны ОС, ядро, драйвер, вычислительная среда, библиотека коллективных операций и версия самого теста. Записывайте не только названия пакетов, но и полный вывод команд инвентаризации. Номер версии без параметров запуска не позволяет повторить измерение.

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

Нормальный критерий задает нижнюю границу и разброс. Например, «каждая карта сохраняет не менее согласованного результата после 20 минут прогрева, разница между картами не превышает согласованный процент, ошибок вычислений и памяти нет». Конкретный процент зависит от платформы и нагрузки. Универсальные 90 или 95 процентов выглядят удобно, но без эталона они ничего не доказывают.

Разделите обязательные и информационные показатели. Обязательный критерий влияет на решение комиссии: ошибка памяти, неработающая линия, недобор согласованной скорости или запрещенное тепловое ограничение ведут к отклонению либо повторному испытанию после исправления. Информационный показатель описывает систему, но не имеет утвержденного порога. Такое разделение не дает задним числом превратить любопытную метрику в причину отказа или, наоборот, списать обязательный показатель в примечания.

Укажите границы объекта проверки. Ускорители зависят от процессоров, NUMA, оперативной памяти, PCIe, сетевых карт и питания, поэтому «тест GPU» часто проверяет весь узел. Если закупка включает несколько одинаковых серверов, заранее решите, проходит ли полный цикл каждый экземпляр или часть тестов выполняют по выборке. Для дорогой многокарточной системы я бы не принимал выборочную проверку производительности: перестановка райзера или кабеля делает каждый узел отдельной конфигурацией.

Оговорите условия помещения и стойки. Температура воздуха на входе, закрытые панели, занятые соседние юниты и профиль вентиляторов влияют на результат. Сервер, испытанный на столе со снятой крышкой, не прошел приемку для закрытой стойки. Перед тестом синхронизируйте время, освободите ускорители от посторонних процессов и сохраните исходные настройки питания и частот. Изменение лимита мощности ради красивой цифры допустимо только тогда, когда именно такой режим предусмотрен проектом и будет применяться в эксплуатации.

Инвентаризация ловит ошибки еще до нагрузки

До нагрузки надо подтвердить идентичность устройств, состояние линий и отсутствие накопленных аппаратных ошибок. Это не формальность: переставленная карта, линия PCIe меньшей ширины, неподходящий драйвер или активный чужой процесс способны исказить любой последующий тест.

Для системы с NVIDIA минимальный снимок состояния можно собрать так:

nvidia-smi -L
nvidia-smi topo -m
nvidia-smi -q -d PCI,ECC,POWER,TEMPERATURE,CLOCK
dcgmi discovery -l

Первая команда связывает индекс карты с моделью и UUID. Матрица topo -m показывает отношения между ускорителями, процессорами и сетевыми адаптерами. Подробный запрос фиксирует текущую и максимальную ширину PCIe, состояние ECC, лимиты мощности, температуры и частоты. Инвентаризация DCGM дает независимый перечень сущностей, которые увидит диагностический набор. Для AMD ту же роль выполняют AMD SMI и средства ROCm, но поля и имена команд надо зафиксировать под установленную версию, а не переносить синтаксис из чужого отчета.

Сравните UUID и адреса PCI с проектной схемой слотов. Индексы 0, 1, 2 могут поменяться после обновления прошивки или перестановки устройства, поэтому индекс не годится как постоянный идентификатор. В протоколе связывайте результаты с UUID, серийным номером, если он доступен, и адресом шины.

Проверьте текущую ширину и поколение линии под нагрузкой. В простое некоторые платформы снижают скорость связи для экономии энергии, поэтому низкое текущее значение без нагрузки еще не означает дефект. Но если линия остается в узком режиме во время передачи, ищите проблему в слоте, райзере, настройках BIOS или распределении линий процессора.

Счетчики ECC, PCIe replay и журналы ядра снимайте до и после каждого большого этапа. Важна разница между двумя снимками. Старый исправленный сбой может относиться к заводскому тесту, а рост счетчика во время вашей нагрузки прямо связывает событие с испытанием. Не обнуляйте счетчики до первого снимка, иначе потеряете исходное состояние поставленного сервера.

Быстрая диагностика подтверждает, что драйвер и библиотеки загружаются, контекст создается, а устройство доступно. Руководство NVIDIA DCGM прямо разделяет проверки готовности и активные аппаратные тесты: пропущенная проверка означает, что здоровье подсистемы не установлено, а не то, что она исправна. Поэтому статусы Pass, Fail, Warn и Skip надо хранить отдельно. Подменять Skip зеленой отметкой нельзя.

Вычисления и память проверяют разными нагрузками

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

В DCGM длинный набор включает диагностику вычислений, локальную пропускную способность памяти, целевую вычислительную нагрузку и нагрузку по мощности. Средний набор добавляет тесты памяти и PCIe к быстрой проверке программной среды. Документация DCGM описывает диагностический модуль как активную проверку, которой нужен исключительный доступ к картам. Это разумное ограничение: приемочный результат не должен зависеть от чужой задачи, которая забрала часть памяти или изменила частоты.

Пример воспроизводимой последовательности для всех доступных карт:

dcgmi diag -r 2 -j > dcgm-medium.json
dcgmi diag -r targeted_stress -p targeted_stress.test_duration=1200 -j > dcgm-compute.json
dcgmi diag -r memory_bandwidth -p memory_bandwidth.is_allowed=True -j > dcgm-memory.json

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

Вычислительный тест обязан проверять корректность, а не только число операций в секунду. DCGM Diagnostic Plugin сочетает крупные матричные умножения с записью и чтением разных областей кадрового буфера и отслеживает XID, неисправимые ошибки памяти и температурные нарушения. Для прикладного теста добавьте проверку результата по эталону или контрольной сумме. Быстрая, но неверная матрица не проходит приемку.

Нагрузите нужные форматы данных. Сервер для обучения моделей может зависеть от BF16 или FP16 и тензорных блоков, научный расчет может требовать FP64, а инференс может использовать FP8 или целые типы. Результат FP32 нельзя автоматически переносить на другой режим. В отчете рядом с производительностью укажите тип данных, размеры матриц, библиотеку, режим разреженности и разрешение на пониженное округление.

Отдельно исключите узкое место на стороне CPU. Генератор данных должен успевать снабжать все карты, а процессу нужны достаточные потоки и правильная привязка памяти. Если загрузка ускорителя плавает, сначала повторите тест с заранее подготовленными данными в памяти и проверьте загрузку процессоров. Приемка ускорителя не должна случайно превратиться в измерение медленного чтения с накопителя, если накопитель не входит в предмет этого этапа.

Смотрите на результат каждой карты, даже когда тест печатает только общую скорость. Инструмент, который распределяет работу неравномерно, может скрыть отключенный вычислительный блок или карту, получившую меньше задач. Телеметрия загрузки и мощности помогает увидеть такой перекос, но лучше выбрать тест с отдельным результатом по устройствам. Если это невозможно, выполните дополнительный одинаковый прогон на каждой карте и приложите его рядом с общей серией.

Тест памяти должен занимать существенную долю доступного объема и проходить по разным адресам, а не многократно читать маленький буфер из кэша. Разделяйте целостность и скорость. Шаблонная запись с последующей проверкой ловит ошибки ячеек и адресации; потоковое копирование или триада измеряет пропускную способность. Оба результата нужны, потому что исправная память может работать медленно из-за частотного режима, а быстрая передача не гарантирует безошибочное хранение по всему объему.

Все ускорители надо нагружать одновременно

Сервер принимают в проектном составе, поэтому главная серия должна одновременно загрузить все ускорители. Последовательный прогон по одной карте полезен для локализации дефекта, но он не проверяет общий бюджет питания, поток воздуха, пропускную способность процессорных корней и поведение коллективных операций.

Сначала измерьте каждую карту отдельно одинаковой командой. Этот прогон показывает выбросы: одна карта может заметно отставать из-за более узкой линии, другого лимита мощности или плохого контакта охлаждения. Затем повторите тот же тест на всех картах одновременно. Сравните не только сумму, но и значение каждой карты. Если общий результат вырос, а одна карта просела после прогрева, агрегат скрыл проблему.

Для однокарточной и общей серии сохраняйте одинаковые размеры задачи и достаточно большую очередь операций. Слишком маленькая матрица измеряет запуск ядер и работу процессора, а не установившуюся скорость ускорителя. Слишком маленький набор данных помещается в кэш и завышает впечатление от памяти. Размер должен удерживать устройство занятым и соответствовать инструменту, но не вызывать обмен с диском или аварийное завершение из-за нехватки памяти.

Продолжительность выбирают по установлению теплового режима, а не по красивому круглому числу. Двух минут достаточно для проверки запуска, но мало для тяжелого пассивно охлаждаемого ускорителя в плотном корпусе. Стройте график температуры и частоты. Когда обе кривые вышли на плато, продолжайте нагрузку еще согласованный интервал. Для многих серверов серия в 30-60 минут выявляет то, что не видно в пятиминутной диагностике, но сам интервал надо обосновать графиком и требованиями проекта.

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

Не запускайте разрушительные или неподдерживаемые утилиты только потому, что их называют «прожигом». Безопасный приемочный тест работает в штатных лимитах прошивки, не меняет напряжение, не отключает защиту и не прошивает устройства. Перед длительной нагрузкой подтвердите требования производителя к охлаждению и свободному пространству. Тест должен выявлять слабое место, а не создавать режим, запрещенный документацией.

Температура важна только вместе с частотой и причиной ограничения

Температурный график сам по себе не доказывает отсутствие троттлинга. Ускоритель может удерживать приемлемую температуру именно потому, что автоматика уже снизила частоту, либо упереться в лимит мощности при низкой температуре. На одной временной шкале нужны температура ядра и памяти, частоты вычислительных блоков и памяти, потребление, лимит мощности, загрузка и причины ограничения частот.

Руководство nvidia-smi различает программное ограничение по мощности, программное и аппаратное тепловое замедление, внешний сигнал Power Brake и другие причины событий частоты. Это полезнее общего слова «троттлинг». Ограничение по мощности при штатном лимите может быть нормальным поведением расчетной нагрузки, если сервер сохраняет согласованную производительность. Аппаратное тепловое замедление или Power Brake требуют разбирательства с охлаждением и питанием, даже когда средний результат еще проходит порог.

Соберите временной ряд с интервалом одна секунда или с частотой, которую поддерживает средство мониторинга без заметного влияния на тест. Для NVIDIA подойдет nvidia-smi dmon, который умеет писать мощность, температуры, загрузку, частоты, нарушения лимитов и ошибки. Для AMD SMI зафиксируйте аналогичные поля температуры, мощности, частот и причин ограничения. Не смешивайте мгновенные и усредненные показания без подписи: руководство NVIDIA, например, описывает потребление платы как среднее за последний интервал на поддерживаемых устройствах.

Смотрите на форму кривой. Исправная система обычно прогревается, выходит на устойчивый режим и сохраняет близкую производительность. Пилообразные частоты вместе с касанием температурного предела указывают на циклическое ограничение. Постепенное падение частоты при росте температуры показывает нехватку теплового запаса. Одновременная просадка всех карт при росте мощности может указывать на общий лимит питания, а просадка одной карты чаще связана с ее каналом охлаждения, слотом или настройкой.

Температурный порог берите из документации конкретной модели и телеметрии устройства. Нельзя объявлять единое значение для любой карты: разные модули показывают разные датчики и имеют разные целевые температуры. Некоторые пассивные ускорители полагаются на вентиляторы корпуса и могут не отдавать все типы показаний. Отсутствующее поле надо пометить как недоступное, а не подставлять ноль.

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

Схема слотов должна совпасть с реальной топологией

Топологию принимают по фактическим путям между устройствами, а не по количеству установленных карт. Два сервера с одинаковыми ускорителями могут дать разную скорость коллективных операций, если карты подключены к разным корневым комплексам PCIe, связь проходит через процессорный межсокетный канал или проектный мост не поднялся.

Сначала сопоставьте физические слоты, адреса PCI и матрицу nvidia-smi topo -m либо эквивалент производителя. Матрица показывает относительный маршрут: прямая межкарточная связь, один или несколько мостов PCIe, общий корневой комплекс, переход через процессорный интерфейс. Она также показывает близость сетевых адаптеров и процессорную аффинность. Это важно для серверов, где данные приходят с высокоскоростной сети прямо к ускорителям.

Затем проверьте разрешение прямого доступа между каждой парой. Наличие двух карт еще не означает, что приложение может передавать данные напрямую. Режим зависит от аппаратной поддержки, драйвера, настроек виртуализации и IOMMU. Если прямой доступ недоступен, данные могут пройти через память хоста, а задержка и нагрузка на процессор вырастут.

Топологическая метка не равна измеренной скорости. Она говорит, каким путем пойдут данные, но не доказывает ширину, состояние линии и отсутствие конкуренции. Поэтому отчет, где есть только снимок topo -m, неполон. После схемы нужна матрица фактической пропускной способности и задержки для всех направленных пар.

Проверьте также связь «ускоритель - процессорная память» в обоих направлениях. Для загрузки моделей и потоковой обработки важны host-to-device и device-to-host. Закрепите процесс на процессорном узле, близком к тестируемой карте, затем повторите на удаленном узле. Большая разница объясняет цену NUMA и помогает проверить, правильно ли служба будет привязана в эксплуатации. Не усредняйте близкий и удаленный маршрут в одно число.

Если спецификация обещает отдельную межкарточную фабрику, запросите состояние всех ее линий и счетчики ошибок. Прямой маршрут может существовать, но работать с меньшим числом активных линий. Именно здесь схема поставки, телеметрия и измерение должны совпасть.

Межкарточную связь измеряют полной матрицей

Пропускную способность между картами надо измерять для каждой направленной пары и отдельно для одновременного обмена. Проверка только пары 0 и 1 не замечает неверно установленную четвертую карту, асимметричный маршрут или конкуренцию нескольких передач за один мост.

CUDA sample p2pBandwidthLatencyTest проверяет возможность прямого доступа, пропускную способность и задержку между парами GPU. Его вывод представляет собой матрицы, где строки и столбцы соответствуют устройствам. Сохраните матрицу с включенным и отключенным прямым доступом, если инструмент и платформа это позволяют. Разница показывает, что прямой путь действительно работает, а не только объявлен драйвером.

Для серверов, которые будут обучать модели на нескольких картах, добавьте коллективный тест. Официальный набор NVIDIA NCCL Tests запускает all_reduce_perf на заданном числе устройств и выводит размер сообщения, время, алгоритмическую пропускную способность, busbw и число ошибок. В документации набора отдельно объясняется, что algbw и busbw нельзя считать одним и тем же: busbw нормализует результат с учетом обменов конкретной коллективной операции. Сравнивайте одинаковый столбец, одинаковое число карт и одинаковый размер сообщения.

Пример односерверного прогона на восьми картах:

./build/all_reduce_perf -b 8 -e 8G -f 2 -g 8 -n 50 -w 10

Здесь диапазон размеров показывает, где задержка уступает место пропускной способности, десять прогревочных итераций убирают холодный запуск, а пятьдесят измеряемых повторов дают материал для оценки разброса. Число карт должно совпадать с поставкой. Если сервер содержит другое количество, параметр -g меняют, а команду целиком сохраняют в протоколе.

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

Сначала прогоните одну пару за раз, затем несколько непересекающихся пар и, наконец, коллективную операцию на всех картах. Если каждая пара по отдельности быстрая, а одновременный обмен проседает, вы нашли общий ресурс: мост, корневой комплекс, межсокетный канал или настройку фабрики. Это и есть причина не ограничиваться суммой однопарных результатов.

Повторяемость важнее лучшего результата

Исправный сервер дает узкий и объяснимый разброс после одинакового прогрева. Лучший результат в серии почти бесполезен для приемки, потому что он отбирает удачный запуск и скрывает редкие ошибки, фоновые процессы и тепловую нестабильность.

Храните результат каждой итерации, а не только среднее. Для производительности полезны медиана, минимум, максимум и один из процентилей нижней части распределения. Выбор статистики зафиксируйте заранее. Если в техническом задании указан минимум, нельзя заменить его средним после теста.

Сравнивайте четыре среза: одна карта против такой же карты, холодный запуск против горячего, одиночная нагрузка против одновременной, первый прогон против повторов. Каждый срез отвечает на отдельный вопрос. Межкарточный разброс ищет локальный дефект, горячий запуск проверяет охлаждение, одновременная серия проверяет общие ресурсы, повторы показывают нестабильность.

Любой выброс надо связать с телеметрией и журналами по времени. Просадка вместе с тепловым ограничением говорит об охлаждении. Просадка без изменения частот, но с ростом PCIe replay указывает на путь ввода-вывода. Пауза всех карт при сообщении ядра может быть проблемой драйвера или сбросом устройства. Если часы не синхронизированы, это расследование превращается в догадки.

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

Разницу результатов иногда создает автоматическая настройка библиотек. Первый запуск подбирает алгоритм, создает кэш или компилирует ядра, поэтому его нельзя молча смешивать с установившимися итерациями. Отделяйте прогрев от измерения и храните число прогревочных повторов. Если кэш сохраняется между сериями, либо очищайте его по утвержденной процедуре, либо честно считайте это штатным горячим состоянием.

После сбоя не перезапускайте тест молча. Сохраните неудачный вывод, журналы ядра, состояние драйвера, новые счетчики ошибок и только затем повторяйте. Успешный повтор не отменяет первого события. В протоколе должны остаться оба результата и объяснение исправления, если вы меняли кабель, слот, прошивку, параметры BIOS или охлаждение.

Допустима ли небольшая разница между одинаковыми картами? Да, если она укладывается в заранее согласованный коридор, не растет после прогрева и не связана с ошибками или ограничениями. Нельзя объявлять любую разницу дефектом, но еще хуже подгонять коридор после того, как одна карта уже показала низкий результат.

Прикладной тест подтверждает пригодность, а не заменяет диагностику

Синтетические тесты находят дефекты и дают сравнимые числа, но финальный прогон должен воспроизводить форму будущей работы. Он подтверждает, что выбранные драйверы, библиотеки, тип данных, размеры пакетов и схема распределения действительно работают вместе.

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

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

Контейнер не делает результат автоматически воспроизводимым. Зафиксируйте образ по неизменяемому идентификатору, команду запуска, переменные окружения, доступные устройства, привязку CPU и NUMA, смонтированные данные и лимиты ресурсов. Тег latest для приемки непригоден, потому что завтра он может указывать на другой образ.

Не обновляйте драйвер между синтетическим и прикладным этапом без повторения предыдущих тестов. Измененная программная среда создает новый объект проверки. То же относится к обновлению BIOS, прошивки ускорителя, библиотеки коллективных операций или профиля мощности.

В проектах инфраструктуры для ИИ GSE.kz может связать конфигурацию сервера, интеграцию программного стека и дальнейшую поддержку, но приемочные пороги все равно нужно записать в техническом задании до поставки. Ни производитель, ни интегратор не должен угадывать, какой режим заказчик считает рабочим.

Протокол должен позволять повторить каждый вывод

Хороший протокол приемки позволяет другому инженеру повторить тест без устных пояснений. Скриншоты терминала плохо подходят для этой задачи: на них теряются команды, часть строк, машинное время и исходные файлы. Сохраняйте текстовые и структурированные результаты, а в протокол включайте контрольные суммы файлов.

Для каждого этапа запишите цель, команду, начальное состояние, время начала и конца, температуру воздуха на входе, идентификаторы устройств, версии ПО, критерий, фактический результат и решение. Рядом укажите пути к сырым логам в архиве поставки. Если инструмент вернул код завершения, сохраните и его.

Итоговую ведомость удобно строить из семи полей: ID проверки, название, конфигурация, критерий, фактическое значение, имя артефакта и решение. Для вычислений укажите тип данных, размер и версии; для памяти добавьте проверенный объем и шаблон; для теплового режима сохраните максимумы и временной ряд; для связи приложите матрицу пар и busbw. Одинаковая форма строк упрощает проверку полноты, но содержание критерия всегда остается конкретным для этапа.

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

Архив должен содержать исходную спецификацию, снимки инвентаризации, проектную и фактическую топологию, команды или сценарии запуска, сырые результаты, телеметрию, системные журналы, сведения об исправлениях и подписанный итог. Проверьте, что файлы открываются на отдельной машине и не зависят от истории оболочки испытателя.

Названия файлов должны связываться с ID проверки и временем, а не с пометками вроде final2. Для больших журналов укажите контрольную сумму и часовой пояс. Секреты, токены доступа и персональные данные удалите до передачи архива, но не редактируйте измерения вручную. Если журнал приходится очищать, сохраните сценарий фильтрации и исходник в защищенной части комплекта, чтобы комиссия могла подтвердить происхождение результата. Подписи сторон ставят после проверки состава архива, потому что один итоговый документ без сырых данных не дает доказать ни длительность нагрузки, ни состояние отдельных карт.

Не принимайте сервер, если тест не запускался из-за отсутствующего плагина, если результат получен только на части карт, если телеметрия оборвалась до прогрева или если порог придумали после измерения. Эти случаи означают «доказательств недостаточно». Дополнительный прогон стоит дешевле спора о производительности уже после ввода системы в эксплуатацию.