Как составить протокол проверки охлаждения GPU-сервера в стойке

GPU-сервер можно нагрузить, увидеть приемлемую температуру accelerators и сделать вывод:

«Охлаждение справляется».

Но одной температуры для такого вывода недостаточно.

Без контекста неизвестно:

• какая температура воздуха была непосредственно на входе сервера;

• какую мощность реально потребляли GPU;

• сохранялись ли рабочие частоты;

• возникали ли thermal-, power- или platform-related clock events;

• насколько тяжёлой была workload;

• сохранялась ли application performance;

• одинаково ли вели себя все accelerators;

• где именно сервер находился в стойке.

Поэтому thermal validation GPU-сервера — это не поиск одной «нормальной температуры».

Рабочая последовательность:

Exact Server / BOM → Rack Position + Airflow Direction → Vendor / Facility Limits → Inlet Conditions → Power / Fan Baseline → Reproducible Workload → Synchronized Telemetry → Idle → Ramp → Sustained Window → Temperature + Power + Clocks + Event Reason + Performance → Cooldown → Classification → Predefined Criteria → Evidence Pack.

Главный принцип:

Температуру GPU нужно интерпретировать вместе с inlet conditions, workload, board power, clocks, event reasons и фактической производительностью.

Сначала определите границы проверки

Вопрос должен звучать не:

«Хорошо ли охлаждается эта модель сервера?»

А:

Обеспечивает ли конкретная rack position согласованный режим работы конкретного GPU-сервера при зафиксированных inlet conditions и workload?

Это принципиально.

Если test выполнен:

• в Rack A;

• в определённых U;

• при конкретной inlet temperature;

• с конкретным BIOS и thermal profile;

• при конкретном GPU power limit;

• на одной workload,

результат нельзя автоматически переносить на:

• другую стойку;

• другое помещение;

• другой BOM;

• другую cooling architecture;

• другой power profile.

Поэтому:

Thermal Result for One Configuration ≠ Universal Platform Result.

Не начинайте с универсальной «нормальной температуры GPU»

Один threshold для всех accelerators не существует.

Допустимая operating envelope зависит от:

• exact GPU SKU;

• server platform;

• cooling implementation;

• firmware;

• power configuration;

• manufacturer requirements.

Правильный acceptance criterion выглядит не так:

GPU должна быть холоднее X °C.

А так:

оборудование должно оставаться внутри документированных vendor limits и согласованной operating envelope, без запрещённых thermal-related events и с требуемой performance.

Поэтому:

Temperature Number without Device Limit ≠ PASS/FAIL Criterion.

ASHRAE — ориентир для facility, а не универсальный threshold GPU

ASHRAE рассматривает environmental conditions на equipment inlet как ключевой интерфейс между air-cooled IT equipment и facility.

В guidance также подчёркивается ценность granular rack-inlet monitoring для обнаружения recirculation и неравномерных условий в стойке.

Но ASHRAE не заменяет документацию конкретного сервера.

Практический порядок:

Exact Vendor / Platform Requirement

→ Project Requirement

→ ASHRAE Facility Guidance.

Не наоборот.

High-density GPU server не означает автоматически ASHRAE H1

ASHRAE использует отдельные environmental classes для datacom equipment, включая high-density class H1.

Но наличие мощных GPU само по себе ещё не доказывает, что конкретная платформа классифицирована производителем именно таким образом.

Поэтому:

High-Density GPU Server ≠ Automatically H1-Classified Equipment.

Для acceptance используйте documentation exact platform.

Room temperature и server inlet — разные данные

Датчик помещения может показывать нормальную температуру, а конкретный server intake получать более горячий воздух из-за:

• exhaust recirculation;

• bypass airflow;

• высокой rack density;

• соседних систем;

• незакрытых U;

• особенностей containment.

Поэтому:

Room Temperature ≠ Server Inlet Temperature.

В thermal protocol нужно сохранять именно rack/server inlet conditions.

Положение inlet sensor нужно документировать

Запишите:

• sensor ID/type;

• rack ID;

• U position;

• положение относительно server intake;

• расстояние от rack face;

• sampling interval;

• timestamp source.

Для высокой или неоднородно загруженной стойки может быть полезно несколько inlet points.

Но не устанавливайте универсальное правило:

всегда должно быть ровно N датчиков.

Instrumentation должна соответствовать задаче.

Blanking panels и airflow management важны, но не являются verdict сами по себе

Открытые пространства в стойке способны усиливать bypass и recirculation.

Поэтому в Rack Condition Card стоит фиксировать:

• empty U;

• blanking panels;

• cable obstruction;

• containment;

• door state.

Но:

отсутствует blanking panel

ещё не равно:

thermal FAIL.

Это потенциальная причина, которую нужно связать с measurement.

Зафиксируйте airflow direction оборудования

Большинство rack servers рассчитано на определённое направление воздушного потока, часто front-to-rear, но возможны и другие схемы.

Поэтому в Rack Condition Card добавить:

Equipment Airflow Direction.

Главная формула:

Rack Orientation Must Match Equipment Airflow Design.

Cooling architecture должна быть указана

Минимально:

• air-cooled;

• direct-liquid-cooled;

• hybrid;

• rack-assisted cooling, если применимо.

Основная методика статьи относится к air-cooled rack validation.

Для liquid-cooled platform нужны уже другие facility variables:

• coolant supply;

• return;

• flow;

• pressure;

• CDU state;

• alarms.

И значения должны происходить из exact vendor requirements.

Зафиксируйте точный BOM

Thermal behaviour относится к конкретной configuration.

Сохраните:

• server model/SKU;

• GPU SKU × count;

• CPU;

• RAM;

• storage;

• NIC;

• PSU;

• BIOS;

• BMC;

• GPU firmware;

• driver;

• cooling options.

Другой BOM способен изменить:

• тепловую нагрузку;

• internal airflow;

• fan behaviour;

• obstruction внутри chassis.

Power configuration тоже часть thermal baseline

До run зафиксируйте:

• GPU power limit;

• CPU power profile;

• BIOS performance profile;

• BMC thermal policy;

• fan profile;

• application clocks, если применимо.

Нельзя сравнивать:

Run A

с reduced GPU power limit

и:

Run B

с другим limit

как чистое изменение охлаждения.

Fan Policy Change → New Thermal Test Context

Если между runs изменились:

• fan mode;

• BIOS thermal policy;

• BMC cooling profile,

следующий run относится к другой configuration.

Это нужно явно записать в evidence.

Нагрузка должна быть воспроизводимой

Фраза:

«нагрузили сервер на максимум»

не является test definition.

Load Definition Card:

Controlled stress и target workload отвечают на разные вопросы

Controlled stress

Позволяет воспроизводимо создать:

• compute load;

• memory load;

• board-power load.

Representative workload

Показывает поведение на реальном:

• inference;

• training;

• rendering;

• simulation;

• другом application workload.

Сильный protocol может использовать:

Controlled Stress

и отдельно:

Representative Workload.

NVIDIA DCGM Diagnostic — один из вариантов controlled load

Current DCGM diagnostic plugin выполняет sustained matrix workload, проверяет correctness и одновременно отслеживает hardware/thermal conditions.

Он также может выполнять cross-GPU comparisons по throughput, clocks и board power, если соответствующие tolerances включены.

То есть:

cross-GPU outlier detection

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

Её configuration нужно сохранить.

И:

DCGM Diagnostic PASS ≠ Universal Rack Cooling PASS.

Default duration diagnostic tool не является duration проекта

Vendor tool может иметь default duration.

Но:

Tool Default Duration ≠ Project Thermal Validation Duration.

Продолжительность thermal test определяется:

• workload;

• risk;

• platform;

• acceptance plan;

• временем выхода на representative sustained state.

Для power-focused run у DCGM есть targeted_power

Current targeted_power создаёт sustained matrix-compute workload и пытается привести GPU к configured board-power target.

PASS определяется относительно target и minimum ratio, а installed SKU configuration обычно предоставляет product-specific target.

Generic plugin fallback существует, но сам по себе не является подходящим engineering target.

Поэтому:

Plugin Fallback ≠ Appropriate Acceptance Target.

И не нужно описывать targeted_power как:

«тест максимального TDP».

Точнее:

sustained workload toward a configured board-power target.

Если enforced power limit ниже target, это не hardware FAIL

Current DCGM отдельно обрабатывает ситуацию, когда установленный power limit делает configured target недостижимым: такой result относится к configuration constraint и может быть SKIP, а не свидетельством дефекта GPU.

Поэтому:

Targeted-Power SKIP due to Enforced Limit ≠ GPU Power Failure.

Сначала исправьте test target или baseline.

FAIL targeted_power тоже требует интерпретации

FAIL может возникнуть не только потому, что GPU не достигла power target.

Возможны также:

• telemetry error;

• CUDA setup failure;

• host-memory problem;

• DCGM API/internal error;

• XID;

• thermal condition;

• memory error.

Поэтому:

Tool FAIL ≠ Root Cause.

Читайте:

Status + Error Code + Message + Context.

Board power и total server power — разные вещи

DCGM работает с GPU board-power telemetry.

Но:

GPU Board Power ≠ Total Server Power.

В total server power входят:

• CPU;

• memory;

• NIC;

• storage;

• fans;

• PSU losses;

• другие components.

Если цель — capacity/facility validation, потребуется отдельная server/rack electrical measurement.

Nameplate power тоже не равно фактической тепловой нагрузке

Максимальная PSU/nameplate rating — это не измеренная потребляемая мощность конкретного run.

Поэтому:

Nameplate Power ≠ Measured Heat Load.

Для thermal interpretation важна фактическая нагрузка при tested workload.

Temperature without Power / Load Context = Weak Thermal Evidence

Одинаковая temperature при:

• высокой board power;

и:

• существенно более низкой board power

не описывает одинаковый thermal condition.

Поэтому temperature в отчёте всегда должна находиться рядом с:

• workload;

• utilization;

• power.

Clocks тоже нужно анализировать вместе с temperature

Если temperature стабилизировалась, а clocks снизились, нужно понять:

почему?

Current DCGM имеет отдельные clock-event reasons:

• GPU idle;

• application clock settings;

• software power cap;

• generic hardware slowdown;

• sync boost;

• software thermal slowdown;

• hardware thermal slowdown;

• hardware power brake.

Поэтому:

Clock Drop ≠ Thermal Throttling by Definition.

SW_POWER_CAP не является thermal throttling

Current DCGM использует SW_POWER_CAP, когда clocks ограничены для соблюдения установленного power limit.

Поэтому:

Power-Limited ≠ Thermally Throttled.

SW_THERMAL — конкретный thermal signal

Current DCGM описывает SW_THERMAL как программное управление clocks для удержания GPU и memory temperatures внутри maximum operating limits.

Это уже thermal-related evidence.

Но оно не означает:

аппаратная авария.

Корректнее:

SW Thermal Slowdown = Thermal Control Action.

HW_THERMAL — более сильный hardware thermal event

Current HW_THERMAL означает hardware thermal slowdown из-за слишком высокой temperature с существенным снижением core clocks.

Такое событие требует investigation.

Но project disposition всё равно должен быть определён test plan заранее.

HW_SLOWDOWN нельзя автоматически считать thermal

Это особенно важная граница.

Generic HW_SLOWDOWN в DCGM может быть связан с:

• слишком высокой temperature;

• external power-brake assertion;

• чрезмерным power draw / protection;

• некоторыми P-state/clock changes.

Поэтому:

HW_SLOWDOWN ≠ Thermal Cause by Definition.

Нужна дальнейшая классификация.

HW_POWER_BRAKE — ещё одна отдельная причина

Current DCGM связывает HW_POWER_BRAKE с external hardware power-brake assertion, например со стороны system power supply.

Если event именно такой, first branch investigation:

power/platform delivery,

а не автоматический вывод:

охлаждение стойки недостаточно.

Сильная thermal interpretation использует несколько сигналов

Наиболее полезная комбинация:

Temperature

Clock Event Reason

Board Power

Clock

Application Performance.

Тогда уже можно классифицировать:

• thermal;

• power;

• policy;

• workload;

• other.

Thermal Event ≠ Automatic Project FAIL

Даже thermal-related signal должен оцениваться относительно заранее утверждённой программы.

Например, project может определить:

• любой sustained thermal slowdown → FAIL;

• transient SW thermal event → investigate;

• hardware thermal event → blocking.

Главное:

правило должно существовать до run.

Не после того, как увидели логи.

Температура внутри limit ещё не означает PASS performance

Оставляем важную границу:

Temperature Within Limit ≠ Performance Requirement Met.

Система может оставаться в допустимой temperature envelope, но:

• быть power-capped;

• иметь lower clocks;

• не достигать performance target.

Поэтому thermal validation должна сохранять application performance.

Для AMD используйте AMD-specific tools и telemetry

Current ROCm Validation Suite содержит:

• GST — compute stress;

• IET — sustained power stress;

• TST — thermal stress.

Но их scope нужно интерпретировать отдельно.

AMD IET — sustained power stress относительно configured target

IET выполняет GEMM workloads для создания sustained GPU power load и проверяет достижение заданной target power.

Корректная формулировка:

sustained power stress against configured/platform target.

Не:

«IET всегда автоматически нагружает GPU до абсолютного максимума».

AMD TST наблюдает edge и junction temperatures

Current RVS Thermal Stress Test:

• измеряет/наблюдает GPU edge temperature;

• junction temperature;

• может проверять достижение configured target/throttle temperatures.

Поэтому generic telemetry table лучше содержит:

• GPU/core/edge temp;

• junction/hotspot temp — if available;

• memory temp — if separately available.

Не смешивать:

junction

и:

memory temperature

в одно поле.

Не каждая platform предоставляет все temperature sensors

Отсутствие:

• junction;

• hotspot;

• memory temp

не является автоматическим test failure.

Telemetry matrix строится из того, что supported/exposed конкретной platform.

AMD RVS Pulse остаётся вне default production gate

Current RVS прямо помечает Pulse Stress Test как beta, not intended for production use; pass/fail criteria ещё дорабатываются.

Поэтому:

AMD RVS Pulse Beta ≠ Default Production Acceptance Test.

Важно именно указывать vendor/tool.

У NVIDIA есть отдельный DCGM Pulse с другой semantics — beta qualifier AMD к нему автоматически не относится.

Idle → Ramp → Sustained → Cooldown

Удобная структура одного thermal run:

Idle Baseline

До controlled load сохранить:

• inlet;

• component temperatures;

• clocks;

• board power;

• fan state;

• existing events.

Ramp

Переход к target workload.

Sustained Window

Основная зона анализа.

Cooldown

Нагрузка снята, система возвращается к baseline.

Не требуйте идеального temperature plateau

Thermal curve может продолжать медленно drift.

Поэтому лучше термин:

Representative Sustained Window

вместо требования:

temperature должна стать идеально горизонтальной.

Главное — заранее определить:

• observation window;

• stability criteria.

Longer Run ≠ Automatically Better Thermal Test

Нет универсального:

thermal test всегда должен длиться час;

или:

сутки.

Vendor tool defaults тоже не являются acceptance methodology проекта.

Tool Default Duration ≠ Project Thermal Validation Duration.

Синхронизируйте telemetry

Чтобы связать:

• inlet change;

• temperature;

• board power;

• clock event;

• performance drop,

нужен общий timeline.

В protocol записать:

• time source;

• timezone;

• synchronization method;

• sampling interval каждого source.

Sampling interval тоже часть evidence

Нельзя интерпретировать вместе:

• temperature каждые 60 секунд;

• power каждую секунду;

• performance только одной итоговой цифрой

без оговорки.

Для каждого source сохранить temporal resolution.

Thermal Run Matrix

Так таблица не предполагает одинаковую telemetry на всех platforms.

Для multi-GPU сервера анализируйте accelerators отдельно

Среднее значение по восьми GPU способно скрыть outlier.

Сохраняйте per-GPU:

• temperature;

• clocks;

• power;

• utilization;

• event reasons.

Если включены соответствующие DCGM tolerances, diagnostic также может сравнивать GPUs по GFLOPS, clocks и board power.

Temperature spread — descriptive evidence, не универсальный threshold

Можно считать:

Temperature Spread = Tmax − Tmin

между GPU при сопоставимой workload.

Но нельзя утверждать:

spread больше X °C всегда означает плохой airflow.

Причины могут зависеть от:

• chassis layout;

• GPU positions;

• power distribution;

• cooling design.

Fan speed тоже не является самостоятельным verdict

Высокий fan RPM может быть normal response fan curve.

Поэтому:

High Fan RPM ≠ Cooling Failure.

Используйте fan telemetry как часть общего context:

• faults;

• policy;

• temperature;

• power;

• performance.

Inlet-to-exhaust ΔT также требует контекста

Если exhaust measurement доступен, можно считать:

ΔT = Texhaust − Tinlet.

Но:

Delta-T without Power / Airflow Context = Weak Evidence.

Большой или малый ΔT сам по себе не доказывает достаточный/недостаточный cooling.

Acceptance Criteria должны существовать до запуска

Заранее определите:

• exact vendor environmental/device limits;

• required inlet envelope;

• disallowed clock-event reasons;

• permitted transient conditions;

• minimum application performance;

• blocking hardware incidents;

• workload;

• duration/observation window.

Иначе verdict становится post-hoc.

Более сильный PASS gate

Thermal test считается PASS по методике проекта, если одновременно выполнены обязательные условия:

Vendor / Platform Limits Met

Required Inlet Conditions Maintained

No Project-Disallowed Thermal Events

Required Application Performance Maintained

No Blocking Hardware Errors

Evidence Complete.

При этом:

Thermal Event ≠ Automatic Project FAIL unless Test Plan Says So.

Если performance снизилась — сначала классифицируйте причину

Workflow:

Performance / Clock Change

↓

Read Exact Clock-Event Reason

↓

Check GPU Board Power

↓

Check Device Temperature

↓

Check Inlet at Same Timestamp

↓

Compare Other GPUs

↓

Check Fan / Platform State

↓

Check Rack Airflow

↓

Classify Thermal / Power / Policy / Workload / Other

↓

Apply Project Criterion.

Это сильнее логики:

temperature высокая → cooling плохой.

Если обнаружена thermal-related проблема

Используйте controlled remediation:

Capture Evidence

↓

Choose One Variable

↓

например:

• blanking;

• cable obstruction;

• placement;

• fan policy;

• airflow correction;

↓

Record New Baseline

↓

Repeat Same Workload

↓

Compare Same Metrics.

Placement Change → New Thermal Context

Переставили сервер:

• на другие U;

• в другую стойку;

• рядом с другим оборудованием —

это уже новые test conditions.

Результаты нельзя объединять как повтор одного неизменного стенда.

Power-cap mitigation тоже меняет условия

Если после thermal issue снизили GPU power limit и temperature улучшилась, корректный вывод:

thermal behaviour improved under reduced power configuration.

Но затем нужно проверить:

выполняется ли performance requirement?

Это не то же самое, что:

rack cooling стала лучше.

Rack Condition Card

Server Baseline Card

Load Definition Card

Thermal Evidence Pack

Document Control

• project;

• test ID;

• plan revision;

• date.

Hardware Baseline

• exact BOM;

• firmware/software;

• power/fan policies.

Rack Context

• rack/U;

• airflow direction;

• containment;

• inlet sensor positions;

• photos.

Workload

• tool;

• version;

• config;

• duration;

• target.

Telemetry

• inlet;

• device temperatures;

• clocks;

• GPU board power;

• utilization;

• fan data;

• clock-event reasons.

Performance

• baseline;

• sustained result.

Exceptions

• thermal events;

• power events;

• hardware errors;

• remediation.

Final Disposition

• criteria;

• pass/fail/deviation;

• exact tested conditions.

Итоговая формулировка должна иметь границы применимости

Плохой вывод:

«Этот сервер хорошо охлаждается».

Сильнее:

В протестированной rack position, при зафиксированных inlet conditions, hardware/software baseline, power/fan configuration и workload система выполнила заранее заданные thermal и performance criteria без project-disallowed thermal events. Вывод относится только к протестированной configuration и условиям.

Что нельзя делать

Не определять PASS по одной максимальной temperature.

Не использовать room sensor вместо server inlet.

Не назначать универсальную температуру для всех GPU.

Не называть любой clock drop thermal throttling.

Не трактовать generic HW_SLOWDOWN автоматически как thermal.

Не путать SW_POWER_CAP с thermal condition.

Не путать GPU board power с total server power.

Не использовать PSU/nameplate rating вместо measured load.

Не принимать plugin fallback target за project criterion.

Не считать targeted-power SKIP аппаратным failure.

Не считать высокий fan RPM самостоятельным FAIL.

Не делать вывод по средней температуре всех accelerators.

Не рисовать synthetic thermal curves как будто это реальный test Start Server.

Связь с подготовкой площадки

До установки оборудования нужно ответить:

готова ли площадка по power, cooling и placement?

Thermal validation решает следующий вопрос:

что реально происходит с сервером в конкретной rack position под measured load?

Связка:

Design / Readiness → Measured Thermal Validation.

Связь с production monitoring

Production monitoring отвечает на вопрос:

какие metrics нужно наблюдать постоянно?

Thermal validation отвечает на другой вопрос:

что происходит во время controlled thermal experiment в определённом временном окне?

Metrics могут пересекаться.

Назначение разное.

Связь с общей программой приёмки

В общей программе приёмки GPU-сервера thermal stability может быть одной строкой Acceptance Matrix.

Эта статья раскрывает отдельный deep thermal branch и определяет evidence, необходимый для закрытия такой проверки.

Связь с batch-size experiment

Отдельный batch-size experiment исследует влияние batch size на производительность и memory behaviour.

В thermal validation workload configuration должна оставаться фиксированной.

Нельзя изменять batch во время thermal comparison и затем приписывать изменение temperature только cooling.

Что требуется для result-driven версии

Чтобы заменить H1 на:

«Проверка охлаждения GPU-сервера в стойке: результаты нагрузочного прогона»

нужно иметь реальный Evidence Pack:

До этого нельзя публиковать придуманные temperature curves или результаты.

Практический протокол

Шаг 1. Зафиксируйте exact server/BOM

Не platform family, а tested configuration.

Шаг 2. Задокументируйте rack position и airflow direction

Rack/U + photos.

Шаг 3. Определите cooling architecture

Air / liquid / hybrid.

Шаг 4. Определите exact vendor limits

Не универсальную «нормальную температуру».

Шаг 5. Измерьте server inlet conditions

Не room average.

Шаг 6. Зафиксируйте power/fan baseline

До workload.

Шаг 7. Определите reproducible load

Tool/version/config.

Шаг 8. Определите PASS criteria

До измерений.

Шаг 9. Синхронизируйте telemetry

Один timeline.

Шаг 10. Запишите idle baseline

До active workload.

Шаг 11. Выполните ramp

Переход к target state.

Шаг 12. Наблюдайте representative sustained window

Temperature + power + clocks + events + performance.

Шаг 13. Выполните cooldown

Сохраните recovery behaviour.

Шаг 14. Классифицируйте любые clock/performance constraints

Thermal / power / policy / other.

Шаг 15. Если нужно — измените одну переменную и повторите test

С новым baseline.

Шаг 16. Соберите Evidence Pack

И только после этого выдавайте thermal-validation verdict.

Что подготовить для проверки размещения GPU-сервера

Полезные входные данные:

• server SKU;

• GPU SKU/count;

• rack/U;

• equipment airflow direction;

• cooling architecture;

• available facility/rack cooling data;

• inlet measurements;

• power limits;

• target workload;

• sustained performance requirement;

• exact vendor thermal/environmental requirements;

• известные thermal/power incidents.

CTA: Проверить размещение выбранного сервера.

Главное

Проверка охлаждения GPU-сервера — это не вопрос:

«сколько градусов показывает GPU?»

Сначала нужно понимать:

где стоит оборудование и какой воздух оно фактически получает.

Затем:

какую workload и power оно действительно держит.

И только после этого интерпретировать:

temperature + clocks + clock-event reason + performance.

Current NVIDIA DCGM особенно хорошо показывает, почему одного clock drop недостаточно: software power cap, software thermal control, hardware thermal protection, hardware power brake и generic hardware slowdown — разные event reasons.

Generic HW_SLOWDOWN сам по себе может иметь thermal или power-related причины и требует дальнейшей классификации.

DCGM targeted_power аналогично проверяет достижение configured board-power target, а не абстрактного «максимального TDP»; если enforced power limit делает target недостижимым, это рассматривается как configuration constraint.

Для AMD ROCm Validation Suite разделяет sustained power stress через IET и thermal behaviour через TST, который работает с edge/junction temperatures.

AMD Pulse module при этом по-прежнему обозначен как beta и не предназначен для production use.

Правильная последовательность:

Exact Server / BOM

→ Rack Position + Airflow

→ Vendor / Facility Limits

→ Inlet Conditions

→ Power / Fan Baseline

→ Fixed Workload

→ Synchronized Telemetry

→ Idle → Ramp → Sustained → Cooldown

→ Temperature + Board Power + Clocks + Event Reason + Performance

→ Thermal / Power / Other Classification

→ Predefined Criteria

→ Remediation / Retest

→ Evidence Pack

→ Validation under Tested Conditions.

Ключевые правила:

Room Temperature ≠ Server Inlet Temperature.

High-Density GPU Server ≠ Automatically H1-Classified Equipment.

Temperature Number without Device Limit ≠ PASS/FAIL Criterion.

Low Temperature ≠ Cooling Validation PASS.

Clock Drop ≠ Thermal Throttling by Definition.

HW_SLOWDOWN ≠ Thermal Cause by Definition.

Power-Limited ≠ Thermally Throttled.

GPU Board Power ≠ Total Server Power.

Nameplate Power ≠ Measured Heat Load.

Temperature Within Limit ≠ Performance Requirement Met.

Temperature without Power / Load Context = Weak Thermal Evidence.

Plugin Fallback ≠ Appropriate Acceptance Target.

Tool Default Duration ≠ Project Thermal Validation Duration.

Thermal Event ≠ Automatic Project FAIL.

High Fan RPM ≠ Cooling Failure.

Delta-T without Power / Airflow Context = Weak Evidence.

Longer Run ≠ Automatically Better Thermal Test.

Thermal Result for One Configuration ≠ Universal Platform Result.

И основной вывод:

Сильный thermal-validation result должен доказывать не одну максимальную температуру, а полную связь между rack conditions, inlet, workload, фактической power, clocks/event reasons и application performance. Итог действует только для той configuration и тех условий, которые действительно были протестированы.