Привет. Я – Богдан. И мне стало интересно понять как вообще устроен датацентр. Если точнее - то как устроен AI датацентр, который может запустить KIMI-3, Sonnet-5 или Sol (ну или чем вы там ещё пользуетесь). И если ещё точнее, то как он обеспечивается энергией, какие в нем есть важные критические компоненты, как они взаимосвязаны друг с другом.
Если вдруг вам тоже стало интересно - приглашаю присоединиться.
Что будет в этой части
- небольшая вводная часть
- зафиксируем в качестве примера мощный сервер и начнём его разбирать
- сделаем отступление и поприкидываем какие модели вообще можно запускать на этой сервере
- бегло пробежимся по базовой терминологии
- опишем что и как будем симулировать
- прогоним несколько сценариев, будем смотреть на графики и пытаться делать выводы
Кто я
Я не электрик, не строитель ЦОДов. Просто любознательный тип.
И разработчик, который за свою карьеру успел поработать в разных областях. Из самых ярких этапов это: молекулярная биология и биоинформатика под руководством Паши Яковлева, строительство многоэтажных домов из дерева (текущая компания). Я умею и люблю погружаться в предметную область. Вот сейчас предмет моих интересов пал на энергетику датацентров.
А ещё я худо-бедно умею моделировать. Ну или симулировать. Ну или делать цифровой двойник системы, чтобы посмотреть на её поведение до того, как на эту систему будет потрачено 100500 денег.
Этим я и буду заниматься. Рассказывать что узнал сам. Моделировать и делиться всякими графиками. Обсуждать с вами, если вам тоже интересно и особенно если у вас есть релевантный опыт.
Погнали.
AI дисклеймер
Конечно, для рисёча я использовал AI. Но текущий текст будет написан мною, а в местах где мне будет лень пересказывать своими словами, будет написано что-то в духе "AI говорит:". Ан-нет. Этот пост написан без AI.
Что вам выдаёт нейрослоп
Нейрослопит вам какая-то модель. Вот ровно та, которую вы выбираете в ChatGPT или Claude Code. Но модель - это набор весов и хитрых архитектур, которые на входной запрос генерируют последовательность ответных токенов. С точки зрения энергии и потребления они интересны, их нужно тоже оценивать (когда-нибудь это сделаем). Но с точки зрения физического мира гораздо интереснее на чём это генерируется.
По-любому вы хотя бы краем уха слышали, что быстрее и эффективнее всего это делать на GPU-подобных устройствах. На одну очень мощную карточку может влезть неплохая, но далеко не топовая модель. Поэтому оставим это развлечение сыну маминой подруги. А настоящие пацаны оперируют стойками и целыми цодами. Вот и мы будем смотреть на монстра NVIDIA GB300 NVL72.
Попробуем откопать документацию и понять что эта стойка из себя представляет:
- из названия понятно, что у неё в кишочках 72 штуки B300, одни из самых передовых карточек
- суммарная стоимость за стойку по оценкам интернета - $4.000.000 (включая $50.000 чисто за систему охлаждения)
- потребляемая мощность от 135 kW до 142 kW с пиком в 155 kW
- 90% жидкостного охлаждения и 10% тепла отводится через воздух
Небольшое отступление
Чтобы понимать мощь этой поделки, немного отвлечёмся и быстро прикинем какие модели вообще могут влезть на одну стойку. Очень быстро и с большим количеством допущений.
Итак, за 4 млн долларов у вас будет 72 GPU Blackwell и около 20 Tb GPU суммарной памяти (72 раза по 288 Gb быстрой памяти HBM3e) .
Формула для моделей будет такой: память под веса = число параметров × бит на параметр / 8. Число параметров – то чем хвастаются компании. А бит на параметр – сколько знаков после запятой вы хотите хранить для каждого параметра. Чем больше – тем модель (в теории) "умнее". Обычно хранят: 16 бит, 8 бит, 4 бита и особо одарённые ужимают до 2-х.
Поэтому для модели с 1 миллиардом параметров вес будет такой:
- для 16 бит - 2 Gb
- для 8 бит - 1 Gb
- для 4 бит - 0.5 Gb
Ну и если взять последние модели у которых известны веса, то расклад получается такой:
| Модель | Параметры | Формат | Веса |
|---|---|---|---|
| Llama 3.1 70B | 70B | FP8 | 70 ГБ |
| Qwen3 235B-A22B | 235B | FP8 | 235 ГБ |
| Llama 3.1 405B | 405B | FP8 | 405 ГБ |
| DeepSeek V3 | 671B | FP8 | ~671 ГБ |
| Kimi K2 | 1T | FP8 | ~1 ТБ |
| Kimi K3 | 2.8T | MXFP4 | ~1.4 ТБ |
Замечание №1. В таблице у Kimi K3 стоит формат MXFP4. Это хитрый формат для весов, который позволяет практически без потери качется тратить 4.25 бита на параметр. Поэтому и числа получаются другие.
Замечание №2. Мы тут дико упростили, не думая о всяких буферах, KV-кэшах и других расходов на память (особенно если собираемся учить или дообучать модель). Но чтобы не утонуть в деталях, нам этого хватит пока что.
А теперь вспомним, что у нас на стойке аж целых 20 Tb памяти. Поэтому даже последняя Kimi K3 на стойку влезет. И даже не одна. Кайф, осталось её запитать, охладить и можно стать почётным провайдером моделей!
Первая пачка открытий
Самое неожиданное для меня, когда я прочитал про характеристики сервера - одна такая стойка потребляет около 135 kW. Вспомните ИЖС или СНТ в России или Европе. На частный дом обычно выделяется 10-15 kW, иногда 30 kW (перед тем как вы отрубите свет вашим соседям). А тут одна серверная стойка потребляет как небольшой коттеджный посёлок.
Второе - что практически вся энергия, которая приходит на чип, потом конвертируется в тепло (и вашего Бомбардиро Крокодило). И это тепло нужно яростно отводить, пока карточка ценой в новую семейную машину не перегрелась.
Базовая терминология
Немного поговорим о терминах и понятиях, чтобы дальше быть на одной волне. Можете смело пропускать этот раздел, если шарите.
Мощность = скорость передачи/потребления энергии. Измеряем с W (Ваттах). Для микро-цодов в киловаттах, пацаны на районе оперируют гиго и мегаваттами. Для нашей одной стойки это в среднем 135kW.
Энергия = мощность, накопленная или потраченная за время. Измеряем в ватт-час (Wh). Если отключили свет на районе, но у вас под рукой оказалась батарейка на 700 kWh, то для нашей стойки этого хватит примерно на 5 часов работы.
Тепловая мощность = скорость выделения тепла. Тоже измеряется в кило-ваттах. То, с какой наша стойка греется и с какой скоростью нужно отводить это тепло.
Температура. Текущее состояние железки. Важно отличать от тепловой мощности. Железка может колбасить вам нейрослоп с дикой скоростью и выделять стабильно 150kW. А температура при этом может постоянно расти, если мы это тепло не будем успевать отводить.
КПД и потери. Ни один компонент не передаёт энергию на 100%. Что-то из этого теряется и обычно превращается опять в тепло. Которое, как вы уже догадались, нужно отводить.
PSU/VRM loss. PSU - это Power Supply Unit, конвертирует переменный ток в постоянный. VRM (Voltage Regulator Module) — понижает/стабилизирует DC до напряжения чипа . loss - сколько эти гады теряют по дороге в виде нагрева.
Первая симуляция: постановка
Конечно, хочется замоделировать сразу весь датацентр, а ещё чтобы с анимацией и красивыми графиками. Но в таком прыжке можем упустить смысл, поэтому в этом посте ограничимся только серверными стойками и базовыми компонентами вокруг них. И будем делать допущения. Очень много допущений.
Допущение №1. Энергия нам достаётся с небес как фиксированное число. Не будем думать пока что о трансформаторах, батареях, генераторах, распределительных щитах. "Доступно столько kW на входе" и всё.
Допущение №2. Охлаждение нам тоже достаётся как пара фиксированных чисел: жидкостное и воздушное. И оно не связано и независит от энергоснабжения.
Моделировать будем стойку. А точнее, представим что нам на голову упало ещё 12 млн долларов и мы можем позволить себе аж целых 4 стойки.
На эти стойки у нас будет приходить 3 входящих сигнала:
- Первый сигнал - доступная электроенергия. Ведь без него наша стойка даже не включится.
- Второй сигнал - доступное охлаждение, без которого все наши деньги натурально сгорят.
- Третий сигнал - нагрузка от пользователей. Иначе для кого всё это?
В качестве выхода будем снимать показатели, такие как:
- статус стойки (жива, перегрелать, пытается запуститься)
- реальное потребление энергии с разбиением на полезную мощность и PSU/VRM потери (о них говорили в предыдущем параграфе)
- реальное потребление охраждения с разделением на жидкостное и воздушное
- температура стоек
Как устроена симуляция
Мы будем использовать дискретно-событийное моделирование (discrete-event simulation по аглицки). В нём модель крутится тиками – временными шагами. В нашей системе временным шагом будет минута. И на каждом шаге происходит одно и то же:
- спрашиваем, сколько сейчас хотят GPU в зависимости от потребностей пользователей (нагрузка);
- сколько реально нам дают энергии;
- сколько реально из этого можно охладить;
- меняем состояние системы если нужно (например, отключаем или включаем стойку);
- идём в следующую минуту.
Стойка не может взять больше, чем ей физически позволено — у неё есть свой паспортный потолок (те самые 135-155 кВт), и если реально доступной энергии меньше, чем попросили — она режет потребление. Сначала пытается работать на урезанной мощности (throttling), а если совсем плохо — вырубается целиком. То же самое происходит, если тепло недостаточно быстро отводится (например, сломалось охлажление).
В целом, вот и вся механия: три входа, один выход (что вошло — то и нагрелось). И стойка, которая реагирует на баланс между ними.
А теперь погнали смотреть на занимательные картинки. Разберём 3 сценария:
- стойки работают в режиме инференса
- стойки работаеют в режиме обучения
Хьюстон, у нас проблемана время отказала система охлаждения
Небольшой дисклеймер, чтобы вы не разочаровались раньше времени
В этой части мы будем смотреть на графики. Эти графики нужно читать так: мы провели симуляцию, записали все параметры системы и потом их визуализировали. В этой части не будет красивых и динамичных симуляций, сорян. Вообще, из хорошего графика или отчёта зачастую можно вытащить больше информации, нежели из красивой моргающей картинки.
Но! Если вдруг этот пост будет интересен публике, у него появятся следующие части, я постараюсь накрутить визуализацию, чтобы в динамике можно было проследить как элементы системы влияют друг на друга.
Сценарий 1: инференс (aka "обслуживаем пользователей")
Если хотите сразу сами пойти потыкать, весь код выложен тут: https://github.com/ozzzzz/energy_simulations.
Итак, первый сценарий: мы подгрузили на наши стойки веса моделей и теперь просто обрабатываем запросы пользователей. Они у нас будут неравномерные по времени, ведь пользователи иногда спят.
Сначала посмотрим на график потребления стойками энергии. Пунктиром обозначено "сколько хотели", сплошной линией "сколько реально потратили".
А вот температура стоек. Всё отлично, стабильно держится на 25 градусах.
Ну и общее потребление (сверху) и охлаждение (снизу). Охлаждение разбито на жидкость и воздух, пунктиром – полный запас охлаждения, сплошной линией – сколько потратили.
Наконец, мой самый любимый график. Он не временной, а показывает то как энергия суммарно перетекает из одной системы в другую за всё время наблюдения.
Собственно, тут видны все этапы превращения энергии (слева направо):
- сколько энергии требовалось
- сколько энергии получили из сети
- дальше разбивается на 2 куска:
- большая часть уходит на полезный компьют
- какой-то процент уходит на потери (PSU/VRM loss)
- соединямся в общее тепло, которое наши стойки произвели
- переходим в сколько тепла отвели с разбиением по типу охлаждения
В самом низу видна мааааленькая штучка Unmet demand - разница между тем сколько GPU хотели и сколько реально получили. В этом сценарии она практически нулевая, потому что у нас всё настроено хорошо и с запасом. И ничего не ломалось. И никаких денег на простой системы мы впустую не потратили.
Сценарий 2: обучение модели
Теперь другой сценарий. Представим себя на месте Илона Маска и xAI, которые сдают свои сервера на обучение моделей. А чем мы хуже? Давайте посмотрим как поменяются графики, если наши стойки будут учить модели.
Оговоримся, что в нашей симуляции нам дико повезло и наши GPU загружены на полную мощность. Вообще-то это не совсем тревиальная задача. И тот же xAI облажался несколько месяцев назад, потому что они смогли выжать какие-то жалкие 11% во время обучения.
Ещё одно небольшое отступление. Во-первых, для обучения нужно хранить не только веса, но и градиенты и ещё кучу всего дополнительного. Поэтому наши прикидки выше будут расти сильно в большую сторону.
Быстро глянем на потребление энергии и температуры. Видим, что все 4 стойки стабильно бултыхаются в районе 135-150 kW, рядом со своим пределом. Ну и они опять не греются, охлаждение работает в штатном режиме.
Потребление энергии и охлаждение тоже стабильно. Близко к максимальным значениям, но не доходит с небольшим запасом.
Распределение энергии по этапам тоже будет до боли напоминать график из предыдущего сценария.
Так не весело, нужно что-нибудь сломать!
Сценарий 3: отказ охлаждения
Пусть у нас сломается система охлаждения. Причём капитально, суток на полтора. Тогда картинка будет такой (захватим побольше графиков, чтобы было интересней посмотреть на взаимосвязь):
Последовательно событый такая:
- снижается доступное охлаждение (первый график)
- температура на стойках начинает расти (третий график)
- стойки сначала переходям в защитный режим, а при достижении критической температуры отключаются. Немного остывают. включаются, но пока система охлаждения не заработает по полную мощность, постоянно переходят из режима в режим (второй график)
Если увеличить графики в области аварии, картинка будет такой:
Ну и наконец, если посмотреть на то как распределялась энергия за всё время, то виден явный кусок unmet demand. И сеть могла, и стойки были, но из-за охлаждения мы сильно недонагрузили наши стойки полезной нагрузкой и натурально сожгли деньги.
Если взять не все 7 дней нашей симуляции, а только период с аварией, то картина будет вообще печальная:
Тепло не отводится, и это каскадом справа налево недозагружает наши сервера за 16 млн долларов. Обидно!
Сценарий 4: смешаный
В репозитории (вот этом https://github.com/ozzzzz/energy_simulations) есть ещё один вариант: часть стоек обрабатывает инференс, а часть обрабатывает обучение. Чтобы не утомлять вас графиками, предоставляю на это самостоятельно посмотреть самым любознательным читателям.
Финалочка
Пока что это всё. Я буду дальше разбираться в системах и компонентах. Буду моделировать энергию не как простое число, а как набор отдельных компонентов, которые проходит ток от подстанции до стоек. Буду разбираться в системах и различных схемам резервирования.
Если у вас есть желание прочитать это в следующих частях – плюсика будет достаточно. Ну и любым комментариям, полезным ссылкам и источникам я тоже буду очень рад и благодарен.
