Сервер начинается с помещения, а не с видеокарты

Когда компания решает держать модель внутри своего контура, обсуждение часто начинается с объёма памяти GPU и скорости генерации. Но купленный сервер должен где-то стоять, получать питание, отдавать тепло, переживать кратковременные сбои и оставаться доступным сотрудникам без открытия доступа всему интернету. Если эти условия не проверены, «локальность» может обернуться простоями и ручной работой именно в тот момент, когда ИИ стал частью процесса.

Это не аргумент против собственного сервера. Он может быть разумным для конфиденциальных документов, устойчивой нагрузки и полного контроля над данными. Это аргумент за проверку площадки до закупки. В руководстве по энергоэффективным дата-центрам Министерство энергетики США рассматривает ИТ-нагрузку вместе с воздушными потоками, охлаждением и электроснабжением: отдельное устройство нельзя планировать в отрыве от помещения. Руководство NVIDIA по размещению DGX Station служит конкретным примером того, что производитель задаёт требования к питанию, вентиляции и окружающей среде. Значения из него не надо переносить на любую рабочую станцию: они относятся к указанной модели.

1. Сначала — профиль работы и допустимый простой

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

Разделите нагрузки: интерактивные запросы, пакетную индексацию RAG, распознавание документов и резервное копирование. Они могут конкурировать за память, диск, сеть и питание. Тест на одном пользователе с коротким запросом не показывает, как система поведёт себя при одновременном поиске по базе и ночной обработке PDF. Прежде чем выбирать сервер, замерьте хотя бы примерную пиковую и среднюю нагрузку на пилоте, а также целевое время ответа и допустимое время восстановления.

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

2. Питание: номинал блока не равен фактическому расходу

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

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

3. Тепло и воздух: киловатты остаются в комнате

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

Сделайте простой осмотр площадки:

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

Министерство энергетики США отдельно рассматривает воздушные потоки, охлаждение и электрические системы как связанные части проектирования. Для малого офиса это не означает строительство дата-центра. Это означает замерить условия и не ставить вычислительный узел в помещение, где его тепловая нагрузка не управляется.

4. Данные, сеть и доступ не становятся безопасными автоматически

Фраза «сервер стоит у нас» ничего не говорит о том, кто может открыть API модели, читать документы RAG и скачать резервную копию. Держите сервис во внутренней сети, ограничивайте доступ по ролям, отделяйте тестовые данные от рабочих, ведите журнал административных действий. Если приложение обращается к модели через шлюз, задайте там аутентификацию и квоты, а не рассчитывайте на секретность адреса сервера.

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

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

5. Считайте эксплуатацию, а не только коробку

Модельный расчёт, не рыночный тариф: если узел и связанные компоненты в среднем потребляют 1 кВт и работают непрерывно 30 дней, это 720 кВт·ч. При условной цене 8 ₽ за кВт·ч прямое электричество составит 5 760 ₽ за месяц. Здесь не учтены охлаждение, потери ИБП, сеть, аренда помещения, замена компонентов, обслуживание, простои и амортизация. Реальная мощность меняется с загрузкой; замер на вашей конфигурации важнее этого примера.

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

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

Проверка перед заказом

Попросите ИТ-ответственного и владельца процесса подписать короткий лист допусков:

1. Нагрузка и время ответа измерены на реальных задачах, включая пики и ночные партии.
2. Для конкретной конфигурации проверены питание, кабели, вентиляционные зазоры и температура.
3. ИБП выбран по подключённой нагрузке и требуемому времени завершения; отключение протестировано.
4. Известны владелец сервиса, схема доступа, резервные копии и процедура восстановления.
5. Есть сравнение полной цены операции и сценарий работы людей при отказе.

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