Перевести TDP в BTU: тепловыделение GPU-серверов в стойках

С чего начинается перегрев в стойке с GPU

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

GPU-серверы перегреваются чаще по простой причине: у них высокая мощность на единицу высоты (U) и очень горячий выхлоп. Один 2U или 4U узел с несколькими ускорителями может выделять тепла как половина стойки обычных CPU-серверов. Если рядом стоят такие же узлы, а воздух забирается и выдувается не так, как задумано, температура растет скачками.

Вторая причина - разрыв между паспортом и реальностью. В документации вы видите TDP, но в жизни есть пики нагрузки, разные режимы питания, КПД блоков питания и то, как реально работает ваш AI-стек. В итоге "по бумаге" все сходится, а на практике вентиляторы уходят в максимум, начинается троттлинг, а дальше - ошибки GPU и внезапные перезагрузки.

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

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

TDP, TBP и реальное потребление: простыми словами

TDP часто читают как "столько ватт будет жечь железо". На деле TDP - это ориентир для системы охлаждения: какое тепло нужно отвести в типовом режиме. Он помогает сравнивать модели, но не обещает, что процессор или GPU всегда будут держаться ровно в этих ваттах.

У видеокарт вы чаще встретите TBP или TGP. Это ближе к жизни: обычно это лимит мощности всей карты (не только чипа), заданный в прошивке. Карта может кратковременно уходить выше из-за буста, а в некоторых задачах стабильно держаться около лимита. Поэтому для расчета стойки TBP/TGP обычно полезнее, чем "красивый" TDP.

Важно помнить, что греется не только GPU и CPU. По отдельности вклад кажется небольшим, но в сервере он складывается: память и контроллеры, диски и сетевые карты, VRM (питание CPU и GPU), вентиляторы и помпы (если они есть), а также потери блока питания.

Отсюда частая ошибка: "у нас все GPU по 350 Вт, значит узел 350 Вт". Нет, 350 Вт - это только видеокарта по своему лимиту. Если в узле 2 GPU по 350 Вт и CPU с TDP 250 Вт, то даже без учета остального получается 950 Вт. Добавьте память, диски, вентиляторы и потери БП - и уже легко увидеть 1,1-1,3 кВт на один сервер.

Простой сценарий: в стойке планируют 8 таких узлов и рассчитывают охлаждение "по 1 кВт". Ошибка в 200-300 Вт на узел превращается в лишние 1,6-2,4 кВт тепла на стойку. Именно из таких "мелочей" потом появляются горячие точки и неожиданно высокие значения, когда вы переводите ватты в BTU/ч и сравниваете с возможностями кондиционирования.

Перевод ватт в BTU/ч: формула и быстрые примеры

Чтобы "перевести TDP в BTU", сначала стоит принять простое правило: почти все электричество, которое сервер потребляет, в итоге превращается в тепло внутри зала. Поэтому для прикидки тепловыделения обычно достаточно мощности в ваттах.

Базовая формула такая:

BTU/ч = Вт x 3,412

Главная ловушка - путаница единиц. BTU бывает "за час" (BTU/ч) и просто BTU (энергия). Для охлаждения почти всегда нужна скорость тепловыделения, то есть BTU/ч.

Как считать на практике: сначала складываете ватты по узлам (или по серверам), потом умножаете сумму на 3,412. Так проще контролировать итог и меньше шанс запутаться, чем переводить каждую мелочь отдельно.

Несколько быстрых примеров, чтобы чувствовать порядок цифр:

• 500 Вт -> 500 x 3,412 = 1 706 BTU/ч
• 1 кВт (1 000 Вт) -> 3 412 BTU/ч
• 3 кВт -> 10 236 BTU/ч
• 10 кВт (небольшая "горячая" стойка) -> 34 120 BTU/ч

Если у вас GPU-сервер: допустим, 2 видеокарты по 350 Вт (700 Вт), CPU и остальная часть системы еще 250 Вт. Итого около 950 Вт. В тепле это будет 950 x 3,412 = 3 241 BTU/ч на один сервер.

Нужен ли запас

Запас нужен, но без фанатизма. Обычно ориентируются так:

• +10%: есть замеры потребления, нагрузка стабильная.
• +15-20%: планируется рост нагрузки, есть неопределенность по конфигурациям.
• +30%: нет данных, много плавающих сценариев, есть риск, что TDP окажется ниже реального потребления.

Помните, что к теплу серверов добавляются сетевые устройства, дисковые полки и потери в ИБП. Поэтому запас лучше закладывать на уровне стойки, а не пытаться "докрутить" по одной видеокарте.

Единицы, которые чаще всего путают

• кВт: это ватты, деленные на 1 000.
• BTU/ч: тепловая мощность, то, что обычно указывают для кондиционирования.
• ккал/ч: реже в ЦОД, но встречается. Прикидка: 1 Вт примерно 0,86 ккал/ч.

Если держать в голове две опоры (1 кВт = 3 412 BTU/ч и BTU/ч, а не BTU), расчеты становятся заметно спокойнее.

Пошаговый расчет тепловой нагрузки для стойки

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

Сначала зафиксируйте исходные данные по каждому серверу. Важно не только число GPU, но и то, как узел питается и охлаждается:

• модель сервера, CPU и количество GPU
• TDP/TBP для CPU и каждой видеокарты, а также лимиты питания (power limit)
• количество блоков питания и их КПД (обычно 80 PLUS)
• ожидаемая загрузка (инференс, обучение, смешанный режим)
• форм-фактор и место в стойке (сколько U занимает)

Дальше пройдите по шагам.

1. Разделите режимы работы: пик (стресс-тест или обучение), типовой день, "ночной" фон. Для каждого режима вы получите свою цифру.

2. Оцените потребление одного узла в ваттах. Почти все эти ватты станут теплом внутри помещения. Если есть сомнения, берите не только сумму TDP, а реальный лимит питания GPU и CPU плюс запас 10-20%.

3. Пересчитайте тепло в BTU/ч. Формула та же: BTU/ч = Вт x 3,412. Например, узел на 2 200 Вт дает около 7 506 BTU/ч.

4. Сложите все узлы в стойке для каждого сценария и сравните с возможностями охлаждения (по стойке, по ряду, по залу). Если по пику вы упираетесь в лимит, сразу планируйте разнос по стойкам или снижение power limit.

5. Зафиксируйте план раскладки и контрольные измерения после установки: температура на входе, разница вход-выход, скорость вентиляторов, аварийные пороги.

Как разложить "горячие" узлы по стойке без сюрпризов

Самая частая причина перегрева в GPU-стойке - не "плохой кондиционер", а неудачная раскладка. Важно распределять нагрузку не только по суммарным ваттам, но и по высоте. Теплый воздух поднимается, поэтому плотная "стенка" из горячих серверов ближе к верху почти гарантирует проблемы.

"Горячие" узлы чаще всего проявляются в трех местах: в верхней трети стойки, у задней двери (если есть рециркуляция), и там, где кабели собраны в плотный пучок и перекрывают выдув. Даже аккуратный на вид кабель-менеджмент может стать пробкой для воздуха.

Несколько правил, которые обычно работают:

• Не ставьте самые мощные GPU-узлы подряд и на одной высоте. Разнесите их по стойке.
• Держите тяжелые узлы ниже середины, а легкие (коммутаторы, управляющие серверы) - выше.
• Делайте интервалы: между горячими серверами оставляйте 1U пустым или ставьте "холодный" 1U/2U узел, если это допустимо по инструкции.
• Следите за направлением потока (обычно спереди назад). Не смешивайте в одной стойке оборудование с разным направлением выдува.
• Уважайте зазоры производителя: не прижимайте задние разъемы и кабели к двери, оставляйте место для нормального выдува и обслуживания.

Простой пример: если у вас два 4U GPU-сервера, не ставьте их подряд в верхних юнитах. Лучше поставить один в нижней части, затем 1U заглушка, затем 2U более холодный узел (например, контроллер или storage с меньшим теплом), и только потом второй GPU-сервер ближе к середине.

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

• не перекрывают ли кабели решетки выдува и вентиляторы;
• стоят ли заглушки на пустых U, чтобы воздух не "коротил" внутри стойки;
• есть ли запас по температуре у верхних узлов (они почти всегда в худших условиях);
• совпадают ли требования по зазорам и глубине установки у всех устройств.

Такая раскладка обычно дает больше эффекта, чем попытки решить проблему постоянным ростом оборотов вентиляторов.

Воздушные потоки: коридоры, заглушки и рециркуляция

Даже если вы правильно посчитали суммарное тепло, стойка все равно может перегреваться из-за плохого движения воздуха. Причина часто простая: холодный воздух не доходит до "лица" серверов, а горячий возвращается обратно в забор.

Холодный и горячий коридор: где "лицо", где "спина"

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

Проверьте ориентацию не только серверов, но и PDU, KVM, сетевых устройств и любых "коробок", которые могут выдувать в неожиданную сторону.

Заглушки и вводы: мелочи, которые лечат рециркуляцию

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

Быстрые меры, которые часто дают заметный эффект:

• закрыть все пустые U заглушками, особенно рядом с GPU-серверами;
• поставить щетки или уплотнители на кабельные вводы, чтобы не было "дырок" между зонами;
• уложить кабели так, чтобы они не перекрывали фронтальные решетки и не создавали "штору" перед забором;
• убедиться, что двери (если они перфорированные) не забиты пылью и имеют достаточную прозрачность;
• проверить, что подача холода (плитки, решетки, воздуховоды) попадает именно в холодный коридор, а не рассеивается в помещении.

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

Связь тепла и электропитания: простая проверка здравого смысла

Планируя охлаждение, полезно сначала посмотреть на питание. Для IT-оборудования почти вся потребляемая из сети мощность превращается в тепло в той же стойке: процессоры, GPU, память, диски и вентиляторы в итоге греют воздух. Поэтому расчет тепла легко проверяется по электрике: если стойка реально берет 12 кВт, то и тепловая нагрузка будет близка к 12 кВт (и дальше уже пересчитывается в BTU/ч).

Частая ловушка - складывать "максимумы" по паспортам блоков питания. Два БП по 2000 Вт не означают, что сервер всегда потребляет 4000 Вт. Это запас по питанию и резервирование (например, 1+1), а реальная нагрузка зависит от профиля работы GPU и CPU, лимитов мощности, настроек и загрузки.

КПД блока питания тоже добавляет тепла. Если сервер потребляет 3000 Вт "на компоненты", а КПД БП 92%, то из розетки он возьмет примерно 3000 / 0,92 = 3260 Вт. Разница (около 260 Вт) уйдет в тепло внутри сервера, то есть тоже в стойку. Чем ниже КПД и чем выше нагрузка, тем заметнее эта прибавка.

Отсюда простое правило: когда вы хотите перевести TDP в BTU, делайте проверку по ожидаемой мощности "из стены" и лимитам PDU, а не по сумме мощностей БП.

Быстрая проверка здравого смысла перед раскладкой по стойкам:

• сложите ожидаемое потребление серверов в кВт (лучше по измерениям или по профилю нагрузки, а не по "пиковым" паспортам);
• уточните лимит стойки по питанию: ввод, PDU, автоматы, число фаз и допустимую длительную нагрузку;
• добавьте потери БП (через КПД) и мелочь вроде коммутаторов и KVM;
• сравните: если по питанию вы близко к лимиту, по охлаждению сюрпризов тоже не избежать;
• оставьте запас: при росте загрузки или обновлении прошивок потребление часто поднимается.

Частые ошибки при планировании охлаждения GPU-стоек

Самая частая ошибка начинается с хорошего намерения: взять TDP видеокарт, перевести TDP в BTU и на этом закончить расчет. В реальности тепло дают не только GPU. CPU, память, диски, сетевые карты, блоки питания и даже потери в ИБП превращаются в дополнительные ватты, а значит - в дополнительную нагрузку на охлаждение.

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

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

Что чаще всего упускают в механике воздуха

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

Датчики важнее одной температуры в зале

Опираться на один термометр в помещении опасно. Важнее знать температуру на входе в каждый сервер и разницу между входом и выходом.

Короткая проверка перед запуском помогает поймать проблемы заранее:

• учтите тепло от всех компонентов и потери питания, а не только от GPU;
• проверьте пиковые режимы (старт задач, тесты, обучение) и заложите запас;
• разнесите горячие узлы по стойке и оставьте интервалы, если это возможно;
• закройте пустые U заглушками и уберите щели, чтобы не было рециркуляции;
• поставьте датчики на вход серверов и сравнивайте их между разными U.

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

Короткий чек-лист перед установкой и запуском

Перед тем как завозить железо в зал, полезно пройтись по короткому списку. Он помогает поймать ошибки, которые потом выглядят как "внезапный" перегрев или непонятные перезагрузки под нагрузкой.

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

Проверьте это перед установкой и первым включением:

• Тепловая нагрузка в пике: сколько Вт и BTU/ч дает один узел и вся стойка, с учетом худшего случая (турбо-частоты, полная загрузка GPU, активные NIC, диски).
• Раскладка горячих узлов: где стоят самые плотные GPU-серверы, есть ли зазоры 1U-2U, заглушки на пустых местах и нет ли "стены тепла" в одном месте стойки.
• Температура на входе в серверы: измеряйте именно воздух перед фронтальной панелью, а не только "в помещении". Часто в зале 22 C, а на входе в верхние узлы уже 30 C.
• Запас по питанию и по охлаждению: оставьте резерв хотя бы под рост нагрузки и будущие карты. Если по PDU и автоматам все впритык, перегрев часто идет рядом с просадками питания.
• Мониторинг и реакция: какие датчики смотрите (входной воздух, скорость вентиляторов, потребление, GPU hotspot), какие пороги считаются аварийными и кто принимает решение ночью.

Практический ориентир: если вы ставите два одинаковых 4U GPU-сервера рядом без заглушек вокруг, верхний почти всегда получает более теплый входной воздух. Иногда достаточно поменять местами один горячий узел с более холодным (например, storage) и убрать проблему без перестройки всей стойки.

Реалистичный пример: две стойки под GPU и соседние узлы

Представим типичный проект под AI: две стойки 42U. В каждой планируются горячие GPU-узлы (по 4-8 GPU), а рядом нужны более холодные серверы под хранение и сервисы (контроллеры, менеджмент, вспомогательные VM).

Возьмем два типа узлов для оценки:

• GPU-узел: реальное потребление под нагрузкой около 3,5 кВт (часто выше паспортного TDP, если включены турбо-режимы и активно работает память).
• Узел хранения: около 0,8 кВт (диски и контроллеры тоже греются, но обычно заметно меньше GPU).

Чтобы быстро прикинуть тепло, используйте правило 1 Вт = 3,412 BTU/ч. Тогда GPU-узел 3,5 кВт - это примерно 11 942 BTU/ч, а узел хранения 0,8 кВт - примерно 2 730 BTU/ч.

Дальше проверка "сколько влезет" упирается не в U, а в охлаждение и допустимую тепловую плотность. Если на стойку заложено, например, 20 кВт отвода тепла, то в теории в нее помещается 5 GPU-узлов по 3,5 кВт (17,5 кВт). Но на практике оставьте запас: под пики, деградацию фильтров и рост температуры в зале.

По высоте раскладка может выглядеть так:

• Самые горячие GPU-узлы - ближе к середине стойки (примерно 14U-28U), где обычно лучше приток и проще удержать ровный фронтальный поток.
• Снизу - место под PDU и кабельные вводы, чтобы не "душить" забор воздуха.
• Сверху - более холодные узлы (хранение, сервисы), чтобы не подогревать вход горячим выхлопом.

В первые 48 часов после запуска лучше не гадать, а измерять:

• температуру на входе в сервер (front inlet) у верхних, средних и нижних устройств;
• разницу температур вход/выход по самым горячим узлам;
• скорость вентиляторов и частоту троттлинга GPU;
• горячие точки в коридоре и за стойкой тепловизором или датчиками;
• потребление по фазам на PDU, чтобы не было перекоса и скрытых пиков.

Следующие шаги: от расчета к внедрению

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

Начните с инвентаризации: модель серверов и GPU, количество блоков питания, ожидаемая загрузка, схема стойки и ограничения зала (температура подачи, доступный расход воздуха, допустимый шум). Если данных по конкретной конфигурации нет, закладывайте консервативно: реальное потребление под задачей легко отличается от "бумажного".

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

Практичный порядок действий обычно такой:

• собрать паспортные данные, план раскладки по U и ограничения по залу;
• посчитать тепло в Вт и BTU/ч и сверить с возможностями охлаждения по стойке и по ряду;
• сделать пилотную установку 1-2 узлов и замерить температуры при типовой нагрузке;
• заложить резерв под рост, обслуживание и деградацию фильтров (не ставить все на предел);
• уточнить теплопрофиль и требования к питанию до закупки, а не после поставки.

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

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