Обучение LLM: Supermicro GPU‑кластер против облачных GPU — что выгоднее по 3‑летнему TCO?
Эта статья адресована техническим руководителям и архитекторам, которые планируют инфраструктуру для обучения моделей масштаба 7B и 70B и пытаются решить, стоит ли в ближайшие три года инвестировать в собственный Supermicro GPU‑кластер или продолжать арендовать облачные GPU.
Задача материала — дать понятный, основанный на числах ориентир: при каком масштабе моделей, профиле нагрузки и ограничениях российского рынка дешевле и безопаснее жить в облаке, а при каком — строить локальный кластер на Supermicro и смотреть на облако как на «эластичный буфер».
Какой выбор вы на самом деле делаете
В типичной компании с LLM‑инициативой на столе лежит компромисс: при ограниченном бюджете и жестком time‑to‑market нужно понять, когда достаточно облака, а когда оправдана покупка Supermicro‑кластера под 3–5 лет эксплуатации.
Сомнения обычно крутятся вокруг нескольких вопросов: нужны ли локальные GPU, если проекты в основном крутятся вокруг 7B/13B‑моделей; насколько «страшно» выглядит upfront‑инвестиция в железо по сравнению с почасовыми ставками облака; и как требования по локализации данных и санкционные риски меняют картину TCO.
7B‑модели: «средний стакан» на 4×GPU
Для моделей уровня Llama 2/3 7B FP16‑веса занимают порядка десятков гигабайт, а с учетом градиентов, состояний оптимизатора и активаций полная нагрузка на видеопамять выходит на уровень 40–60 GB, что укладывается в совокупный объём 4× A100/H100 80 GB с запасом.
- Рекомендуемая конфигурация: 4× A100 80 GB или 4× H100 80 GB на одном сервере с использованием ZeRO или Fully Sharded Data Parallel для оптимального размещения состояний модели.
- Серверный профиль: 2U/4U Supermicro GPU‑сервер с 4 двухслотовыми GPU, 2× Xeon или 2× EPYC (64+ ядер суммарно), 512 GB–1 TB DDR4/DDR5 и 8–12 NVMe в RAID0/10 под датасеты и checkpoint‑ы.
Когда 7B разумнее оставить в облаке
Если основной паттерн использования — нерегулярный fine‑tuning 7B/13B‑моделей «под запрос» с окнами обучения в считанные дни или недели и длинными периодами простоя, по 3‑летнему TCO облако выглядит выгоднее, потому что вы платите только за фактические GPU‑часы.
Такой режим нагрузки плохо загружает локальный кластер и не позволяет «досжечь» стоимость железа, в то время как облако даёт эластичность: легко поднять 4× A100‑инстанс на несколько дней и тут же его выключить, не думая о простое стойки.
70B‑класс: зона тяжёлого on‑prem
Для Llama 2/3 70B FP16‑веса выходят примерно на 140 GB, а с учетом оптимизатора и активаций совокупное потребление памяти переходит в несколько сотен гигабайт, что требует как минимум 8×GPU на узел и серьёзных объёмов системной памяти и NVMe.
- Узел: 8× A100 80 GB или 8× H100 80 GB (NVLink/PCIe), 2 TB+ RAM, 16–24 NVMe‑диска под высокоскоростное хранилище и сеть уровня не ниже 200–400 Gbit/s на сервер.
- Кластер: 2–4 таких узла в режимах data parallel + model parallel с тщательно настроенным All‑Reduce и схемой прогрева датасетов.
Когда 70B подталкивает к собственному кластеру
Если 70B‑модели используются эпизодически, аренда 8× A100/H100‑инстансов на время одного‑двух больших запусков в год пусть и ощутима, но остаётся контролируемой в рамках проектного бюджета и позволяет обойтись без капитальных вложений.
Однако при наличии нескольких команд и конвейера проектов, где 70B‑обучение идёт почти непрерывно и легко набирает десятки тысяч GPU‑часов в год, затраты на облако становятся сопоставимыми с покупкой собственного кластера, а затем начинают её заметно превышать.
Кейс: 3‑летний TCO узла 4×A100 on‑prem
Для ориентира рассмотрим узел с 4× A100 80 GB и сравним его 3‑летний TCO с эквивалентным облачным инстансом при средней загрузке около 70 %, опираясь на открытый TCO‑разбор для подобной конфигурации.
В этом анализе 3‑летний совокупный on‑prem‑TCO одного 4× A100‑узла с учетом оборудования, инфраструктуры ЦОД и операционных расходов составил около 246 624 долларов, в то время как облачный аналог при той же загрузке дал примерно 122 478 долларов.
Из чего складываются 246 624 $ on‑prem
| Компонент on‑prem узла 4× A100 | Оценочная стоимость (USD) | Комментарий |
|---|---|---|
| GPU (4× A100 80 GB) | ≈ 40 000 | Основной CAPEX по видеокартам. |
| Корпус, CPU, RAM, NVMe и пр. | ≈ 15 000 | Серверная платформа и хранилище. |
| Сеть и коммутация (amort.) | ≈ 5 000 | Коммутаторы, кабели, базовый запас. |
| Инфраструктура ЦОД (3 года) | ≈ 42 624 | Стойка, питание, охлаждение и пр. |
| Операционные расходы (3 года) | ≈ 144 000 | Администрирование, поддержка, лицензии. |
| Итого 3‑летний TCO on‑prem | ≈ 246 624 | Оценка «с запасом» для верхней границы. |
122 478 $: структура 3‑летнего TCO облачного 4×A100
Облачный эквивалент — инстанс с 4× A100 80 GB и около 1 TB хранилища — при 70 % средней загрузке за три года даёт приблизительно 122 478 долларов TCO, в основном за счёт почасовой оплаты GPU и относительно скромных затрат на дисковый объём.
| Компонент облачной конфигурации | Оценочная стоимость (USD, 3 года) | Комментарий |
|---|---|---|
| GPU‑вычисления (4× A100) | ≈ 120 678 | Учтены 70 % средней загрузки за 3 года. |
| Хранение (1 TB) | ≈ 1 800 | Типовая ставка порядка 0,05 $/GB в месяц. |
| Итого 3‑летний TCO облака | ≈ 122 478 | Около 50 % от on‑prem в данном сценарии. |
Главный вывод: TCO определяется загрузкой
При умеренной загрузке (порядка 50–70 %) облачный вариант оказывается дешевле почти вдвое, поскольку не требует капитальных вложений и берёт на себя часть операционных расходов, тогда как стоимость локального кластера остаётся фиксированной и амортизируется на меньшее число задач.
On‑prem‑кластеры начинают выигрывать у облака только при стабильно высокой загрузке — порядка 70–80 % и выше на протяжении нескольких лет, когда суммарная стоимость аренды в облаке становится сопоставимой или превышает цену железа и сопровождения.
Как это ложится на ваши 7B/70B‑сценарии
| Сценарий | Паттерн использования | Вероятно выгоднее |
|---|---|---|
| 7B/13B fine‑tuning, редкие запуски | Несколько крупных обучений в год, значительные периоды простоя GPU | Облачные GPU (оплата по мере использования) |
| 70B‑обучение, несколько команд | Почти постоянное использование 8×GPU‑узлов, тысячи часов в год | Локальный Supermicro‑кластер (лучшее TCO при высокой загрузке) |
| Смешанная нагрузка 7B/70B | Базовая постоянная нагрузка + пики под отдельные проекты | Гибрид: базовый кластер Supermicro + облако как эластичный буфер |
Российские реалии: санкции, данные и доступность GPU
В российских условиях решение «облако против собственного кластера» нельзя рассматривать только через призму денежного TCO: важную роль играют требования по локализации данных, отраслевые регуляции и риски санкций, влияющие на доступность зарубежных облаков и проприетарного ПО.
Для финансового сектора, онлайн‑сервисов с чувствительными пользовательскими данными и госзаказчиков локальный кластер на Supermicro с размещением в российском ЦОДе и стеком Alt Linux + Proxmox позволяет обеспечить контроль над данными и предсказуемую доступность вычислительных ресурсов на горизонте 3–5 лет.
Сильные стороны локального Supermicro‑кластера
- Контроль над данными и соответствие требованиям регуляторов: физическое хранение в российском ЦОДе и прозрачность архитектуры облегчают аудиты и снижают юридические риски.
- Предсказуемость производительности: отсутствие «шумных соседей», оптимизация сети и хранилища под конкретные LLM‑ворклоады, возможность повторно использовать один и тот же «золотой» профиль конфигурации для разных проектов.
- Гибкая комплектуемость: платформы Supermicro позволяют свободно сочетать различные CPU, GPU и NVMe‑накопители, подстраивая конфигурацию под целевой бюджет и доступность компонентов в регионе.
Плюсы облака: без CAPEX, но с риском «раздувания» счетов
Облачные GPU привлекательны тем, что снимают необходимость в капитальных вложениях: достаточно создать аккаунт, выбрать инстанс с нужными GPU и оплатить первые часы, что особенно удобно на этапе R&D, когда модель, фреймворк и сами требования к железу ещё не зафиксированы.
При этом облачный TCO легко выходит за пределы планов, если инстансы не выключаются по окончании экспериментов или большие объёмы дисков и снапшотов висят месяцами, а периодические изменения цен и квот со стороны провайдера добавляют неопределённости в долгосрочные бюджеты.
Таблица быстрого решения: облако или Supermicro
| Критерий | Сигнал в пользу облака | Сигнал в пользу Supermicro on‑prem |
|---|---|---|
| Масштаб моделей | 7B/13B доминируют, 70B используются редко | 70B+ присутствуют в большинстве проектов |
| Профиль нагрузки | Несколько отдельных обучений в год, долгие простои | Почти постоянное обучение, загрузка GPU > 70–80 % |
| Финансовая модель | Предпочтение Opex, гибкие ежемесячные расходы | Готовность инвестировать CAPEX ради 3‑летней предсказуемости |
| Локализация данных | Данные можно размещать у облачного провайдера в разрешённом регионе | Данные должны оставаться в российском ЦОДе по регуляторике |
| Команда и компетенции | Нет собственной инфраструктурной команды, ставка на DevOps «в облаке» | Есть операционная команда или готовность привлечь интегратора |
| Отношение к рискам санкций | Допустимы ограничения по квотам и тарифам облака | Критична 3–5‑летняя гарантированная доступность вычислительных ресурсов в России |
Как использовать эту статью в своём проекте
Если команда только выходит на траекторию LLM и работает в основном с 7B/13B, разумнее стартовать в облаке, зафиксировать реальные GPU‑часы и стоимость по прошедшим проектам, а затем сравнить эти данные с ценой одного‑двух Supermicro‑узлов на горизонте трёх лет.
Если же уже сейчас понятно, что 70B‑обучения будут идти регулярно и станут основой продуктовой стратегии, имеет смысл спланировать кластер Supermicro под on‑prem‑размещение и рассматривать облако как вспомогательный ресурс для PoC и кратковременных пиковых нагрузок.
