Локальная GPU-инфраструктура при 20 часах нагрузки

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

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

Двадцать часов не определяют победителя

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

Для первой оценки возьмите 20 часов в неделю, 52 недели и трехлетний горизонт. Получится 3120 часов полезной нагрузки. Это база, а не готовый объем для счета. Умножьте ее на коэффициент простоя облачного экземпляра. Если на каждый час вычислений приходится 15 минут подготовки и ожидания, оплачиваемое время равно 3900 часам. Затем добавьте одновременность: две задачи, которым нужен отдельный GPU в течение одного часа, дают два GPU-часа.

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

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

Сначала измерьте реальную нагрузку

Решение стоит принимать по телеметрии за четыре-восемь типичных недель, а не по заявкам команды. Запишите длительность процесса, занятость GPU, максимальный объем видеопамяти, объем прочитанных и записанных данных, число параллельных запусков и допустимое время ожидания. Отдельно отметьте подготовку данных и CPU-этапы: переносить их цену на GPU нельзя.

На локальном Linux-узле базовый срез дает команда:

nvidia-smi --query-gpu=timestamp,name,utilization.gpu,memory.used,memory.total,power.draw --format=csv -l 60

Ее вывод имеет такую форму:

timestamp, name, utilization.gpu [%], memory.used [MiB], memory.total [MiB], power.draw [W]
2026/07/28 10:00:00.000, GPU model, 87 %, 18432 MiB, 24576 MiB, 286.40 W

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

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

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

Полная цена локального узла больше ценника сервера

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

Рабочая формула выглядит так:

TCO_local = purchase + facility + energy + admin + maintenance + downtime + upgrades - residual_value

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

energy = average_system_kW × powered_hours × electricity_price × facility_factor

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

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

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

Облачный счет растет за пределами GPU-часа

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

TCO_cloud = instance_hours + storage + snapshots + egress + interzone + operations + support

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

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

Передача данных заслуживает отдельной модели. Входящий трафик нередко стоит мало или не тарифицируется, но обратная выгрузка результатов и регулярное перемещение наборов данных могут оплачиваться. Даже бесплатная передача занимает время. Один терабайт по каналу 100 Мбит/с в идеальных условиях идет около 22 часов; протокольные накладные расходы и конкурирующий трафик увеличат срок. Если каждую неделю отправлять изменившийся многотерабайтный набор, облачный GPU может ждать данные дольше, чем считать.

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

Один расчет показывает чувствительность решения

Рассмотрим условный проект, чтобы увидеть механику, а не получить универсальную цену. Все суммы ниже организация подставляет сама. Горизонт равен 36 месяцам, полезная нагрузка - 20 GPU-часов в неделю, облачный коэффициент оплачиваемого времени - 1,25, локальный сервер включен 60 часов в неделю. Требуется один ускоритель с достаточной памятью; производительность выбранных вариантов подтверждена одним и тем же тестом.

Заполните таблицу такими входными данными:

| Параметр | Локально | Облако | | Покупка и монтаж | L | 0 | | Оплачиваемые GPU-часы | 0 | 3900 | | Ставка за экземпляр | 0 | C | | Средняя мощность системы, кВт | P | 0 | | Часы под питанием | 9360 | 0 | | Электроэнергия за кВт·ч | E | 0 | | Хранилище и трафик | D_local | D_cloud | | Труд эксплуатации | A_local | A_cloud | | Остаточная стоимость | R | 0 |

Тогда упрощенные итоги равны:

local = L + (P × 9360 × E × facility_factor) + D_local + A_local - R
cloud = (3900 × C) + D_cloud + A_cloud

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

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

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

Конфиденциальность меняет допустимые варианты

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

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

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

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

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

Эксплуатация решает не меньше закупки

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

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

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

Заранее определите отказ. Для локального варианта это поломка ускорителя, диска, питания или охлаждения; для облака - отсутствие емкости, ошибка учетной записи, сетевой разрыв или остановка прерываемого экземпляра. Назначьте допустимое время восстановления и стоимость задержки. Если 20 часов относятся к редкому, но критическому недельному окну, средняя загрузка почти ничего не говорит о требуемой надежности.

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

Гибридная схема полезна только с ясной границей

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

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

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

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

До закупки запросите не один итоговый ценник, а разложение конфигурации. В нем должны быть модель и объем памяти каждого ускорителя, число доступных линий PCIe, память CPU, пропускная способность сети, тип и ресурс накопителей, мощность блоков питания, условия гарантии и срок замены. Два сервера с одинаковым GPU ведут себя по-разному, если один не успевает подавать данные или сохранять контрольные точки. Эта детализация также не дает незаметно сравнить локальный сервер, готовый к эксплуатации, с облачным экземпляром без долговременного диска и резервной копии.

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

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

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

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

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

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

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

Решение должно пройти пилот и финансовый порог

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

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

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

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